There doesn't seem to be a way to expose new loop devices in a rootless container

[gabeblack]

Issue Description

My ultimate goal is to create a disk image file in a rootless container.

The usual pattern is to create a file (e.g., using dd), use sfdisk or parted to create a partition table and losetup and kpartx to map the file via loop devices, mkfs to create the filesystem, grub2-install or similar for bootable disks, and then finally mount the loop devices to interact with the filesystem.

Anyhow, I'd like to do this in a podman container (one of our build steps is to create a disk/iso image); specifically a rootless container that has the requisite permissions to be able to use loop devices. So far, in order to accomplish this I've had to add my user to the disk group and add the following options:

--device /dev/loop-control:/dev/loop-control:rwm 
--device /dev/loop0:/dev/loop0:rwm
--security-opt unmask=/sys/dev/block 

If my disk image were a single partition, I think I'd be ok, as in order to mount the "disk", all I'd need to do is mount /dev/loop0, which I've already mapped to the container. However, since the disk has multiple partitions, I need to mount /dev/loop0p1 and /dev/loop0p2.

The losetup command to create those devnodes works in the container, but the devnodes are only visible in the host environment (i.e., loop0p1 and loop0p2 are only listed in /dev in the host environment, NOT in the podman container).

I can't simply add --device /dev/loop0p1 to the podman run command, because at the time of invocation, those devnodes do not exist. They are only created after losetup is run.

So finally, the issue is there doesn't seem to be a way to get dynamically created devnodes to show up in the (rootless) container...

Steps to reproduce the issue

Steps to reproduce the issue:

1. Add your user to the disk group: sudo usermod -aG disk <user>
2. run an interactive podman container with the following options --device /dev/loop-control:/dev/loop-control:rwm --security-opt unmask=/sys/dev/block --device /dev/loop0:/dev/loop0:rwm

In the container (assuming the container has the parted and losetup utilities)

1. create a blank disk image file: dd if=/dev/zero of=disk.img bs=1000 count=0 seek=1000000
2. add partitions to the disk image:

parted -s disk.img -- mklabel msdos \
       mkpart primary fat16 2048s 1753069s \
       set 1 lba off \
       set 1 boot on \
       mkpart primary fat32 1753070s 1785199s \
       set 2 lba off \
       set 2 esp on 

3. set up the loop device(s):
   /sbin/losetup -Pf --show disk.img

4. run ls /dev/loop*
   (The issue is you will only see /dev/loop-control and /dev/loop0. On the Host you will additionally see /dev/loop0p1 and /dev/loop0p2)

Note: to "clean up" all the loop devices, run losetup -D

Describe the results you received

The result is I only see /dev/loop-control and /dev/loop0 in the podman container. On the Host /dev/loop0p1 and /dev/loop0p2 are created, but not visible in the container.

Describe the results you expected

I expect to see /dev/loop-control, /dev/loop0, /dev/loop0p1, and /dev/loop0p2 in the container.

podman info output

host:
  arch: amd64
  buildahVersion: 1.37.6
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.10-1.el9.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.10, commit: 24a5a709fd6110529a775eb9f8fe12d8ca8cf0e8'
  cpuUtilization:
    idlePercent: 98.17
    systemPercent: 0.98
    userPercent: 0.85
  cpus: 4
  databaseBackend: sqlite
  distribution:
    distribution: ol
    variant: server
    version: "9.4"
  eventLogger: file
  freeLocks: 2048
  hostname: cgbu-phx-289
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 500
      size: 1
    uidmap:
    - container_id: 0
      host_id: 1607952
      size: 1
  kernel: 5.15.0-301.163.5.2.el9uek.x86_64
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 2797084672
  memTotal: 33172914176
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.10.0-3.el9_4.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.10.0
    package: netavark-1.10.3-1.el9.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.10.3
  ociRuntime:
    name: crun
    package: crun-1.14.3-1.el9.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.14.3
      commit: 1961d211ba98f532ea52d2e80f4c20359f241a98
      rundir: /run/user/1607952/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  pasta:
    executable: /bin/pasta
    package: passt-0^20240806.gee36266-2.el9.x86_64
    version: |
      pasta 0^20240806.gee36266-2.el9.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1607952/podman/podman.sock
  rootlessNetworkCmd: pasta
  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: false
  serviceIsRemote: false
  slirp4netns:
    executable: /bin/slirp4netns
    package: slirp4netns-1.2.3-1.el9.x86_64
    version: |-
      slirp4netns version 1.2.3
      commit: c22fde291bb35b354e6ca44d13be181c76a0a432
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 18520326144
  swapTotal: 18974998528
  uptime: 878h 49m 5.00s (Approximately 36.58 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - container-registry.oracle.com
  - docker.io
store:
  configFile: /scratch/home/gabblack/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.ignore_chown_errors: "true"
  graphRoot: /home/gabblack/.local/share/containers/storage
  graphRootAllocated: 1098974756864
  graphRootUsed: 296497758208
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 10
  runRoot: /run/user/1607952/containers
  transientStore: false
  volumePath: /scratch/home/gabblack/.local/share/containers/storage/volumes
version:
  APIVersion: 5.2.2
  Built: 1738666229
  BuiltTime: Tue Feb  4 10:50:29 2025
  GitCommit: ""
  GoVersion: go1.22.9 (Red Hat 1.22.9-2.el9_5)
  Os: linux
  OsArch: linux/amd64
  Version: 5.2.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

Oracle Linux 9 is the host OS (running in an OCI VM environment) if that matters.

Additional information

No response

[Luap99]

This has nothing to do with podman really, I am not sure why you are even be allowed to manipulate disks. The kernel will never allow an unprivileged user namespace to mount "real" file systems.

https://man7.org/linux/man-pages/man7/user_namespaces.7.html

Holding CAP_SYS_ADMIN within the user namespace that owns a
process's mount namespace allows that process to create bind
mounts and mount the following types of filesystems:

       •  /proc (since Linux 3.8)
       •  /sys (since Linux 3.8)
       •  devpts (since Linux 3.9)
       •  [tmpfs(5)](https://man7.org/linux/man-pages/man5/tmpfs.5.html) (since Linux 3.9)
       •  ramfs (since Linux 3.9)
       •  mqueue (since Linux 3.9)
       •  bpf (since Linux 4.4)
       •  overlayfs (since Linux 5.11)

So I would say whatever you want to do is not possible. I don't know how loop devices work in general but if it /dev/loop-control talks to the host and then it will create the device nodes there as it doesn't seem to be namespace aware. You likely would need to create your own device node in the container namespace which again is not possible as the kernel will block that.

Permission wise this just doesn't sounds like it can ever work.

Now you could try to mount all devices with something like -v dev:/dev but I don't think that will get you much further.
In any case this is not a podman bug.