Pulse permissions after upgrade to 13.2

After upgrading to 13.2 “play” command stopped working with an error like this:

stan@linux-ektu:~/bin> play /home/stan/Music/alarms/timesUp.mp3
Failed to create secure directory (/run/user/1000/pulse): Permission denied
play FAIL formats: can't open output file `default': can not open audio device: Connection refused
stan@linux-ektu:~/bin> 

Changing ownership of /run/user/1000/pulse from root to myself fixes it temporarily, next time I wait for alarm it never plays.

All media players seem to work okay so far.

Perhaps it should be moved to “Applications” forum but this happened right after upgrade so I am not sure.

What were the original permission? Changing ownership is seldom a solution. Are your a member of the audio group. Is the alarm running as you or as root or some other user ID?

/run/user/1000/pulse owned by root with read+write permissions and no access for anybody else. I’ve changed it yesterday but it reverted after a while. I’m running “play” as myself and I just added myself to the audio group and to pulse and pulse-access for good measure, no luck.

My user rights and group membership shouldn’t have been affected by the upgrade, right? Afaik, on 13.1 the only group I belonged to was users and that was enough. I don’t know what permissions were there before the upgrade and I obviously can’t check.

Running as root also fails:

linux-ektu:~ # play /home/stan/Music/alarms/timesUp.mp3
play FAIL formats: can't open output file `default': can not open audio device: Connection refused
linux-ektu:~ # 

Pulseaudio is installed from 13.2 Update repository.

I’m still on 13.1 and that equivalent location is owned by me. Since the path has my UID in it I’m not suprised. Check and see if your UID is still 1000. It really should not change but that is my best guess to check maybe someone else has a better Idea or can check the analogous location on 13.2

Yes, UID is still 1000.

I understand that when evoked Pulse creates it’s own directory in /run/user/1000 but gives it root permissions or overwrites existing ones. On my unupdated machines that directory owned by me, not by root.

I just tried to open Pusle Audio Volume Control and it shows error in the opened window. I don’t see how I copy that and it’s quite long:

"Connection to PulseAudio failed, retry in 5s

This is likely because PULSE_SERVER in the Environment/X11 Root Window Properties or default-server in client.conf is misconfigured"

There’s more but it’s about Pulse crashing, not failing to start. In the terminal window, in the meantime, there’s this:

stan@linux-ektu:~> pavucontrol

** (pavucontrol:12921): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(pavucontrol:12921): GLib-GObject-WARNING **: The property GtkMisc:xpad is deprecated and shouldn't be used anymore. It will be removed in a future version.

(pavucontrol:12921): GLib-GObject-WARNING **: The property GtkMisc:ypad is deprecated and shouldn't be used anymore. It will be removed in a future version.

(pavucontrol:12921): GLib-GObject-WARNING **: The property GtkAlignment:bottom-padding is deprecated and shouldn't be used anymore. It will be removed in a future version.

(pavucontrol:12921): GLib-GObject-WARNING **: The property GtkAlignment:left-padding is deprecated and shouldn't be used anymore. It will be removed in a future version.

(pavucontrol:12921): GLib-GObject-WARNING **: The property GtkAlignment:right-padding is deprecated and shouldn't be used anymore. It will be removed in a future version.

(pavucontrol:12921): GLib-GObject-WARNING **: The property GtkContainer:resize-mode is deprecated and shouldn't be used anymore. It will be removed in a future version.
Failed to create secure directory (/run/user/1000/pulse): Permission denied
Failed to create secure directory (/run/user/1000/pulse): Permission denied
Failed to create secure directory (/run/user/1000/pulse): Permission denied
Failed to create secure directory (/run/user/1000/pulse): Permission denied
^C
stan@linux-ektu:~> 

Do you think I should ask this in another forum?

Otoh, during upgrade something could have happened to pulse, perhaps some of its components were originally installed from a different repo that was disabled during “zypper dup”.

This can only happen if you run pulseaudio as root inside the user’s session (it normally runs as user), and the environment is set wrong.
And as /run is a tmpfs, the directory is created freshly during login, with the user’s permissions.

So, are you running any applications as root inside the user session? How are you doing that? (Hint: you should not use “su” or “sudo” for running GUI applications as root!)
There was a bug in xdg-utils (xdg-su) causing something like this, but IIRC that was in 13.1 and should be fixed already.

No, I’m not starting any GUI programs with root privileges, I’m not doing anything differently from before the upgrade, it was only a couple of days ago.

I’ve taken back the ownership with “sudo chown -R stan /run/user/1000/pulse” and so far it stuck. Logged out and logged back in again, rebooted - directory is still mine. Fingers crossed, it will stay that way in the future.

Ok, but that directory can only be owned by root if a program that runs as root changes the ownership (only root is allowed to do that), or if a program running as root creates it in the first place.
And this doesn’t survive a reboot.

I’ve taken back the ownership with “sudo chown -R stan /run/user/1000/pulse” and so far it stuck. Logged out and logged back in again, rebooted - directory is still mine. Fingers crossed, it will stay that way in the future.

Again, this directory is deleted on shutdown (it does not exist on your hard disk at all). So just rebooting should have “fixed” it too.

So far it holds, but now the keyring won’t open on login. I’ll have to observe the system for some more, fix keyring problem, see how it all goes.

What does this print?

grep keyring /etc/pam.d/*

You should get something similar like this:

# grep keyring /etc/pam.d/*/etc/pam.d/common-auth:auth     optional        pam_gnome_keyring.so
/etc/pam.d/common-auth-pc:auth  optional        pam_gnome_keyring.so
/etc/pam.d/common-password:password     optional        pam_gnome_keyring.so    use_authtok
/etc/pam.d/common-password-pc:password  optional        pam_gnome_keyring.so    use_authtok
/etc/pam.d/common-session:session       optional        pam_gnome_keyring.so    auto_start only_if=gdm,gdm-password,lxdm,lightdm 
/etc/pam.d/common-session-pc:session    optional        pam_gnome_keyring.so    auto_start only_if=gdm,gdm-password,lxdm,lightdm 

If not, run this:

sudo /usr/sbin/pam-config -a --gnome_keyring --gnome_keyring-auto_start --gnome_keyring-only_if=gdm,gdm-password,lxdm,lightdm

or reinstall the package “gnome-keyring-pam” via:

sudo zypper in -f gnome-keyring-pam

And what displaymanager are you using? As can be seen in the output, this only works with gdm, lxdm, and lightdm.
If you use something else, you might try adding it to the list, preferably by running a modified “pam-config” line with that entry added.
Something like this:

sudo /usr/sbin/pam-config -a --gnome_keyring --gnome_keyring-auto_start --gnome_keyring-only_if=gdm,gdm-password,lxdm,lightdm,kdm

Umm, somehow my keyring reverted to my login password, keyrings, I understand, are managed separately from logins, so it’s possible that logging in and out caused some changes to it. I reset it back to blank and so far everything is okay, password prompt is gone and the sound is still there.

There was a similar thread about a year ago and it ended in the same way - pulse issue went away on its own. Taking ownership might have been only a temporary fix, until the next login/restart.

Initially, however, I can’t explain how pulse was giving ownership to root and not once but regularly, over the course of several days.

And what keyring are you actually talking about?
I meant gnome-keyring, that should be unlocked automatically on login with your user password.

Anyway, the password should not be changed automatically, and definitely not by logging in and out.

Initially, however, I can’t explain how pulse was giving ownership to root and not once but regularly, over the course of several days.

pulse is not giving ownership to anybody.
Again, pulse runs as user and it is started on login, and that directory is created from scratch when you first login after boot (owned by your user).

It can only be owned by root if something running as root changed the ownership, or created it as owned by root in the first place.

On 2015-01-16 14:36, Stan Ice wrote:

> Initially, however, I can’t explain how pulse was giving ownership to
> root and not once but regularly, over the course of several days.

Curious.

But the X server runs as root. It should drop privileges, but… :-?
Some component might be running as root.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

DO you ever log in as root to a GUI? If so stop it.

On 2015-01-16 16:36, gogalthorp wrote:
>
> DO you ever log in as root to a GUI? If so stop it.

He said not.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Just looked at my bash history, both as myself and as “su” - I didn’t start any GUI or any CL apps or players with root privileges since update, and I certainly never logged in as root.

Since the problem can’t be replicated anymore it could probably be written off as a one time post upgrade quirk. Maybe X server didn’t release the privilges indeed.

By “keyring” I meant “Login” entry that appears under Passwords in “Passwords and Keys” program in XFCE Accessories. It can have a separate password from my login and to open it automatically I set this keyring’s password to blank. I’ve dealt with it a long time ago and so not sure how exactly it’s supposed to work but that was the solution I found then and it still works now, except a few days after the upgrade it started reporting that it’s unlocked and I had to set password to blank again.

But the X server does not use PulseAudio nor starts it, and it has no business accessing/modifying /run/user/xxx/pulse either.

Well, you can also run programs as root via xdg-su, kdesu, gnomesu, sudo, and from the menu (YaST e.g.).
There was a bug in xdg-su that could cause changing the owner of /run/user/xxx/pulse to root, but that should be fixed.

Since the problem can’t be replicated anymore it could probably be written off as a one time post upgrade quirk. Maybe X server didn’t release the privilges indeed.

It’s normal that the X server runs as root. That shouldn’t cause this problem.

By “keyring” I meant “Login” entry that appears under Passwords in “Passwords and Keys” program in XFCE Accessories. It can have a separate password from my login and to open it automatically I set this keyring’s password to blank. I’ve dealt with it a long time ago and so not sure how exactly it’s supposed to work but that was the solution I found then and it still works now, except a few days after the upgrade it started reporting that it’s unlocked and I had to set password to blank again.

This is indeed gnome-keyring then I suppose.
As I wrote, when using gdm, lxdm, or lightdm, the keyring should be automatically unlocked at login via pam. For this to work it must have your user’s password I think.

If you use kdm, this isn’t done, you might try to add kdm to the list in the pam config as already mentioned.

And even if he did, that wouldn’t automatically touch any user files/directories.

It is actually more dangerous to run programs as root in your user’s X session than logging in as root regarding this.
If the environment is setup wrong, they might end up accessing user’s files/directories like /run/user/xxx/ or config files in the user’s home and even change the ownership.

When you login as root, it is a completely separate session running as user “root” with /root as home directory and /run/user/0/ as XDG_RUNTIME directory. So something like this cannot happen (unless you modify user files yourself).

I “figured” it out - on Xfce Yast uses GTK, takes over pulse directory as root and then never releases it.

Just checked, changed ownership back to myself, started Yast, and sure enough, it took over /run/user/1000/pulse and never let it go. Works the same for either Software Management or the main Yast panel.

Well, sounds exactly like this bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=852015

But that should have been fixed via an online update in 13.1.

So either the fixes did not make it into 13.2 for some reason, or there’s a regression, or the fixes never worked.

In any case, you should probably reopen that bug report, or create a new one.

Personally I don’t use pulseaudio, but I have it running in a Tumbleweed VM I use for testing things. I never experienced that problem there using KDE. So probably that’s specific to XFCE, gnomesu (which is what xdg-su uses in XFCE), or YaST GTK.

Does this also happen when you run the Qt version if YaST? The GTK interface has been dropped recently because it has no maintainer, and there were some (severe) problems that nobody worked on.

xdg-su -c /sbin/yast2 --qt

Maybe also try using gnomesu or kdesu (whatever you have installed) instead of xdg-su.