Bug 11643 - dconf can not access to /run/user/1000/dconf/user
Summary: dconf can not access to /run/user/1000/dconf/user
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: All Packagers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-11 14:44 CET by Atilla ÖNTAŞ
Modified: 2019-04-04 13:12 CEST (History)
3 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
this patch forces root to use its own homedir (.config/dconf) (898 bytes, patch)
2013-11-11 14:44 CET, Atilla ÖNTAŞ
Details | Diff
Reviewed dconfsu patch (850 bytes, patch)
2013-11-17 15:33 CET, Atilla ÖNTAŞ
Details | Diff

Description Atilla ÖNTAŞ 2013-11-11 14:44:47 CET
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%
Comment 1 Colin Guthrie 2013-11-11 19:28:51 CET
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

Comment 2 Atilla ÖNTAŞ 2013-11-11 22:45:26 CET
(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.
Comment 3 Atilla ÖNTAŞ 2013-11-17 15:33:14 CET
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

Comment 4 Colin Guthrie 2013-11-17 19:22:34 CET
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!
Comment 5 Atilla ÖNTAŞ 2013-11-19 06:40:46 CET
(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...
Comment 6 Atilla ÖNTAŞ 2014-02-07 09:48:19 CET
Colin, do you have any progress on this? We still use patched dconf...
Comment 7 Nic Baxter 2016-01-24 12:25:52 CET
It is almost 2 years since last comment. Is the issue fixed?

CC: (none) => nic

Samuel Verschelde 2016-10-16 15:28:22 CEST

Assignee: bugsquad => pkg-bugs

Comment 8 Atilla ÖNTAŞ 2017-01-16 22:57:50 CET
We still use patched dconf but main issue seems fixed.But not a clean and nice way. Anyways, closing this bug report.

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

ankit saini 2019-04-04 12:04:00 CEST

CC: (none) => ankiesaini147


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