Multi-user X11 Shenanigans (feat. `ssh` and PipeWire)

Generally I avoid putting any files or applications which have to do with my work on my personal computers; however, after a hardware failure and a shipping delay left my work machine unusable for several days, I realized there were some minimum tasks which REQUIRE I install the chrome web browser, slack, and a couple of other efficiency / office tools.

I realized that X11 forwarding, which I've used for some gui-required remote applications, might actually let me run the application with an underprivileged user while still using my same desktop.

So: easy-peasy! Slap the -X flag onto ssh and we should be off to the races.

With google chrome securely installed to the user, ssh -X work-user@localhost seemed to work immediately! I slapped this in an easy-to-find, launcher script on my PATH and quickly added slack and the other tools.

BONUS: I could set the default web browser for this user to be google chrome and then clicking links in slack would automagically open the work user's chrome without adjusting my personal defaults!

Problems tho

At least it SEEMED like everything was working immediately. I ran into two sticking points.

Clipboard?

Clipboard seemed to work... one way! Anything I copied from applications on my main user pasted just fine into the application, but I couldn't copy things from google chrome. I tried to figure out why, but then eventually tried -Y instead of -X and it just worked. Something something trust me bro (says both X11 and the Arch Wiki), so I stopped trying to figure it out since it seemed like a WAY deeper dive than I'd hoped.

So since I wanted the clipboard forwarded (and I suppose the localhost, I'm-managing-this-user-myself level of trust seems Fine by me), I just swapped them all out for the -Y

# somewhere conveniently in my PATH called "slack"
#!/bin/sh
ssh -Y work-user@localhost -C slack

Audio... but only on SOME setups

On one computer, audio worked just fine! When I went to propagate this to my secondary personal, however, I ran into a weird issue where the USB audio card just wasn't available in the ssh -Y environment. It took me a bit of digging through "Help me, I have no audio at all" articles (a Linux-forum CLASSIC), before I finally found some articles talking about some oddities when sharing audio through simultaneous users.

Let me just admit that I know very little about the whole Linux sound ecosystem. When the Arch Wiki told me to switch to PipeWire... I did. Especially since there's "support for PulseAudio", and it worked out-of-the-box with all the weird audio-controller scripts I've written over the years, I had little reason not to mindlessly upgrade to the new, improved(?), low-level multimedia framework.

SO. From what I understand:

PulseAudio is a server which serves as a higher-level interface to PipeWire
PipeWire is the low-level audio framework which runs a separate session for every user, initializing PulseAudio or other servers as necessary
some audio interfaces (particularly the integrated ones) can be seamlessly used across several servers & sessions
... but not ALL of them

After trying the recommended "make sure everybody is in the audio group" and "make sure your PipeWire is configured right" and "make sure you restart all the pipewire and pulseaudio services" and what felt like dozens of useless, unhelpful suggestions, I finally landed in the right place. Apparently my USB device was reporting "busy" to the work user's audio configuration (no thanks to the SUPER helpful error message audio open error: Device or resource busy). We can fix this by making sure the pipewire instance for the work user is configured to point to the same server being used by my primary user.

Two pieces to that:

1. Enable PulseAudio server forwarding

I managed this with a PipeWire configuration file:

# under the PRIMARY user
# ~/.config/pipewire/pipewire-pulse.conf.d/share-audio-with-other-users.conf

pulse.properties = {
	server.address = [
		"unix:native"
		"tcp:4713"
	]
}

2. Use the forwarded PulseAudio server on the other user

Since I'm literally never going to log in to this user any other way, I adjusted the default configuration (but I think you can achieve the same thing with the PULSE_SERVER environment variable):

# under the WORK user
# ~/.config/pulse/client.conf

default-server = tcp:127.0.0.1:4713

4.7 KiB Raw Blame History

Multi-user X11 Shenanigans (feat. ssh and PipeWire)