Fedora Account System
Red Hat Associate
Red Hat Customer
The following was filed automatically by setroubleshoot: Got the following plugging in a LUKS USB hard drive. Here is /var/log/messages: Sep 23 06:11:43 tlondon kernel: usb 1-5.3: new high speed USB device using ehci_hcd and address 6 Sep 23 06:11:43 tlondon kernel: usb 1-5.3: New USB device found, idVendor=04b4, idProduct=6830 Sep 23 06:11:43 tlondon kernel: usb 1-5.3: New USB device strings: Mfr=56, Product=78, SerialNumber=100 Sep 23 06:11:43 tlondon kernel: usb 1-5.3: Product: USB2.0 Storage Device Sep 23 06:11:43 tlondon kernel: usb 1-5.3: Manufacturer: Cypress Semiconductor Sep 23 06:11:43 tlondon kernel: usb 1-5.3: SerialNumber: DEF107679C83 Sep 23 06:11:43 tlondon kernel: usb 1-5.3: configuration #1 chosen from 1 choice Sep 23 06:11:44 tlondon kernel: scsi5 : SCSI emulation for USB Mass Storage devices Sep 23 06:11:44 tlondon kernel: usbcore: registered new interface driver ums-cypress Sep 23 06:11:50 tlondon kernel: scsi 5:0:0:0: Direct-Access MAXTOR S TM3320620A PQ: 0 ANSI: 0 Sep 23 06:11:50 tlondon kernel: sd 5:0:0:0: Attached scsi generic sg3 type 0 Sep 23 06:11:50 tlondon kernel: sd 5:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB) Sep 23 06:11:50 tlondon kernel: sd 5:0:0:0: [sdc] Write Protect is off Sep 23 06:11:50 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Sep 23 06:11:50 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Sep 23 06:11:50 tlondon kernel: sdc: sdc1 Sep 23 06:11:50 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through Sep 23 06:11:50 tlondon kernel: sd 5:0:0:0: [sdc] Attached SCSI disk Sep 23 06:11:58 tlondon kernel: usb 1-5.3: reset high speed USB device using ehci_hcd and address 6 Sep 23 06:11:59 tlondon kernel: Intel AES-NI instructions are not detected. Sep 23 06:11:59 tlondon kernel: padlock: VIA PadLock not detected. Sep 23 06:11:59 tlondon kernel: padlock: VIA PadLock Hash Engine not detected. Sep 23 06:11:59 tlondon modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.31-33.fc12.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device Sep 23 06:12:03 tlondon setroubleshoot: SELinux is preventing /sbin/cryptsetup "relabelto" access on temporary-cryptsetup-2339. For complete SELinux messages. run sealert -l 2fec7120-1c9a-49d2-a495-95e383c61799 Sep 23 06:12:03 tlondon kernel: EXT4-fs (dm-2): barriers enabled Sep 23 06:12:03 tlondon kernel: kjournald2 starting: pid 2447, dev dm-2:8, commit interval 5 seconds Sep 23 06:12:03 tlondon kernel: EXT4-fs (dm-2): warning: maximal mount count reached, running e2fsck is recommended Sep 23 06:12:03 tlondon kernel: EXT4-fs (dm-2): internal journal on dm-2:8 Sep 23 06:12:03 tlondon kernel: EXT4-fs (dm-2): delayed allocation enabled Sep 23 06:12:03 tlondon kernel: EXT4-fs: file extents enabled Sep 23 06:12:03 tlondon kernel: EXT4-fs: mballoc enabled Sep 23 06:12:03 tlondon kernel: EXT4-fs (dm-2): mounted filesystem with ordered data mode Sep 23 06:12:45 tlondon setroubleshoot: [dbus.proxies.ERROR] Introspect error on :1.84:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. The mount appears to have worked nevertheless. Summary: SELinux is preventing /sbin/cryptsetup "relabelto" access on temporary-cryptsetup-2339. Detailed Description: SELinux denied access requested by cryptsetup. It is not expected that this access is required by cryptsetup and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:lvm_t:s0-s0:c0.c1023 Target Context system_u:object_r:fixed_disk_device_t:s0 Target Objects temporary-cryptsetup-2339 [ lnk_file ] Source cryptsetup Source Path /sbin/cryptsetup Port <Unknown> Host (removed) Source RPM Packages cryptsetup-luks-1.1.0-0.1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-8.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31-33.fc12.x86_64 #1 SMP Thu Sep 17 15:40:43 EDT 2009 x86_64 x86_64 Alert Count 1 First Seen Wed 23 Sep 2009 06:11:59 AM PDT Last Seen Wed 23 Sep 2009 06:11:59 AM PDT Local ID 2fec7120-1c9a-49d2-a495-95e383c61799 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1253711519.973:35): avc: denied { relabelto } for pid=2339 comm="cryptsetup" name="temporary-cryptsetup-2339" dev=tmpfs ino=26912 scontext=system_u:system_r:lvm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=lnk_file node=(removed) type=SYSCALL msg=audit(1253711519.973:35): arch=c000003e syscall=189 success=no exit=-13 a0=7fffb05ff890 a1=7f7d1833a649 a2=17d3f30 a3=29 items=0 ppid=1886 pid=2339 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cryptsetup" exe="/sbin/cryptsetup" subj=system_u:system_r:lvm_t:s0-s0:c0.c1023 key=(null) audit2allow suggests: #============= lvm_t ============== allow lvm_t fixed_disk_device_t:lnk_file relabelto;
What lnk file is this relabeling? If this is a link file under /dev then it should be device_t. I see no place in the file context file where a lnk_file would be labeled fixed_disk_device_t.
Please can you provide ersion of libdevmapper? rpm -q device-mapper (If it is last build, this is probably related udev changes in libdevmapper.)
[root@tlondon ~]# rpm -qa device-mapper\* device-mapper-1.02.37-3.fc12.x86_64 device-mapper-multipath-libs-0.4.9-5.fc12.x86_64 device-mapper-event-1.02.37-3.fc12.x86_64 device-mapper-event-libs-1.02.37-3.fc12.x86_64 device-mapper-libs-1.02.37-3.fc12.x86_64 device-mapper-devel-1.02.37-3.fc12.x86_64 device-mapper-multipath-0.4.9-5.fc12.x86_64 [root@tlondon ~]#
I'm not seeing this any longer with: device-mapper-multipath-libs-0.4.9-5.fc12.x86_64 device-mapper-devel-1.02.38-2.fc12.x86_64 selinux-policy-3.6.32-12.fc12.noarch device-mapper-1.02.38-2.fc12.x86_64 device-mapper-event-libs-1.02.38-2.fc12.x86_64 selinux-policy-targeted-3.6.32-12.fc12.noarch device-mapper-event-1.02.38-2.fc12.x86_64 device-mapper-multipath-0.4.9-5.fc12.x86_64 device-mapper-libs-1.02.38-2.fc12.x86_64 udev-145-10.fc12.x86_64 Fixed? Vanished? ;)
No, just the package is reverted and udev support is disabled again.. :)
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Well, there is no udev support in F12 for dm devices so this bug disappeared in F12. Please if you see this again in rawhide, report new bug, there were a lot of changes since then.