Description of problem: SELinux is preventing fprintd from read, write access on the chr_file 040. ***** Plugin device (91.4 confidence) suggests **************************** If you want to allow fprintd to have read write access on the 040 chr_file Then you need to change the label on 040 to a type of a similar device. Do # semanage fcontext -a -t SIMILAR_TYPE '040' # restorecon -v '040' ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that fprintd should be allowed read write access on the 040 chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'fprintd' --raw | audit2allow -M my-fprintd # semodule -X 300 -i my-fprintd.pp Additional Information: Source Context system_u:system_r:fprintd_t:s0 Target Context system_u:object_r:device_t:s0 Target Objects 040 [ chr_file ] Source fprintd Source Path fprintd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-41.33-1.fc41.noarch Local Policy RPM selinux-policy-targeted-41.33-1.fc41.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.12.15-200.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Feb 18 15:24:05 UTC 2025 x86_64 Alert Count 2 First Seen 2025-02-18 08:59:43 CET Last Seen 2025-02-19 17:10:03 CET Local ID 053dcaed-2fc0-48aa-9611-11a776e15fee Raw Audit Messages type=AVC msg=audit(1739981403.799:337): avc: denied { read write } for pid=126718 comm="fprintd" name="040" dev="devtmpfs" ino=1763 scontext=system_u:system_r:fprintd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0 Hash: fprintd,fprintd_t,device_t,chr_file,read,write Version-Release number of selected component: selinux-policy-targeted-41.33-1.fc41.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing fprintd from read, write access on the chr_file 040. package: selinux-policy-targeted-41.33-1.fc41.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.12.15-200.fc41.x86_64 component: selinux-policy
Created attachment 2077204 [details] File: description
Created attachment 2077205 [details] File: os_info
Kamile, The 040 char device file has incorrect label. Can you locate the file and check if the current label is correct? The path expectedly is in /dev/bus/usb, e.g. ls -liZ /dev/bus/usb/*/040
Hi Zdenek, today it was "047" and not "040": úno 24 12:04:29 chronos audit[13777]: AVC avc: denied { read write } for pid=13777 comm="fprintd" name="047" dev="devtmpfs" ino=1922 scontext=system_u:system_r:fprintd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0 The problem is, there are no such files (neither 047 nor 040) on my filesystem: $ sudo find / -name 047 find: ‘/proc/2762/task/2762/net’: Invalid argument find: ‘/proc/2762/net’: Invalid argument find: ‘/run/user/1000/doc’: Permission denied find: ‘/run/user/1000/gvfs’: Permission denied Perhaps it's some temporary file that gets deleted after being used? Any idea how to debug this closer? I believe I saw the error pop up after system resume, but when I tried suspend+resume again, it didn't happen again.
Actually, today it is 056 and I can find it! úno 28 09:26:46 chronos audit[262404]: AVC avc: denied { read write } for pid=262404 comm="fprintd" name="056" dev="devtmpfs" ino=1857 scontext=system_u:system_r:fprintd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0 $ ls -liZ /dev/bus/usb/003/056 1857 crw-rw-r--. 1 root root system_u:object_r:usb_device_t:s0 189, 311 28. úno 09.27 /dev/bus/usb/003/056 $ lsusb | grep 056 Bus 003 Device 056: ID 06cb:00f9 Synaptics, Inc. I connected my suspended laptop to a thunderbolt dock (which waked it up, to my dissatisfaction) and then I connected another USB-C with my monitor (which acts like a USB hub, with keyboard and mouse attached to it). Not sure whether it can have any impact on the fingerprint denial.
Thank you, so since you can see the label correct, it looks more like a race condition - as if the device was accessed earlier than udev finishes and the label is set properly. Switch the component for further investigation.
OK, so … 1. Fingerprint readers get tagged with "ID_PERSIST=0" through hwdb and the "power/persist" feature is turned off. As such, the device may get recreated at resume time. 2. this is fprintd -> libfprint -> lib(g)usb -> libudev device monitoring. It should only access a new device after it is available through udev. As such, I see two possibilities right now: 1. We are still accessing the old stale device that was removed due to resume. In that case, the error should just be ignored, there is nothing we can do. 2. We are opening the a newly added device (I don't think so?). If this was the case, then there would be a race condition and it would definitely not be our fault if the permissions are incorrect when udev returns. I doubt that is the case … Which I guess means this is point #1, i.e. an old device that libfprint has still open but which was removed. In that case, we can probably just ignore the error, though I suppose one could argue that it shouldn't log a warning as we used to be permitted to read/write the device before suspend. So, what is it? :-)
> we can probably just ignore the error, though I suppose one could argue that it shouldn't log a warning Yeah, it's not fully convenient to see an error sometimes pop up on resume (through setroubleshoot), look into details, remember this conversation, and then realize "oh yeah, I should ignore this" :-D > We are still accessing the old stale device that was removed due to resume However, in comment 5, the AVC error mentioned a device which was still around and showing in lsusb. Is it possible that it still was an old stale device? The next time it happens, what can I check/what logs I can provide, to better determine this?
Right, so this *is* the newly created USB device and we are looking at a race condition (sorry, could have known if I had the history more carefully). You can enable debugging output for fprintd/libfprint, even if I doubt that will be helpful. Run "systemctl edit fprintd.service" and enter: """ [Service] Environment=G_MESSAGES_DEBUG=all """ @zpytela are you really sure the selinux is entirely safe with regard to race conditions? I do believe that libusb uses udev, so all the rules for the new device should have been completed when it appears. I remember a bug where someone complained about libusb being too slow because TLP is badly written and makes udev rule handling slow.
Elaborating only on the second case. There is a known race condition, or maybe rather a short time window when the file is created with the default=incorrect label, it actually is systemd-udevd which then responds to the ADD udev event and runs relabel. Enable debugging in udev can get additional data, but I am not sure how it would help. In a different case, a simple (nano)sleep command in the service gave the time needed for relabeling. Adding Ondrej to chime in. Some hints can be found in https://issues.redhat.com/browse/RHEL-2036 https://issues.redhat.com/browse/RHEL-55133 there is also this kbase article https://access.redhat.com/solutions/7022020 which adds 16000 new rules, I am afraid it does not feel like the right solution
> …, it actually is systemd-udevd which then responds to the ADD udev event and runs relabel. Hrm, that sounds really weird. If udevd relabels the device and we wait for the udev ADD signal, then there really shouldn't be any race condition … so why are we not seeing the correct labels when fprintd opens the device?
Created attachment 2080867 [details] journal during avc Happened again during system resume. Attaching the journal with debug messages enabled (comment 9).
Comment on attachment 2080867 [details] journal during avc Oh, hmm, interesting. fprintd did an idle shutdown and is starting up there. And, then we do a g_usb_context_enumerate. Which should be doing a linux_udev_scan_devices and then uses udev_enumerate_scan_devices. So, I think we are looking at a libusb bug here. It should not enumerate devices that are not yet ready in udev. The udev API is not really obvious here as udev_enumerate_scan_devices returns the device. I suppose that linux_udev_scan_devices needs to call udev_device_get_is_initialized, i.e. this the below patch for libusb. Can you test that? diff --git a/libusb/os/linux_udev.c b/libusb/os/linux_udev.c index 9ec9eb17..629aac6d 100644 --- a/libusb/os/linux_udev.c +++ b/libusb/os/linux_udev.c @@ -290,6 +290,9 @@ int linux_udev_scan_devices(struct libusb_context *ctx) udev_dev = udev_device_new_from_syspath(udev_ctx, path); + if (!udev_device_get_is_initialized(udev_dev)) + continue; + r = udev_device_info(ctx, 0, udev_dev, &busnum, &devaddr, &sys_name); if (r) { udev_device_unref(udev_dev);
Well, obviously: diff --git a/libusb/os/linux_udev.c b/libusb/os/linux_udev.c index 9ec9eb17..5e5f0c77 100644 --- a/libusb/os/linux_udev.c +++ b/libusb/os/linux_udev.c @@ -290,6 +290,11 @@ int linux_udev_scan_devices(struct libusb_context *ctx) udev_dev = udev_device_new_from_syspath(udev_ctx, path); + if (!udev_device_get_is_initialized(udev_dev)) { + udev_device_unref(udev_dev); + continue; + } + r = udev_device_info(ctx, 0, udev_dev, &busnum, &devaddr, &sys_name); if (r) { udev_device_unref(udev_dev);
OK, opened an upstream PR for libusb: https://github.com/libusb/libusb/pull/1625 I think this is correct. umockdev seems to agree (to the extend that its emulation can trigger this scenario). But I haven't tried with real hardware; I guess one could do that by inserting a udev rule with a long sleep and checking how libusb device enumeration behaves during that time. But, honestly, what could possibly go wrong? This is a pretty straight forward fix.
Thanks. We're in the middle of releasing Fedora 42, I can't spend much time on this atm. Also, I can't really confirm that it's fixed, I can only confirm that I haven't seen the AVC for X weeks :-) If there's a Koji build with the fix, I can install it and report after some time.
Upstream doesn't seem to want to do anything until it is tested. So I now posted an PR: https://src.fedoraproject.org/rpms/libusb1/pull-request/9 Once that has been in for a bit someone should probably kick upstream again to make them move.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. 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 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.