Bug#732209: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.
Vlad Orlov
thanks
Hi,
Messing with /run/user/1000/dconf/user ownership seems to be the work
of libpam-systemd - somewhat similar things had been happening before,
as reported in [1] (and the merged reports).
See also another bug report [2] about the similar issue.
[1] https://bugs.debian.org/731300
[2] https://bugs.debian.org/766464
Crowley, Stephen
--Stephen
________________________________________
From: Vlad Orlov [mon...@inbox.ru]
Sent: Wednesday, November 26, 2014 6:39 AM
To: 732...@bugs.debian.org; control
Cc: Miklos Quartus; Crowley, Stephen
Subject: Re: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.
Hi,
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vlad Orlov
I just decided to nofity all the participants here, in case
this new info might be interesting or useful :)
Michael Biebl
<mon...@inbox.ru> wrote:
> reassign 732209 libpam-systemd 215-6
> thanks
>
>
> Hi,
>
> Messing with /run/user/1000/dconf/user ownership seems to be the work
> of libpam-systemd - somewhat similar things had been happening before,
> as reported in [1] (and the merged reports).
In all cases I read so far, the user was using gksu or su "without -".
So the environment is not cleared and the
XDG_RUNTIME_DIR environment still points to the one from the calling user.
As soon as a dconf-using program is started, this will change the
permissions of the dconf db (as expected).
The user should use "su -" and gksu should make sure to clear the
environment.
Afaics, there is not to fix on the libpam-systemd/systemd side here.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
> On Wed, 26 Nov 2014 15:39:15 +0300 =?UTF-8?B?VmxhZCBPcmxvdg==?=
> <mon...@inbox.ru> wrote:
>> reassign 732209 libpam-systemd 215-6
>> thanks
>>
>>
>> Hi,
>>
>> Messing with /run/user/1000/dconf/user ownership seems to be the work
>> of libpam-systemd - somewhat similar things had been happening before,
>> as reported in [1] (and the merged reports).
>
> I'm not convinced it is libpam-systemd which is responsible here.
>
> In all cases I read so far, the user was using gksu or su "without -".
> So the environment is not cleared and the
> XDG_RUNTIME_DIR environment still points to the one from the calling user.
>
> As soon as a dconf-using program is started, this will change the
> permissions of the dconf db (as expected).
>
> The user should use "su -" and gksu should make sure to clear the
> environment.
>
> Afaics, there is not to fix on the libpam-systemd/systemd side here.
Open a shell
unset XDG_RUNTIME_DIR
gksu xterm
→ XDG_RUNTIME_DIR won't be set
I studied the su man page and it resets
$HOME, $SHELL, $USER, $LOGNAME, $PATH, and $IFS
Contrary to sudo, which by default clears the environment (or pkexec).
Michael Biebl
> To verify that point:
> Open a shell
> unset XDG_RUNTIME_DIR
> gksu xterm
> → XDG_RUNTIME_DIR won't be set
>
> I studied the su man page and it resets
> $HOME, $SHELL, $USER, $LOGNAME, $PATH, and $IFS
> Contrary to sudo, which by default clears the environment (or pkexec).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794972
Contrary to what's been mentioned in the bug report, I can not confirm
that "su" resets XDG_RUNTIME_DIR in Debian.
Michael Biebl
> Am 14.04.2016 um 17:34 schrieb Michael Biebl:
>
>> To verify that point:
>> Open a shell
>> unset XDG_RUNTIME_DIR
>> gksu xterm
>> → XDG_RUNTIME_DIR won't be set
>>
>> I studied the su man page and it resets
>> $HOME, $SHELL, $USER, $LOGNAME, $PATH, and $IFS
>> Contrary to sudo, which by default clears the environment (or pkexec).
>
> Found this
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794972
>
> Contrary to what's been mentioned in the bug report, I can not confirm
> that "su" resets XDG_RUNTIME_DIR in Debian.
su <command>
gksu <command>
because it doesn't clear the environment.
If you use
su -l <command> (or su - <command>)
gksu -l <command>
you get a login-like session with the environment reset.
So, if you insist on using su or gksu to run X/GNOME applications (which
is imho not a good idea), I would suggest that you use it only in
combination with "-l".
Michael Biebl
The only difference is, that gnome shell doesn't lock up anymore because
of that. If that is due to a change dconf or gnome-shell, I haven't
investigated.
That said, this issue needs to be addressed at the su/gksu level anyway
afaics.
Vlad Orlov
> I'm not convinced it is libpam-systemd which is responsible here.
You can check [1] to get some info about libpam-systemd doing
something wrong here.
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.
> So, if you insist on using su or gksu to run X/GNOME applications (which
> is imho not a good idea), I would suggest that you use it only in
> combination with "-l".
Well, that seems to work for me (I'm using MATE though - but it's affected by
the issue as well). But it's not a complete solution. Some apps are meant to
be run via gksu and have gksu without '-l' in their .desktop files. For example,
some of the reporters simply launched a root terminal and then ran some apps
in it. The .desktop file for launching that root terminal is shipped with gksu
itself and has no '-l' in it. Even if you tell users to remember to always run apps
manually with gksu (instead of using root terminal) and always specify '-l', they
might easily forget about that.
I heard several times it's not a good idea to use gksu, but no one suggested
a good, complete replacement for it. The current situation is that we have to use
it sometimes. A few apps like Synaptic or GParted have pkexec support, others
don't have it and we use gksu with them.
> In unstable, this problem still persists (obviously).
> The only difference is, that gnome shell doesn't lock up anymore because
> of that. If that is due to a change dconf or gnome-shell, I haven't
> investigated.
Ok, so maybe it's time to remove 'moreinfo' and 'unreproducible' tags?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=753882
[2] https://github.com/linuxmint/systemd-betsy/commit/f7ab85f1e1169ac1598dfc1fba1c01063840b3c5.patch
Martin Pitt
Vlad Orlov [2016-04-20 17:00 +0300]:
> something wrong here.
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.
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?
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
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)