Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Root privilege should not be necessary #724

Open
edmeme opened this issue Nov 13, 2023 · 1 comment
Open

Root privilege should not be necessary #724

edmeme opened this issue Nov 13, 2023 · 1 comment

Comments

@edmeme
Copy link

edmeme commented Nov 13, 2023

Is there any interest in making pi-gen run as a non-privileged user? At the end of the day, pi-gen is creating a disk image file. That should not really require any privileges.

I am aware there are some challenges in doing that. I have played with this idea before, attempting to build arch images, I did not get through but I did some progress.

QCOW2 and Ext images can be mounted with fuse. Fuse2fs allows mounting Ext images, the '-o fakeroot' option allows processes running under fakeroot to create and manipulate root-owned files within the image. Qcow2fuse should do the same for QCOW2.

It could be possible to run debootstrap with fakeroot/fakechroot.

My bane was chroot. It can be replaced with unshare -mr chroot. However, procfs seems to be a requirement... Edit: a first step to chroot with procfs in place without root is: unshare --fork --mount-proc=${ROOTFS}/proc --pid -mr chroot ${ROOTFS} /bin/qemu-aarch64-static /bin/bash
APT is not too happy about this, though.

@XECDesign
Copy link
Member

It looks like qcow2fuse uses qemu-ndb in the background and my past experience with it hasn't been great. It appeared to work for a bit, but eventually images would get corrupted, writes would time out or qemu-nbd would fail to disconnect images cleanly.

I'm not sure how the -o fakeroot option works. Does it provide the ability to run things as another user in that environment? In a normall fakeroot chroot environment, if you are user id 1001 and you chroot into an image, it's treated the same as user id 0. When you create a file and leave the chroot environment, you'll see what was previously owned by root is actually owned by 1001. AFAIK, there's no way to distinguish between user 1001 and 0, which would be important when generating an image. Then if you add user 1002, are you able to run something in the chroot as that user?

I'd be interested if it was possible, stable, reliable, didn't introduce unnecessary complexity and hacky workarounds for things that 'just work' as root. I'm a bit sceptical about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants