systemd-nspawn unprivileged equivalent to normal user?

duyinthee · 2023-11-04 09:45:51

I am trying to run Libreoffice from container by systemd-nspawn on Arch with sway.

I start my container and login as root.
Should I create normal user and add it to wheel group which I can configure in sudoer for root access?

For unprivileged, if I start my container with -U flag, I can no longer run my GUI application from the container.
Running container unprivileged is equivalent to normal user in containerized OS?

twelveeighty · 2023-11-04 18:31:09

I think you're mistakenly thinking that a container 'runs' its own OS, similar to a virtual machine. It doesn't. "Running" a container is just a process running on your (host) OS, (somewhat) isolated from other processes using namespaces and cgroups. The file/folder UID/GID permissions set in container's image become the container's file/folder UID/GID, so an unprivileged user on the host OS must be mapped to a UID/GID that allows it access to the files/folders inside the container.
That mapping could be from random user UID e.g. 1000 on the host to root UID 0 "in" the container, which effectively grants the OS user '1000' root access to all the files/folders inside the container. Some Kubernetes based container orchestrators provide more flexibility and let you map a non-root user on the OS to a non-root UID inside the container, which is safer.

Now, going back to your original problem: the reason that running any GUI-based apps unprivileged from that container is by design: process isolation. Running it privileged just means you are running the host process as root, which 'breaks' the isolation. This is at the heart of the criticism of containerization: running container processes as root is a false sense of isolation and dangerous things could happen if a malicious script or executable is launched inside that container.

Possible solutions are: 1) find a way to 'share' your X/Wayland session with the isolated unprivileged process; 2) keep running the container privileged, and hope nothing bad ever happens from running a complex application as root; 3) I would argue the 'true' Arch approach: forget running a GUI application as a container and simply install Libreoffice as a regular package.

Last edited by twelveeighty (2023-11-04 18:33:23)

duyinthee · 2023-11-05 02:20:21

Thanks a lot for explaining the concept.
Let me explain my situation here. After many years of using Arch linux for my work seriously, I found myself requiring to run LibreOffice two separate version.
In my office work, I do a lot of documents. Most are Eng and others are local language, Burmese in my case.
For Eng documents, the default setting is the best while locale setting is required to set to local language for local language documents.
I know styles and templates. But that's not enough for me in some way. So, I look at running another LibreOffice from the container using systemd-nspawn.

I created the container and boot with the following.

# systemd-nspawn --bind-ro=/run/user/1000/wayland-1 -b -D ~/MyContainer

After boot and normal user login, I just need to run Libreoffice Writer with the following.

$ WAYLAND_DISPLAY=wayland-1 XDG_RUNTIME_DIR=/run/user/1000 lowriter

It works but the message is showing that ... unable to create folder /run/user/1000/dconf... in containerized OS's console.
So, I do

# chown -R username:username /run/user/1000

and run again Libreoffice Writer. It works perfect but after next boot, I would have to run the chown command again because /run/user/1000 folder is reset to be owned by root. That's my problem.
Should I bind /run/user/1000 folder with read & write using --bind. I'm not sure that coz I don't want to mess up my host.

icar · 2023-11-05 05:44:52

This does seem like you are reinventing the wheel. Have you considered Flatpak? There is a package for LibreOffice.

Anyway, if you only want to change locales, I'm pretty sure LibreOffice has something akin to profiles to change on the fly. But, you could always run it as a different user without using something like nspawn.

seth · 2023-11-05 08:21:38

Sounds like everyone's re-inventing XDG_CONFIG_HOME

I've not use LO in years, but afaiu it's using a lock file in your home directory to prevent a second instance for the user and also seems to respect XDG_CONFIG_HOME
So

export XDG_CONFIG_HOME=$HOME/.config_burma
lowriter

should™ get you a second lowriter instance operating on that config path where you can store the burmese settings.

Arch Linux

#1 2023-11-04 09:45:51

systemd-nspawn unprivileged equivalent to normal user?

#2 2023-11-04 18:31:09

Re: systemd-nspawn unprivileged equivalent to normal user?

#3 2023-11-05 02:20:21

Re: systemd-nspawn unprivileged equivalent to normal user?

#4 2023-11-05 05:44:52

Re: systemd-nspawn unprivileged equivalent to normal user?

#5 2023-11-05 08:21:38

Re: systemd-nspawn unprivileged equivalent to normal user?

Board footer