Bug#732209: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.

[Linas Vepstas]

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:
https://github.com/linuxmint/systemd-betsy/commit/f7ab85f1e1169ac1598dfc1fba1c01063840b3c5

--linas

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 [1] to get some info about libpam-systemd doing
>> something wrong here.
>> [1] 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
> ago.
>
>> Also we had this issue for months in Linux Mint before Clement Lefebvre
>> made a patch [2] 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.
>
> Thanks,
>
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20160909/632a5afa/attachment.html>