You likely run some stuff as root after running "su" instead of "su -"

CC: (none) => mageia, thierry.vignaud

Worth a try as a clue...  :)  However, I _always_ run "su -", never "su" -- a habit going back many years...

Is /run/user/500/gvfs "normal" or a sign of directory corruption?

Happens every time I try to play a sound...

$ paplay /usr/share/sounds/pop.wav 
Failed to create secure directory (/run/user/500/pulse): Permission denied
Connection failure: Connection refused

$ play /usr/share/sounds/pop.wav 
Failed to create secure directory (/run/user/500/pulse): Permission denied
Failed to create secure directory (/run/user/500/pulse): Permission denied
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

play FAIL formats: can't open output file `default': snd_pcm_open error: Connection refused


However, sound works just fine from firefox/nightly

audacity also works; though it dumps this at startup:
$ audacity &
[1] 14252
$ 
(process:14252): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(process:14252): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(process:14252): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(process:14252): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
Failed to create secure directory (/run/user/500/pulse): Permission denied
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

Failed to create secure directory (/run/user/500/pulse): Permission denied
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

Failed to create secure directory (/run/user/500/pulse): Permission denied
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

Failed to create secure directory (/run/user/500/pulse): Permission denied
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4582
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4582

(In reply to Pierre Fortin from comment #2)
> Worth a try as a clue...  :)  However, I _always_ run "su -", never "su" --
> a habit going back many years...
> 
> Is /run/user/500/gvfs "normal" or a sign of directory corruption?

Using su or su - doesn't matter at this time, as the XDG_RUNTIME_DIR is either preserved (su) or reinjected (su -).

I have patches pending to pam_systemd to fix this. I'll push them shortly. "su" will likely still be busted tho' (which is expected - su is a pretty basic utility ultimately).

Longer term, we are looking to create a new su that actually proxies X and PA properly (kinda like how it's done via "ssh localhost", but ensures root has it's own proper session. Unfortunately pam doesn't let you start a new session from within a session as this break immutable login ids (i.e. loginuid) which (I think) is related to the kernel audit subsystem. Anyway, work is progressing generally for a long term way to be able to more sensible run applications as root.

But ultimately the "correct" solution here is to split apps into frontend/backend designs with the frontend running non-privileges and the backend doing very little but running privileged - perhaps via polkit-based auth. Although I'm going off topic now....

If this is a stupid remark please throw it out, but I see stg in a Mageia 3 box which looks somewhat similar: when I start gedit from a terminal I see loads of errors that /run/user/500/dconf is owned by root:root instead of <USER>:<USER>.

When I add a line in msec --> security settings --> permissions, instructing ownership to change to <USER>:<USER>, the error does not occur anymore.

HTH

(In reply to Dick Gevers from comment #5)
> If this is a stupid remark please throw it out, but I see stg in a Mageia 3
> box which looks somewhat similar: when I start gedit from a terminal I see
> loads of errors that /run/user/500/dconf is owned by root:root instead of
> <USER>:<USER>.

This is what happens when you run GUI apps (or rather dbus apps) via su which inherits environment variables (and in this case XDG_RUNTIME_DIR) from the user. In Cauldron it's been worse as even "su -" would inherit this env var also.

Last night I pushed a fix for this in systemd (or rather logind) in cauldron.

In Mageia 3, the XDG_RUNTIME_DIR should be set to  that of the root user via "su -" (just tested) and should be unset under sudo (both -i and -s). I'd argue it should be set to that of the root user each time, but such is life - as running GUI apps as root is generally not recommended this isn't too bad.

> When I add a line in msec --> security settings --> permissions, instructing
> ownership to change to <USER>:<USER>, the error does not occur anymore.

You'd be better using tmpfiles for something like that IMO. But even better, just don't run GUI apps as root!

As mentioned, in the above comment, I suspect this should be fixed after a freshly booted, updated cauldron.

Colin, does this apply to running GUI as another user?  
[Background: for years, I've been doing "su - user2" and starting a 2nd claws-mail client.  Instance-1 of claws-mail handles professional accounts, instance-2 personal ones (12 [active]  accounts total).   Also, I did run into one of my scripts (written some time back) where it used XDG_RUNTIME_DIR and now failed under mga4; but not remembering why I used it, realized that $HOME was all I needed now...  :]

(In reply to Pierre Fortin from comment #8)
> Colin, does this apply to running GUI as another user?  

Kinda yeah. It really depends on whether the application (or it's libraries) makes use of the XDG constructs. As time goes on more and more apps/libs do and thus this kind of problem comes more to the fore.

The underlying problem is that it's not possible to create a "session within a session" (if you've seen the movie "Inception", then basically it doesn't apply to PAM sessions, even if you *think* it looks like it does :p)

There are various ways around this, one of them being "ssh user2@localhost". This should work nicely and give you a properly tracked user session and setup the XDG_RUNTIME_DIR for you properly.

Longer term, we're looking into providing solutions for this, e.g. an alternative version of su that does some of the same proxying stuff that ssh does for X11 but without the overhead of actually connecting over a network and doing encryption etc. It will properly register a new session and let you do all this properly (there is proof of concept systemd-su utility that goes half way there) but similar problems also exist in things like "screen" where no new session is registered and if the user then detaches and logs out, they will call pam_close_session() (or whatever the API is called) and their session might be tidied up - which would include killing the screen process which is basically the exact opposite of what you really want! This is the main reason the KillUserProcesses=no option is still in /etc/systemd/logind.conf (KillUserProcesses=yes would be much nicer overall!). So there are still a few things to do to get things working nicely and being tracked in an appropriate way.

Anyway, your "su - user2" should still kinda work if you don't need XDG_RUNTIME_DIR. If you do need it, then you can export it to some known PATH and just rm -rf that path. e.g. export XDG_RUNTIME_DIR=/home/user2/.xdg-runtime; rm -rf $XDG_RUNTIME_DIR; mkdir $XDG_RUNTIME_DIR; chown 700 $XDG_RUNTIME_DIR. Or something similar.

HTHs and explains things a little!

In reply to coling in comment #6

>This is what happens when you run GUI apps (or rather dbus apps) via su which >inherits environment variables (and in this case XDG_RUNTIME_DIR) from the user. >In Cauldron it's been worse as even "su -" would inherit this env var also.

That's not what I meant: I was referring to gedit being used by a (the) regular user (500) *not* as root, but buggy root ownership of the dconf directory interfering with the '500' use.

CC: (none) => dvgevers

(In reply to Dick Gevers from comment #10)
> That's not what I meant: I was referring to gedit being used by a (the)
> regular user (500) *not* as root, but buggy root ownership of the dconf
> directory interfering with the '500' use.

And I tried to explain that the buggy ownership of the users dconf directory is *caused* by running a dconf app as root which then *affects* gedit running as the user. That said I did say "dbus" rather than "dconf" so apologies if that was confusing.

Anyway, this should be fixed now.

No apologies needed. Thanks :)

closing according to comment #11

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Reopening. I experienced this issue recently on Mageia 5.

After investigating discussions here:
https://bugzilla.redhat.com/show_bug.cgi?id=753882
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1197395

I came to the conclusion that systemd is not really to blame. The behaviour of su is indeed as expected. It's inner workings is a little fuzzy: we want to switch to another user, but at the same time still inherit much of the original environment (no login).

Some distributions like LinuxMint do disagree however and patch systemd:
https://github.com/linuxmint/systemd-rosa/commit/50d0f45f22494e004b927060bc0fc2d32136dee6


Anyway, pulseaudio is the one who performs the chown to root of XDG_RUNTIME/DIR. The fix was posted here:
https://lists.freedesktop.org/archives/pulseaudio-discuss/2013-November/019121.html

The final commit never made it into pulseaudio-5.0-6.mga5. It was only introduced in pre 6.0 (5.99.2 to be exact).

I see 2 options here:
* backport pulseaudio-8.0-5.mga6.src.rpm. This could have potential compatibility problems
* apply the patch to 5.0

Status: RESOLVED => REOPENED
CC: (none) => smout.jan
Resolution: FIXED => (none)

Created attachment 7869 [details]
Patch based on git commit 076601ee28a442868ba4ab92a6f379190f6fa0ab

closing as old

Status: REOPENED => RESOLVED
Resolution: (none) => OLD