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

[Linas Vepstas]

On Thu, Sep 15, 2016 at 6:45 AM, Vlad Orlov  wrote:
>
>
> Is su actually used for running graphical apps?


In my case, I either accidentally typed into an su window, or possibly ran
the gconf editor as root, for some possibly good or bad reason, possibly
having to do with xdm, gdm whateverdm, or possibly some intentional or
unintentional debugging of audio or video playback. This is the "shit
happens" category, and based on the rate of reports streaming in, "shit
happens" every now and then for everyone. If it happened a lot, the problem
would be fixed. If it happened very rarely, there would be no heat.

>
> There's also this problem... no one still volunteered to actually help
> fixing
> su or gksu/libgksu.
>

 "fixing" su could have very long-running reprecussions: it is a
40-year-old utility, and I know for a fact that there are people out there
who run 40-year-old shell scripts (I have a friend who works at a company
that specializes in porting ancient, undocumented code to modern systems.)
 If you "fix" it, the various vendors (red-hat, ubuntu, debian) will very
slowly start accumulating bug reports related to the change. These reports
will arrive at the rate of a few a year, for a decade (similar to the rate
of reporting on this bug-- which is now 3-4 years old, and gets a new
complaint every now and then). The knee-jerk reaction will be to undo
whatever the "fixes" were. So the volunteer needs to not only fix the
problem, update the man page, etc. but then be persistent for many years.
That's hard.

--linas

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

[Vlad Orlov]

Hi,

Just found a link to a pam module [1] (posted in the comment at [2]).

> It's a pam module that removes the XDG_RUNTIME_DIR environment variable from
> the environment if the user authenticating is different from the user owning
> it.  This is for the case of programs like gksu clobbering the users' dconf
> settings.

I don't know if this would be an acceptable workaround for this problem.
Can you please give your opinion on it?


[1] https://github.com/sbalneav/libpam-envclean
[2] 
https://github.com/mate-desktop/mate-settings-daemon/issues/44#issuecomment-247147445

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

[Vlad Orlov]

Hi,

Is su actually used for running graphical apps? Most people seem to use gksu
for that. But gksu --help shows a weird warning about using -l argument:

  --login, -l
Make this a login shell. Beware this may cause
problems with the Xauthority magic. Run xhost
to allow the target user to open windows on your
display!

Hmm, what? Some easily-broken magic? Isn't gksu supposed to handle stuff like
that automatically? :)

There's also this problem... no one still volunteered to actually help fixing
su or gksu/libgksu.

What's the status of gksu and libgksu anyway? I see no new upstream releases
since 2009, and upstream bug tracker seems to be completely abandoned.

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
>

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

[Michael Biebl]

CCing the login maintainer, maybe he has some input on this matter.


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
> 


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[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

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

[Vlad Orlov]

Hi,


> 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

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

[Michael Biebl]

Am 14.04.2016 um 17:57 schrieb Michael Biebl:
> Am 14.04.2016 um 17:47 schrieb 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.
> 
> To summarize: The issue happens if you run
> su 
> gksu 
> because it doesn't clear the environment.
> 
> If you use
> su -l  (or su - )
> gksu -l 
> 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".

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.
That said, this issue needs to be addressed at the su/gksu level anyway
afaics.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Michael Biebl]

Am 14.04.2016 um 17:47 schrieb 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.

To summarize: The issue happens if you run
su 
gksu 
because it doesn't clear the environment.

If you use
su -l  (or su - )
gksu -l 
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".




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[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.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Michael Biebl]

Am 14.04.2016 um 17:00 schrieb Michael Biebl:
> On Wed, 26 Nov 2014 15:39:15 +0300 =?UTF-8?B?VmxhZCBPcmxvdg==?=
>  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.

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).



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Vlad Orlov]

Hi,

 BTW, this only happens with GNOME sessions. With other window managers
 (e.g. LXDE, Openbox) it does *not*. Therefore, I do not think it's a
 systemd bug, rather it's related to GNOME. Do you agree to reassign this
 bug against either the 'gnome-session' or the 'gnome-shell' package?

No, I don't agree. I can reproduce it 100% in MATE desktop environment and
also in Cinnamon, see [1]. I'm actually thinking of merging that bug report with
this one.

Please read the comments from Linas Vepstas there, they confirm that it's not
a desktop environment or a text editor itself that causes it. Also, systemd had
been messing up the ownership of /run/user/1000/dconf/user in the past, see [2].


[1] https://bugs.debian.org/766464
[2] https://bugs.debian.org/731300

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

[Vlad Orlov]

Hi,

I just decided to nofity all the participants here, in case
this new info might be interesting or useful  :)

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

[Vlad Orlov]

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).

See also another bug report [2] about the similar issue.


[1] https://bugs.debian.org/731300
[2] https://bugs.debian.org/766464

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

[Crowley, Stephen]

Curious, why am I  being CC'ed on ths? Not that I am upset about anything... 
also, hi Linas, long time no chat, is this some attempt to get me back as an 
active member of the Debian project? :)

--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.

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).

See also another bug report [2] about the similar issue.


[1] https://bugs.debian.org/731300
[2] https://bugs.debian.org/766464


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org