Skip to content
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

Add support for enabling/disabling kernel keyring in engines #354

Merged
merged 1 commit into from
Nov 20, 2020

Conversation

rhatdan
Copy link
Member

@rhatdan rhatdan commented Nov 19, 2020

Signed-off-by: Daniel J Walsh dwalsh@redhat.com

Copy link
Member

@saschagrunert saschagrunert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@rhatdan
Copy link
Member Author

rhatdan commented Nov 19, 2020

@containers/podman-maintainers PTAL

Copy link
Member

@vrothberg vrothberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I

@@ -179,6 +179,7 @@ func DefaultConfig() (*Config, error) {
DNSServers: []string{},
DNSOptions: []string{},
DNSSearches: []string{},
EnableKeyring: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want this to be set unconditionally. This code will likely be greeted on older kernels, where keyrings are not namespaced.

I think we need to run a kernel version check for the built-in default.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hate kernel version checks, becasue they usually are wrong on systems like RHEL that back port fixes. We have been defaulting to on for a long time now without an issue. This has only been asked for inside of a locked down container. I don't believe this is a security issue, and has nothing to do with whether the container can use the kernel keyring. This is the podman/buildah command attempting to create a kernel keyring though conmon.

When people run podman build within a container from Docker, the seccomp rules block this and cause podman to not run, we have been requested to set this field in the podman container to allow it to run with seccomp enabled.

@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rhatdan, saschagrunert, vrothberg

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Comment on lines +150 to +151
# a kernel keyring for use within the container.
# keyring = true
Copy link
Member

@ashley-cui ashley-cui Nov 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tiny nit: consistent formatting

otherwise, LGTM once other stuff is addressed

Suggested change
# a kernel keyring for use within the container.
# keyring = true
# a kernel keyring for use within the container.
#
# keyring = true

@rhatdan rhatdan merged commit cf7ee15 into containers:master Nov 20, 2020
M1cha pushed a commit to M1cha/common that referenced this pull request Dec 20, 2022
…rde-1.0.140

build(deps): bump serde from 1.0.139 to 1.0.140
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants