On Sat, Oct 19, 2024 at 15:02:56 +1100, George at Clug wrote: > On Saturday, 19-10-2024 at 14:20 Greg Wooledge wrote: > > I also wonder whether runuser is actually needed there, or whether > > setpriv would be sufficient. It might depend on whether "notroot" is > > already logged in to establish a "seat" or whatever it's called with > > access to the audio devices. (That's another thing I'd want to test, > > if this were my project -- does "notroot" need to be logged in for > > this to work?) > > I was curious too: > > # runuser --user notloggedinnotrootuser -- bash -lic 'aplay > /usr/share/sounds/sound-icons/prompt.wav' > > aplay: main:831: audio open error: Host is down > > I guess you have to be logged in as yourself, using your own user > account, then open a terminal and su in as root.
Nice to know. I'm not too surprised by this result. > And I found that this worked even without the -l and -i > > # runuser --user loggedinnotrootuser -- bash -c 'aplay > /usr/share/sounds/sound-icons/prompt.wav' You shouldn't even need the bash -c. Bash is not playing any critical role here at all. > I was not able get "# sudo -u" to work in place of using runuser. Fascinating. So then setpriv definitely wouldn't work either. > So much more testing one could do. Indeed. So, if I understand correctly, the case that failed was: * Logout as yourself. * Login as root. * runuser --user yourself -- aplay sound And the case that worked was: * Login as yourself. * su * runuser --user yourself -- aplay sound I'm wondering whether the shell created by su has special access privileges inherited from your login session. I'd be curious whether this works: * Login as yourself. * Switch to a Linux virtual terminal (e.g. Crtl-Alt-F2) * Login as root on the VT * runuser --user yourself -- aplay sound If that fails, then a lot of roads are closed off. You can't play sounds from a root crontab job, etc. My understanding of PAM and systemd seats and all the other related stuff is still woefully incomplete. ............. Now let's do some testing on my own system. Debian 12. Logged in as myself (on tty1, then startx, currently in fvwm), in an opened rxvt-unicode terminal window: hobbit:~$ aplay /usr/share/sounds/alsa/Front_Center.wav Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono That played successfully. Next: hobbit:~$ su Password: root@hobbit:/home/greg# aplay /usr/share/sounds/alsa/Front_Center.wav XDG_RUNTIME_DIR (/run/user/1000) is not owned by us (uid 0), but by uid 1000! (This could e.g. happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.) Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono That *also* played successfully, despite the warning message. Next: t@hobbit:/home/greg# runuser -u greg -- aplay /usr/share/sounds/alsa/Front_Center.wav Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono That also played successfully, and had no warning. Next: root@hobbit:~# tty /dev/tty2 root@hobbit:~# aplay /usr/share/sounds/alsa/Front_Center.wav Playing WAVE .... After logging in on TTY 2 (Ctrl-Alt-F2), that also played successfully, with no warning. Perhaps the login session as root establishes its own PulseAudio or ALSA or ... I really have no idea. Next: root@hobbit:/home/greg# apt-get install at ... root@hobbit:/home/greg# at now + 1 minute warning: commands will be executed using /bin/sh at Sat Oct 19 09:07:00 2024 at> aplay /usr/share/sounds/alsa/Front_Center.wav at> <EOT> job 1 at Sat Oct 19 09:07:00 2024 After a minute, that *also* played. I got this familiar warning in email: XDG_RUNTIME_DIR (/run/user/1000) is not owned by us (uid 0), but by uid 1000! (This could e.g. happen if you try to connect to a non-root PulseAudio as a root user, over the native protocol. Don't do that.) Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono This tells me the at job inherited something from the su session, which in turn inherited something from my login session as greg. At the very least, it's inheriting XDG_RUNTIME_DIR as shown in the warning message. Perhaps it's getting all of these: root@hobbit:/home/greg# env | grep XDG XDG_SEAT=seat0 XDG_SESSION_TYPE=tty XDG_SESSION_CLASS=user XDG_VTNR=1 XDG_SESSION_ID=1 XDG_RUNTIME_DIR=/run/user/1000 Next test: root@hobbit:/home/greg# exit hobbit:~$ su - Password: root@hobbit:~# env | grep XDG root@hobbit:~# With a (partly? fully?) scrubbed environment, let's see what happens: root@hobbit:~# aplay /usr/share/sounds/alsa/Front_Center.wav Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono That played, with no warning. Hmm, does "su -" establish its own seat? It's not present in the environment. root@hobbit:~# env | grep seat root@hobbit:~# So, in conclusion, I really don't understand *nearly* enough about what's happening here.
