-
Notifications
You must be signed in to change notification settings - Fork 34
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
feature: Support atomfs molecule mount in containers #359
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some suggestions / questions.
i do think the uid_map reading is wrong, so i'm saying 'Request changes'
2187eb3
to
a427449
Compare
a7eef77
to
88b0636
Compare
88b0636
to
58619a0
Compare
Slated for v0.40.2 |
58619a0
to
3772b11
Compare
3772b11
to
d061e11
Compare
Signed-off-by: Serge Hallyn <serge@hallyn.com>
d061e11
to
28cd3d9
Compare
That is wrong guidance. I see that it's hardcoded in test/static-analysis.sh, but as I don't have my nitrokey with me I can't append a patch to this PR to remove it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some issues that need fixing.
Would it be easier / better to have 'guestMount' return a known error?
noSquashFuseAvailable = errors.New("No squashfuse binary in PATH")
And then callers could handle that error specially ?
18b73d1
to
e472442
Compare
Oh - that's what I ended up doing. |
1e4402e
to
30968be
Compare
49f9503
to
a86d7aa
Compare
2e7e447
to
3d1bf2a
Compare
While stacker knows how to use squashfuse for 'stacker grab', that function simply keeps the squashfuse process running for the duration of the grab, then lets it close. For atomfs molecule.Mount, we must release that process. So when doing atomfs.Mount(), first check whether we are definitely NOT root using amHostRoot(). There is a corner case which can slip past this - namely if you, as root, create a userns wherein you map the full host uid range. However, you'll never have real root being told it wasn't real root. Second, if neither of those are the case, then try the regular mount syscall, requiring root. If that succeeds, or fails with a non-permission error, then return. If we are detected as not-real-root, or if mount failed as real root with a permission error, and no verity root has was provided, then use squashfuse, and release the exec'd process so that it can outlive us. The actual squashfuse mount function is shared with the extract path. Signed-off-by: Serge Hallyn <serge@hallyn.com>
3d1bf2a
to
6a64317
Compare
Support mounting atomfs stacks as root in a container.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.