Description of problem: losetup fails to setup a loop device because no /dev/loop? entries exist since I've upgraded to F20 (they where there previously). This shouldn't be a problem, as losetup is able to create those entries by means of /dev/loop-control, however the default ownership for this node is root.root with rw-permission only for root. Hence losetup fails to create a new loop device unless executed as root. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Reboot system 2. losetup -f somefile.img 3. Actual results: losetup: somefile.img: failed to set up loop device: No such file or directory Expected results: New device /dev/loop? should be created and linked to somefile.img Additional info: After changing the ownership of /dev/loop-control from root.root to root.disk, losetup is able to create the /dev/loop? device and links it to the image file just fine. For this purpose I've created a new udev rule: KERNEL=="loop-control", GROUP="disk
Well, I'm not able to reproduce this problem on system with: $ rpm -q kernel util-linux systemd kernel-3.12.5-302.fc20.x86_64 util-linux-2.24-2.fc20.x86_64 systemd-208-9.fc20.x86_64 Please try to debug the problem -- losetup uses LOOP_CTL_GET_FREE ioctl to ask for free loop device, then kernel allocates necessary stuff and send "add" event to userspace, try: # udevadm monitor and on another terminal: # strace -e ioctl losetup -f file.img For example: # ll /dev/loop-control crw------- 1 root root 10, 237 Jan 3 11:10 /dev/loop-control # ll /dev/loop3 ls: cannot access /dev/loop3: No such file or directory # strace -e ioctl losetup -f /home/fs-images/2g.img ioctl(3, LOOP_CTL_GET_FREE) = 3 ioctl(4, LOOP_SET_FD, 0x3) = 0 ioctl(4, LOOP_SET_STATUS64, {offset=0, number=0, flags=0, file_name="/home/fs-images/2g.img", ...}) = 0 +++ exited with 0 +++ # ll /dev/loop3 brw-rw---- 1 root disk 7, 3 Jan 3 11:19 /dev/loop3 and udev monitor: KERNEL[1533.168532] add /devices/virtual/bdi/7:3 (bdi) UDEV [1533.169457] add /devices/virtual/bdi/7:3 (bdi) KERNEL[1533.169981] add /devices/virtual/block/loop3 (block) KERNEL[1533.170020] change /devices/virtual/block/loop3 (block) UDEV [1533.172780] add /devices/virtual/block/loop3 (block) UDEV [1533.177493] change /devices/virtual/block/loop3 (block) ... note that I don't use selinux.
Created attachment 844928 [details] losetup strace
Same version numbers here: $ rpm -q kernel util-linux systemd kernel-3.12.5-302.fc20.x86_64 util-linux-2.24-2.fc20.x86_64 systemd-208-9.fc20.x86_64 $ ll /dev/loop* crw-------. 1 root root 10, 237 Jan 3 11:33 /dev/loop-control udevadm and "strace -e ioctl" give no output, see attachment above for full strace output. Additionally, losetup with debug output gives: $ LOOPDEV_DEBUG=1 losetup -f test.img loopdev: [0x7ffffdf25750]: init: ignore ioctls loopdev: [0x7ffffdf25750]: init: loop-control detected loopdev: [0x7ffffdf25750]: find_unused requested loopdev: [0x7ffffdf25750]: find_unused by loop-control [rc=-1] loopdev: [0x7ffffdf25750]: iter: initialize loopdev: [0x7ffffdf25750]: iter: next loopdev: [0x7ffffdf25750]: iter: next: default check loopdev: [0x7ffffdf25750]: loop0 successfully assigned loopdev: [0x7ffffdf25750]: sysfs: failed devname to devno loopdev: [0x7ffffdf25750]: get_offset [rc=-22] loopdev: [0x7ffffdf25750]: iter: de-initialize loopdev: [0x7ffffdf25750]: find_unused by scan [rc=0] loopdev: [0x7ffffdf25750]: set backing file=/home/ottmi/test.img loopdev: [0x7ffffdf25750]: device setup requested loopdev: [0x7ffffdf25750]: setup: backing file open: OK loopdev: [0x7ffffdf25750]: open /dev/loop0 [rw]: failed loopdev: [0x7ffffdf25750]: setup failed [rc=-2] losetup: test.img: failed to set up loop device: No such file or directory loopdev: [0x7ffffdf25750]: de-initialize loopdev: [0x7ffffdf25750]: iter: de-initialize Running losetup as root works fine, of course: sudo LOOPDEV_DEBUG=1 losetup -f test.img [sudo] password for ottmi: loopdev: [0x7fff51c5d220]: init: ignore ioctls loopdev: [0x7fff51c5d220]: init: loop-control detected loopdev: [0x7fff51c5d220]: find_unused requested loopdev: [0x7fff51c5d220]: loop0 successfully assigned loopdev: [0x7fff51c5d220]: find_unused by loop-control [rc=0] loopdev: [0x7fff51c5d220]: set backing file=/home/ottmi/test.img loopdev: [0x7fff51c5d220]: device setup requested loopdev: [0x7fff51c5d220]: setup: backing file open: OK loopdev: [0x7fff51c5d220]: open /dev/loop0 [rw]: ok loopdev: [0x7fff51c5d220]: setup: device open: OK loopdev: [0x7fff51c5d220]: setup: LOOP_SET_FD: OK loopdev: [0x7fff51c5d220]: setup: LOOP_SET_STATUS64: OK loopdev: [0x7fff51c5d220]: setup success [rc=0] loopdev: [0x7fff51c5d220]: de-initialize loopdev: [0x7fff51c5d220]: closing old open fd loopdev: [0x7fff51c5d220]: iter: de-initialize So obviously, losetup is not using ioctl to create the device but loop-control to which it doesn't have proper access rights unless they are set by the previously mentioned udev rule. Is there any way to force ioctl over loop-control ?
OK, so the problem is really only the ownership of the control file ;-) (I wasn't sure, so I have asked for the strace and described all the loops allocation... for me it's little bit unusual that you call losetup as non-root, but your use-case makes sense.) Thanks. Reassign to udev... by the way, for example btrfs-control is also root.root, maybe it would be better to fix it too.
Wellll.... Is losetup supposed to be callable unpriviliged? If so, then it should probably be suid root or so. It sounds really wrong to open up /dev/loop-control for everybody. Creating loop devices should not be unrestricted! It's similar to the mount() syscall in this regard, which is priviliged by default, but which /bin/mount by being suid-root can open up to unprivileged userspace in certain cases. REassigning to util-linux again.
(In reply to Lennart Poettering from comment #5) > Wellll.... Is losetup supposed to be callable unpriviliged? If so, then it > should probably be suid root or so. Ah.. did you read the comment #1 ? He does not want to open up it for everyone, but change *group* to "disk" ask we use for regular loop devices (and many others files in /dev). And yes, it's unexpected and unwanted to have losetup suid. The problem is that originally losetup used /dev/loopN files only (all with root.disk perms), now it uses also /dev/loop-control (unfortunately root.root with perms), so users who rely on "disk" group have a problem after update to system with /dev/loop-control.
Just to comment on that: I'm using this to mount a Truecrypt container. Obviously this will require root priviliges lateron anyway for tcplay. So for myself it's not really an issue, I was just surprised that my script didn't work anymore after the upgrade to FC20. However, I'm not sure whether there are any use cases for loop devices that won't require root priviliges down the chain...
In my setup pam_mount is used to mount an encrypted container after the login of the user. I guess cryptsetup is not called with root privileges there as the mount didn't succeed any more after upgrading to FC20 (from FC18).
/dev/mapper/control is root.root, even though /dev/dm-* are root.disk. I guess that loop-control and loop* should use the same pattern... So either all disk control devices like mapper/control, btrfs-control, loop-control should be owned by the disk group, or none. Since write access to the underlying block devices is given to the disk group, withholding privileges on control devices doesn't really make sense... I guess we should change the ownership.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #9) > /dev/mapper/control is root.root, even though /dev/dm-* are root.disk. I > guess that loop-control and loop* should use the same pattern... Well, as described in comment #6 -- the original losetup (without /dev/loop-control) works just fine, so the current state could be interpreted as regression ... but yes, it's unusual use-case. Not sure if we care about it. Note that I have also improved upstream losetup(8). There is a race (thanks to Harald who found it). The losetup does not wait for udevd to complete setup of the device. It seems more robust to wait and try it more than once if open(/dev/loopN) ends with EACCES or ENOENT. (util-linux commit 663bf040611240d164f2464b4d892ecd2b02fa6f).
It sounds reasonable to make to make btrfs-control and loop-control owned by the "disk" group. mapper/control, probably too, but that's owned by the lvm guys.
Fixed in systemd git, it will show up in rawhide with the next release. http://cgit.freedesktop.org/systemd/systemd/commit/?id=27e7c26268bd4c16edb92f2b8a8626b00c6f2dad
systemd-208-18.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/systemd-208-18.fc20
Package systemd-208-18.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-208-18.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7512/systemd-208-18.fc20 then log in and leave karma (feedback).
Package systemd-208-19.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-208-19.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7512/systemd-208-19.fc20 then log in and leave karma (feedback).
The update has long been in stable, closing this bug.