search

containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.26k stars 2.37k forks source link

incorrect ownership with configmap/secret content from container, when related volume mounted with restrictive defaultMode and pod running with userns auto mode #20956

Closed flabatut closed 3 months ago

flabatut commented 9 months ago

Issue Description

I'm using podman kube play to create a pod and associated volume, made from a configmap (or a secret) resource. I run this pod, as root, using --userns=auto mode. Whenever such volume is created:

Whenever my volume is declared with restrictive permissions for others, using defaultMode:

  volumes:
  - name: test
    configMap:
      defaultMode: 0750
      name: "test"

I'm no longer able to consume volume's content from a container standpoint, lack of permissions prevent any access/modification.

Steps to reproduce the issue

  1. create resources:
cat <<EOF >test.configmap.yml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: test
data:
  readme.txt: lorem ipsum
EOF
cat <<EOF >test.pod.yml
---
apiVersion: v1
kind: Pod
metadata:
  name: "test"
spec:
  containers:
  - name: "test"
    image: docker.io/alpine:latest
    command: ["sleep", "3600"]
    volumeMounts:
    - name: "test"
      mountPath: /test
  volumes:
  - name: "test"
    configMap:
      name: "test"
      defaultMode: 0600
EOF

  1. run podman kube play:

    /usr/bin/podman kube play --replace --service-container=true --log-driver journald --userns auto  --configmap test.configmap.yml  test.pod.yml

  2. podman volume inspect test

[
     {
          "Name": "test",
          "Driver": "local",
          "Mountpoint": "/var/lib/containers/storage/volumes/test/_data",
          "CreatedAt": "2023-12-09T00:12:05.321084238+01:00",
          "Labels": {},
          "Scope": "local",
          "Options": {},
          "UID": 100000,
          "GID": 100000,
          "MountCount": 0,
          "NeedsCopyUp": true,
          "LockNumber": 62
     }
]
  1. volume permissions from host standpoint
ls -ld /var/lib/containers/storage/volumes/test/_data
drwxr-xr-x 2 100000 100000 24 Dec  9 00:12 /var/lib/containers/storage/volumes/test/_data

ls -l /var/lib/containers/storage/volumes/test/_data/
total 4
-rw------- 1 root root 11 Dec  9 00:00 readme.txt
  1. volume permissions from container standpoint 
    
podman exec -it test-test stat /test/readme.txt
File: /test/readme.txt
Size: 11              Blocks: 8          IO Block: 4096   regular file
Device: fe01h/65025d    Inode: 50099       Links: 1
Access: (0600/-rw-------)  Uid: (65534/  nobody)   Gid: (65534/  nobody)
Access: 2023-12-08 23:00:35.613724591 +0000
Modify: 2023-12-08 23:00:35.613724591 +0000
Change: 2023-12-08 23:00:35.613724591 +0000

podman exec -it test-test cat /test/readme.txt cat: can't open '/test/readme.txt': Permission denied

podman exec -it test-test chmod 666 /test/readme.txt chmod: /test/readme.txt: Operation not permitted

podman exec -it test-test chown root:root /test/readme.txt chown: /test/readme.txt: Operation not permitted


### Describe the results you received

until some action to fix permission, at host level is performed, volume file content at container level is unusable

### Describe the results you expected

volume files permissions owned by a container subordinate uid/gid rather than a host uid/gid. Differently speaking, make volume file content available as soon as pod running without any post action required.

### podman info output

```yaml
- architecture

# uname -a
Linux nas 6.2.0-1018-raspi #20-Ubuntu SMP PREEMPT Tue Nov 21 13:32:12 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

running on raspberry pi4, no virtualization

Additional information

github-actions[bot] commented 8 months ago

A friendly reminder that this issue had no activity for 30 days.

rhatdan commented 8 months ago

@umohnani8 or @ygalblum PTAL

flabatut commented 3 months ago

For reference, problem solved, thanks to @rhatdan 's meaningful comment :)

Setting :U option to volume's mounPath let podman know how to correlate userns's idmap and volume content's permission:

    volumeMounts:
    - name: "test"
      mountPath: /test:U

Afterwards, problem is no longer reproducible, no post actions needed at host level to fixup content's ownership:

# podman exec -it test-test stat /test/readme.txt
  File: /test/readme.txt
  Size: 11              Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 18607005    Links: 1
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-06-28 06:18:43.427719744 +0000
Modify: 2024-06-28 06:18:36.193222163 +0000
Change: 2024-06-28 06:18:36.661254353 +0000

# podman exec -it test-test cat  /test/readme.txt
lorem ipsum

# podman exec -it test-test chmod 666 /test/readme.txt
# echo $?
0
# podman exec -it test-test chown root:root /test/readme.txt
# echo $?
0