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
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) => TriagedAssignee: bugsquad => balcaen.johnSource RPM: (none) => kde
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
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 ?
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.
with the xguest user too ?
Oh one more thing, by fresh install you did keep your $HOME i guess ?
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/
(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.
Assignee: balcaen.john => bugsquad
Assignee: bugsquad => balcaen.john
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.
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 ?
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
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.
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
ok i can reproduce on fedora 15 (4.6.5) but also on cauldron. On OpenSuse systemsettings is crashing ... :)
comment added on upstream bug
Keywords: (none) => UPSTREAMSee Also: (none) => https://bugs.kde.org/show_bug.cgi?id=264200
*** Bug 3490 has been marked as a duplicate of this bug. ***
CC: (none) => jan-olof.eriksson
Hardware: x86_64 => AllSee Also: https://bugs.kde.org/show_bug.cgi?id=264200 => https://bugs.kde.org/show_bug.cgi?id=254430
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
*** Bug 7572 has been marked as a duplicate of this bug. ***
CC: (none) => stryder
(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.
(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 ?)
(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.
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 ?
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
Version: 1 => 2
Version: 2 => 3Whiteboard: (none) => MGA2TOO
*** Bug 11380 has been marked as a duplicate of this bug. ***
CC: (none) => bugzzzz
Solved upstream https://bugs.kde.org/show_bug.cgi?id=254430
Depends on: (none) => 14487
upstream patch added for mga3 in kdebase4-workspace-4.10.5-1.2.mga3 (bug#14487).
CC: (none) => lmenutSource RPM: kde => kdebase4-workspace-4.10.5Whiteboard: MGA2TOO => (none)
Just fixed in http://advisories.mageia.org/MGASA-2014-0445.html
So closing as fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED