/run/user/$ID/pulse owned by root and not by the user

[Davide Depau]

I'm experiencing this problem with Ubuntu Saucy. Some times, when I start a media player (I use Musique), it freezes, as it finds that it cannot write into /run/user/$ID/pulse.
If I change the owner of that directory to me, the media player starts as usual and is able to play music.
I've never had this problem with previous versions of Ubuntu.
Someone says that running PulseAudio with the -D argument changes the owner of that directory, but I didn't try.

This is before manually changing the owner of that directory:
$ musique
Failed to create secure directory (/run/user/1000/pulse): Permission denied+

... # it doesn't crash, it keeps waiting

If needed:
(dmesg attached)
lspci:
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
85:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8072 PCI-E Gigabit Ethernet Controller (rev 10)

From /var/log/syslog:
Jul 3 14:44:12 Davideddu-Laptop pulseaudio[11387]: [pulseaudio] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
Jul 3 14:44:12 Davideddu-Laptop pulseaudio[11387]: [pulseaudio] main.c: User-configured server at {781995e0a8db2617790d55ca51c37499}unix:/run/user/1000/pulse/native, refusing to start/autospawn.
Jul 3 14:46:08 Davideddu-Laptop pulseaudio[11443]: [pulseaudio] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
Jul 3 14:46:08 Davideddu-Laptop pulseaudio[11443]: [pulseaudio] main.c: User-configured server at {781995e0a8db2617790d55ca51c37499}unix:/run/user/1000/pulse/native, refusing to start/autospawn.

This is a fresh installation, I haven't updated it from a previous version. I'm using Ubuntu with Unity, not a derivative.
These are my PPAs:
canonical-qt5-edgers-qt5-proper-saucy.list
dropbox.list
dukto.list
google-earth.list
jd-team-jdownloader-saucy.list
kivy-team-kivy-saucy.list
mitya57-ppa-saucy.list
numix-icon-theme-dev-utouch-saucy.list
otto-kesselgulasch-gimp-saucy.list
phablet-team-desktop-deps-saucy.list
satyajit-happy-themes-saucy.list
steam.list
ubuntu-sdk-team-ppa-saucy.list
ubuntutrucchi.list
ubuntutrucchi-testing.list
ubuntu-wine-ppa-saucy.list
webupd8team-y-ppa-manager-saucy.list

SRU INFORMATION
===============
TEST CASE:
- Ensure that as a normal user "echo $XDG_RUNTIME_DIR" is something like "/run/user/1000"
- do "sudo su -" to get a root shell
- In that root shell, do "echo $XDG_RUNTIME_DIR". In the saucy final package this still gives /run/user/1000, which is incorrect for root and leads to destroying the real
user's runtime dir. With the fixed package it should be empty.

Fix: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/systemd/trusty/revision/58 : This checks if the runtime dir delivered by logind (which is based on the session uid) is owned by the target user, and only puts it in the environment if it is.

Regression potential: The only case where a runtime dir from a different user could work at all is for opening a su/pkexec session as root; but any client using the runtime dir (pulseaudio, dconf, etc.) would destroy the original user's runtime dir, and we don't have any functionality which depends on this. For non-root su/pkexec targets this potentially leads to different errors (inaccessible $XDG_RUNTIME_DIR vs. a nonexisting one). But again the practical impact is limited to things that you do in su/pkexec shells, not in "real" desktop/ssh/VT login sessions.

[Dr (dr-redhat-bugs)]

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:

[Dr (dr-redhat-bugs)]

Following 11-11-2011 F16 updates I have following problem
99% certain this did not happen before the updates

Login to the console as fred
Create a konsole window

[fred@naxos ~]$ xhost +
access control disabled, clients can connect from any host
[fred@naxos ~]$ su - ja
Password:
ja@naxos ~ 1$ export DISPLAY=:0.0
ja@naxos ~ 2$ gedit prob.txt
** (gedit:4544): CRITICAL **: unable to create '/run/user/fred/dconf'; dconf will not work properly.
ja@naxos ~ 3$

Editing is possible but ja preferences are not honoured

Why is gedit trying to create a file in fred's directory?
[root@naxos ~]# ls -l /run/user/
total 0
drwx------. 4 fred fred 80 Nov 11 11:29 fred
drwx------. 2 root root 40 Nov 11 12:00 root

Fully updated F16
Using KDM and XFCE (not GDM or Gnome)

[root@naxos ~]# yum info gconf*
Installed Packages
Name : GConf2
Arch : x86_64
Version : 3.2.3
Release : 1.fc16
Size : 6.2 M
Repo : installed
From repo : local-16-update
Summary : A process-transparent configuration system
URL : http://projects.gnome.org/gconf/
License : LGPLv2+
Description : GConf is a process-transparent configuration database API used to
            : store user preferences. It has pluggable backends and features to
            : support workgroup administration.

[root@naxos ~]# yum info dconf
Installed Packages
Name : dconf
Arch : x86_64
Version : 0.10.0
Release : 1.fc16
Size : 210 k
Repo : installed
From repo : anaconda-0
Summary : A configuration system
URL : http://live.gnome.org/dconf
License : LGPLv2+
Description : dconf is a low-level configuration system. Its main purpose is to provide a
            : backend to the GSettings API in GLib.

[Matthias (matthias-redhat-bugs)]

This is because su - does not change the XDG_RUNTIME_DIR environment variable.

Setting XDG_RUNTIME_DIR=/run/user/ja is not going to solve the problem, since dconf relies on the system to create (and remove) the runtime dir.

Unsetting XDG_RUNTIME_DIR will make dconf use ~/.cache, and thus avoid the problem.

[Dodji (dodji-redhat-bugs)]

Matthias, I am sorry, but I don't understand why you close this as 'NOTABUG'.

So what you are essentially saying by doing this is that end users should not expect dconf to work after they did 'su -', and for what it's worth, I would find that assertion questionable. In other words, this ought to be fixed somehow, IMHO.

[Guillaume (guillaume-redhat-bugs)]

(In reply to comment #2)
> Setting XDG_RUNTIME_DIR=/run/user/ja is not going to solve the problem, since
> dconf relies on the system to create (and remove) the runtime dir.

Then we have at least one of the following problem:
- dconf shouldn't rely on the sytem to create the runtime dir
- the sytem (systemd?) should create the runtime dir when loging in using "su -".

I do need a working environnement when testing with my test user.

Can you please re-open this bug ? Looks like I don't have the rights to do it.

[Dodji (dodji-redhat-bugs)]

I am tentatively re-opening the bug. I don't meant to be rude by doing this. It's just that I think we need at least some rationale of why this should be seen as an expected behaviour.

[Michael (michael-redhat-bugs)]

I guess this could also have been added to the release notes.

[Matthias (matthias-redhat-bugs)]

(In reply to comment #3)
> Matthias, I am sorry, but I don't understand why you close this as 'NOTABUG'.
>
> So what you are essentially saying by doing this is that end users should not
> expect dconf to work after they did 'su -', and for what it's worth, I would
> find that assertion questionable. In other words, this ought to be fixed
> somehow, IMHO.

I closed it as NOTABUG because dconf is behaving as expected.

[Dodji (dodji-redhat-bugs)]

I see. So I guess this should be assigned to another component, then. Which component would this belong to? I am not sure.

[Michael (michael-redhat-bugs)]

Why doesn't dconf do a fall back on ~/.cache if XDG_RUNTIME_DIR is incorrect ?

[Marek (marek-redhat-bugs)]

I confirm that something has started going wrong in F16. On the earliest of my F16 (VPN) boxes, everytime I do gsettings there, I get:

[root@box ~]# su - username
[username@box ~]$ export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-eQQWiB57Vt,guid=89efbb85dbd202c7c0d0a74d0000001f
[username@box ~]$ gsettings list-recursively org.gnome.Vino

** (process:2599): CRITICAL **: unable to create '/run/user/root/dconf'; dconf will not work properly.
org.gnome.Vino alternative-port uint16 5900
org.gnome.Vino authentication-methods ['none']
org.gnome.Vino disable-background false
org.gnome.Vino disable-xdamage false
org.gnome.Vino enabled false
org.gnome.Vino icon-visibility 'client'
org.gnome.Vino lock-screen-on-disconnect false
org.gnome.Vino mailto ''
org.gnome.Vino network-interface ''
org.gnome.Vino prompt-enabled true
org.gnome.Vino require-encryption false
org.gnome.Vino use-alternative-port false
org.gnome.Vino use-upnp false
org.gnome.Vino view-only false
org.gnome.Vino vnc-password 'keyring'

Once I read through this bug description and comments I did:

[username@box ~]$ echo $XDG_RUNTIME_DIR
/run/user/root
[username@box ~]$ XDG_RUNTIME_DIR=/run/user/username

And voilà:

[username@box ~]$ gsettings list-recursively org.gnome.Vino
org.gnome.Vino alternative-port uint16 5900
org.gnome.Vino authentication-methods ['none']
org.gnome.Vino disable-background false
org.gnome.Vino disable-xdamage false
org.gnome.Vino enabled true
org.gnome.Vino icon-visibility 'client'
org.gnome.Vino lock-screen-on-disconnect false
org.gnome.Vino mailto ''
org.gnome.Vino network-interface ''
org.gnome.Vino prompt-enabled false
org.gnome.Vino require-encryption false
org.gnome.Vino use-alternative-port false
org.gnome.Vino use-upnp false
org.gnome.Vino view-only false
org.gnome.Vino vnc-password 'keyring'

You can even see that some values are different between first and second listings (second surely for "username", but first? "root"?).

Therefore, there surely is something wrong with settings XDG_RUNTIME_DIR. /run/user/username/dconf was created by the system as, after reading the comments, I assume it should be.

[Marek (marek-redhat-bugs)]

On a F15 boxes I get:

[root@box ~]# echo $XDG_RUNTIME_DIR
/run/user/root
[root@box ~]# su - username
[username@box ~]$ echo $XDG_RUNTIME_DIR
/run/user/username
[username@box ~]$ exit
logout
[root@box ~]# echo $XDG_RUNTIME_DIR
/run/user/root
[root@box ~]# su username
[username@box root]$ echo $XDG_RUNTIME_DIR
/run/user/username

And on F16 boxes:

[root@box ~]# echo $XDG_RUNTIME_DIR
/run/user/root
[root@box ~]# su - username
[username@box ~]$ echo $XDG_RUNTIME_DIR
/run/user/root
[username@box ~]$ exit
logout
[root@box ~]# echo $XDG_RUNTIME_DIR
/run/user/root
[root@box ~]# su username
[username@box root]$ echo $XDG_RUNTIME_DIR
/run/user/root

So something definitely changed in the way "su" works.

[Marek (marek-redhat-bugs)]

(In reply to comment #8)
> I see. So I guess this should be assigned to another component, then. Which
> component would this belong to? I am not sure.

Since it is a problem with "su" and "su" belongs to "coreutils", I propose this should be reassigned to "coreutils" component.

At the same time I would recommend changing the summary to something along the lines of '"su" fails to set XDG_RUNTIME_DIR in F16'.

(In reply to comment #2)
> This is because su - does not change the XDG_RUNTIME_DIR environment variable.

That's exactly right.

> Setting XDG_RUNTIME_DIR=/run/user/ja is not going to solve the problem,

Yes it does - see comment #10.

> since dconf relies on the system to create (and remove) the runtime dir.

The proper runtime directory is created by the system, but "su" fails to set XDG_RUNTIME_DIR - see comment #10 and comment #11.

-------------

OTOH - I would like to generalize Dodji Seketeli's notion in comment #5, to point to or give the rationale behind the change, if it is purposeful rather than a random "feature" addition.

[Guillaume (guillaume-redhat-bugs)]

Reading https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/Pam_systemd Systemd's pam module is supposed to create this directory when user logs in so I guess it should do it when loging in using 'su' as well. Should we re-assign to systemd then?

[Marek (marek-redhat-bugs)]

(In reply to comment #13)
> Reading https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/Pam_systemd
> Systemd's pam module is supposed to create this directory when user logs in so
> I guess it should do it when loging in using 'su' as well. Should we re-assign
> to systemd then?

Please, do reassign this to systemd. Thank you. This certainly is the module to perform the needed actions.

It still seems though, that the problem is with interfacing with "su", since the variable is properly set for the user to originally log in into the system (different use of PAM modules than when logging through GDM or SSH, maybe?).

Scripting with "su -c" is also affected - checked it.

Also, as previously mentioned (comment #12), the needed directory is actually created but the variable $XDG_RUNTIME_DIR is not set appropriately to point to it (it keeps pointing to where it did for the "su"-ing user, which is then unreadable for the logged-in-with-"su" user - hence the original reporter's problem with launching gedit which is a side-effect of it), it has to be set manually to make everything work properly again.

[Michael (michael-redhat-bugs)]

Reassigned to systemd

[Michal (michal-redhat-bugs)]

I can reproduce this. With the patch adding a debug print to pam_systemd (
http://cgit.freedesktop.org/systemd/commit/?id=ce9593140b127ce782e2fa2f47fc55558b331126) I am getting this when I do "su - michich" from root's shell:

Dec 14 14:49:45 f16 su: pam_systemd(su-l:session): Asking logind to create session: uid=0 pid=1362 service=su-l type=tty seat= vtnr=0 tty=pts/0 display= remote=no remote_user=root remote_host=

Dec 14 14:49:45 f16 su: pam_systemd(su-l:session): Reply from logind: id=3 object_path=/org/freedesktop/login1/session/3 runtime_path=/run/user/root session_fd=6 seat= vtnr=0

Dec 14 14:49:45 f16 su: pam_unix(su-l:session): session opened for user michich by root(uid=0)

[Michal (michal-redhat-bugs)]

(In reply to comment #16)
> Dec 14 14:49:45 f16 su: pam_systemd(su-l:session): Asking logind to create
> session: uid=0 [...]

It got that uid from the loginuid. Calling pam_loginuid.so from /etc/pam.d/su-l would make this work, but I guess the purpose of loginuid is exactly not to be called from su...

[Marek (marek-redhat-bugs)]

Since it looks like the problem is at least with "su"'s interaction with the PAM module (if not an incorrect usage), it seems that maybe it would be slightly more fruitful to attract the attention of coreutils maintainers (CC? reassign? I guess they don't even know about this...).

On a side note - the directory /run/user/username *might* not get created at the time of performing "su", since all the computers I tested this with are automatically logging in to username and are not logging out until the computer is shut down. As I understand, the directory is created right after first logging in and removed at the last logging out of a user, therefore its existence does nothing to trace the bug on my side.

On a second side note - is it possible to change the title/summary to something more to the point (at least getting rid of "gedit" mention which has absolutely nothing to do with the actual problem).

[Jóhann (jhann-redhat-bugs)]

Reassigning to coreutils and changing summary.

Coreutil maintainer(s) see comment 16 and comment 17.

Just reassign to systemd with feedback if this is something we should be solving on that end.

Thanks

[Ondrej (ondrej-redhat-bugs)]

In reply to comment#11 - su pam support (which is added by downstream patch) changed quite a lot recently - we merged SUSE and RedHat pam support patch to consolidate these two distributions. However, there was one change in pam between F15 and F16 - trying to support ecryptfs mount of "Private" - #722323 . But even that change was not sufficient to make it working and probably was not correct.

Anyway, adding Tomas Mraz to CC as he is more experienced with pam.

[Tomas (tomas-redhat-bugs)]

loginuid is original UID of the session and should not/may not be changed by su. Thus pam_systemd should not use loginuid for the purpose of setting XDG_RUNTIME_DIR.

[Eric (eric-redhat-bugs)]

This bug still exists in F17. It certainly seems to be a legitimate bug to me.

I want user isolation for two users, alice and bob, but I want bob to be able to throw windows up on alice's display, and those x11 apps to work correctly.

For example, alice allows bob access to her display:

   [alice@localhost] $ xhost +si:localuser:bob

Somehow bob gets a login shell, in my instance specfic instance, root does:

   [root@localhost] # su -l bob

Then bob exports his display to alice's desktop, local in this case,

   [bob@localhost] $ export DISPLAY=:0.0

and throws up a PDF

   [bob@localhost] $ evince misunderstanding-x11-fundamentals.pdf

only to receive:

** (evince:9077): CRITICAL **: unable to create '/run/user/alice/dconf'; dconf will not work properly.

(caveat, root was a bash login shell, su - by alice)

though the PDF displays on alice's desktop, evince prefs are not saved at all.

In reply to comment#21, seems to be that there is an issue with your statement. When su -luser, this is a login shell. Seems to me that loginuid should be changing at this point.

In my opinion su should not be knowing or caring anything about XDG_RUNTIME_DIR, evar. (*cough* *cough* hack.)

I don't care why app saving prefs (dconf) does not work but from a user perspective it seems intuitive that it should work and it doesn't.

[Tomas (tomas-redhat-bugs)]

(In reply to comment #22)

> In reply to comment#21, seems to be that there is an issue with your
> statement. When su -luser, this is a login shell. Seems to me that loginuid
> should be changing at this point.

Nope, the loginuid traces the UID of the original user account that was logged into the machine. This is really important for auditing who is the real user behind the operations on the different account.

[Marek (marek-redhat-bugs)]

As I understand it, the pam_loginuid is for auditing to tag a process with "original logger's UID from the authentication entry point". In the case of su, only the superusers don't have to authenticate themselves, so the purpose of the "thou shalt not pam_loginuid from su" is not really clear for me.

Whatever was meant for pam_loginuid, the bottom line is that if someone gets root rights they can do anything - also save a password for some account, change this password, log in remotely as that account (it's an entry point, so the account becomes the "original logger"), do something bad or good, then log off, and change the password back.

In the end, I propose pam_systemd should get the UID for the new user some other way and set the environment accordingly. This would let the discussion of whether (or when) su should run pam_loginuid be resolved by philosophers.

PS. I was about to bump this in a couple of days as to not look too aggressive about it. I'm still waiting for this to be resolved. Even though I grew accustomed to it, entering "export XDG_RUNTIME_DIR=/run/user/*" every time I login to a remote machine to do anything that is connected with FreeDesktop specifications is really bothersome (especially that more and more is relying on those standards, which by itself is for the better).

[Michal (michal-redhat-bugs)]

(In reply to comment #23)
> (In reply to comment #22)
>
> > In reply to comment#21, seems to be that there is an issue with your
> > statement. When su -luser, this is a login shell. Seems to me that loginuid
> > should be changing at this point.
>
> Nope, the loginuid traces the UID of the original user account that was
> logged into the machine. This is really important for auditing who is the
> real user behind the operations on the different account.

Right. And additionally, with CONFIG_AUDIT_LOGINUID_IMMUTABLE enabled in the kernel, it is not even possible to change the loginuid of a process.

[Eric (eric-redhat-bugs)]

In reply to comment#23,
You're not discussing, you're making categorical statements. "su -login user" is a perfectly legitimate login entry point as far as I'm concerned. "su user" is not. I understand the ramifications for auditing.

In reply to comment#24,
> In the end, I propose pam_systemd should get the UID for the new user
> some other way and set the environment accordingly."

I think you hit the nail on the head here. While it may be expedient, it doesn't seem to cover corner cases well; like multi-user X?

In reply to comment#25,
Your statement is counter intuitive. If loginuid "was supposed to be" immutable, there wouldn't be a need for a kernel config option. I notice how it mentions systemd in the Kconfig and that I'm guessing that it's systemd folks who wanted it in there. See point #2 above.

Back to the point of my original post and comment#1's (and not arguing details and philosophy) bob's evince and ja's prefs should be saved correctly. This is a bug.

[Michal (michal-redhat-bugs)]

(In reply to comment #26)
> If loginuid "was supposed to be" immutable, there wouldn't be a need for
> a kernel config option. I notice how it mentions systemd in the Kconfig and
> that I'm guessing that it's systemd folks who wanted it in there.

The guess is wrong. The audit developers always wanted loginuid to be immutable, but only systemd made it possible to achieve in practice. That's when the config option was introduced:
See http://www.redhat.com/archives/linux-audit/2011-November/msg00040.html:
"Systemd has changed how userspace works and allowed us to make the kernel
work the way it should."

[Michal (michal-redhat-bugs)]

(In reply to comment #26)
> Back to the point of my original post and comment#1's (and not arguing
> details and philosophy) bob's evince and ja's prefs should be saved
> correctly. This is a bug.

Perhaps. Does anyone have specific suggestions how a fix should look like?

[Lennart (lennart-redhat-bugs)]

I explicitly chose to bind this to loginuid rather than anything else. People shouldn't fool themselves in assuming that "su" would get them a completely new session that has all properties of the destination user rather than the source user. THis is technically not possible, and if it would be implemented would even kinda defeat the point of su.

For example, people probably want DISPLAY= to be the old one so that their root program they started with su an run on X11. OTOH the home directory should probably be the one of the destination user afterwards, but the current directory the one of the source user. The audit trail should be the one of the old user, but $PATH of the new user. And so on and so on.

So people want a weird mix of things from the old and the new user session, and even worse, people want different things from the old and from the new session. For example, PA now places its socket in XDG_RUNTIME_DIR, and so does dconf. But apparently this bug report is a complaint that dconf should be the one of the new user. THis would break audio of however, which probably should be the one of the original user.

So, we should not pretend we could make "su" work properly for the general case, or that we could find a way that makes this work for everybody.

When we decided to base our systemd XDG_RUNTIME_DIR logic on the audit login session id (if it is available) is the thinking that "su" should be minimal in its effect, and almost everything that is not explicitly detached from the old session should continue to be from the old session. i.e. the default should be not to detach rather than to detach.

If you want a fully detached text session then use "ssh localhost" or so, which virtualizes everything.

So really, I see little to fix here in systemd. I believe basing this on loginuid is the right thing. And if the trade-off is between breaking PA and breaking dconf my choice is to stick to what makes sense on logical level.

[Jimmy (jimmy-redhat-bugs)]

(In reply to comment #29)
> So, we should not pretend we could make "su" work properly for the general
> case, or that we could find a way that makes this work for everybody.
>

So for a sysadmin, I need to be able to run commands as other users. For years "su - username" has provided this. How can I accomplish if "su" doesn't work anymore?

[Lennart (lennart-redhat-bugs)]

(In reply to comment #30)
> (In reply to comment #29)
> > So, we should not pretend we could make "su" work properly for the general
> > case, or that we could find a way that makes this work for everybody.
> >
>
> So for a sysadmin, I need to be able to run commands as other users. For
> years "su - username" has provided this. How can I accomplish if "su"
> doesn't work anymore?

Well running X11 apps via su has always been half-broken (D-Bus!), and it continues be half-broken. gedit just won't save its settings, and that's it.

[Fedora (fedora-redhat-bugs)]

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Jóhann (jhann-redhat-bugs)]

Based on comment 29 I'm closing this as notabug feel free to reopen and move to rawhide if you still believe this is incorrect behaviour.

Thanks

[Marek (marek-redhat-bugs)]

Finally finding some time to get back to writing here - yes, I do think it is incorrect behaviour.

Shortly:
If you really feel the need to keep "su" clean, I propose, to resolve this, additional PAM modules that could be attached to "su" and "su-l" events through configuration.

Back to discussion:
I see most critical issues in following situations:
- systems where you cannot install things like ssh - any way to achieve the same result as earlier anymore?
- quite obvious information leak - how can one create a clean environment e.g. for a temporary server than communicates with outside world, with a script now? Especially using a user that has a nologin shell?

(In reply to comment #31)
> gedit just won't save its settings, and that's it.

Way to show scorn! Eristic classes maybe?

It is not "oh, it's just gedit" - almost everything now uses gconf / dconf for settings (and otherwise), including practically all of the GUI and also some command-line tools. It breaks old scripts - simple use of gsettings does not work either as was already shown. Combining this fact with little information about what environment variables programs use (look those up e.g. for gedit while it's mentioned) means we're back to the "diagnose a not working black box" tile.

(In reply to comment #29)
> People shouldn't fool themselves in assuming that "su" would get them a
> completely new session that has all properties of the destination user
> rather than the source user. THis is technically not possible, and if it
> would be implemented would even kinda defeat the point of su.

This is wrong from the starting point - *YOU* don't want people get a completely new session. If it was impossible I wouldn't become myself after ssh'ing into a server but rather some mutilated root offspring, because that's what's running the server daemon. I see no reason to not let people get exactly what ssh is giving them (auditing? - read on).

Also, why would it "kinda defeat the point of su"? What is THE point of su? If you would be so kind to enlighten me.

> OTOH the home directory should probably be the one of the destination user
> afterwards, but the current directory the one of the source user.

Isn't this was is happening now?

> The audit trail should be the
> one of the old user, but $PATH of the new user. And so on and so on.

This idea of auditing is coarse-grained. Finer auditing could be made through permanent process parent tagging (PPPID, different from casual PPID) - if a process was forked off some other it is permanently tagged as it's child even if it forks and PPID changes to 1. The PPPID would disappear only when all of its forks die.

If such auditing was implemented there would be no reason to keep and secure explicit loginuid since it's equivalent could be derived from the permanent-process-parent chain. What I wouldn't give to have SUCH auditing - many times have I wondered what other process forked off a process that is now PPID 1.

This idea is also quite similar to CGroups which are already implemented, so it might not have to be written from scratch.

> So people want a weird mix of things from the old and the new user session,
> and even worse, people wa...

[Adam (adam-redhat-bugs)]

(In reply to comment #29)
> I explicitly chose to bind this to loginuid rather than anything else.
> People shouldn't fool themselves in assuming that "su" would get them a
> completely new session that has all properties of the destination user
> rather than the source user. THis is technically not possible, and if it
> would be implemented would even kinda defeat the point of su.
>
> For example, people probably want DISPLAY= to be the old one so that their
> root program they started with su an run on X11. OTOH the home directory
> should probably be the one of the destination user afterwards, but the
> current directory the one of the source user. The audit trail should be the
> one of the old user, but $PATH of the new user. And so on and so on.
>
> So people want a weird mix of things from the old and the new user session,
> and even worse, people want different things from the old and from the new
> session. For example, PA now places its socket in XDG_RUNTIME_DIR, and so
> does dconf. But apparently this bug report is a complaint that dconf should
> be the one of the new user. THis would break audio of however, which
> probably should be the one of the original user.
>
> So, we should not pretend we could make "su" work properly for the general
> case, or that we could find a way that makes this work for everybody.
>
> When we decided to base our systemd XDG_RUNTIME_DIR logic on the audit login
> session id (if it is available) is the thinking that "su" should be minimal
> in its effect, and almost everything that is not explicitly detached from
> the old session should continue to be from the old session. i.e. the default
> should be not to detach rather than to detach.
>
> If you want a fully detached text session then use "ssh localhost" or so,
> which virtualizes everything.
>
> So really, I see little to fix here in systemd. I believe basing this on
> loginuid is the right thing. And if the trade-off is between breaking PA and
> breaking dconf my choice is to stick to what makes sense on logical level.

This statement is definitely right for "su". However for "su -" case I would expect that XDG_* directories are created with uid of destination user. To accomplish this I think two changes need to be done:

1. Change "session" part of /etc/pam.d/su (i.e. "su" variant) to

session optional pam_keyinit.so revoke
session required pam_limits.so
session required pam_unix.so

The main reason behind this is that "su" should just borrow uid and all environment variables (with some exceptions - $HOME, $SHELL, $USER, $LOGNAME, $PATH, and $IFS, not sure if others) should be preserved. This is also true for XDG_ variables. Another reason for this change is to avoid calling pam_systemd for non-login shell.

2. Change pam_systemd to create & set XDG_ directories with UID of target user, not of the loginuid user.

After those two changes, "su" will just borrow uid of new user but "su -" will create new session, including XDG_ directories.

Note there might be needed even more sophisticated pam.d/* change to keep "runuser", which is just variant of "su", in sync with "su" so /etc/pam.d/su might lo...

[Ondrej (ondrej-redhat-bugs)]

*** Bug 915498 has been marked as a duplicate of this bug. ***

[Tomas (tomas-redhat-bugs)]

The proposal is good but I'd change it to do all the modification in /etc/pam.d/system-auth with calling pam_succeed_if and skipping pam_systemd if the service is su or runuser (without -l).

[Lennart (lennart-redhat-bugs)]

I am sorry, but I am firmly of the opinion that we should bind the XDG_RUNTIME_DIR stuff, the bus, the user session and the audit session together, and that "su" should only do the minimal work beyond that.

Closing.

[Adam (adam-redhat-bugs)]

(In reply to comment #38)
> I am sorry, but I am firmly of the opinion that we should bind the
> XDG_RUNTIME_DIR stuff, the bus, the user session and the audit session
> together, and that "su" should only do the minimal work beyond that.

You are absolutely right about "su". However I disagree with "su -". "su -" should bring you brand new session. Please note that in this usecase auditing point of view and user point of view are different.

From auditing point of view you want to track which physical person does something and it's clear that if someone calls "su -", it's still physical person (i.e. same user who logged through ssh/gdm/kdm etc). I.e. you need auditing for tracking which physical person is logged in.

However from user point of view, I expect that computer thinks that I'm brand new user when I call "su -", even when I'm same physical person. So "su -" (however not "su") should create brand new session, with new bus, new XDG_ dirs etc.

Don't you think that goals of auditing and goals of user sessions are pretty different? Reopening for further consideration.

[Tomas (tomas-redhat-bugs)]

I completely agree with Adam here. The loginuid purpose is auditing and should not be bound with the user point of view.

[Dr (dr-redhat-bugs)]

As the original poster I would like to second comment #39

The ability to have a fully functional "su - user2" session is a fundamental user requirement particularly for testing or development activities.

[Lennart (lennart-redhat-bugs)]

Well, there is never geing to be a "fully functional" implementation of "su -" because it always inherits state from the session, and that state is quite substantial.

I mean, you can reopen this bug as much as you want, but I fundamentally believe that the scheme of "su" (or "su -" if you want to nitpick), can never work for desktop applications. You can lie to yourself, and claim D-Bus wouldn't exist and what else, but I don't see why systemd should play this game of pretending.

I am not binding our session definition to the audit sessionid because it was the same thing, but because it turned out to have the same lifecycle, and we thus just decided that we can avoid a new identification scheme, and just reuse the id audit introduced.

Anyway, closing again. This can never fly. And the same way as the destination user might or might not get access to the bus, it should also get or not get access to the XDG_RUNTIME_DIR. It's the same thing. And to PA, and whatnot. I am not going to handle XDG_RUNTIME_DIR differently from the rest.

[Dr (dr-redhat-bugs)]

Is this such an unreasonable thing to want to do ?

In one terminal

ja@ferrari ~ 2$ su -
Password:
[root@ferrari:~]$ gedit test1

(XDG_RUNTIME_DIR set to UID of ja)

In 2nd terminal

ja@ferrari ~ 1$ gedit test2

** (gedit:3096): CRITICAL **: unable to create file '/run/user/1050/dconf/user': Permission denied. dconf will not work properly.

** (gedit:3096): CRITICAL **: unable to create file '/run/user/1050/dconf/user': Permission denied. dconf will not work properly.

Reversing the order of editing only delays the occurrence of the problem

[Miloslav (miloslav-redhat-bugs)]

(In reply to comment #42)
> Well, there is never geing to be a "fully functional" implementation of "su
> -" because it always inherits state from the session, and that state is
> quite substantial.

Care to explain what exactly is inherited through loginuid?

> I mean, you can reopen this bug as much as you want, but I fundamentally
> believe that the scheme of "su" (or "su -" if you want to nitpick), can
> never work for desktop applications.

It worked for years well enough, only having to set up xauth to let two separate environments access the same display. What made it suddenly impossible?

You've mentioned audio - couldn't it be solved by a similar authentication forwarding mechanism?

> You can lie to yourself, and claim
> D-Bus wouldn't exist and what else, but I don't see why systemd should play
> this game of pretending.

AFAIK D-Bus uses DBUS_SESSION_BUS_ADDRESS, which can be separate; org.freedesktop.DBus.GetConnectionUnixUser does not use the loginuid. What exactly is problematic about D-Bus?

> Anyway, closing again. This can never fly. And the same way as the
> destination user might or might not get access to the bus, it should also
> get or not get access to the XDG_RUNTIME_DIR. It's the same thing.

When an unprivileged-user-foo does (su - unprivileged-user-bar), the user "foo" should not be asked to give away access to all of XDG_RUNTIME_DIR. That would make (su -) a "please compromise me" command.

[Tomas (tomas-redhat-bugs)]

*** Bug 965419 has been marked as a duplicate of this bug. ***

[Jan (jan-redhat-bugs)]

Re [comment 29]:
> If you want a fully detached text session then use "ssh localhost" or so,
> which virtualizes everything.

True, I wonder when it becomes impossible to send GUI notifications through
SSH (using standard programs and default settings): [bug 915346].

[Luke Yelavich (themuso)]

Given you have so many PPAs enabled on your system, it is entirely possible that one of those PPAs has updated PulseAudio. Please reply back with the output of "apt-cache policy pulseaudio" so I can find out what version of pulse you have, and where its from.

Thanks.

[Davide Depau (depau)]

No, it's not from a PPA:

pulseaudio:
  Installed: 1:3.0-0ubuntu8
  Candidate: 1:3.0-0ubuntu8
  Version table:
 *** 1:3.0-0ubuntu8 0
        500 http://it.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
        100 /var/lib/dpkg/status

[Luke Yelavich (themuso)]

Ok then, could you please try testing Pulseaudio 4.0 from ppa:ubuntu-audio-dev/pulse-testing? I must say I am not seeing any such problem similar to this here locally, although I am running Pulse 4.0.

[Davide Depau (depau)]

Ok, I'm adding it. I didn't have the problem again. I'll try to play music
every time I turn on the PC, and if I won't have problem for almost a week,
I will report it here.

2013/7/9 Luke Yelavich <email address hidden>

> Ok then, could you please try testing Pulseaudio 4.0 from ppa:ubuntu-
> audio-dev/pulse-testing? I must say I am not seeing any such problem
> similar to this here locally, although I am running Pulse 4.0.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1197395
>
> Title:
> /run/user/$ID/pulse owned by root and not by the user
>
> Status in “pulseaudio” package in Ubuntu:
> New
>
> Bug description:
> I'm experiencing this problem with Ubuntu Saucy. Some times, when I
> start a media player (I use Musique), it freezes, as it finds that it
> cannot write into /run/user/$ID/pulse.
> If I change the owner of that directory to me, the media player starts
> as usual and is able to play music.
> I've never had this problem with previous versions of Ubuntu.
> Someone says that running PulseAudio with the -D argument changes the
> owner of that directory, but I didn't try.
>
> This is before manually changing the owner of that directory:
> $ musique
> Failed to create secure directory (/run/user/1000/pulse): Permission
> denied+
>
> ... # it doesn't crash, it keeps waiting
>
> If needed:
> (dmesg attached)
> lspci:
> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
> Controller Hub (rev 07)
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
> Chipset Integrated Graphics Controller (rev 07)
> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
> Integrated Graphics Controller (rev 07)
> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #4 (rev 03)
> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #5 (rev 03)
> 00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #6 (rev 03)
> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
> Controller #2 (rev 03)
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
> Controller (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 1 (rev 03)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 2 (rev 03)
> 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 3 (rev 03)
> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 5 (rev 03)
> 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
> Port 6 (rev 03)
> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #1 (rev 03)
> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #2 (rev 03)
> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #3 (rev 03)
> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
> Controller #1 (rev 03)
> 00:1e.0 PCI bridge: Intel ...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Nicolas Devillers (nicolas-devillers)]

I meet the same problem with the same version of pulseaudio and permission set uncorrectly as found in my syslog.

pulseaudio:
  Installé : 1:3.0-0ubuntu8
  Candidat : 1:3.0-0ubuntu8
 Table de version :
 *** 1:3.0-0ubuntu8 0
        500 http://fr.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
        100 /var/lib/dpkg/status

after running "musique" I got a hang with :
"Failed to create secure directory (/run/user/1000/pulse): Permission non accordée"

[Roland Dreier (roland.dreier)]

affecting me on a system upgraded from raring around saucy-alpha1.

[Luke Yelavich (themuso)]

As above, please try testing with Pulseaudio 4.0 from the mentioned PPA.

[Iain Lane (laney)]

I am seeing this right now. I got the updated PA from saucy when it was uploaded on the 26th and rebooted on the 27th, so my system was booted with 4.0.

laney@iota> ls -la /run/user/1000
total 0
drwx------ 7 laney laney 160 Jul 27 10:40 ./
drwxr-xr-x 3 root root 60 Jul 27 10:41 ../
drwx------ 2 laney laney 60 Jul 30 12:43 dconf/
dr-x------ 2 laney laney 0 Jul 27 10:40 gvfs/
drwx------ 2 laney laney 40 Jul 27 10:40 gvfs-burn/
drwx------ 2 laney laney 120 Jul 27 10:40 keyring-ibRVX2/
drwx------ 2 root root 100 Jul 27 10:40 pulse/
lrwxrwxrwx 1 root root 17 Jul 27 10:41 X11-display -> /tmp/.X11-unix/X0=

laney@iota> sudo ls -la /run/user/1000/pulse
[sudo] password for laney:
total 4
drwx------ 2 root root 100 Jul 27 10:40 .
drwx------ 7 laney laney 160 Jul 27 10:40 ..
srwxrwxrwx 1 laney laney 0 Jul 27 10:40 dbus-socket
srwxrwxrwx 1 laney laney 0 Jul 27 10:40 native
-rw------- 1 laney laney 5 Jul 27 10:40 pid

laney@iota> sudo more /run/user/1000/pulse/pid
2198

laney@iota> ps faux | grep 2198
laney 2198 0.0 0.0 375976 1140 ? Sl Jul27 0:32 /usr/bin/pulseaudio --start --log-target=syslog

So it's started correctly as my user but the directory has the wrong permissions. Could this be a bug in lightdm?

[David Henningsson (diwic)]

> So it's started correctly as my user but the directory has the wrong permissions. Could this be a bug in lightdm?

At least it can't be a bug in PulseAudio, because PulseAudio shouldn't have the permission to create that directory with those permissions, right?

[Iain Lane (laney)]

When I press the media keys I can hear the 'pip' sound telling me what the volume will be, so somehow that can use the sound hardware.

Thinking about it, while I can't be sure, it seems quite unlikely that sound would have been broken for me for a week without me noticing (implied if it happened at login time). I wonder if it broke somehow at runtime.

laney@iota> loginctl show-session c2
Id=c2
Timestamp=Sat 2013-07-27 10:41:27 BST

[Davide Depau (depau)]

> At least it can't be a bug in PulseAudio, because PulseAudio shouldn't have the permission to create that directory with those permissions, right?

I agree with you, but what else could make it owned by root? Or PA is started as root before the DM is started, and maybe it doesn't remove it after terminating/crashing, or the DM does something nasty...
A workaround could be a script runned *after* login and whitelisted in /etc/sudoers.d that checks the permissions of that directory.

[Luke Yelavich (themuso)]

Pulseaudio is run as the logged in user. Pulse itself will refuse to start as root if system mode is not enabled in the config. I think this is happening post pulse start, although I have no idea what the problem could be, and I haven't experienced this problem myself.

[Davide Depau (depau)]

On Thu, Aug 1, 2013 at 12:29 AM, Luke Yelavich
<email address hidden>wrote:

> Pulseaudio is run as the logged in user. Pulse itself will refuse to
> start as root if system mode is not enabled in the config. I think this
> is happening post pulse start, although I have no idea what the problem
> could be, and I haven't experienced this problem myself.
>

It may be a media player started as root! Maybe if a media player is
started as root could change the owner of that directory to root..

[Luke Yelavich (themuso)]

On Thu, Aug 01, 2013 at 08:39:59AM EST, Davide Depau wrote:
> It may be a media player started as root! Maybe if a media player is
> started as root could change the owner of that directory to root..

If a media player was started as root, libpulse would notice that pulseaudio is not running for root, and attempt to spawn a new instance of pulseaudio, which likely wouldn't work due to the conditions I outlined in my comment earlier.

[Antti Kaijanmäki (kaijanmaki)]

OK, hit this today. Never seen it before. I started to have weird problems with Google Hangout; the plugin failed to start on both
firefox and chromium. Manually starting the plugin from command line I got:

$ /opt/google/talkplugin/GoogleTalkPlugin
Failed to create secure directory (/run/user/1000/pulse): Permission denied

There I figured out there is something wrong with pulse:
$ pulseaudio --check
E: [pulseaudio] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied

$ ls -lah /run/user/1000/
drwx------ 2 root root 100 elo 13 11:31 pulse

Removing the directory fixed the problem with GoogleTalk. I guess all the programs using pulse were affected.

Everything was working just fine yesterday. This morning I noticed my laptop had apparently run out of battery. Pluggin in the power chord and power up the machine it seemed that unity did not start straight away. I'm not sure what the failsafe error session looks like, but at least I first saw a bunch of undecorated problem report windows. So I would guess that the first session was run as root or something. Anyway after that the normal unity session started and I was greeted with this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1211674

So, could it be that at some error situation the X session is started as root and pulse somehow creates it's /run/user/1000/pulse with root permissions at situation like this?

[Antti Kaijanmäki (kaijanmaki)]

ApportVersion: 2.12-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: antti 9912 F.... pulseaudio
 /dev/snd/pcmC1D0c: antti 9912 F...m pulseaudio
 /dev/snd/pcmC1D0p: antti 9912 F...m pulseaudio
 /dev/snd/controlC0: antti 9912 F.... pulseaudio
DistroRelease: Ubuntu 13.10
InstallationDate: Installed on 2013-08-06 (6 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130805)
MarkForUpload: True
Package: pulseaudio 1:4.0-0ubuntu1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.10.0-6.17-generic 3.10.3
Tags: saucy
Uname: Linux 3.10.0-6-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 04/18/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A08
dmi.board.name: 0PJHXN
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnDellInc.:bvrA08:bd04/18/2013:svnDellInc.:pnDellSystemXPSL322X:pvr:rvnDellInc.:rn0PJHXN:rvrA00:cvnDellInc.:ct8:cvr0.1:
dmi.product.name: Dell System XPS L322X
dmi.sys.vendor: Dell Inc.

[Antti Kaijanmäki (kaijanmaki)]

apport information

[Antti Kaijanmäki (kaijanmaki)]

apport information

[Antti Kaijanmäki (kaijanmaki)]

apport information

[Antti Kaijanmäki (kaijanmaki)]

apport information

[Antti Kaijanmäki (kaijanmaki)]

apport information

[Tomas (tomas-redhat-bugs)]

*** Bug 999707 has been marked as a duplicate of this bug. ***

[Carlos (carlos-redhat-bugs)]

This is breaking tightvnc-server (F19), that starts the sessions via systemd with

ExecStart=/sbin/runuser -l <USER> -c "/usr/bin/vncserver ..."

Comment 34 explains very well why this is a bug, and Comment 35 offers a reasonable path to find a fix.

May be it is time to introduce a "--subsession" flag to "su", that works like "--login" plus the PAM/systemd calls needed to spawn the sub-session.

Lennart, you are blocking this bug because it hurts your design paradigm. The use cases exposed here were not taken into account when the design was done, it is time to integrate them. Your postulate "This can never fly" is a poor excuse, Linux gives us wings. Multi-user desktops have been working for ages, now they are broken. Please help us find a reasonable trade-off!

[Richard (richard-redhat-bugs)]

It's definitely a bug that su - username doesn't work correctly.
This breaks libguestfs which wants to put a socket into
$XDG_RUNTIME_DIR but cannot if the user has su - into the account.

I guess our only workaround is to stop using XDG_RUNTIME_DIR
and to dissuade anyone else from using too.

[gururise (gururise)]

This bug happened to me on upgrade to saucy daily build (10/13/2013)

[David Henningsson (diwic)]

There was something upstream that looked somewhat related:

"
Ok, got the error: the systemd pam module in /etc/pam.d/common-session does not create a secure run dir in /run/user for every logged in user.
So pulse is complaining about access .
Deleted the systemd line in /etc/pam.d/common-session makes all work well.
Maybe it's because this is on multi-user (multiseat) computers.
"

If any of you can reproduce this, can you check if this workaround works?

Source: http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-October/018970.html

[Ales (w-ales)]

Fixed by deleting the directory '/run/user/1000/pulse'.
Then I had to kill vlc (VLC media player) process that was waiting endlessly saing "Failed to create secure directory (/run/user/1000/pulse)".
But I think after reboot it will be the same again.

[Alexander List (alexlist)]

Hit this bug running latest Saucy, with distro pulseaudio after a cold reboot.

pulseaudio:
  Installed: 1:4.0-0ubuntu6
  Candidate: 1:4.0-0ubuntu6
  Version table:
 *** 1:4.0-0ubuntu6 0
        500 http://tw.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
        100 /var/lib/dpkg/status

What I did (don't know if it's related / required to trigger the bug):

- close lid of my Thinkpad X201 while docked
- undock TP
- open TP next morning, LEDs start up but sceen stays dark
- need to hard reboot (4s on power button)
- screen is set to darkest setting
- Ubuntu boots up, but above Pulseaudio problem

[Alexander List (alexlist)]

Syslog says:

Oct 22 12:01:51 thinkpad pulseaudio[7500]: [pulseaudio] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Permission denied
Oct 22 12:01:51 thinkpad pulseaudio[7500]: [pulseaudio] main.c: User-configured server at {8fd1761c7e3ddb8d6613834f51480041}unix:/run/user/1000/pulse/native, refusing to start/autospawn.

[Alexander List (alexlist)]

Workaround: I removed the offending directory, and pulse immediately created one owned by the right user. Even after a reboot, no issues here.

[Ales (w-ales)]

I can confirm that. Deleting the directory '/run/user/1000/pulse' is apparently enough. The problem is solved for good I guess.

[duportail (guy-linux-service)]

The error stays, even in fully updated xubuntu 13.10, on multiseatcomputer.
Log in a first user, the dir /run/user/1001 is created.
Logout this user and login with another user, pulse error shows up in syslog complaining access to this 1001 dir.
Delete this dir, reboot and do the same logins and logout, same problems.
Seems that this libpam-systemd module is not creating a /run/user/dir for every user.Maybe this module is creating dirs upon x displays or something.
In ubuntu 13.04 these dirs were created according the usernames.
Again, disabling this module in pam.d solves the problem.

[Laurent Séguin (cybersdf)]

I don't know if it is related, but under XFCE the "indicator-sound" is not functional (luckily hotkeys work).

[L. (nemosdca)]

After updated to ubuntu 13.10 I also have this issue. The permission of the directory (/var/run/user/1000/pulse) was changed to root, every time I run synaptic, from the gnome-flashback menu in the panel.

From the menu synaptic is invoked by pkexec. I tried gksudo synaptic then no such problem, i.e. the directory remians owned by myslef. I think it may be a problem caused by pkexec

[Florian (florian-redhat-bugs)]

The XDG Base Directory Specification says that the "directory MUST be owned by the user, and he MUST be the only one having read and write access to it", so the "su -" behavior is non-compliant. su isn't just passing through an existing environment variable, it's systemd's PAM module that causes this, so the fix really has to be in systemd.

[Kootee (kootee)]

I think problem is connected with system crash. I also musted do hard reboot of my computer, because after wake-up my usb WiFi didn't work and system didn't wanted to reboot (even with root privilages). So after some minutes of waiting i've pressed power button and after new boot got this error.

[Y. Leretaille (yleretaille)]

Just had the same problem after a (normal) restart on a Macbook Retina 10,1. Sound wasn't working anymore and most applications using sound hung up/waited for a ling time and then crashed (most annoyingly flashplayer, which caused firfox to hang). After deleting the folder pulse, sound instantily worked again.

[Riley Baxter (rileyb1106)]

I had this happen after a failed attempt to put my computer into standby that required a force poweroff.

[Scorpil (scorpil)]

Same here: after failed attempt to suspend my PC, directory /run/user/1000/pulse was owned by root.
I've just installed system yesterday (fresh one, not upgraded from previous version).

I've installed only one program that has anything to do with pulseaudio: skype (from repo, not official deb package).
Anyone experiencing this issue installed skype recently?

[Philip Aston (philipa)]

Yes - same for me as #37,#38 after failing to enter standby / forced power off.

[Horst Schirmeier (horst)]

Same here, had several standby issues before seeing this. Dell Latitude E6400, Ubuntu 13.10 (saucy) 64-bit. Temporary workaround: "sudo chown -R 1000:1000 /run/user/1000".

[wizzor (visa-parviainen)]

I can reconfirm.

Also, other users have pointed out putting the lid down while docked, which results in a crash, having to hard-reboot and on restart find this problem.

This also is exactly how my problem appeared. I think I closed the lid first, then docked, though.

Clean install 64b, Lenovo X220 w. dock.

[Colin (colin-redhat-bugs)]

From the perspective of "pkexec", we go out of our way to explicitly clear all envronment variables (e.g. DISPLAY) except for a special whitelist. But pam_systemd.so then *injects back* a broken XDG_RUNTIME_DIR.

That just has to be wrong. Right, Lennart?

There are a few options here.

One that occurs to me is for pam_systemd.so to special case XDG_RUNTIME_DIR when uid != loginuid. We could leave XDG_RUNTIME_DIR unset, and apps would have to fall back.

But as with most other people in this thread, I'm really concluding that pam_systemd.so should explicitly use getuid() for XDG_RUNTIME_DIR.

[josef (josef-redhat-bugs-1)]

Im setting this to priority medium and severity medium, as this is annoying to the enduser and the disussion seems to lead nowhere.
we learned for years, that "su -" was the way to go for starting programs as another user. now (YEARS ago) someone (maybe even a group) changes that behaviour and breaks alot of other programs and the outcome is some academic parlay.

asked frankly:
*) will there be a solution?
*) from whom?
*) when?

if there will be no solution, we could take actions against that (by modifying software not to use XDG_RUNTIME_DIR, which would be wrong in my opinion, but if this is the only solution: go for it.

all we need is a decision.

[jnns (jnns)]

Problem occurs on a Lenovo Thinkpad X230 as well.

[jradwans (jradwans)]

I have the same problem with FLash in all Web Browsers :(

The problem starts after upgrade to ubuntu 13.10 (32bit)

My notebook PacardBell Intel i3-2330M 4x2,2GHz
Intel Sandybridge Mobile

patrycja@patrycja-Satellite-L300:~$ ls -l ./.dmrc
-rw-r--r-- 1 patrycja patrycja 93 lis 9 21:42 ./.dmrc
patrycja@patrycja-Satellite-L300:~$ ls -l /home
razem 12
drwxr-xr-x 80 patrycja users 12288 lis 9 21:42 patrycja
patrycja@patrycja-Satellite-L300:~$ pulseaudio --check
E: [pulseaudio] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Brak dostępu

[TooDiesel (zotovd)]

I've also installed skype recently (before upgrading), and the issue has affected me since upgrading to ubuntu 13.10

[Y. Leretaille (yleretaille)]

Reencountered the same problem again today (again on my MPr 15"). I _did_ shutdown the computer properly yesterday evening, but I'm pretty sure that I closed the lid immediatly after clicking on shutdown.

[Clement Lefebvre (clementlefebvre)]

Hi,

It's a regression in the pam module for systemd: https://bugzilla.redhat.com/show_bug.cgi?id=753882

It affects all distributions afaik and it can make any app/package using XDG_RUNTIME_DIR crash if it's used with root privileges (including dconf)...

This is a huge bug. I think the most relevant person to look into this on your side is Martin Pitt. Let us know if we can help on our side. As always we're available at #linuxmint-dev on irc.spotchat.org.

Here's a quick way to troubleshoot it:

echo $XDG_RUNTIME_DIR
sudo su -
echo $XDG_RUNTIME_DIR

In raring, this returns different paths. In saucy they collide.

This is because /etc/pam.d/common-session* no longer use Ubuntu's libpam-xdg-support (xdg_support.so) but the systemd pam module.

As far as I understand it from the https://bugzilla.redhat.com/show_bug.cgi?id=753882, this isn't actually a bug in systemd, but a change by design.

We're considering solutions in Mint and we'd love to talk to you about it. We've a few ideas we can run by you and it would be better for everyone if we tackled this the same way in Saucy/Petra and got involved in the upstream discussion.

[David Henningsson (diwic)]

Aha, thanks for that. I've been trying to find a way to reproduce the bug and with the help of comment #46 I got one that worked for me:

sudo su -
pacmd list

This will result in an error message and the directory being owned by root, which screws up further connections.

This does not happen when trying to use the native/normal protocol (e g used by paplay or pactl), because that connection, I believe, uses the PULSE_SERVER x11 property ( see "xprop -root | grep PULSE_SERVER" ).

Pacmd goes straight ahead and calls pa_runtime_path which does a chown on the directory, and normal clients can do that in more unusual situations too, e g if there is no such x11 property.

[Clement Lefebvre (clementlefebvre)]

Please don't use that as a solution... it's just for the purpose of troubleshooting:

- Add the following to /etc/profile

if [ "`id -u`" -eq 0 ]; then
  mkdir -p /run/user/0
  XDG_RUNTIME_DIR='/run/user/0'
fi

- log out and log back in.

This should force the system to behave like it did in raring. So if you're joe and your uid is 1000, it looks like this:

user -> /run/user/1000
sudo -> /home/joe/.cache (which was really bad.. but heh, at least it worked)
gksu -> /root/.cache
su - -> /run/user/0

You can test that by running a script or a program which calls g_get_user_runtime_dir() from glib and outputs it somewhere you can see.

Here's an example (main.c):

#include <stdio.h>
#include <stdlib.h>
#include <glib.h>

int main(void)
{
  const char * runtime_dir = g_get_user_runtime_dir();
  char * cmd = g_strdup_printf("notify-send 'Runtime directory is %s'", runtime_dir);
  FILE *fp = popen(cmd, "r");
  pclose(fp);
  exit(0);
}

Compile it with "gcc -Wall main.c $(pkg-config --cflags --libs glib-2.0)", you'll need the glib dev package installed.

Then mv a.out somewhere in /usr/bin and run that as yourself, with sudo, with gksu and as root behind su -.

[Clement Lefebvre (clementlefebvre)]

^^ this is mostly for the Ubuntu developers by the way. Please don't modify your /etc/profile unless you know your way around the tty consoles and how to repair cache/run permissions. You could find yourself unable to log back in.

[Clement (clement-redhat-bugs)]

Hi everyone,

In Ubuntu, raring used libpam-xdg-support which was setting XDG_RUNTIME_DIR or not based on getuid(). In Saucy, it's changed to the systemd PAM module and the behaviour is different.

Say joe is user 1000, in raring his runtime directory was:

- /run/user/joe (when running an app)
- /home/joe/.cache (when running an app with sudo)
- /root/.cache (when running an app with gksu)
- /run/user/root (when running an app as root after an "su -")

In saucy, his runtime directory is:

- /run/user/1000 (when running an app)
- /home/joe/.cache (when running an app with sudo)
- /root/.cache (when running an app with gksu)
- /run/user/1000 (when running an app as root after an "su -")

As you can see it's the exact same (other than the fact that we've traded usernames for uids as required upstream) for every case except for "su -".

sudo seems to fall in a category where it's using the fallback... I wish it didn't write root files in the ~ dir, but at least that worked.

Before I go on further, let me say that I've no experience with systemd (this is all new to me), very little with PAM and I'm not here to have an opinion but to seek your advice.

It looks to me like systemd behaves the way it should but that breaks with the way things worked before. Is the solution either for systemd to set XDG_RUNTIME_DIR differently when the UID is 0, or for techs like glib and apps using this variable, to only rely on it when the UID isn't 0?

How should this be tackled by distributions between an upstream solution is adopted?

- Should we patch glib and individual apps to use a different runtime directory than XDG_RUNTIME_DIR when UID == 0?

- Should we patch the systemd PAM module to set XDG_RUNTIME_DIR with a different value based on the uid and not the loginuid?

We found a really hacky solution. Adding the following to /etc/profile sets XDG_RUNTIME_DIR the way the Ubuntu pam module used to set it in raring:

if [ "`id -u`" -eq 0 ]; then
  mkdir -p /run/user/0
  XDG_RUNTIME_DIR='/run/user/0'
fi

I hope I won't get laughed at for mentioning that hack :)

I'm sure you guys will work out a proper solution. In the meantime we need a fix or a workaround. This affects almost all distros out there, with apps crashing all over the place, desktops freezing, dconf, pulseaudio breaking etc..

Is the /etc/profile hack a bad workaround? Would it tackle all cases? Would there be issues in your opinion? Is it the worst idea you've read in a long time? or does it sound like a good temporary solution?

Thanks in advance for your expertise on this and good luck from us in agreeing on a solution.

[David Henningsson (diwic)]

Ok, here's my take on the problem:

http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-November/019121.html

Let's give Lennart a day or two to respond, if he does not, let's deploy the patch.

[Richard (richard-redhat-bugs)]

(In reply to Clement Lefebvre from comment #53)
> Is the solution either for systemd to set
> XDG_RUNTIME_DIR differently when the UID is 0, or for techs like glib and
> apps using this variable, to only rely on it when the UID isn't 0?
[...]
> - Should we patch glib and individual apps to use a different runtime
> directory than XDG_RUNTIME_DIR when UID == 0?

The problem is the exact opposite of this. When someone is root
and 'su -' to a user, XDG_RUNTIME_DIR still points to the root-owned
directory and so is unusable by applications.

I am recommending that no one uses XDG_RUNTIME_DIR at all since you
cannot be sure it exists and has usable permissions.

[Matthias (matthias-redhat-bugs)]

su is the problem, not XDG_RUNTIME_DIR. There is simply no way to make su behave 'correctly' wrt to all the things a modern application might need from the user session. su is at best sufficient for running simple commandline tools like ls

[Clement (clement-redhat-bugs)]

Here's a scenario where this freezes the desktop entirely:

- Open a Cinnamon session
- Open nemo
- Right-click a directory and select "Open as Administrator"
- Wait a few minutes

The entire desktop freezes.

You can tail -f your .xsession-errors to see that the two nemo (the one run by cinnamon-session as you, and the one run as root via pkexec) collide with the same runtime directory (/run/user/1000). The root nemo is using dconf which creates a root:root rw------- dfonf/user file in /run/user/1000.

While that file exists, any application using dconf can either crash or freeze, as dconf is unable to function correctly. What usually happens in Cinnamon is that cinnamon-settings-daemon is the first to freeze.

In this example I used nemo and cinnamon, but this would happen with any other components using dconf, or even glib, or XDG_RUNTIME_DIR directly (like pulseaudio).

What we're doing at the moment is switching nemo to use gksu instead of pkexec... and we're considering patching glib to stop using XDG_RUNTIME_DIR entirely.

Of course glib is doing what it should, and so is pkexec.. and according to upstream so is systemd, but as you can see there's absolutely no way we can ship with a bug that critical. Apps cannot use the same runtime path when they are elevated with admin permissions, because they create files which permissions prevent other apps to access thus generating crashes and freezes.

This problem is brand new in Ubuntu. I understand that from a design point of view there might be issues with su and all, but we did not face random loss of pa servers, DE freezes and app crashes like we're facing now.

Again, I've no opinion as to which components should adapt here, but there is a clear issue and a huge impact on the users.

[Martin (martin-redhat-bugs)]

(In reply to Richard W.M. Jones from comment #54)
> The problem is the exact opposite of this. When someone is root
> and 'su -' to a user, XDG_RUNTIME_DIR still points to the root-owned
> directory and so is unusable by applications.

It works both ways -- in both cases the program you run under su gets an $XDG_RUNTIME_DIR which isn't owned by the target user, which either (1) results in EPERM issues (for "su user" from root) or (2) hijacking files and changing their owner (for "su -" from user).

> I am recommending that no one uses XDG_RUNTIME_DIR at all since you
> cannot be sure it exists and has usable permissions.

The idea is fine in general, it's just that due to this pam_systemd bug it doesn't promise what it says in the specification ("directory MUST be owned by the user").

Taking Lennart's concerns into account, I think an acceptable compromise would be for pam_systemd to unset $XDG_RUNTIME_DIR if it already exists but isn't owned by geteuid(). Then the program you run under su won't use a wrong runtime dir any more, but also doesn't pretend to be a full session.

(In reply to Matthias Clasen from comment #55)
> su is the problem, not XDG_RUNTIME_DIR.

It's not -- su has nothing to do with $XDG_* stuff. It's just running the standard PAM modules.

For the record, David proposed a workaround for pulse in http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-November/019121.html, but that would need to be applied to dconf, dbus, and everything else that uses $XDG_RUNTIME_DIR. That's just wrong, this check should be done in the pam_systemd dir.

[Florian (florian-redhat-bugs)]

(In reply to Martin Pitt from comment #57)
> Taking Lennart's concerns into account, I think an acceptable compromise
> would be for pam_systemd to unset $XDG_RUNTIME_DIR if it already exists but
> isn't owned by geteuid(). Then the program you run under su won't use a
> wrong runtime dir any more, but also doesn't pretend to be a full session.

I still hope that we'll eventually see something like XDG_RUNTIME_DIR that is universally available, so that we can avoid sprinkling fallback code across tons of programs (and that fallback code tends to be buggy).

[Martin (martin-redhat-bugs)]

Created attachment 823388
pam: Check $XDG_RUNTIME_DIR owner

This patch only sets $XDG_RUNTIME_DIR if its owned by the user. This fulfills the basedir spec in a minimal way. I can't say I'm truly happy with this (this is a new user session and should get its own runtime dir), but as this is contentious I'm not shooting for that. With that minimal solution we at least stop the dconf/pulse bugs.

This is a patch against current upstream trunk. I applied a backport to 204 to the Ubuntu package (it needs some fuzzing due to the slightly changed code structure).

[Martin Pitt (pitti)]

Patch sent to RedHat bug, and applied locally in my systemd packaging git. With that I think we shoudln't work around this in pulse. David's proposed patch might still be useful for upstream pulse though, if upstream systemd refuses to apply this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 204-5ubuntu6

---------------
systemd (204-5ubuntu6) trusty; urgency=low

  * Add pam-check-runtime-dir-user.patch: Don't set an existing
    $XDG_RUNTIME_DIR in the PAM module if it isn't owned by the session user.
    Otherwise su sessions get a runtime dir from a different user which leads
    to either permission errors or scribbling over the other user's files.
    (LP: #1197395)
  * Update debian/extra/60-keyboard.hwdb from current upstream trunk:
    - Fix Lenovo Z370 (LP: #1245189)
 -- Martin Pitt <email address hidden> Wed, 13 Nov 2013 14:00:55 +0100

[Colin (colin-redhat-bugs)]

Can you send this patch to systemd-devel? Red Hat Bugzilla is a crappy patch system.

On the actual content of your patch:

* We could also check whether uid != getuid() - i mean we know the code above uses loginuid, so indirecting via lstat() is weird. But I'm OK with the code as is.

* No need to log a message when this happens. We know it will happen, it's "normal", and there are already several log messages emitted for su.

[Clement (clement-redhat-bugs)]

Hi Martin,

In your patch you're checking for the ownership of the runtime dir. That's a good idea but I don't think it's enough.

For instance we're observing a conflict on /run/user/1000/dconf/user when we run dconf apps as root.

The conflict isn't because of the permissions of the runtime dir (in our tests, they seem to always be right.. i.e. /run/user/1000 belongs to 1000:1000, and so does the dconf dif).

The problem is with the "user" file created by dconf in /run/user/1000/dconf/. When it exists (it doesn't always since it's removed when dconf no longer needs it), it either belongs to 1000, or to root.

Of course in a systemd patch, you can't check that specific dconf file.

But it's just to illustrate that although the issue is with file permissions, I don't think a fix should involve checking these permissions, or at least that's not sufficient.

I think Colin is right here, we need to check the user id and categorically forbid different users (root included) to share the same runtime path.

In raring, the first thing libpam-xdg-support did was to check for the user ID.

[Clement Lefebvre (clementlefebvre)]

Hi Martin,

Thanks for stepping up on this.

I think Colin is right over on https://bugzilla.redhat.com/show_bug.cgi?id=753882, you need to check the UID. I added a comment there with an example where permissions on the runtime dir itself are fine.

[Martin (martin-redhat-bugs)]

(In reply to Colin Walters from comment #60)
> Can you send this patch to systemd-devel? Red Hat Bugzilla is a crappy
> patch system.

Can do, yes.

> On the actual content of your patch:
>
> * We could also check whether uid != getuid() - i mean we know the code
> above uses loginuid, so indirecting via lstat() is weird. But I'm OK with
> the code as is.

Does getuid() make any sense here? It's a PAM module, so do we ever expect this to be something else than root?

> * No need to log a message when this happens. We know it will happen, it's
> "normal", and there are already several log messages emitted for su.

Ack. That was primarily for debugging, so I guess I'll tone it down to LOG_DEBUG.

[Martin (martin-redhat-bugs)]

(In reply to Clement Lefebvre from comment #61)
> In your patch you're checking for the ownership of the runtime dir. That's a
> good idea but I don't think it's enough.
>
> For instance we're observing a conflict on /run/user/1000/dconf/user when we
> run dconf apps as root.

But these shouldn't use that runtime dir in the first place. As soon as you have a root process scribbling over your user's runtime dir, you have lost. That's precisely what we want to avoid here, isn't it?

> The problem is with the "user" file created by dconf in
> /run/user/1000/dconf/. When it exists (it doesn't always since it's removed
> when dconf no longer needs it), it either belongs to 1000, or to root.

It should never belong to root.

> I think Colin is right here, we need to check the user id and categorically
> forbid different users (root included) to share the same runtime path.

That's what this patch is supposed to do. What would be the scenario where that fails?

Note that there are still cases where this would fail. For example, if you use sudo (without -i), that doesn't involve PAM, but might (depending on the config) keep the $XDG_* variables around for the process you run through it. That doesn't happen on the default sudo configuration, but you can tell it to keep the whole environment.

[Colin (colin-redhat-bugs)]

Clement: basically Martin's patch should prevent that situation from occurring in the first place.

(It won't undo the damage, but...no one is talking about a plan for that since it's *really* ugly)

[Martin (martin-redhat-bugs)]

(In reply to Colin Walters from comment #64)
> (It won't undo the damage, but...no one is talking about a plan for that
> since it's *really* ugly)

No, but /run being a tmpfs, the next reboot or at least session restart will clean it up. Before you do that, you won't run the new PAM module anyway.

[Colin (colin-redhat-bugs)]

(In reply to Martin Pitt from comment #65)

> No, but /run being a tmpfs, the next reboot or at least session restart will
> clean it up. Before you do that, you won't run the new PAM module anyway.

Right, for some reason I had been thinking files were written owned by root to /home/user, but that's not the case.

(In reply to Martin Pitt from comment #62)
>
> Does getuid() make any sense here? It's a PAM module, so do we ever expect
> this to be something else than root?

Yeah, I meant: pam_get_item(pamh, PAM_USER, &user);

But I'm unable to construct a scenario where this really matters, so let's just go with your lstat() approach.

[Martin (martin-redhat-bugs)]

(In reply to Colin Walters from comment #60)
> Can you send this patch to systemd-devel? Red Hat Bugzilla is a crappy
> patch system.

Done now, with INFO -> DEBUG as discussed.

> On the actual content of your patch:

Thanks for your review!

[Clement (clement-redhat-bugs)]

Hi Martin, Colin,

"That's what this patch is supposed to do. What would be the scenario where that fails?"

--> Sorry about this, you're right. I reviewed the patch again and it should prevent root from using the same runtime dir. I mustn't have read it properly the first time and I thought you were testing access rather than ownership. It looks good and it should take care of the test-case I mentioned pretty well.

[Clement Lefebvre (clementlefebvre)]

Hi Martin,

Just to echo my comment on bugzilla. I reviewed the patch again and you're entirely right, it deals with the problem pretty well. Sorry about the confusion. The patch looks good.

[David Henningsson (diwic)]

I wouldn't mind a Saucy SRU for this. It seems to hit quite a few people.

[Martin (martin-redhat-bugs)]

(In reply to Colin Walters from comment #60)
> Can you send this patch to systemd-devel? Red Hat Bugzilla is a crappy
> * We could also check whether uid != getuid() - i mean we know the code
> above uses loginuid, so indirecting via lstat() is weird. But I'm OK with
> the code as is.

Sorry for the confusion (on both sides, I suppose). For me audit_loginuid_from_pid() does not actually succeed, so it's falling back to pam_get_username(). But *if* that succeeds, the current patch is wrong indeed, we need to *always* get the username from PAM. But that's indeed a separate issue (and in fact it seems it's the original issue of this bug, which I didn't really fully understand until now). So we need to check pam_get_user() against the owner of $RUNTIME_DIR (as logind always gives us the one from the session, not the one for the target user) to fix the "root destroys my runtime dir" issue, and secondly we would ideally drop the audit_loginuid_from_pid() thing as it's not really what we want. I'll follow up on the upstream ML with updated patches.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ville Ranki (ville-ranki)]

For end user this is visible as any application (rhythmbox, flash in browser, etc) freezing totally if trying to play audio. It would be really good idea to update systemd on Saucy asap.

[Colin (colin-redhat-bugs)]

*** Bug 1037285 has been marked as a duplicate of this bug. ***

[Colin (colin-redhat-bugs)]

For those not following the list,

http://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f

I haven't tried testing this commit myself, as

http://cgit.freedesktop.org/polkit/commit/?id=8635ffc16aeff6a07d675f861fe0dea03ea81d7e

works around it now too.

[xan (xan-zappa)]

Hi there,
just tried this evening to read a film with Totem and VLC - and got this bug, too.

Fyi, if it helps, here is the terminal output I got when trying to read a film with VLC:

Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Failed to create secure directory (/run/user/1000/pulse): Permission non accordée
[0xaf054be0] pulse audio output error: PulseAudio server connection failure: Connexion refusée
Failed to create secure directory (/run/user/1000/pulse): Permission non accordée
[0x9fc5f70] access_http access error: error: HTTP/1.1 403 Forbidden
[0x9fc5f70] access_http access error: error: HTTP/1.1 403 Forbidden
[0x9fc5f70] access_mms access error: invalid chunk FATAL (0x3f3c)
[0x9fc5f70] access_mms access error: header size == 0
[0xa136978] main demux meta error: no suitable access module for `http://services.tvrage.com/feeds/search.php?show=Misfits'

thanks in advance for the help =)

[Martin Pitt (pitti)]

Uploaded fix for saucy, now waiting for SRU team to review/accept.

[Stéphane Graber (stgraber)]

Hello Davide, or anyone else affected,

Accepted systemd into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/systemd/204-0ubuntu19.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Id2ndR (id2ndr)]

The packages from -proposed fixed the bug for me after rebooting the computer.

[Steve White (stevan-white)]

Hi, with some difficulty I installed the -proposed packages for saucy having to do with systemd.
This is a Lenovo E135 running Saucy.

This cleared up several problems for me, some related to sound, some not obviously related.

One not mentioned here exactly:
FlashPlugin in Firefox made like an old TV showing static, and the message
   "an error occurred, try again later"
(this message has been reported appearing in other situations, too.)

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 204-0ubuntu19.1

---------------
systemd (204-0ubuntu19.1) saucy-proposed; urgency=low

  * Add pam-check-runtime-dir-user.patch: Don't set an existing
    $XDG_RUNTIME_DIR in the PAM module if it isn't owned by the session user.
    Otherwise su sessions get a runtime dir from a different user which leads
    to either permission errors or scribbling over the other user's files.
    (Backported from current trusty package) (LP: #1197395)
  * debian/extra/60-keyboard.hwdb: Backport latest maps from trusty, as per
    standing SRU exception:
    - Fix Lenovo Z370 (LP: #1245189)
    - Add Toshiba Satellite U940
 -- Martin Pitt <email address hidden> Fri, 06 Dec 2013 08:37:14 +0100

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Wolfgang (wolfgang-redhat-bugs)]

Could you please apply those commits in fedora.
That /run/user/1000/dconf/ isn't writeable produce crashes in other applications.
https://bugzilla.redhat.com/show_bug.cgi?id=1044542

Thank you

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 1044542 has been marked as a duplicate of this bug. ***

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 961890 has been marked as a duplicate of this bug. ***

[Nivag (nivag-redhat-bugs)]

I applied the work-around given by Wolfgang in https://bugzilla.redhat.com/show_bug.cgi?id=961890#c39 to get around the problem. I am user 'gavin' (1000).

# cd /run/user/1000/dconf
# ll
total 4
-rw-------. 1 root root 2 Jan 18 08:27 user
# chown -R gavin:gavin user
# ll
total 4
-rw-------. 1 gavin gavin 2 Jan 18 15:05 user
#

I was then able to start caja without having to logout or reboot.

Thanks Wolfgang!

[Mikhail (mikhail-redhat-bugs)]

Like to hear that something going to be fixed here.
Will this fix be available in Fedora 20 or not?

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 1059388 has been marked as a duplicate of this bug. ***

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 1000164 has been marked as a duplicate of this bug. ***

[Kelly-Rand (kelly-rand-redhat-bugs)]

Another user waiting for the patch to manifest itself to F20.

Kernel-3.13.3-201.x86_64
Mate desktop

[Charles (charles-redhat-bugs)]

The fix should be available in Fedora20 now:

(7:58:39 AM) ccrouch: is there any chance of getting http://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f backported to systemd v2.0.8 in Fedora20?
(7:58:39 AM) ccrouch: it would address  https://bugzilla.redhat.com/show_bug.cgi?id=753882#c49 which I and others are running into
(8:03:33 AM) zdzichu: ccrouch: it's already in v208 (no dots) in F20 branch
(8:03:49 AM) zdzichu: http://pkgs.fedoraproject.org/cgit/systemd.git/commit/0268-pam_systemd-do-not-set-XDG_RUNTIME_DIR-if-the-sessio.patch?h=f20&id=a52f6741bd20d8383d75ad852a37699fbfb4b896
(8:05:59 AM) zdzichu: ccrouch: in 208-15 http://pkgs.fedoraproject.org/cgit/systemd.git/commit/systemd.spec?h=f20&id=a52f6741bd20d8383d75ad852a37699fbfb4b896

[Bill (bill-redhat-bugs)]

looks like we're working again?

=====
[flowerpt@aughra ~]$ rpm -q systemd
systemd-208-16.fc20.x86_64
[flowerpt@aughra ~]$ echo $XDG_RUNTIME_DIR
/run/user/1001
[flowerpt@aughra ~]$ ls -ld /run/user/1001
drwx------ 9 flowerpt flowerpt 220 Apr 24 00:32 /run/user/1001
[flowerpt@aughra ~]$ su -
Password:
Last login: Fri Apr 25 10:12:08 EDT 2014 on pts/4
[root@aughra ~]# echo $XDG_RUNTIME_DIR

[root@aughra ~]# ls -ld /run/user/1001
drwx------ 9 flowerpt flowerpt 220 Apr 24 00:32 /run/user/1001
[root@aughra ~]# su - flowerpt
Last login: Fri Apr 25 10:12:18 EDT 2014 on pts/4
[flowerpt@aughra ~]$ echo $XDG_RUNTIME_DIR
/run/user/1001
[flowerpt@aughra ~]$ ls -ld /run/user/1001
drwx------ 9 flowerpt flowerpt 220 Apr 24 00:32 /run/user/1001
=====

[W (w-redhat-bugs)]

Hello
Any chance this update could be made available for Fedora 19?
Much appreciated and kind regards.

[Raphael (raphael-redhat-bugs)]

*** Bug 1104951 has been marked as a duplicate of this bug. ***

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 1165182 has been marked as a duplicate of this bug. ***

[Wolfgang (wolfgang-redhat-bugs)]

msg = 0xc5ab90 "unable to create file '/run/user/1000/dconf/user': Keine Berechtigung. dconf will not work properly."
        msg_alloc = 0xc5ab90 "unable to create file '/run/user/1000/dconf/user': Keine Berechtigung. dconf will not work properly.

He guys, the issue is back in f21.

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 984279 has been marked as a duplicate of this bug. ***

[Mildred (mildred-redhat-bugs)]

Is there an upstream bug report ? If not, I suggest this could be a better place to discuss this issue. Or perhaps not.

I think, as many others in this thread, that the solution we came to is a half solution only. Not setting XDG_RUNTIME_DIR at all when using 'su -l' breaks many things, and not just graphical applications. I'm one of those people that things running graphical applications using su is a bad idea.

There is a reason behind the distinction between 'su' and 'su --login'. The latter is supposed to recreate a complete login environment. I think it then should also register a session within logind and of course provide a XDG_RUNTIME_DIR.

I came across this issue trying to use 'systemctl --user' over 'su' to activate a (pulseaudio) systemd unit for a ad-hoc user. This command appears in a deployment shell script and I had to set XDG_RUNTIME_DIR manually in a non portable way. I do not like it.

This is to say that the problem is not just with graphical application, but to anything that happens to use XDG_RUNTIME_DIR. And it seems that more and more console applications should use this.

Perhaps using 'su' for that is wrong and we should have another command that runs the exact same pam modules than login.

[Raphael (raphael-redhat-bugs)]

(In reply to Mildred from comment #87)
…
> I think, as many others in this thread, that the solution we came to is a
> half solution only. Not setting XDG_RUNTIME_DIR at all when using 'su -l'
> breaks many things, and not just graphical applications. I'm one of those
> people that things running graphical applications using su is a bad idea.
+1

…
> This is to say that the problem is not just with graphical application, but
> to anything that happens to use XDG_RUNTIME_DIR. And it seems that more and
> more console applications should use this.
All graphical applications that need root access use gksu / pkexec, so this will call su (without -l option).

> Perhaps using 'su' for that is wrong and we should have another command that
> runs the exact same pam modules than login.
So do you think a wrapper für 'su' will solve most of the issues? Please don't be so naive to think more complexity will solve anything, there's already too much of it! [rant] Reducing complexity should always be a big goal. [/rant]

[Mildred (mildred-redhat-bugs)]

> So do you think a wrapper für 'su' will solve most of the issues? Please don't be so naive to think more complexity will solve anything, there's already too much of it! [rant] Reducing complexity should always be a big goal. [/rant]

I was more thinking of another PAM configuration with a slightly different semantic than su. it could be another command like `su` or an option that would use a different PAM configuration. It would be identical to the login command. Then again, that's probably what `su --login` is for.

[Raphael (raphael-redhat-bugs)]

The new scratch build is okay with a nice menu icon. But the icon is not the same as the window icon. Tested with the x86_64 package.

[Raphael (raphael-redhat-bugs)]

(In reply to Raphael Groner from comment #90)
This was spam, sorry for the noise. :(((

[Dariusz (milley)]

This bug affects me today on actual elementary 0.3 freya

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 1234318 has been marked as a duplicate of this bug. ***

[Jan (jan-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

[Jan (jan-redhat-bugs)]

Since the discussion in this bugzilla really died out a year ago, and there's no clear resolution, any further discussion about propagating/unsetting XDG_RUNTIME_DIR should be moved upstream.

[Richard (richard-redhat-bugs)]

Setting the resolution, per comment 94.

[CoolAller (coolaller-redhat-bugs)]

It is impossible to use DE MATE. All the same error described above (using 100% CPU and memory leak.)
strace -f $(pidof mate-settings-daemon | sed 's/([0-9]*)/-p \1/g'):

6240 recvmsg(3, 0x7ffda79f9640, 0) = -1 EAGAIN (Resource temporarily unavailable)
6240 recvmsg(3, 0x7ffda79f9640, 0) = -1 EAGAIN (Resource temporarily unavailable)
6240 munmap(0x7f87d53b6000, 21236) = 0
6240 access("/run", F_OK) = 0
6240 stat("/run", {st_mode=S_IFDIR|0755, st_size=860, ...}) = 0
6240 access("/run/user", F_OK) = 0
6240 stat("/run/user", {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
6240 access("/run/user/1000", F_OK) = 0
6240 stat("/run/user/1000", {st_mode=S_IFDIR|0700, st_size=140, ...}) = 0
6240 access("/run/user/1000/dconf", F_OK) = 0
6240 stat("/run/user/1000/dconf", {st_mode=S_IFDIR|0700, st_size=60, ...}) = 0
__________________________________________________________________________
6240 open("/run/user/1000/dconf/user", O_RDWR|O_CREAT, 0600) = -1 EACCES (Permission denied)
__________________________________________________________________________
6240 write(2, "\n(mate-settings-daemon:6240): dc"..., 150) = 150
6240 close(-1) = -1 EBADF (Bad file descriptor)
6240 open("/home/coolaller/.config/dconf/user", O_RDONLY) = 16
6240 fstat(16, {st_mode=S_IFREG|0644, st_size=21236, ...}) = 0
6240 mmap(NULL, 21236, PROT_READ, MAP_PRIVATE, 16, 0) = 0x7f87d53b6000
6240 close(16) = 0
6240 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=3, revents=POLLOUT}])
6240 writev(3, [{"\203\2\1\0", 4}, {NULL, 0}, {"", 0}], 3) = 4
6240 poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])
6240 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\1\2\353+\200\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 544

This continues from 2013, is it really impossible to fix? Do something with this error, please!

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 1292670 has been marked as a duplicate of this bug. ***

[Wolfgang (wolfgang-redhat-bugs)]

Another report about!!!
https://bugzilla.redhat.com/show_bug.cgi?id=1292670
Please fix it.
https://github.com/linuxmint/systemd-rosa/commit/50d0f45f22494e004b927060bc0fc2d32136dee6
LinuxMint can do that. Why not fedora ?
Maybe you want that users switch to LinuxMint.

[Raphael (raphael-redhat-bugs)]

Wolfgang, it seems to be fixed in RHEL.

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 1357129 has been marked as a duplicate of this bug. ***

[Wolfgang (wolfgang-redhat-bugs)]

*** Bug 1403257 has been marked as a duplicate of this bug. ***

[Yaniv (yaniv-redhat-bugs)]

(In reply to Jan Synacek from comment #94)
> Since the discussion in this bugzilla really died out a year ago, and
> there's no clear resolution, any further discussion about
> propagating/unsetting XDG_RUNTIME_DIR should be moved upstream.

Since I've just hit by this, in 2017, with Fedora 25, any idea what ever happened to the upstream discussion?

[Ccurtis0 (ccurtis0)]

With the caveat that I haven't followed the entire thread, I had a similar problem today on an older 14.04 release: the owner of /run/user/$id/pulse would "spontaneously" become root. Comment #34 says this is easily reproducible when running pkexec/synaptic. I believe I can explain - broadly - what is happening by describing what I can confirm.

First, here is one way to reproduce the problem:
*) PulseAudio (v4 in this case) starts as a normal user.
*) As root (via sudo su -), run 'aplay --list-devices'
*) /run/user/$id/pulse is now owned by root.

Tracing 'aplay' I can see that it is dlopen()ing a bunch of pulseaudio support libraries. *Somehow* they (the pulseaudio support libraries, I presume) determine that pusleaudio is running. They extract a cookie from /root/.config/cookie and try to connect to the server via /run/user/$id/pulse/native socket.

At this point, I don't know what the code is trying to do, but what it _does_ do is this:

mkdir("/run/user/1000/pulse", 0700) = -1 EEXIST (File exists)
open("/run/user/1000/pulse", O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 5
fchown(5, 0, 0) = 0
fchmod(5, 0700) = 0
[...]
getuid() = 0
socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 5
connect(5, {sa_family=AF_LOCAL, sun_path="/run/user/1000/pulse/native"}, 110) = -1 ENOENT (No such file or directory)
[...]

If my supposition is true that this is in the pulseaudio libraries, any application running as root (like synaptic) is going to disable the sound server when it tries to play audio through pulseaudio.

I scanned the pulseaudio changelogs and didn't see anything mentioning this, but I can also confirm that Ubuntu 17.10 with pulseaudio version 10 and aplay version 1.1.3 does not do this. The older aplay version was 1.0.27.2.

In Ubuntu 17.10 pulseaudio is being run by 'gdm' but the same aplay strace shows that it now looks for the socket in /var/run/pulse/native instead of any particular UID in /run. It's unclear to me if the problem is solved (in pulseaudio, if the culprit) or just band-aided by changing the configuration (perhaps of ALSA integration with pulseaudio).

[Daniel van Vugt (vanvugt)]

This bug is closed. If you have any issues, please open a new bug.