-
Notifications
You must be signed in to change notification settings - Fork 242
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
overlay: add detection for overlay support in a user namespace #845
Conversation
Signed-off-by: Giuseppe Scrivano <[email protected]>
07c805b
to
8c82e3a
Compare
A couple of nits, but LGTM |
track if if the storage was created using a mount_program. Signed-off-by: Giuseppe Scrivano <[email protected]>
add a public function to check whether the kernel supports native overlay. If the existing storage was created using a mount_program, refuse to use the native overlay as they are not fully compatible, e.g. native overlay uses device whiteout files while a mount_program such as fuse-overlayfs could be using a different format to accomodate older kernels where unprivileged users cannot create whiteout devices. Signed-off-by: Giuseppe Scrivano <[email protected]>
prevent a recursion with the reexec program if the check for native overlay is done in a "init()" function. Signed-off-by: Giuseppe Scrivano <[email protected]>
otherwise it prints all the time with rootless on kernels not supporting native overlay. Signed-off-by: Giuseppe Scrivano <[email protected]>
Signed-off-by: Giuseppe Scrivano <[email protected]>
Signed-off-by: Giuseppe Scrivano <[email protected]>
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
One concern with this, is the fix of placing an SELinux label on the context mount, which just got merged into the upstream security kernel. Not in a released kernel yet. I will merge, but we might need to test this. |
add a public function to check whether the kernel supports native overlay.
If the existing storage was created using a mount_program, refuse to use the native overlay as they are not fully compatible, e.g. native overlay uses device whiteout files while a mount_program such as fuse-overlayfs could be using a different format to accomodate older kernels where unprivileged users cannot create whiteout devices.
Users will need the equivalent of "podman system reset" to move to native support.
Signed-off-by: Giuseppe Scrivano [email protected]