OCI Permission Denied when running on host with VirtualBox

[Chaz6]

When running crun with podman on a host with VirtualBox, it failes with the message Error: crun: error stat'ing file /dev/vboxusb/001/006: Permission denied: OCI permission denied. I checked the selinux audit.log but could not find anything relevent. Hopefully the below information is helpful for troubleshooting.

podman run \
  --name=mysql-container \
  -d \
  --label io.podman.compose.config-hash=123 \
  --label io.podman.compose.project=podman \
  --label io.podman.compose.version=0.0.1 \
  --label com.docker.compose.project=podman \
  --label com.docker.compose.project.working_dir="/home/chaz/containers/mysql" \
  --label com.docker.compose.project.config_files=docker-compose.yml \
  --label com.docker.compose.container-number=1 \
  --label com.docker.compose.service=mysql \
  -e MYSQL_ROOT_PASSWORD=secret \
  -e MYSQL_DATABASE=name_db \
  -e MYSQL_USER=user \
  -e MYSQL_PASSWORD=password \
  -v "/home/chaz/containers/mysql/data/dump.sql:/docker-entrypoint-initdb.d/dump.sql" \
  -v "/home/chaz/containers/mysql/data/mysql:/var/lib/mysql" \
  --net podman_default \
  --network-alias mysql \
  -p 3306:3306 \
  --privileged \
  mysql:latest
Error: crun: error stat'ing file `/dev/vboxusb/001/006`: Permission denied: OCI permission denied

$ uname -r
5.18.19-200.fc36.x86_64

$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="36 (KDE Plasma)"
ID=fedora
VERSION_ID=36
VERSION_CODENAME=""
PLATFORM_ID="platform:f36"
PRETTY_NAME="Fedora Linux 36 (KDE Plasma)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:36"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f36/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=36
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=36
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="KDE Plasma"
VARIANT_ID=kde

$ podman info
host:
  arch: amd64
  buildahVersion: 1.27.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpuUtilization:
    idlePercent: 82.23
    systemPercent: 3.61
    userPercent: 14.16
  cpus: 8
  distribution:
    distribution: fedora
    variant: kde
    version: "36"
  eventLogger: journald
  hostname: zoidberg
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.18.19-200.fc36.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 396820480
  memTotal: 18792480768
  networkBackend: cni
  ociRuntime:
    name: crun
    package: crun-1.5-1.fc36.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.5
      commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 8576561152
  swapTotal: 8589930496
  uptime: 7h 20m 51.00s (Approximately 0.29 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/chaz/.config/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 0
    stopped: 4
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/chaz/.local/share/containers/storage
  graphRootAllocated: 498387124224
  graphRootUsed: 193862119424
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 8
  runRoot: /run/user/1000/containers
  volumePath: /home/chaz/.local/share/containers/storage/volumes
version:
  APIVersion: 4.2.0
  Built: 1660228937
  BuiltTime: Thu Aug 11 15:42:17 2022
  GitCommit: ""
  GoVersion: go1.18.4
  Os: linux
  OsArch: linux/amd64

[giuseppe]

can your user access that file?

What is the output of the commands stat /dev/vboxusb/001/006 and podman unshare stat /dev/vboxusb/001/006?

[giuseppe]

closing the issue since I've got no answer to my previous question. Please reopen if the issue persists and you've more information to share

[sfrashid]

@giuseppe I am experiencing the same issue and running the command you suggested outputs the following for me:

stat /dev/vboxusb/001/                                                                                                                                 163ms  10:56:17 PM 
  File: /dev/vboxusb/001/
  Size: 120       	Blocks: 0          IO Block: 4096   directory
Device: 0,5	Inode: 530         Links: 2
Access: (0750/drwxr-x---)  Uid: (    0/    root)   Gid: (  973/vboxusers)
Context: system_u:object_r:device_t:s0
Access: 2023-02-08 22:56:14.848548137 -0500
Modify: 2023-02-08 22:03:03.922543581 -0500
Change: 2023-02-08 22:03:03.922543581 -0500
 Birth: 2023-02-07 00:41:48.210999823 -0500

id
uid=1000(fedora) gid=1000(fedora) groups=1000(fedora),10(wheel),36(kvm),971(lxd),973(vboxusers),977(libvirt) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

podman unshare stat /dev/vboxusb/001/                                                                                                              150ms  10:56:12 PM 
  File: /dev/vboxusb/001/
  Size: 120       	Blocks: 0          IO Block: 4096   directory
Device: 0,5	Inode: 530         Links: 2
Access: (0750/drwxr-x---)  Uid: (65534/  nobody)   Gid: (65534/  nobody)
Context: system_u:object_r:device_t:s0
Access: 2023-02-08 22:56:14.848548137 -0500
Modify: 2023-02-08 22:03:03.922543581 -0500
Change: 2023-02-08 22:03:03.922543581 -0500
 Birth: 2023-02-07 00:41:48.210999823 -0500

[giuseppe]

so that is expected. The device file is owned by a UID/GID that are not mapped inside the user namespace and their mode is 0750 (so no world access). You need to chmod that file to mode 0755

[mtalexan]

I was thinking this was inconsistent behavior, but it's just an incorrect user expectation. I believe the user expectation was that all the container construction is done from the host user namespace, so if there's a folder permissions issue it would prevent usage in the container, but wouldn't prevent the container from running.

I went thru the cases of trying to map a file from a folder, assuming no groups are being included into the container. The identical behavior applies for when it's a device node instead of a file.

Folder access	File Access	Succeeds?	Permissions in Container?
Owner	Owner	Y	Y
Owner	Group	Y	N
Owner	Other	Y	Y
Owner	None	Y	N
Group	Owner	Error: crun:	n/a
Group	Group	Error: crun:	n/a
Group	Other	Error: crun:	n/a
Group	None	Error: crun:	n/a
Other	Owner	Y	Y
Other	Group	Y	N
Other	Other	Y	Y
Other	None	Y	N
None	Owner	Error: statfs	n/a
None	Group	Error: statfs	n/a
None	Other	Error: statfs	n/a
None	None	Error: statfs	n/a

Given the results, it actually seems odd that the Owner,None case allows the container to run. I suspect that's the cause of confusion about the Group,* cases, and could be surprising for the None,* cases.