-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Annotation "io.podman.annotations.seccomp" has no effect #12671
Comments
@vrothberg Is this defined in the OCI Spec? Personally I don't believe that there should be anything in the image that can cause containers to run with less privilege, unless the caller to the container engine wants to "trust" the image. @MaxKellermann are you saying the Docker works with this annotation? Kubernetes? |
No that's our custom way of shipping seccomp profiles with images. I don't think that I can have a look tomorrow. |
It's a Podman-specific feature. |
No, I'm not saying that. I have never used Docker, and this is a podman-specific annotation. Like all annotations, it is undocumented. This annotation showed up in Maybe my "reverse-engineered" wisdom is wrong, and then this can be closed. But I'm pretty lost with the Podman documentation; any time I'm looking for something, there's no word about it in the documentation, so I started looking for clues in how it really works. |
Where can I find documentation on what values for this annotations are legal, and how can I allow my container to use io_uring? That's all I really want. |
The idea of this flag, was to allow a user to set a subset of seccomp rules to allow, Less then the default. So setting unconfined would not be allowed by default. (Not sure if this feature was ever fully implemented.) |
The
|
Tried searching the documentation for "annotation": https://docs.podman.io/en/latest/search.html?q=annotation |
If an unsupported value is specified, I'd expect podman to fail with an error, instead of promoting the (unsupported and actually unused) value straight into the "inspect" command. If I see something in "inspect", I expect it to work. Maybe, after clearing up that what I try to do isn't supposed to work, this is the remaining bug - just an error handling bug. |
I agree, although, it should probably print a warning. I would not want to block users from using an image, that was created incorrectly. |
OK, it is documented (see https://github.com/containers/podman/blob/main/docs/source/markdown/podman-create.1.md#--seccomp-policypolicy) but the annotation is a different one: I'll take a look now what |
The annotation is only set when a container has been created with a custom seccomp profile (or unconfined) and it is only used in |
Clarify the semantics of the `io.podman.annotations.seccomp` annotation which is set when a container has been created with a custom seccomp profile. Fixes: containers#12671 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Here's a PR to clarify the semantics: #12679 As mentioned in #12671 (comment), the correct label to use in the image is Previous statements from me above were incorrect (e.g, re: undocumented etc.). |
Thanks @vrothberg, that is an improvement - but one issue remains: if specified in the container manifest, the
|
Clarify the semantics of the `io.podman.annotations.seccomp` annotation which is set when a container has been created with a custom seccomp profile. Fixes: containers#12671 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Let me see what I can do. Podman is applying the annotations from the image to the container, which explains why the annotation is shown there. |
Do not apply reserved annotations from the image to the container. Reserved annotations are applied during container creation to retrieve certain information (e.g., custom seccomp profile or autoremoval) once a container has been created. Context: containers#12671 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Do not apply reserved annotations from the image to the container. Reserved annotations are applied during container creation to retrieve certain information (e.g., custom seccomp profile or autoremoval) once a container has been created. Context: containers#12671 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Added another commit to #12679 to prevent Podman from applying "reserved" annotations from the image to the container. |
Do not apply reserved annotations from the image to the container. Reserved annotations are applied during container creation to retrieve certain information (e.g., custom seccomp profile or autoremoval) once a container has been created. Context: containers#12671 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Do not apply reserved annotations from the image to the container. Reserved annotations are applied during container creation to retrieve certain information (e.g., custom seccomp profile or autoremoval) once a container has been created. Context: containers#12671 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Clarify the semantics of the `io.podman.annotations.seccomp` annotation which is set when a container has been created with a custom seccomp profile. Fixes: containers#12671 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Do not apply reserved annotations from the image to the container. Reserved annotations are applied during container creation to retrieve certain information (e.g., custom seccomp profile or autoremoval) once a container has been created. Context: containers#12671 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Annotation
io.podman.annotations.seccomp=unconfined
has no effect. The setting shows up ininspect
:This is the same output which also appears when I create the container with
--security-opt=seccomp=unconfined
. With the command line option, io_uring system calls work, but with just an annotation in the image manifest, io_uring system calls are blocked.Steps to reproduce the issue:
Create OCI image with the following in the manifest:
{"annotations": {"io.podman.annotations.seccomp": "unconfined"} ...
Run container without
--security-opt=seccomp=unconfined
Try to use any io_uring system call
Describe the results you received:
All io_uring system calls fail with EPERM because they were blocked with seccomp.
Describe the results you expected:
All io_uring system calls should succeed.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
: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/master/troubleshooting.md)
No.
I have tested Podman 3.0.1 (Debian Bullseye) and 3.4.2 (Debian Unstable), but not the latest version.
There is nothing relevant in the troubleshooting guide.
Additional environment details (AWS, VirtualBox, physical, etc.):
Debian Bullseye + Unstable.
The text was updated successfully, but these errors were encountered: