Description of problem: Inserting a USB disk causes systemd-udevd to loop infinitely. Version-Release number of selected component (if applicable): systemd-197-1.fc18.1.x86_64 How reproducible: Plug in a USB disk. In this case, a FAT32 partition is on the disk. Steps to Reproduce: 1. Plug in USB disk. 2. 3. Actual results: Lots and lots of messages like: [58083.384750] systemd-udevd[5032]: Failed to set security context (null) for /dev/disk/by-label: File exists [58083.384806] systemd-udevd[5032]: Failed to set security context (null) for /dev/disk/by-label: File exists [58083.384846] systemd-udevd[5032]: Failed to set security context (null) for /dev/disk: File exists [58083.384902] systemd-udevd[5032]: Failed to set security context (null) for /dev/disk: File exists [58083.384921] systemd-udevd[5032]: Failed to set security context (null) for /dev/disk/by-label: File exists [58083.384977] systemd-udevd[5032]: Failed to set security context (null) for /dev/disk/by-label: File exists [58083.385016] systemd-udevd[5032]: Failed to set security context (null) for /dev/disk: File exists [58083.385093] systemd-udevd[5032]: Failed to set security context (null) for /dev/disk: File exists eventual termination: [58083.385126] systemd-udevd[368]: worker [5032] /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/1-1.2:1.0/host19/target19:0:0/19:0:0:0/block/sdb timeout; kill it [58083.385146] systemd-udevd[368]: seq 2809 '/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/1-1.2:1.0/host19/target19:0:0/19:0:0:0/block/sdb' killed Expected results: Don't flood dmesg. Offer to mount USB disk. Additional info: /dev/disk/by-label does NOT in fact exist, despite the message /dev/disk/ does exist, and contains: $ ls -la /dev/disk /dev/disk/by-label ls: cannot access /dev/disk/by-label: No such file or directory /dev/disk: total 0 drwxr-xr-x. 6 root root 120 Feb 11 08:14 . drwxr-xr-x. 20 root root 3520 Feb 11 11:05 .. drwxr-xr-x. 2 root root 340 Feb 11 11:05 by-id drwxr-xr-x. 2 root root 60 Feb 9 16:08 by-partlabel drwxr-xr-x. 2 root root 100 Feb 9 16:08 by-partuuid drwxr-xr-x. 2 root root 160 Feb 11 11:05 by-uuid $ sudo fdisk -l /dev/sdb Disk /dev/sdb: 31.0 GB, 30992891904 bytes, 60532992 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x6b8b4567 Device Boot Start End Blocks Id System /dev/sdb1 2048 60532991 30265472 b W95 FAT32
Hitting the same issue when plugging-in mp3 player. # cat /var/log/messages | grep systemd-udevd | wc -l 367049
Created attachment 697217 [details] /var/log/messages snippet
I experienced the same symptoms here, but as it had worked the previous day (or so), and I had installed some SELinux updates, I just rebooted and the problem was solved. Hoping it works for you, too !
In my case (f18, selinux-policy-3.11.1-79.fc18.noarch ), rebooting occasionnaly solves the problem, but it eventually re-appears. Temporarily disabling selinux while plugging the USB drive allows it to be recognized. However, I don't like disabling selinux everytime I put a stranger's drive into my computer! Goulou
Potentially related: 1. plug in disk 2. no offer to mount 3. open nautilus 4. locate disk 5. click disk result: ask for password to mount expected: no password prompt This may or may not have something to do with longer than 24 hour logins and password agent timeouts. This may or may not be either cause or effect.
*** Bug 915941 has been marked as a duplicate of this bug. ***
looks like an selinux problem. reassigning.
Lennart why do you think this is an libselinux issue? It looks like udev is getting signals to create or label a file that does not exist. Not sure what libselinux could do to cause this.
Hmm, we are not aware of any changes in that area in udev, and the reporter says: "Temporarily disabling selinux while plugging the USB drive allows it to be recognized." I've never seen such messages before, hence we assumed it's a selinux issue.
I think it is an SELinux issue in udev code path. Basically disabling SELinux causes udev to not walk down that code path. But I don't see how this could be caused by libselinux.
Ok, let's check. There have been no recent changes in that area. It must be some weird setup that triggers this. We do: selabel_lookup_raw(label_hnd, &fcon, newpath, S_IFDIR); and it can return -EEXIST? If security_getenforce() == 1, we seem to skip the mkdir() call and return the error -- that might be the failure we see, but it seem only to happen on special setups? Any idea?
Dan, are we sure there are no changes in libselinux or related that might have changed the returned error from: -ENOENT -- which might fit, and which systemd handles to -EEXIST -- which sounds rather weird ?
*** Bug 907759 has been marked as a duplicate of this bug. ***
Same thing happened to me after updates. The problem was solved by rebooting the machine. I will attach a list of all updated packages for reference.
Created attachment 706966 [details] Log of all packages updated right before the problem happened
AFAICS, libselinux never sets errno to EEXIST directly. Not sure what kernel calls it might be making that could yield that but seems unusual (no file creation should be happening there). Also, selabel_lookup of those paths should find a matching regex (/dev/.* if nothing else). matchpathcon utility works as expected on F18.
The only thing I can think of is the pcre code is returning this.
As an experiment, anyone who is getting this regularly could you rm -f /etc/selinux/targeted/contexts/files/*.bin And see if the problem goes away.
Never mind, that will not change it, I do not believe.
(In reply to comment #17) > The only thing I can think of is the pcre code is returning this. Alternative hypothesis: Maybe selabel_lookup_raw forgets to set errno, so the EEXIST originates from some previous operation udev was doing.
Hypothesis supported by https://bugzilla.redhat.com/show_bug.cgi?id=907759#c9 EEXIST there comes from mkdir() failure, nothing selabel_lookup does. And somewhat odd sequence: stat of /dev/disk/by-path with ENOENT followed by mkdir /dev/disk with EEXIST. What is udevd trying to do there?
I just built libselinux-2.1.12-7.3.fc18 in Koji which forces errno to ENOENT in a labeling situation where there is a potential it would not be set, could someone try it out and see if it fixes the problem.
Won't that just hide the real bug? selabel_lookup shouldn't be returning an error at all on those paths. How does systemd / udevd refresh its internal copy of file_contexts upon a policy update? Are they listening for policyload notifications and handling them?
Well the paths I fixed were not setting errno to anything. diff --git a/libselinux/src/label_file.c b/libselinux/src/label_file.c index 5f697f3..9b0d6b0 100644 --- a/libselinux/src/label_file.c +++ b/libselinux/src/label_file.c @@ -649,6 +649,8 @@ static struct selabel_lookup_rec *lookup(struct selabel_handle *rec, break; } else if (rc == PCRE_ERROR_NOMATCH) continue; + + errno = ENOENT; /* else it's an error */ goto finish; } @@ -660,6 +662,7 @@ static struct selabel_lookup_rec *lookup(struct selabel_handle *rec, goto finish; } + errno = 0; ret = &spec_arr[i].lr; finish: And I am not sure this will fix the problem, just a couple of things I saw. I would doubt that udev or systemd are reloading their labels on refresh, I will create a bug on this.
*** Bug 920780 has been marked as a duplicate of this bug. ***
I'm experiencing this bug with usb thumb drives. libselinux-2.1.12-7.1.fc18.x86_64 libselinux-2.1.12-7.1.fc18.i686 systemd-197-1.fc18.2.x86_64 https://bugzilla.redhat.com/show_bug.cgi?id=909010 duplicate?
Somebody please try the modified libselinux that Dan built (comment #22). Here's a link to Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=401161
Daniel Walsh build (2.1.12-7) seems to solve the issue on my F18/x86_64 laptop. - Gilboa
libselinux-2.1.12-7.3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/libselinux-2.1.12-7.3.fc18
2.1.12-7.3.fc18 seems to have resolved the issue for me, though I have a whopping 7 minutes of uptime so far. I'll add karma later today if I don't find other problems.
Package libselinux-2.1.12-7.3.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libselinux-2.1.12-7.3.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4135/libselinux-2.1.12-7.3.fc18 then log in and leave karma (feedback).
libselinux-2.1.12-7.3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.