Podman 1.4.4: permission denied mounting volume without "--privileged" flag

[orlandocosta76]

/kind bug

Description

With previous versions of podman (e.g. 1.3.2) I could mount the specified working containers' root filesystem with no problem. But in version 1.4.4 using same command does not work, only by adding " --privileged" flag.

Steps to reproduce the issue:

Just run simple container and supply some folder on host to be mounted on container:

1. podman run -it --rm -v /home/orlando/:/sqm/ docker.io/library/alpine sh

2. ls -la /sqm

Describe the results you received:
ls: can't open '/sqm': Permission denied

Describe the results you expected:
total 128
drwx------ 16 root root 4096 Jul 31 14:46 .
drwxr-xr-x 20 root root 4096 Jul 31 18:33 ..
-rw------- 1 root root 6820 Jul 31 10:07 .ICEauthority
-rw------- 1 root root 17472 Jul 30 20:08 .bash_history
-rw-r--r-- 1 root root 18 Feb 16 10:01 .bash_logout
-rw-r--r-- 1 root root 141 Feb 16 10:01 .bash_profile
-rw-r--r-- 1 root root 491 Jul 16 11:04 .bashrc
(...)

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

Output of podman version:

podman version 1.4.4

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.7
  podman version: 1.4.4
host:
  BuildahVersion: 1.9.0
  Conmon:
    package: podman-1.4.4-4.fc30.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.0.0-dev, commit: 164df8af4e62dc759c312eab4b97ea9fb6b5f1fc'
  Distribution:
    distribution: fedora
    version: "30"
  MemFree: 8169803776
  MemTotal: 11141718016
  OCIRuntime:
    package: runc-1.0.0-93.dev.gitb9b6cc6.fc30.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc8+dev
      commit: e3b4c1108f7d1bf0d09ab612ea09927d9b59b4e3
      spec: 1.0.1-dev
  SwapFree: 5641334784
  SwapTotal: 5641334784
  arch: amd64
  cpus: 2
  hostname: vm008394.nsn-intra.net
  kernel: 5.1.20-300.fc30.x86_64
  os: linux
  rootless: true
  uptime: 8h 34m 19.15s (Approximately 0.33 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/orlando/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/orlando/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 7
  RunRoot: /run/user/1000
  VolumePath: /home/orlando/.local/share/containers/storage/volumes

Additional environment details (AWS, VirtualBox, physical, etc.):
I am running Fedora release 30 (Thirty) in a Virtual Box 6.0 running on Windows 10

[mheon]

Are you running with or without root?

[haircommander]

Are you running with or without root?

we should include that question in the issue template, it's asked a lot

[orlandocosta76]

Are you running with or without root?

The problem occurs running as root as well (and non-root of course)

[mheon]

My initial suspicion would be SELinux. If you pass --label=disable at the container command line, instead of --privileged, does it work?

[rhatdan]

This definitely looks like SElinux, If you need to volume mount in your homedir into a container you need to disable SElinux separation as mheon shows above. If you think this worked before and fails now, I would guess you were in permissive mode before.

There is an effort with a new tool called udica which would allow you to generate a policy type to allow the container to use your homedir.

github.com/containers/udica

[orlandocosta76]

My initial suspicion would be SELinux. If you pass --label=disable at the container command line, instead of --privileged, does it work?

Ok, I created a /var/data folder with all permissions and with this instruction it worked:
podman run -it --rm -v /var/data:/sqm --security-opt label=disable docker.io/library/alpine sh

Also, as in the documentation, it possible to disable SELinux with this:
chcon -Rt svirt_sandbox_file_t /var/data
and then I can run the command without flags.

But previously this was not the case, was this added later to podman?

[rhatdan]

You could have also executed

podman run -it --rm -v /var/data:/sqm:Z docker.io/library/alpine sh

Which is what I would recommend, Then podman will do the relabeling for you and the /var/data directory will only be able to be used by this contianer.

podman run -it --rm -v /var/data:/sqm:z docker.io/library/alpine sh

Would relabel /var/data with a shared label container_file_t:s0 so all containers could share the content from an SELinux point of view.

[orlandocosta76]

You could have also executed

podman run -it --rm -v /var/data:/sqm:Z docker.io/library/alpine sh

Which is what I would recommend, Then podman will do the relabeling for you and the /var/data directory will only be able to be used by this contianer.

podman run -it --rm -v /var/data:/sqm:z docker.io/library/alpine sh

Would relabel /var/data with a shared label container_file_t:s0 so all containers could share the content from an SELinux point of view.

Actually either with :z or :Z did not work, I get this error message:
Error: relabel failed "/var/data3": operation not permitted

[rhatdan]

And chcon did? What kind of file system is on /var/data3?

[mheon]

Does :z and :Z work as root?

@rhatdan I think it's a directory his user has read, but not write, perms on.

[rhatdan]

That should give you eperm then.

[orlandocosta76]

And chcon did? What kind of file system is on /var/data3?

It had the same permissions as all other folders I tried previously (chmod a+rwx)
And I did not tried as root, but you can do it, just use simple linux image such as alpine and check it out. For me the original issue is solved, thanks for the support.