Created attachment 4500 [details] this patch forces root to use its own homedir (.config/dconf) On Mate Desktop, whenever an application which uses dconf runs as root and logout/login, screen filled up infinite caja windows named x-caja.desktop and system locks up. Problem is su invades ownership of /run/user/1000/dconf/user, makes owner and group as root; dconf can not access that runtime configuration and modify it. So, mate-session tries to reload caja indefinetly until system locks up. There have been reports about this very similiar issue on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=956306 https://bugzilla.redhat.com/show_bug.cgi?id=753882 It seems it is a common issue for every dconf dependend application like gnome-shell and whole Mate desktop. This issue is critical. While we can not prevent users, most of them do this, running a graphical application as root; we should find a workaround this. There is a proposed patch to dconf here (also i'm attaching this bug report): https://bugzilla.redhat.com/attachment.cgi?id=788786&action=diff This patch simply it tests if dconf used by root and forces root to use its own home dir "/root". It is not an ideal workaround but it works. I have tested this without issues. This bug is already present in both Cauldron and Mageia 3 How reproducible: Run a dconf using app as root. Logout and login. See what happens... Steps to Reproduce: 1. In Mate desktop run gksu pluma from commandline 2. Logout and log back in 3. See indefinite x-caja.desktop windows until cpu usage hits 100%
The patch only solves one of the side effects of this problem, but really the consequences go far, far deeper than dconf - e.g. run mc and see root owned files in your home dir. I would actually argue that this patch is broken as it changes XDG usage behaviour for one particular user. For this reason I expect Matthias to reject the patch in dconf and thus we'd have to carry it as a downstream. As this is just papering over the cracks of the problem rather than solving it, I'd personally rather not include it, but my vote is certainly not final in that regard. Pragmatism may dictate it's better to include it until some better design can come along. The fundamental fact remains however, that using something like su to run GUI apps (or even any apps that use sufficiently high level libs) is just a broken concept by design. All su does is change the uid. It's basically a wrapper around a ioctl and nothing will change that fact. A modern desktop is just not designed to run tools like that as root and the more we can do to discourage users from doing this the better. IMO our efforts would be better spent making it as awkward as possible (or even totally impossible) to use su in this way. Again that's just my opinion. I'll watch the RH bug and see what Matthias' reaction is.
CC: (none) => mageia
(In reply to Colin Guthrie from comment #1) You' re compeletly right. Because of this i called this patch as workaround not a fix. But we need to fix or workaround this issue before Mageia 4 release. I think until a fix issued we should use this patch to avoid this bug.
Created attachment 4514 [details] Reviewed dconfsu patch While i'm not a programmer/coder i tried to revise the dconfsu patch to not leaky. I hope i made things right.
Attachment 4500 is obsolete: 0 => 1
Hi! As mentioned on the list, this is a step in the right direction :) Two main points: 1. the outer if statement should have { } surrounding the inner one (this is not a bug but it aids clarity of reading - especially if indentation were to change). 2. "if (getuid != 0)" should be "if (getuid() != 0)" otherwise the patch has no effect and doesn't solve anything :) Good work so far tho'. Keep it up!
(In reply to Colin Guthrie from comment #4) Thank you Colin, i have modified the patch as suggested and committed to both Cauldron and Mga3/Updates. Requested push. For now i think this bug report should remain open, while we workaround the bug there is no real fix. Until it is fixed in su or pam...
Colin, do you have any progress on this? We still use patched dconf...
It is almost 2 years since last comment. Is the issue fixed?
CC: (none) => nic
Assignee: bugsquad => pkg-bugs
We still use patched dconf but main issue seems fixed.But not a clean and nice way. Anyways, closing this bug report.
Status: NEW => RESOLVEDResolution: (none) => FIXED
CC: (none) => ankiesaini147