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

[aminosbh]

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.

[rhatdan]

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