One of the most annoying things I’ve had using the same machine for work and personal purposes is how the environments can get mixed up.
Someone sends you a link on the corporate slack, you click the link and BOOM – it appears on the personal Google Chrome instance – which means I have to focus on the right Chrome window, then click the link so it goes to the proper browser.
While I was trying to find solutions for this problem, someone pointed me to Qubes OS and it sounded too good to be true! True isolation between profiles, and even support for throwaway accounts! The downside was that all the instances were running on a Xen Hypervisor, which would be sub-optimal for my use case.
Then I tried to run two X sessions simultaneously, and my screen would go crazy by switching beetween them. Also sound would stop working because the first Chrome instance would take the audio card hostage. Xephyr didn’t work as expected with my tiling window manager. I was almost giving up.
hear angels singing and a bright light comes over me realize that if X-Forwarding over SSH works, there must be a way to start X applications under different user accounts, while preserving hardware video acceleration and keeping the footprint low – but would those apps honor the separation between environments?
One of the things I’ve forgot from my shady past doing linux-based thin clients was the
xhost tool. With a single command you can authorize a different user to open apps on an already-running X server.
I then proceeded with creating a new unix account for work-related matters (we’re going to call it
work for now).
We switch to the new user
su - work
To make things easier, just spawn a new terminal under the new user – anything that is started from this terminal is going to be owned by
work user account.
Almost everything works! If I spawn
google-chrome, links clicked on slack appear on the proper browser!
Pulseaudio really really wants to own your sound card, and when you start chrome it starts
pulseaudio‘s daemon automatically. One way to fix that is to make
pulseaudio to communicate over TCP. First we make the daemon to listen for TCP connections:
mkdir -p ~/.pulse && cp /etc/pulse/default.pa ~/.pulse/default.pa
echo "load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1" >> ~/.pulse/default.pa
Then we make the
work user account to connect to this daemon:
mkdir -p ~/.pulse && echo "default-server = 127.0.0.1" > ~/.pulse/client.conf
Make sure to add your
work user to local hardware access groups like
video if you plan to do videoconferencing 🙂