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

Make the store work for unprivileged user #96

Closed
mgoltzsche opened this Issue Sep 6, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@mgoltzsche
Copy link

mgoltzsche commented Sep 6, 2017

Unfortunately this library cannot be used by unprivileged users since mounting is not permitted.

As a workaround for use cases where there is no root access a simple driver should be added that works without actually mounting anything (accepting poor performance).

@rhatdan

This comment has been minimized.

Copy link
Member

rhatdan commented Sep 8, 2017

@nalind Does vfs support this mode?

@nalind

This comment has been minimized.

Copy link
Contributor

nalind commented Sep 8, 2017

Not currently - the remounting of the runroot at startup happens regardless of which driver we're using. If we dropped that, and with the right UID/GID mapping (so that when we explode layers onto disk, we don't fail to fix up permissions), I think it would.

@mgoltzsche

This comment has been minimized.

Copy link
Author

mgoltzsche commented Sep 8, 2017

That would be great and with vfs this could be the very basic solution for this issue.

Ideally I had a mtree-based driver in mind that would work like https://github.com/openSUSE/umoci but I see now that this only makes sense for unprivileged users after the remounting outside the driver is dropped.
@cyphar, is there any work in progress in this direction?

@rhatdan

This comment has been minimized.

Copy link
Member

rhatdan commented Sep 8, 2017

Adding support for ostree might be interesting also.

@cyphar

This comment has been minimized.

Copy link
Contributor

cyphar commented Sep 9, 2017

@mgoltzsche Yeah, umoci does this already (as well as having built-in support for rootless containers 😉). In addition to removing the remounting code, and verifying that the permissions are set up properly, you'd also need to handle a lot of CAP_DAC_OVERRIDE edge-cases. I made a library (github.com/openSUSE/umoci/pkg/unpriv) that transparently emulates CAP_DAC_OVERRIDE in userspace for unprivileged users.

I haven't personally been working on getting it into containers/storage (mainly because I don't particularly like touching the Docker graphdriver code that containers/storage is based on).

@mgoltzsche

This comment has been minimized.

Copy link
Author

mgoltzsche commented Sep 15, 2017

After digging a little deeper into the storage Store/Driver interfaces I realized it is tricky - if not impossible - to be implemented efficiently using mtree. For my use case (image build) a simpler interface with a Commit method is more suitable to take advantage of mtree.

@rhatdan ostree might be interesting indeed. Unfortunately it is not available on all systems (e.g. not available on my ubuntu 16.04 machine).

@cyphar thanks for the update. I'll definitely have another look at umoci again also regarding CAP_DAC_OVERRIDE.

@cyphar

This comment has been minimized.

Copy link
Contributor

cyphar commented Sep 15, 2017

@mgoltzsche I have been talking to @hallyn about potentially having something like umoci revert which will allow you to do some more complex operations efficiently (it would generate an index from the layers to be able to efficiently look up the blob data).

@giuseppe

This comment has been minimized.

Copy link
Member

giuseppe commented Feb 25, 2018

I am trying to run "vfs" in an user namespace, and I see this error when I try to commit the image:

error committing container "fedora-working-container-2" to "giuseppe/lighttpd": error copying layer and metadata: error committing new image "containers-storage:[vfs@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/giuseppe/lighttpd:latest": error determining uncompressed digest for blob "sha256:20b069c8f6656b620092a273cb5c4e5ecce943e32a19c67d1c447bcb6499d141"

Does it depend from containers/image#305 ?

@nalind

This comment has been minimized.

Copy link
Contributor

nalind commented Mar 1, 2018

@giuseppe That message was introduced in containers/image#305, so the tool that produced it already includes a later version of the image library.

@giuseppe

This comment has been minimized.

Copy link
Member

giuseppe commented Mar 1, 2018

@nalind yes, I meant if it was introduced by containers/image#305

To track better this problem, I've opened a new issue here:

containers/buildah#502

@rhatdan

This comment has been minimized.

Copy link
Member

rhatdan commented Mar 8, 2019

This looks like it is fixed, Closing reopen if this is still an issue.

@rhatdan rhatdan closed this Mar 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.