Bug 907759
| Summary: | systemd-udevd[18968]: Failed to set security context (null) for /dev/disk: File exists | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bruno Goncalves <bgoncalv> |
| Component: | udev | Assignee: | udev-maint |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | ajes+redhat, ayurtsev, cristian.ciupitu, D8F55524, dominick.grift, dwalsh, ezwen-redhatbugzilla, fredericg_99, frh+fedora, johannbg, jonathan, lnykryn, loganjerry, luto, marc, metherid, mgrepl, mjc, msekleta, notting, plautrba, pmarciniak, prd-fedora, rc556677, rhel, scorpy_sk, systemd-maint, udev-maint, vpavlin |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-03-08 03:13:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bruno Goncalves
2013-02-05 08:10:29 UTC
Happens for me with every usb mass storage device. Feb 17 18:38:14 pundit systemd-udevd[27155]: Failed to set security context (null) for /dev/v4l: File exists Feb 17 18:38:14 pundit systemd-udevd[27155]: Failed to set security context (null) for /dev/v4l/by-id: File exists It happens with usb webcam and input devices, probably selinux policy issue see http://forums.fedoraforum.org/showthread.php?p=1634011 +1 USB mass storage, msdos partition table, four primary partitions. Over two thousand Failed to set security context (null) for /dev/disk: File exists or Failed to set security context (null) for /dev/disk/by-path: File exists messages. # rpm -q systemd systemd-197-1.fc18.1.x86_64 # rpm -q selinux-policy-targeted selinux-policy-targeted-3.11.1-78.fc18.noarch # uname -r 3.7.7-201.fc18.x86_64 Partitions appear in logged in user desktop/nautilus, but logged in user can only mount as root Tried "restorecon -r -v /dev" to see if this is a labeling problem. Got this: restorecon reset /dev/disk/by-uuid/400A-8D10 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/disk/by-id/usb-SanDisk_Cruzer_Glide_4C532000021126113572-0:0 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/bsg/4:0:0:0 context system_u:object_r:device_t:s0->system_u:object_r:scsi_generic_device_t:s0 restorecon reset /dev/block/8:17 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/block/8:16 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/char/21:2 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/char/252:2 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/char/189:3 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 But it didn't help. Running "udevadm trigger" produced hundreds more of the same messages in /var/log/messages, and still did not mount the device. I'm running selinux-policy-3.11.1-78.fc18.noarch, and the problem seems to have been fixed. Same issue with my ebook. I have selinux-policy-3.11.1-79.fc18 installed. I tried "restorecon -r -v /dev", but it did not help. Disabling selinux via "setenforce 0" is my workaround for now (no more error messages and my usb device is mounted correctly). I had the same experience as Bruno. The problem is gone for me with selinux-policy-3.11.1-79.fc18 (didn't try with 3.11.1-78). I'm afraid the problem is not solved. I've tried using a USB mass storage and the issue continues :( My system just started doing this. strace on systemd-udevd says:
stat("/dev/disk/by-path", 0x7fffa005c000) = -1 ENOENT (No such file or directory)
mkdir("/dev", 0755) = -1 EEXIST (File exists)
(in a loop)
I get this problem, after selinux-policy package is updated when I connect usb drive and it usually disappears after reboot. After almost every weekend mouse is locked and I have to press Ctrl-Alt-Backspace. Hundreds of terminal lines appear in syslog (see below). Of course mouse remain locked and a reboot is required. After reboot everything works correctly. ... [431801.104523] systemd-udevd[15674]: Failed to set security context (null) for /dev/input/by-id: File exists [431801.104579] systemd-udevd[15674]: Failed to set security context (null) for /dev/input: File exists [431801.104602] systemd-udevd[15674]: Failed to set security context (null) for /dev/input/by-id: File exists [431801.104656] systemd-udevd[15674]: Failed to set security context (null) for /dev/input: File exists [431801.104680] systemd-udevd[15674]: Failed to set security context (null) for /dev/input/by-id: File exists [431801.104736] systemd-udevd[15674]: Failed to set security context (null) for /dev/input: File exists [431801.104779] systemd-udevd[15674]: Failed to set security context (null) for /dev/input/by-id: File exists ... I forgot to mention that the mouse works properly in text terminals, only X does not have functional mouse. Try autorelabeling and see if it fixes your issue anyway moving against selinux they will just throw it back if it turns out not to be a policy issue. No this looks like a problem in systemd-udev. probably not a labeling issue. So, I think the same thing was happening on my system and it started a couple weeks ago and just stopped today after a reboot. If it was a change to selinux policy, then it must have been a very very recent update. But, udevd seems to be doing the right thing with USB disks on my system, now. Current policy rpm: selinux-policy-targeted-3.11.1-81.fc18.noarch *** This bug has been marked as a duplicate of bug 909826 *** |