Bug#732209: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.
linasvepstas at gmail.com
Fri Sep 9 20:09:05 BST 2016
The suggestion below, that the core issue is that "su" is leaking the
user-space env variables into the root shell, where they are then used to
clobber the user-space, seems like a good root-cause analysis of the bug.
I agree, it seems like "su" needs to be fixed.
I the meanwhile, can we get a work-around? There are 8 bugs duped to this
one in Debian; there are several dupes in redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=753882 as well as Linux Mint:
https://github.com/mate-desktop/mate-settings-daemon/issues/44 and dozens
of help forums discuss this.
This has been biting untold zillions of people for 3-4-5 years now, and the
fix-process is stalled due to finger-pointing. Yes, the right fix seems to
be to fix "su", but in the meanwhile... something?
The current Linux Mint work-around is here:
Am 10.06.2016 um 16:03 schrieb Martin Pitt:
> Control: tag -1 -moreinfo -unreproducible +wontfix
> Vlad Orlov [2016-04-20 17:00 +0300]:
>> You can check  to get some info about libpam-systemd doing
>> something wrong here.
>>  https://bugzilla.redhat.com/show_bug.cgi?id=753882
> This was fixed up to the extent possible in
> https://github.com/systemd/systemd/commit/baae0358f, i. e. 2.5 years
>> Also we had this issue for months in Linux Mint before Clement Lefebvre
>> made a patch  that fixed it. After the patched libpam-systemd had been
>> released for Mint, the problem was gone. That was it. No patching gksu,
>> no patching dconf.
> That's a very optimistic. Sure, we could (partially) clean up after
> su's brokenness forever, but (1) this makes the fundamental problem
> only a bit smaller, but not go away, and (2) we would then have to
> maintain this wrong patch forever and taking the blame for it instead
> of fixing it at the root cause.
> The problem is not "gone" in any sense of the word -- which of the
> leaked environment variables do you want libpam-systemd to unset in
> su's stead? XDG_RUNTIME_DIR? DBUS_SESSION_BUS_ADDRESS?
> DESKTOP_SESSION? MAIL? XDG_CONFIG_DIRS? SSH_AUTH_SOCK? GPG_AGENT_INFO?
> The fundamental problem is that it's not at all defined what "su"
> without -l actually wants to be: Switching to a different user like a
> suid program? Then you need the *entire* environment and not change a
> few selected variables like $HOME only. Or be like "login"? Then you
> need to clean the env like su -l or sudo. Both of the latter have
> well-defined behaviour, whereas the current "su" has no conceptual or
> consistent (or safe) behaviour at all.
>> Ok, so maybe it's time to remove 'moreinfo' and 'unreproducible' tags?
> Yes, I agree about that. But libpam-systemd is still neither the
> correct nor even a possible place to fix this.
> AFAICS, the behaviour of "su" without -l either needs to be properly
> defined and fixed, or it should be completely deprecated, perhaps
> making it do the same thing as -l.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pkg-systemd-maintainers