search

mviereck / x11docker

Run GUI applications and desktops in docker and podman containers. Focus on security.
MIT License
5.62k stars 378 forks source link

Consider leveraging "--rootfs" option available on podman backend #456

Closed Intensity closed 1 year ago

Intensity commented 2 years ago

The podman backend allows the "container image" that is to be used as root storage to be specified as a directory point instead of a traditional image. It works with and without read-only mode.

The functionality of --rootfs could be integrated into x11docker to support some use cases like (1) running a new x11docker instance that points to the very same live container image point as an already-running instance; or (2) skipping steps related to traditional container image vivification to point to an ad hoc already-unpacked image. There may be some other use cases as well.

A similar option may be available on other backends in some form.

mviereck commented 2 years ago

This looks interesting, thank you for the hint! I was not aware of the --rootfs option. I'll look into this.

Yet x11docker provides something similar with --backend=proot. There's also a small script to convert docker images to rootfs tarballs: https://github.com/mviereck/image2rootfs

Intensity commented 2 years ago

proot would be a very different architecture for me and I'd still prefer podman with --rootfs.

Maybe for shortcut's sake, when someone specifies something like --rootfs they could be referring to the "raw" origin image by a subset of its tags (in this use case, implying read-only mode operation) or they could refer to another running container environment (either by container name, hostname, labels or other metadata in a certain search order).

I've found that my own experimental testing of --rootfs (with an argument manually specified as a raw path) pairs well with my simultaneous use of --no-setup and --read-only.

mviereck commented 2 years ago

I have added an (experimental) option --rootfs for podman run --rootfs. I found that it only works with --no-setup, this is enabled automatically now. I did no deep checks yet, currently it just works. Please report if you try out and find any issues.

Intensity commented 2 years ago

I finally had a chance to try it out. This looks like it works well. It's somewhat of an extra add, but what if by default --rootfs finds and refers to the local storage pertaining to the specified podman image? That way I wouldn't have to maintain my symbolic link in .../ROOTFS/. A user could then manually override the location by giving a parameter to --rootfs=.

If --read-only is given, then the actual direct contents wouldn't ever be altered so I don't believe there would be a downside to directly referring to podman's own storage for an image. If someone chooses not to specify --read-only (and maybe if more than one instance running and referring to the same storage is detected) then a warning could be issued. Perhaps finding the actual image location can work well in multiple storage backends, not just the backend I happen to be using (VFS).

Also I quickly checked the capabilities that x11docker is adding and noticed CHOWN was there. I made a manual modification to remove CHOWN and my container was still able to run just fine. And so if you were wondering if CHOWN is needed, there's at least one case (--rootfs --read-only and I suppose --no-setup - although some other combinations of flags may work well with the removal of CHOWN) in which it's not needed.

mviereck commented 2 years ago

I finally had a chance to try it out. This looks like it works well. It's somewhat of an extra add, but what if by default --rootfs finds and refers to the local storage pertaining to the specified podman image? That way I wouldn't have to maintain my symbolic link in .../ROOTFS/.

AFAIK this is not possible. An image is not stored as a rootfs filesystem but in several somehow stored layers. There is no rootfs before a container is created by podman.

And so if you were wondering if CHOWN is needed, there's at least one case (--rootfs --read-only and I suppose --no-setup - although some other combinations of flags may work well with the removal of CHOWN) in which it's not needed.

I might check that closer. At least with --no-setup it should not be needed.

Intensity commented 2 years ago

I see. I forgot that my case is probably the outlier, in that I'm using podman with the VFS storage backend fundamentally. While it maintains full copies at the directory location, that's an expensive overhead for most users (unless some ad hoc modification is used which layers this on top of ZFS in custom ways to save on storage, as I've done). Still, with the rootfs functionality that's already been added thus far, some may already be able to address certain niche use cases, and so the implementation seems basically complete.

mviereck commented 2 years ago

That way I wouldn't have to maintain my symbolic link in .../ROOTFS/.

Maybe I forgot to mention it, or did not point out clear: You don't depend on the x11docker ROOTFS directory; you can directly provide an absolute path to the rootfs in you VFS storage in the x11docker command. You would not need symbolic links.