Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Cannot give secret to container running in user namespace (Workaroud) #14398

Closed
aminosbh opened this issue May 27, 2022 · 1 comment
Closed
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@aminosbh
Copy link

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Whenever a container is executed in a new user namespace I cannot give it a
secret (mount a secret as a file). Which means that the bug is reproduced when
using at least one of the following options: --userns=auto, --uidmap,
--gidmap, --subuidname or --subgidname.

See #12779

This bug was handled and fix by the podman team. The fix is present in podman
starting from version v4.0.0-rc2.

See 83b0fb4

The problem is that, as of the time of posting, many distribution repositories
do not offer yet the official fixed podman version neither a patched version
with this fix.

See https://github.com/aminosbh/oci-fix-secrets-dir-hook/blob/main/README.md#details-about-the-bug-and-its-fix

I know that those repositories are not under the responsibility of the podman team.
This issue intent is to offer older versions a workaround for the secrets-dir bug
via an OCI hook meanwhile the repositories offer a newer versions or add a patch.

You can find the workaround at https://github.com/aminosbh/oci-fix-secrets-dir-hook

Steps to reproduce the issue:

The steps to reproduce are executed as root.

  1. printf my-test-secret | podman secret create my_secret -
  2. podman run --rm -it --secret my_secret --userns=auto alpine cat /run/secrets/my_secret

The bug is reproducible when using any of the previously mentioned options.

Describe the results you received:

podman run errors out with

Error: error stat'ing file /var/lib/containers/storage/overlay-containers/744dac9a9f757af2d8cbd6581bb375d41a90084506a277a602e967aa8b1bb9e3/userdata/secrets/my_secret: Permission denied: OCI permission denied

Describe the results you expected:

I expected the secret mechanism to work with containers running in user namespaces.

Additional information you deem important (e.g. issue happens only occasionally):

This issue is not reproduced with the OCI hook workaround.

Output of podman version:

Version:      3.4.2
API Version:  3.4.2
Go Version:   go1.16.6
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

No need

Package info (e.g. output of rpm -q podman or apt list podman):

No need

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 need, it is already fixed in v4.0.0-rc2

Additional environment details (AWS, VirtualBox, physical, etc.):

Runs on physical machine.

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label May 27, 2022
@rhatdan
Copy link
Member

rhatdan commented May 28, 2022

Since this is fixed in upstream Podman, I am moving this to a discussion.

@containers containers locked and limited conversation to collaborators May 28, 2022
@rhatdan rhatdan converted this issue into discussion #14406 May 28, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

2 participants