Processed: Re: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.

[Debian Bug Tracking System]

reassign 732209 libpam-systemd 215-6

Bug #732209 [gnome-control-center] (gnome-control-center:11187): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.
Bug reassigned from package 'gnome-control-center' to 'libpam-systemd'.
No longer marked as found in versions gnome-control-center/1:3.14.1-1 and gnome-control-center/1:3.8.3-4.
Ignoring request to alter fixed versions of bug #732209 to the same values previously set
Bug #732209 [libpam-systemd] (gnome-control-center:11187): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.
Marked as found in versions systemd/215-6.

thanks

Stopping processing here.

Please contact me if you need assistance.

[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 [***@inbox.ru]
Sent: Wednesday, November 26, 2014 6:39 AM
To: ***@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

[Vlad Orlov]

Hi,

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

[Michael Biebl]

On Wed, 26 Nov 2014 15:39:15 +0300 =?UTF-8?B?VmxhZCBPcmxvdg==?=

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.

Regards,
Michael

[Michael Biebl]

Post by Michael Biebl
On Wed, 26 Nov 2014 15:39:15 +0300 =?UTF-8?B?VmxhZCBPcmxvdg==?=

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

[Michael Biebl]

Post by Michael Biebl
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.

[Michael Biebl]

Post by Michael Biebl

Post by Michael Biebl
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 <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]

Post by Michael Biebl

Post by Michael Biebl

Post by Michael Biebl
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 <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".

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.

[Vlad Orlov]

Hi,

Post by Michael Biebl
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.

Post by Michael Biebl
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.

Post by Michael Biebl
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]

Control: tag -1 -moreinfo -unreproducible +wontfix

Post by Vlad Orlov
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.

Post by Vlad Orlov
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.

Post by Vlad Orlov
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

[Debian Bug Tracking System]

Post by Martin Pitt
tag -1 -moreinfo -unreproducible +wontfix

Bug #732209 [libpam-systemd] unable to create file '/run/user/1000/dconf/user': Permission denied
Bug #766464 [libpam-systemd] gksu pluma <any_file> sets the ownership of /run/user/1000/dconf/user to root:root
Bug #767173 [libpam-systemd] gnome-shell: Display freezes but mouse stays operational
Bug #769889 [libpam-systemd] dconf-CRITICAL: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
Bug #772910 [libpam-systemd] mate-settings-daemon: Massive memory leak
Bug #807878 [libpam-systemd] gnome: Gnome freezes when root windows are open on user screen.
Bug #818600 [libpam-systemd] mate-settings-daemon cannot create file /run/user/<UID>/dconf/user and fills up the memory (24 GB!)
Bug #818601 [libpam-systemd] mate-settings-daemon cannot create file /run/user/<UID>/dconf/user and fills up the memory (24 GB!)
Bug #824950 [libpam-systemd] systemd: pam_systemd should not use loginuid (at least not when used by su)
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
Bug #732209 [libpam-systemd] unable to create file '/run/user/1000/dconf/user': Permission denied
Bug #766464 [libpam-systemd] gksu pluma <any_file> sets the ownership of /run/user/1000/dconf/user to root:root
Bug #767173 [libpam-systemd] gnome-shell: Display freezes but mouse stays operational
Bug #769889 [libpam-systemd] dconf-CRITICAL: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
Bug #772910 [libpam-systemd] mate-settings-daemon: Massive memory leak
Bug #807878 [libpam-systemd] gnome: Gnome freezes when root windows are open on user screen.
Bug #818600 [libpam-systemd] mate-settings-daemon cannot create file /run/user/<UID>/dconf/user and fills up the memory (24 GB!)
Bug #818601 [libpam-systemd] mate-settings-daemon cannot create file /run/user/<UID>/dconf/user and fills up the memory (24 GB!)
Bug #824950 [libpam-systemd] systemd: pam_systemd should not use loginuid (at least not when used by su)
Removed tag(s) unreproducible.
Removed tag(s) unreproducible.
Removed tag(s) unreproducible.
Removed tag(s) unreproducible.
Removed tag(s) unreproducible.
Removed tag(s) unreproducible.
Removed tag(s) unreproducible.
Removed tag(s) unreproducible.
Removed tag(s) unreproducible.
Bug #732209 [libpam-systemd] unable to create file '/run/user/1000/dconf/user': Permission denied
Bug #766464 [libpam-systemd] gksu pluma <any_file> sets the ownership of /run/user/1000/dconf/user to root:root
Bug #767173 [libpam-systemd] gnome-shell: Display freezes but mouse stays operational
Bug #769889 [libpam-systemd] dconf-CRITICAL: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
Bug #772910 [libpam-systemd] mate-settings-daemon: Massive memory leak
Bug #807878 [libpam-systemd] gnome: Gnome freezes when root windows are open on user screen.
Bug #818600 [libpam-systemd] mate-settings-daemon cannot create file /run/user/<UID>/dconf/user and fills up the memory (24 GB!)
Bug #818601 [libpam-systemd] mate-settings-daemon cannot create file /run/user/<UID>/dconf/user and fills up the memory (24 GB!)
Bug #824950 [libpam-systemd] systemd: pam_systemd should not use loginuid (at least not when used by su)
Added tag(s) wontfix.
Added tag(s) wontfix.
Added tag(s) wontfix.
Added tag(s) wontfix.
Added tag(s) wontfix.
Added tag(s) wontfix.
Added tag(s) wontfix.
Added tag(s) wontfix.
Added tag(s) wontfix.
--
732209: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732209
766464: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464
767173: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767173
769889: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769889
772910: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772910
807878: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807878
818600: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818600
818601: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818601
824950: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824950
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems

[Michael Biebl]

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

Post by Martin Pitt
Control: tag -1 -moreinfo -unreproducible +wontfix

Post by Vlad Orlov
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.

Post by Vlad Orlov
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.

Post by Vlad Orlov
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