-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
libpod: support idmap for --rootfs #17274
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: giuseppe The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
de3b4f9
to
54c88ef
Compare
|
||
The `idmap` option if specified, create an idmapped mount to the target user | ||
namespace in the container. | ||
The idmap option supports a custom mapping that can be different than the user |
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.
Why do you want this? When would you want the idmapping to be differnt the User Namespace mapping?
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 users are using it as a way to restrict access to the file system to certain IDs, we had a request for crun: containers/crun#873
go.mod
Outdated
@@ -177,3 +177,5 @@ require ( | |||
) | |||
|
|||
replace github.com/opencontainers/runc => github.com/opencontainers/runc v1.1.1-0.20220617142545-8b9452f75cbc | |||
|
|||
replace github.com/containers/storage => github.com/giuseppe/storage v1.19.2-0.20230130105941-634c638e5c48 |
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.
Isn't this already merged?
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.
it is failing on freebsd, so I'll need another patch
12b31be
to
f76a114
Compare
pkg/specgen/specgen.go
Outdated
lastColonIndex := strings.LastIndex(csc.Rootfs, ":") | ||
if lastColonIndex != -1 && lastColonIndex+1 < len(csc.Rootfs) && csc.Rootfs[lastColonIndex+1:] == "O" { | ||
csc.RootfsOverlay = true | ||
csc.Rootfs = csc.Rootfs[:lastColonIndex] | ||
parts := strings.SplitN(arg, ":", 2) | ||
if len(parts) == 2 { | ||
for _, opt := range strings.Split(parts[1], ",") { | ||
switch { | ||
case (opt == "idmap" || strings.HasPrefix(opt, "idmap=")): | ||
csc.RootfsMapping = &opt | ||
case opt == "O": | ||
csc.RootfsOverlay = true | ||
default: | ||
return nil, fmt.Errorf("unknown option %q", opt) | ||
} | ||
} | ||
csc.Rootfs = parts[0] |
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.
This will break backwards compat, now it will fail if a path contains a colon. As I understand the old code carefully checked that only :O
was interpreted as option and everything else considered a regular path.
I don't think we can do this if we a serious about backwards compat. Should we add a new flag for this?
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.
yes I know we break that, but that is a bit weird corner case and we already use :
as separator for other options (e.g. --volume
). The previous code was not that much clearer where we only threated :O
as an option and everything else as part of the path. I'd not worry about adding another option just to change this behavior.
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.
How do you envision somebody using a path with a colon
#11913, we should not break them again!
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.
We currently do not support --volume SOURCE or DEST with ':' so I do not see this as a breaking change especially where we have support for ':0'. Sure theoretically they could have a rootfs with a ':' but I don't think this is worth worrying about. We can release not it, and be done.
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.
This is breaking and at least one user depends on it see the linked issue #11913.
For volumes there is --mount
which allows paths to contain a colon.
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.
should we just add another exception for "idmap" and avoid arguments?
@rhatdan what do you think?
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.
supporting "idmap" and arguments is easy in the same way we handle "O" but it is a mess when we want to provide both options like :O,idmap
f76a114
to
caeaeaa
Compare
to get unblocked I'll need containers/storage#1489 |
caeaeaa
to
1f157d3
Compare
ec06220
to
f82893a
Compare
Signed-off-by: Giuseppe Scrivano <[email protected]>
Signed-off-by: Giuseppe Scrivano <[email protected]>
Signed-off-by: Giuseppe Scrivano <[email protected]>
f82893a
to
0de548e
Compare
0de548e
to
881f9b7
Compare
ready for review |
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.
LGTM
@edsantiago PTAL
Test is failing on my f37 laptop, 6.0.9-300.fc37:
I can find nothing useful in the journal. I have one more comment about cleanup; will write that soon |
test/system/030-run.bats
Outdated
|
||
# check if the underlying file system supports idmapped mounts | ||
mkdir -p $PODMAN_TMPDIR/idmap-check | ||
mount --bind -o X-mount.idmap='0:1:1' $PODMAN_TMPDIR $PODMAN_TMPDIR || skip "idmapped mounts not supported" |
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.
Suggestion, to avoid leaving behind a podman-mount:
- mount --bind -o X-mount.idmap='0:1:1' $PODMAN_TMPDIR $PODMAN_TMPDIR || skip "idmapped mounts not supported"
+ echo "$_LOG_PROMPT mount --bind -o X-mount.idmap=0:1:1 ..."
+ run mount --bind -o X-mount.idmap='0:1:1' $PODMAN_TMPDIR $PODMAN_TMPDIR
+ echo "$output"
+ if [[ $status -ne 0 ]]; then
+ run_podman image unmount $IMAGE
+ skip "idmapped mounts not supported"
+ fi
+
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.
It is not a "podman mount", it is a raw mount command. How can it leak (well assuming the script is not killed in the middle) if the next command is an "umount"?
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.
I've moved the 'podman mount
later, does the new version look fine to you?
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.
Yes! That's a much better solution, thank you!
Test still fails on my laptop though. (Same EINVAL)
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.
does the run mount --bind -o X-mount.idmap='0:1:1' $PODMAN_TMPDIR $PODMAN_TMPDIR
command work fine on your laptop?
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.
ah, mount will silently ignore the option if not supported :/
I need to figure out a different way to check the feature
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.
I've not found any way to test it, so I am reusing the podman command and check its error message
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.
Blocking until test-failure issue is resolved
87f623d
to
0251de7
Compare
add a new option idmap to --rootfs that works in the same way as it does for volumes. Signed-off-by: Giuseppe Scrivano <[email protected]>
0251de7
to
2bb4c7c
Compare
LGTM this time - at least, it skips properly. Thanks. (Sigh... we've gone three days without a |
/lgtm |
Does this PR introduce a user-facing change?
allows to specify the option ":idmap" to the --rootfs argument