Bug 3310 - System settings - Lost settings after enter in login screen menu
Summary: System settings - Lost settings after enter in login screen menu
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 3
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: John Balcaen
QA Contact:
URL:
Whiteboard:
Keywords: Triaged, UPSTREAM
: 3490 7572 11380 (view as bug list)
Depends on: 14487
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-10 19:49 CET by Dimitrios Glentadakis
Modified: 2014-11-16 23:57 CET (History)
6 users (show)

See Also:
Source RPM: kdebase4-workspace-4.10.5
CVE:
Status comment:


Attachments

Description Dimitrios Glentadakis 2011-11-10 19:49:44 CET
Description of problem:
After enter to login screen Menu in systemsettings i loose the settings:
- Window decoration
- Color settings
- Default browser
- Mouse double clic setting


Version-Release number of selected component (if applicable):
KDE 4.6.5

Video of the problem:
http://www.mandrivalinux.gr/dimitrios/KDE4_lost_settings.ogv 16.7 mb

Reported in mandriva bugzilla
https://qa.mandriva.com/show_bug.cgi?id=62300

Reported in KDE
https://bugs.kde.org/show_bug.cgi?id=264200
Comment 1 Manuel Hiebel 2011-11-11 00:25:02 CET
Hi, thanks for reporting this bug.
Assigned to the package maintainer.
(I don't know witch package it is sorry)

P.S, for the next time, better is to show us videos, logs, screenshots, in English. To do that, you just need to launch the apps with LC_ALL=C before in a terminal ;)

Keywords: (none) => Triaged
Assignee: bugsquad => balcaen.john
Source RPM: (none) => kde

Comment 2 John Balcaen 2011-11-11 01:12:09 CET
I can't reproduce here.
Could you try with a fresh user especially the xguest user ?
How did you install this mageia ?
Fresh install ? upgrade from mandriva ?
I noticed some MIB related theme, did you install some packages from MIB ?

CC: (none) => balcaen.john

Comment 3 John Balcaen 2011-11-11 01:21:41 CET
Hum this video is the same *as* the one in the kde's bugzilla which was against kde 4.5.5.
Did you test on 4.6.5 ?
Comment 4 Dimitrios Glentadakis 2011-11-11 01:46:47 CET
yes the video is old , i used it to avoid make a new one
now i have a fresh install of mageia with kde 4.6.5 and the bug is always reproducible.
Comment 5 John Balcaen 2011-11-11 02:10:21 CET
with the xguest user too ?
Comment 6 John Balcaen 2011-11-11 02:24:42 CET
Oh one more thing, by fresh install you did keep your $HOME i guess ?
Comment 7 Dimitrios Glentadakis 2011-11-11 03:14:14 CET
i tried with a new user and it is reproducible
i dont have a xguest user, can i create one ?
if i remember well is a new home/ but certainly i brought files from the initial home/
Comment 8 John Balcaen 2011-11-11 09:20:45 CET
(In reply to comment #7)
> i tried with a new user and it is reproducible
There's definitly a problem here because i should be able to reproduce & i can't :/

> i dont have a xguest user, can i create one ?
You need to install the xguest rpm.
Once it's installed you'll have a new user availble in your kdm login screen, where you can simply click yo be able to log in (without pass)

> if i remember well is a new home/ but certainly i brought files from the
> initial home/
I was thinking that the problem may be related to some specific kde's configuration which could be explain eventually from a « broken » kde's config.
John Balcaen 2011-11-11 16:33:13 CET

Assignee: balcaen.john => bugsquad

John Balcaen 2011-11-11 16:33:39 CET

Assignee: bugsquad => balcaen.john

Comment 9 Dimitrios Glentadakis 2011-11-13 17:43:03 CET
I installed the xguest rpm and i can reproduce it, i also tried from the laptop of my wife (32 bit) and i can reproduce it from there too.
Comment 10 John Balcaen 2011-11-13 18:01:53 CET
And you did choose the xguest user to log in ?
Because i'm definitly not able to reproduce anything here with the xguest user on a fully up to date mageia 1 on x86_64 neither on my i586 netbook with here again a fully up to date mageia 1.
Since i'm not able to reproduce it with the xguest user & since xguest user is working on tmpfs i'm not able to understand at all your problem (& even more how to fix it) aka when saving a configuration for example kwinoptions or plasma theme or police or keyboard settings or mouse settings or  anything else available in systemsettings, it's really save another launch of systemsettings does not show « old » settings aka iaora-kde etc etc.
You did check that your $HOME or other partition are not mount as read only (though this should not affect at all the xguest user ), you did not use chattr +i on some configuration files ?
You do not have any warning/errors available in ~/.xsession-errors ?
Comment 11 Dimitrios Glentadakis 2011-11-13 18:57:12 CET
I dont have make any additional setting, actually to reproduce it the steps are exactly these:

From systemsettings:
1) Change the window decoration setting to oxygen
2) Change the Colors of KDE apps to Oxygen
3) Change the window style to Oxygen
4) Change the default browser to konqueror
5) Change the mouse clic behaviour setting from double clic to Simple clic
6) Go to Login Screen in System Administration in System Settings
7) Clic on some tabs, without change any settings
8) Quit System Settings
9) Open again §System Settings

You see that you are switched to the follows -and system default- settings:

- Windows decoration to laOra
- System Colors to laOra Night (or blue i am not sure)
- Windows style to laOra-kde
- Default browser to firefox
- Mouse clic behaviour to double clic
Comment 12 John Balcaen 2011-11-13 19:11:17 CET
ok.
in fact you don't have to follow all this procedure.
The fact of entering in login screen reset the colors/widget style/ to the default's settings
Seems like i miss the « After enter to login screen Menu » in the first comment :/
I'll check to see if i'm able to reproduce on cauldron & suse/fedora.
But i suspect an upstream bug here.
Comment 13 Dimitrios Glentadakis 2011-11-13 19:33:36 CET
ah ok !
i reported in upstream and now the report is closed. They wait a developer of my distribution to confirm if it is a KDE problem to reopen it:

https://bugs.kde.org/show_bug.cgi?id=264200
Comment 14 John Balcaen 2011-11-13 19:51:45 CET
ok i can reproduce on fedora 15 (4.6.5) but also on cauldron.
On OpenSuse systemsettings is crashing ... :)
Comment 15 John Balcaen 2011-11-13 19:59:48 CET
comment added on upstream bug

Keywords: (none) => UPSTREAM
See Also: (none) => https://bugs.kde.org/show_bug.cgi?id=264200

Comment 16 John Balcaen 2011-11-28 05:59:24 CET
*** Bug 3490 has been marked as a duplicate of this bug. ***

CC: (none) => jan-olof.eriksson

John Balcaen 2012-01-11 20:00:07 CET

Hardware: x86_64 => All
See Also: https://bugs.kde.org/show_bug.cgi?id=264200 => https://bugs.kde.org/show_bug.cgi?id=254430

Comment 17 annemarie victor 2012-02-20 13:43:27 CET
I loose my setting and even my bookmarks when I open a new session. It's a new bug since three ou four days.

CC: (none) => annemarievictor

Comment 18 John Balcaen 2012-09-27 01:10:23 CEST
*** Bug 7572 has been marked as a duplicate of this bug. ***

CC: (none) => stryder

Comment 19 Aragorn Son of Arathorn 2012-09-27 17:27:42 CEST
(In reply to comment #18)
> *** Bug 7572 has been marked as a duplicate of this bug. ***

John,

The bug has reported here does indeed cover some of the same things I have reported in bug 7572 and is undoubtedly caused by the same thing.  However, I feel that I have to point out that this is not just a matter of lost settings.  It IS a matter of privilege escalation, testimonial of which are...

(a) the fact that there appears a root-owned dbus session file in ~/.dbus/session-bus/;
    and

(b) something which I forgot to mention in my original report, which is that although I
    have set my security settings so that an unprivileged user cannot shutdown or reboot
    the system, after the events I have reported in bug 7572 and the steps described by
    Dimitrios in comment #11 higher up, I could shutdown/reboot the system from a KDE
    session in another unprivileged user account, i.e. not the account under which this
    perusing of the System Administration tab in System Settings had occurred.

This other unprivileged account has not been customized - unlike my primary user account - so that the shutdown and reboot options would not be shown anymore in the KDE logout menu, and when I try to shut the machine down or reboot from that account using those options, that normally only logs me out of KDE and drops me back to the character mode console from where I logged in and started X11/KDE - which is exactly as it should be, because I have disallowed shutdown and reboot to unprivileged users via both the MCC (msec) and the files in /etc/pam.d.  

However, after having visited the System Administration tab in System Settings under my FIRST account, I was able to reboot the machine from the SECOND account, without that any password was asked for.  And likewise, before rebooting the machine from that second account, I checked the Power Management settings in that account, and there too there were no named power profiles in the list, and the user changes to the "current" profile did not stick.

So clearly, visiting the System Administration section in System Settings - without even changing something, as Dimitrios has also pointed out - as an unprivileged user escalates the privileges for ALL user accounts.

I felt that it is important to take notice of this.  It's not a mere loss of settings.  Someone who visits the System Administration tab of the KDE System Settings will automatically become root from there on.  That's a serious escalation problem, because one can wonder under whose EID any process started by that user after this visit will then be running.
Comment 20 John Balcaen 2012-09-29 12:14:48 CEST
(In reply to comment #19)
[...]


Well i never noticed the root-owned dbus session file in my $HOME :/
Can you report it upstream ? (& eventually test it on others distributions too ?)
Comment 21 Aragorn Son of Arathorn 2012-09-29 19:38:46 CEST
(In reply to comment #20)
> (In reply to comment #19)
> [...]
> 
> 
> Well i never noticed the root-owned dbus session file in my $HOME :/
> Can you report it upstream ? (& eventually test it on others distributions too
> ?)

Uh, I don't wish to sound lame, John, but I have no idea how to contact the people upstream as I'm not even subscribed to any bugzillas or other bug report systems other than here for Mageia, and I wouldn't even know where to start.

I'd feel more comfortable if one of you guys would report this upstream, because after all, you guys are developers and package wranglers, and you guys know the way, so your input upstream will most definitely be appreciated/respected more than that of a simple user somewhere.

I also can't test it on other distributions as I only have Mageia 1 here, plus a very old PCLinuxOS 32-bit on a hard disk that came from a broken machine and is now in this one as a fall-back.  I do however gather that the problem will be the same in the other distros mentioned here - or in the original bug report, I forgot - among which I seem to remember Fedora having been mentioned.

Related or not, all I can add is that the problem with a /.config directory - i.e. in the root directory itself - is also present in all other distributions, ranging from openSUSE over Debian to Slackware and beyond, and that this has been reported upstream, and that it so far has also been ignored.
Comment 22 Dimitrios Glentadakis 2012-09-30 06:03:31 CEST
I repeated the steps, i reproduce the bug but i don't find any file in ~/.dbus/session-bus/ belonged to root. I missed something ?
Comment 23 Manuel Hiebel 2012-11-05 16:51:43 CET
This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad
Dimitrios Glentadakis 2012-11-06 12:17:55 CET

Version: 1 => 2

Manuel Hiebel 2013-08-30 22:33:17 CEST

Version: 2 => 3
Whiteboard: (none) => MGA2TOO

Comment 24 Dimitrios Glentadakis 2013-10-10 12:32:24 CEST
*** Bug 11380 has been marked as a duplicate of this bug. ***

CC: (none) => bugzzzz

Comment 25 Dimitrios Glentadakis 2013-11-02 16:28:44 CET
Solved upstream
https://bugs.kde.org/show_bug.cgi?id=254430
Luc Menut 2014-11-08 13:04:14 CET

Depends on: (none) => 14487

Comment 26 Luc Menut 2014-11-08 13:24:17 CET
upstream patch added for mga3 in kdebase4-workspace-4.10.5-1.2.mga3 (bug#14487).

CC: (none) => lmenut
Source RPM: kde => kdebase4-workspace-4.10.5
Whiteboard: MGA2TOO => (none)

Comment 27 Luc Menut 2014-11-14 09:08:28 CET
Just fixed in http://advisories.mageia.org/MGASA-2014-0445.html
Comment 28 Luc Menut 2014-11-16 23:57:02 CET
So closing as fixed

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.