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

[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

[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

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

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

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

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

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

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