enable non-root operation

[jberkus]

It seems like it ought to be possible to allow buildah to work without root/sudo access. This would enable using it in a lot of places other tools aren't available.

What would it take to enable non-root usage?

[rhatdan]

The biggest problem would be mounting. buildah mount requires SYS_ADMIN capabilities. buildah RUN executes runc which runs a container and requires SYS_ADMIN also.

Usually UserNamespace might make some of this easier. Usually installing rpm/dep requires SETUID/SETGID to lay down files with different UIDs.

[jberkus]

Hmmm, that does sound hard. You get the value of this if we can do it, though, yes?

I mean, IMHO, users don't really care about the daemon or not. They do care about needing root, because in many virtual and/or automated build environments you don't have it.

[rhatdan]

Yes I understand. Would be cool to handle this without root. @cgwalters has some ideas of enhancements we could do using rpm-ostree, for non root use cases.

[timothysc]

I'll echo @jberkus.
If I can replace my build-infra with non-jig'd env, I would wholesale replace with buildah.

[ianmiell]

Hi all, this would be invaluable for us. The ability to build images without root access would solve a huge problem for us.

If memory serves, SYS_ADMIN is a hack^H^H^H^H catch-all capability that's not very fine grained. If anyone wants to collaborate/commandeer me I'd be interested in pursuing this. Powerbroker is another option we use to control acccess to specific commands.

[muayyad-alsadi]

Runc have --rootless option and I have a little demo here.

I know there would be many problems like multiple users ex. When dnf install httpd
Some files would be owned by root and others by web user

http://bcksp.blogspot.com/2018/02/diy-docker-using-skopeoostreerunc.html?m=1

[rhatdan]

@giuseppe PTAL

[ianmiell]

@muayyad-alsadi thanks, but afaict that's run, not build. Build is that ask here.

@rhatdan @giuseppe any update on this? Rootless build still a big deal for us here at $WORK.

[giuseppe]

you can run buildah as non-root but you need an usernamespace where the user can keep the required capabilities.

It doesn't work yet with upstream runc (AFAIK) as it requires some changes that were not yet merged, at least last time I've checked.

I've managed to get it working in an atomic user container (atomic install--user): https://github.com/projectatomic/atomic-system-containers/tree/master/buildah-fedora, but it is still blocked on containers/bubblewrap#256 as we use bubblewrap to run the container.

In both cases, you'll still need to use the vfs storage driver, as overlay requires root access.

I've written more details here:
https://www.scrivano.org/2018/02/25/current-status-problems-running-buildah-non-root/

[ianmiell]

The capabilities are the challenge, hence my comment about SYS_ADMIN above. We operate in a highly restricted environment where capabilities are closely guarded.

[giuseppe]

I am not sure it is possible to avoid that. Most programs that are executed by "buildah run" requires to run as root (e.g. dnf, apt-get) so in a way or another you need to provide these capabilities.

[ianmiell]

I was thinking user mapping could be used for this: https://docs.docker.com/engine/security/userns-remap/

…

On Thu, Mar 22, 2018 at 3:33 PM, Giuseppe Scrivano ***@***.*** > wrote: I am not sure it is possible to avoid that. Most programs that are executed by "buildah run" requires to run as root (e.g. dnf, apt-get) so in a way or another you need to provide these capabilities. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#171 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGrczVFWBdxRQtoGiuXS0WeeZqpAD0_Jks5tg8RAgaJpZM4OHX7q> .

[giuseppe]

@ianmiell yes, sure, the capabilities can be provided from an user namespace as well. That is what I was trying to achieve and described earlier in #171 (comment). The limitations are that you need "vfs" as the backend and a patched runc (or bubblewrap in the bwrap-oci case)

[rhatdan]

I am working with the upstream kernel contributors on User Namesapce and Overlay to get Overlay mount support to be allowed within a UserNS. Once we have that the VFS requirement would go away.

[muayyad-alsadi]

Runc have --rootless option and I have a little demo here.

I know there would be many problems like multiple users ex. When dnf install httpd
Some files would be owned by root and others by web user

http://bcksp.blogspot.com/2018/02/diy-docker-using-skopeoostreerunc.html?m=1

[rhatdan]

@giuseppe PTAL

[ianmiell]

@muayyad-alsadi thanks, but afaict that's run, not build. Build is that ask here.

@rhatdan @giuseppe any update on this? Rootless build still a big deal for us here at $WORK.

[giuseppe]

you can run buildah as non-root but you need an usernamespace where the user can keep the required capabilities.

It doesn't work yet with upstream runc (AFAIK) as it requires some changes that were not yet merged, at least last time I've checked.

I've managed to get it working in an atomic user container (atomic install--user): https://github.com/projectatomic/atomic-system-containers/tree/master/buildah-fedora, but it is still blocked on containers/bubblewrap#256 as we use bubblewrap to run the container.

In both cases, you'll still need to use the vfs storage driver, as overlay requires root access.

I've written more details here:
https://www.scrivano.org/2018/02/25/current-status-problems-running-buildah-non-root/

[ianmiell]

The capabilities are the challenge, hence my comment about SYS_ADMIN above. We operate in a highly restricted environment where capabilities are closely guarded.

[giuseppe]

I am not sure it is possible to avoid that. Most programs that are executed by "buildah run" requires to run as root (e.g. dnf, apt-get) so in a way or another you need to provide these capabilities.

[ianmiell]

I was thinking user mapping could be used for this: https://docs.docker.com/engine/security/userns-remap/

…

On Thu, Mar 22, 2018 at 3:33 PM, Giuseppe Scrivano ***@***.*** > wrote: I am not sure it is possible to avoid that. Most programs that are executed by "buildah run" requires to run as root (e.g. dnf, apt-get) so in a way or another you need to provide these capabilities. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#171 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGrczVFWBdxRQtoGiuXS0WeeZqpAD0_Jks5tg8RAgaJpZM4OHX7q> .

[giuseppe]

@ianmiell yes, sure, the capabilities can be provided from an user namespace as well. That is what I was trying to achieve and described earlier in #171 (comment). The limitations are that you need "vfs" as the backend and a patched runc (or bubblewrap in the bwrap-oci case)

[rhatdan]

I am working with the upstream kernel contributors on User Namesapce and Overlay to get Overlay mount support to be allowed within a UserNS. Once we have that the VFS requirement would go away.

[rhatdan]

@nalind is getting close on this. But I think we have multiple issues on this. @nalind Close the one you do not need.

[rhatdan]

Closing this in favor of #386