Description of problem: In a podman fedora container, lsblk fails. It seems to want to look at /sys/dev/block, but at least in a container, /sys/dev/ is empty: # ls -l /sys/dev/ total 0 The more "traditional" /sys/block is fine: # ls -l /sys/block total 0 lrwxrwxrwx. 1 nobody nobody 0 Oct 1 14:34 dm-0 -> ../devices/virtual/block/dm-0 lrwxrwxrwx. 1 nobody nobody 0 Oct 1 14:34 dm-1 -> ../devices/virtual/block/dm-1 lrwxrwxrwx. 1 nobody nobody 0 Oct 1 14:34 dm-2 -> ../devices/virtual/block/dm-2 lrwxrwxrwx. 1 nobody nobody 0 Oct 1 14:34 sda -> ../devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda It's also difficult to work around this: you can't create symlinks in /sys, and bind mounting is denied: # mkdir /tmp/dev # ln -s ../block /tmp/dev/block # mount -o bind /tmp/dev /sys/dev mount: /sys/dev: permission denied. Could lsblk perhaps gracefully fall back to /sys/block/ ? Version-Release number of selected component (if applicable): util-linux-2.36-3.fc34.x86_64 podman-2.1.1-2.fc33.x86_64 crun-0.15-3.fc33.x86_64 runc-1.0.0-279.dev.gitdedadbf.fc33.x86_64 kernel-5.8.12-300.fc33.x86_64 How reproducible: Always Steps to Reproduce: 1. podman run -it --rm fedora:rawhide bash -i 2. inside, run `lsblk` Actual results: fails with lsblk: failed to access sysfs directory: /sys/dev/block: No such file or directory Expected results: lsblk works. Additional info: Exactly the same in a fedora:32 container, so not a recent regression. This currently gets in the way of running Anaconda tests.
> you can't create symlinks in /sys, and bind mounting is denied: FTR, that's known [1], and can be worked around with --cap-add SYS_ADMIN. (Not really related to this bug report, but to close off that tangent) [1] https://github.com/containers/podman/issues/3112
Hmm ... /sys/dev/block is used by --inverse option, it seems for the default output we do not need to require this directory. Unfortunately, the directory check is generic in the code. I'll fix it.
My previous comment is incorrect. The command lsblk (and many other tools from util-linux) uses /sys/dev/block as it provides unified access to system information based on device numbers rather than device names -- don't forget /sys/block uses kernel device names, but user can use for example human readable names for DM devices, etc. You need to fix your environment (podman) to provide serious and compatible /sys. This is impossible improve without an invasive change to the current code and functionality.
Ack, thanks Karel! Reassigning to podman then.
From the Podman changelogs, we masked this directory in containers to prevent information leakage from the host. I'll look into this more, but if this was done for security reasons, I don't think we can change it.
We have talked about adding a new --security-opt for mask and unmask. To basically allow users to unmask certain parts of the OS without forcing them to go to --privileged mode. We were definitely requested to mask out this information to prevent info leak.
I see, so this is about showing the *host*'s block devices? That's indeed neither useful nor particularly desirable for a container. But indeed a container usually doesn't have its "own" set of block devices, so maybe /sys/dev/block and lsblk are really just non-sensical in a container. FTR, we mocked out that part of the Anaconda tests (which was the right thing to do for other reasons, too), so we are not blocked by this. So I think all in all I concur that this is a wontfix. Thanks, and sorry for the noise!
I do not understand how /sys/dev/block is security sensitive thing and /sys/block is fine. The both directories are symlinks to the same place :)) The difference is only names of the symlinks and /sys/dev/block contains also partitions (but you can see the partitions by /sys/block/<disk>/<part>/). It's just two different ways to the *same* information.
Perhaps we should block /sys/block as well.
We are talking about adding new functionality to Podman to allow selective unmasking podman run --security-opt unmask:/sys/dev ... Would that satisfy your needs.
@Dan: I'm honestly not sure what "my needs" are -- indeed I was originally misled, and on second thought block device operations really don't make much sense in a standard container. There may of course be special cases such as "handing over" an entire block device to a container (for e.g. a database or a bunch of cephfs nodes), and these should of course appear in sysfs.
The block size of the underlying filesystem is useful for open(O_DIRECT) to know what size to use in write syscalls - https://github.com/containers/podman/issues/12746
You can unblock the path. podman run --security-opt unmask=/sys/dev/block ...