Description of problem: The following warning periodically appears when rpc.mountd calls out to libblkid to get the device uuids: Jul 11 08:24:52 fedora25.example.com kernel: device-mapper: core: rpc.mountd: sending ioctl 5331 to DM device without required privilege. Version-Release number of selected component (if applicable): libblkid-2.28.2-2.fc25.x86_64 How reproducible: Easy Steps to Reproduce: 1. Set up an nfs server # mkdir /export # echo "/export *(rw,no_root_squash)" >/etc/exports # systemctl start nfs-server 2. Mount the export from any client # mount 127.0.0.1:/export /mnt 3. Check the journal for the warning message # journalctl -n 4. Note: Once rpc.mountd has the uuid for a device, it caches it for a *really* long time and may not call out to libblkid again. You can flush the cache by running 'exportfs -f'. Actual results: The warning message is produced. Expected results: No warning message. Additional info: The warning message appears in kernel version 4.11 and higher, due to commit e980f62353c697cbf0c4325e43df6e44399aeb64 Author: Christoph Hellwig <hch> Date: Sat Feb 4 10:45:03 2017 +0100 dm: don't allow ioctls to targets that don't map to whole devices .. at least for unprivileged users. Before we called into the SCSI ioctl code to allow excemptions for a few SCSI passthrough ioctls, but this is pretty unsafe and except for this call dm knows nothing about SCSI ioctls. As the SCSI ioctl code is now optional, we really don't want to drag it in for DM, and the exception is not very useful anyway. Signed-off-by: Christoph Hellwig <hch> Acked-by: Mike Snitzer <snitzer> Acked-by: Paolo Bonzini <pbonzini> Reviewed-by: Johannes Thumshirn <jthumshirn> Signed-off-by: Jens Axboe <axboe>
Backtrace leading up to the ioctl call: [root@fedora25 ~]# stap -d /usr/lib64/libc-2.24.so -d /usr/lib64/libblkid.so.1.1.0 -d /usr/sbin/rpc.mountd -e 'probe syscall.ioctl { if (execname()=="rpc.mountd" && $cmd==0x5331) { printf("\n%s %s %s %s\n", execname(), ppfunc(), $$parms, fullpath_struct_file(task_current(), task_fd_lookup(task_current(), $fd))); print_ubacktrace(); } }' rpc.mountd SyS_ioctl fd=0xd cmd=0x5331 arg=0x0 /dev/dm-0 0x7f5835699637 : ioctl+0x7/0x30 [/usr/lib64/libc-2.24.so] 0x7f5835da6c1a : blkid_probe_set_device+0x47a/0x510 [/usr/lib64/libblkid.so.1.1.0] 0x7f5835da9f6a : blkid_verify+0x10a/0x640 [/usr/lib64/libblkid.so.1.1.0] 0x7f5835da100b : blkid_get_dev+0xdb/0x280 [/usr/lib64/libblkid.so.1.1.0] 0x560c6ce69745 : uuid_by_path+0xd5/0x2d0 [/usr/sbin/rpc.mountd] 0x560c6ce6a52e : dump_to_cache.constprop.7+0x1ee/0x360 [/usr/sbin/rpc.mountd] 0x560c6ce6a70a : cache_export_ent.constprop.6+0x6a/0x210 [/usr/sbin/rpc.mountd] 0x560c6ce6b109 : nfsd_fh+0x859/0x9e0 [/usr/sbin/rpc.mountd] 0x560c6ce6bda3 : cache_process_req+0x73/0xc0 [/usr/sbin/rpc.mountd] 0x560c6ce6c2fd : my_svc_run+0x1dd/0x260 [/usr/sbin/rpc.mountd] 0x560c6ce66fa7 : main+0x737/0xa60 [/usr/sbin/rpc.mountd] 0x7f58355bc401 : __libc_start_main+0xf1/0x1d0 [/usr/lib64/libc-2.24.so] 0x560c6ce672fa : _start+0x2a/0x30 [/usr/sbin/rpc.mountd]
Yes, libblkid uses CDROM_GET_CAPABILITY ioctl to detect CDROM. We use it for 10 year, but now kernel spams userspace by useless warnings. I really don't understand why -ENOIOCTLCMD is not enough. Why we need extra warning?
OK, I have improved libblkid to not use the ioctl for DM devices (devices with dm/uuid in sysfs) -- util-linux upstream commit 884659b32a8c632658e00700264570fb027a44d9. The change will be available in v2.30.1. You can close this bug if you believe that the current kernel behaviour is correct.
Underlying this is a security issue, where certain scsi ioctls were passed through to the underlying device and could access content outside the portion of it that the dm device had been permitted to use. Prior to that patch, some scsi code was called to separate safe and unsafe ioctls - a layer violation really. Now those exemptions have just been removed and all are giving the warning including ones that were safe and previously allowed. Given that these accesses are all safely trapped, I'm also not sure why this needs to be logged any more - perhaps we could indeed downgrade the message to DMDEBUG.
Hello, I see same error in FC26 when I run/migrate KVM machine device-mapper: core: qemu-system-x86: sending ioctl * to DM device without required privilege
Hi, +1 kernel: device-mapper: core: nspr-2: sending ioctl 5393 to DM device without required privilege. when start one vbox vm with F26 and F27/rawhide What this message means ?
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.