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
SYS_MKNOD denied by default #15626
Comments
This is intentional, as we feel that the Docker default is dangerous, and almost never needed. So Podman and Buildah decided to remove it by default. We also remove CAP_NET_RAW and CAP_AUDIT_WRITE, which are not needed by almost all containers and potentially could lead to hacks. |
Where in the docs does it claim SYS_MKNOD is allowed by default? |
Here, for one. |
Thanks I will fix that,. I can not find any others, but then again I did not find this one. :^( |
Fixes: containers#15626 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Fixes: containers#15626 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
If you find more instances of bad docs, please reopen. Thanks @tangentsoft for pointing this out. |
Fixes: containers#15626 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Various places in the docs claim the
SYS_MKNOD
capability is granted by default. It is not, as is easy to see with:I happen to think this is a good thing, as
mknod
is potentially quite dangerous, so if it's genuinely needed — thus justifying the use of rootful containers — it should be added to the build and then denied on create and run, baking the additional/dev
nodes into an immutable base layer of the container.That said, this is a "regression" relative to Docker Engine, which grants this by default. I won't say you should be compatible with them at this level, but if not, you should document the difference.
Output of
podman version
:Output of
podman info
:(Note the confirmation under
security.capabilities
.)Package info (e.g. output of
rpm -q podman
orapt list podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
No. If it's changed since CentOS Stream 9 was released, I'll be vaguely interested to know, but this is what I have for the next several years. I won't be building and installing new versions of Podman on my servers just to get around this.
The text was updated successfully, but these errors were encountered: