-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
support changing of lsm mount context on restore #3068
support changing of lsm mount context on restore #3068
Conversation
bc90e5f
to
02139ea
Compare
02139ea
to
d8f84d4
Compare
Made all requested changes and force pushed. |
d8f84d4
to
1c169eb
Compare
Both man page changes applied. |
1c169eb
to
5b1e281
Compare
@adrianreber could you please rebase (needed to run latest CI)? |
5b1e281
to
712fc9c
Compare
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
@adrianreber needs a rebase 🙏🏻 |
712fc9c
to
a9a34a2
Compare
rebased |
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
@thaJeztah PTAL |
Overall looks good; I'm not a very SELinux person, but I noticed that we also have
Which uses label as term. Is it clear that both apply a label? Just asking; I'm fine with this if this term is clearer to more SELinux-savvy users 😅 |
Overall, it seems OK as it is (process -- label, mount -- context). We also have |
@rhatdan can you please review this from the POV of terminology used? |
@@ -74,6 +74,14 @@ daemon. See [criu --lazy-pages option](https://criu.org/CLI/opt/--lazy-pages). | |||
: Specify an LSM profile to be used during restore. Here _type_ can either be | |||
**apparamor** or **selinux**, and _label_ is a valid LSM label. For example, | |||
**--lsm-profile "selinux:system_u:system_r:container_t:s0:c82,c137"**. | |||
By default, the checkpointed LSM profile is used upon restore. | |||
|
|||
**--lsm-mount-context** _context_ |
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 hate typing extra letters, why not just --mount-context? Or --mount-label, since context is not a common user facing term.
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.
As a matter of fact, I think all through runc, it is referred to as the MountLabel.
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.
@adrianreber WDYT about --mount-context
or --mount-label
?
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.
The only reason not to rename it is to keep the options consistent between criu and runc.
Another reason not to rename it is that Podman already uses this option if it finds support for it in runc.
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.
OK I'll leave this decision to @rhatdan 🦆
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 hate typing extra letters, why not just --mount-context? Or --mount-label, since context is not a common user facing term.
@rhatdan I think this option is not likely to be used very often directly by users from command-line and using an explicit name clarifies the meaning of "context".
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.
Yeah I'm with @kolyshkin. I think it would be nice to use something a bit less cryptic -- the fact that podman already expects this (presumably because crun already supports this?) is a bit of a shame.
I thought a bit more about the Podman problem and it is not really a problem. Podman currently checks for the existence of --lsm-mount-context
and tells the user early if runc does not support it. So we can still call it whatever we want in runc and adapt Podman.
Should I change it to --mount-label
? Would that be a good name for everyone?
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.
@kolyshkin Are you sure? The example given in the docs is --lsm-mount-context "system_u:object_r:container_file_t:s0:c82,c137"
. --lsm-profile
takes type:profile
.
However, since we already have --lsm-profile
maybe --lsm-mount-context
is more consistent. Since it looks like we've copied the CRIU argument names in the past we should probably just stick with 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.
@cyphar right, I mixed it with --lsm-profile
which does have apparmor
or selinux
prefix.
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.
Since it looks like we've copied the CRIU argument names in the past we should probably just stick with it...
Fair point. Adding --lsm-mount-label
to the list of possible names (naming is hard!)
a9a34a2
to
142f3c3
Compare
Rebased. |
So, did we agree on not changing the name of the option? Is this ready to be 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.
LGTM. Yeah, let's keep it in line with the other --lsm-*
options.
Signed-off-by: Adrian Reber <areber@redhat.com>
Wire through CRIU's support to change the mount context on restore. This is especially useful if restoring a container in a different pod. Single container restore uses the same SELinux process label and same mount context as during checkpointing. If a container is being restored into an existing pod the process label and the mount context needs to be changed to the context of the pod. Changing process label on restore is already supported by runc. This patch adds the possibility to change the mount context. Signed-off-by: Adrian Reber <areber@redhat.com>
142f3c3
to
43b36dc
Compare
I had to rebase again for go.mod conflicts. |
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
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
Wire through CRIU's support to change the mount context on restore.
This is especially useful if restoring a container in a different pod.
Single container restore uses the same SELinux process label and same mount context as during checkpointing. If a container is being restored into an existing pod the process label and the mount context needs to be changed to the context of the pod.
Changing process label on restore is already supported by runc. This patch adds the possibility to change the mount context.
This requires yet unreleased version of CRIU 3.16.
Proposed changelog entry: