-
Notifications
You must be signed in to change notification settings - Fork 249
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
unprivileged/rootless composefs #2099
Comments
The first one is what @brauner suggested, I do agree on that, even though EROFS has always been trying hard to get rid of any reported stablity and security issues. TBH, set |
There's two sub-paths to such a service. What I was initially thinking here is one where we just create and mount the erofs for the user. That's not going to be much code at all. The second path is where we have something like flatpak's system pull helper - the container image fetching (literally, the c/image code basically) runs in the user context, but passes content objects via fd passing to the service. It's really much like what I was sketching out earlier in #1849 The advantage of this is pretty huge - it's happened to me not infrequently that I want to run the same image rootful and rootless on a desktop system. In combination with containers/bootc#20 - oh and especially if we bring flatpak on board with this composefs-oriented world...a lot of deduplication and integrity to be had. |
Filed containers/composefs#409 |
One concern that's come up but we haven't formally tracked is that we can't do "native composefs" (as an EROFS) from an unprivileged context.
There are two overall options:
Of these I believe the system service should be our default stance; I think we can design it so it's quite low risk to the system.
The text was updated successfully, but these errors were encountered: