Bug 605771
Summary: | SELinux is preventing /bin/mount "read" access to device sde1. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tobias Mueller <fedora-bugs> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | carlg, dwalsh, mgrepl, wolfgang |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | setroubleshoot_trace_hash:5fc8afbb75db9bcd99a5c137d3ee16dd5e5e8f7ee92a38310e90ddb0e41c4d54 | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-07-09 00:28:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tobias Mueller
2010-06-18 18:21:21 UTC
What created /dev/sde1? This is mislabeled. If this was created via udev it should have had the correct label put on it. Hm. That's my external harddisk via FireWire. It's plugged in all the time. Hence I guess it's udev creating the device. Note that I suspended and I think the harddisk gets removed and reattached on resume. Maybe that's a problem. If you run restorecon /dev/sde1 and unplag your hard disk and reattach it, does the label stay correct? ls -lZ /dev/sde1 If you leave it attached and suspend and resume it what does the label say? If you detatch the disk does the device disappear? If so when it comes back is it labeled correctly fixed_disk_device_t? Before suspend: muelli@bigbox ~ $ ls -lZ /dev/sde1 brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sde1 muelli@bigbox ~ $ muelli@bigbox ~ $ sudo restorecon /dev/sde1 [sudo] password for muelli: muelli@bigbox ~ $ ls -lZ /dev/sde1 brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sde1 muelli@bigbox ~ $ Then unplug and replug: Results in weird nautilus behaviour: It shows "FreeAgent750" (my disk) as being mounted (i.e. with the eject button the the right, in that places pane on the left. Even if I manually umount the disk. Trying to eject via the button yields: "umount: /media/FreeAgent750 mount disagrees with the fstab". And Nautilus mounts the disk to /media/FreeAgent750__ although /etc/fstab dictates /mnt/FreeAgent750: muelli@bigbox ~ $ grep FreeAgent /etc/fstab UUID="f899eb61-3dec-452e-82da-0d764494913a" /media/FreeAgent750 ext3 noatime 0 0 muelli@bigbox ~ $ ls -l /dev/disk/by-uuid/f899eb61-3dec-452e-82da-0d764494913a lrwxrwxrwx. 1 root root 10 18. Jun 22:25 /dev/disk/by-uuid/f899eb61-3dec-452e-82da-0d764494913a -> ../../sdd1 muelli@bigbox ~ $ Anyway, the label is the same: muelli@bigbox ~ $ ls -lZ /dev/sdd1 brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sdd1 muelli@bigbox ~ $ Relevant dmesg entries: sd 15:0:0:0: [sde] Unhandled error code sd 15:0:0:0: [sde] Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK sd 15:0:0:0: [sde] CDB: Read(10): 28 00 30 8c 26 a7 00 01 00 00 end_request: I/O error, dev sde, sector 814491303 sd 15:0:0:0: [sde] Stopping disk sd 15:0:0:0: [sde] START_STOP FAILED sd 15:0:0:0: [sde] Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK firewire_sbp2: released fw1.0, target 15:0:0 EXT3-fs error (device sde1): ext3_find_entry: reading directory #37085388 offset 0 scsi16 : SBP-2 IEEE-1394 firewire_core: created device fw1: GUID 0020370100002bca, S400 firewire_core: phy config: card 0, new root=ffc0, gap_count=5 firewire_sbp2: fw1.0: logged in to LUN 0000 (0 retries) scsi 16:0:0:0: Direct-Access Seagate FreeAgent Pro 4109 PQ: 0 ANSI: 4 sd 16:0:0:0: Attached scsi generic sg2 type 0 sd 16:0:0:0: [sdd] 1465149168 512-byte logical blocks: (750 GB/698 GiB) sd 16:0:0:0: [sdd] Write Protect is off sd 16:0:0:0: [sdd] Mode Sense: 1c 00 00 00 sd 16:0:0:0: [sdd] Cache data unavailable sd 16:0:0:0: [sdd] Assuming drive cache: write through sd 16:0:0:0: [sdd] Cache data unavailable sd 16:0:0:0: [sdd] Assuming drive cache: write through sdd: sdd1 sd 16:0:0:0: [sdd] Cache data unavailable sd 16:0:0:0: [sdd] Assuming drive cache: write through sd 16:0:0:0: [sdd] Attached SCSI disk kjournald starting. Commit interval 5 seconds EXT3-fs (sdd1): warning: maximal mount count reached, running e2fsck is recommended EXT3-fs (sdd1): using internal journal EXT3-fs (sdd1): recovery complete EXT3-fs (sdd1): mounted filesystem with ordered data mode SELinux: initialized (dev sdd1, type ext3), uses xattr EXT3-fs error (device sde1): ext3_find_entry: reading directory #2 offset 0 EXT3-fs error (device sde1): ext3_find_entry: reading directory #2 offset 0 EXT3-fs error (device sde1): ext3_find_entry: reading directory #2 offset 0 kjournald starting. Commit interval 5 seconds EXT3-fs (sdd1): warning: maximal mount count reached, running e2fsck is recommended EXT3-fs (sdd1): using internal journal EXT3-fs (sdd1): mounted filesystem with ordered data mode SELinux: initialized (dev sdd1, type ext3), uses xattr EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 kjournald starting. Commit interval 5 seconds EXT3-fs (sdd1): warning: maximal mount count reached, running e2fsck is recommended EXT3-fs (sdd1): using internal journal EXT3-fs (sdd1): mounted filesystem with ordered data mode SELinux: initialized (dev sdd1, type ext3), uses xattr EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 kjournald starting. Commit interval 5 seconds EXT3-fs (sdd1): warning: maximal mount count reached, running e2fsck is recommended EXT3-fs (sdd1): using internal journal EXT3-fs (sdd1): mounted filesystem with ordered data mode SELinux: initialized (dev sdd1, type ext3), uses xattr kjournald starting. Commit interval 5 seconds EXT3-fs (sdd1): warning: maximal mount count reached, running e2fsck is recommended EXT3-fs (sdd1): using internal journal EXT3-fs (sdd1): mounted filesystem with ordered data mode SELinux: initialized (dev sdd1, type ext3), uses xattr EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 After a suspend/resume: I see the SELinux Denial alert libnotify bubble soon: node=(removed) type=AVC msg=audit(1276893214.504:59748): avc: denied { getattr } for pid=14489 comm="mount" path="/dev/sdd" dev=devtmpfs ino=20742198 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=blk_file node=(removed) type=SYSCALL msg=audit(1276893214.504:59748): arch=c000003e syscall=5 success=yes exit=0 a0=4 a1=7fffd982f8f0 a2=7fffd982f8f0 a3=1 items=0 ppid=14477 pid=14489 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount" exe="/bin/mount" subj=system_u:system_r:mount_t:s0 key=(null) Some dmesg (only the last few lines): PM: resume of devices complete after 11774.011 msecs PM: Finishing wakeup. Restarting tasks ... done. sd 16:0:0:0: [sdd] Stopping disk sd 16:0:0:0: [sdd] START_STOP FAILED sd 16:0:0:0: [sdd] Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK firewire_sbp2: released fw1.0, target 16:0:0 scsi17 : SBP-2 IEEE-1394 firewire_core: created device fw1: GUID 0020370100002bca, S400, 1 config ROM retries firewire_sbp2: fw1.0: logged in to LUN 0000 (0 retries) scsi 17:0:0:0: Direct-Access Seagate FreeAgent Pro 4109 PQ: 0 ANSI: 4 EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 sd 17:0:0:0: [sdd] 1465149168 512-byte logical blocks: (750 GB/698 GiB) sd 17:0:0:0: Attached scsi generic sg2 type 0 sd 17:0:0:0: [sdd] Write Protect is off sd 17:0:0:0: [sdd] Mode Sense: 1c 00 00 00 sd 17:0:0:0: [sdd] Cache data unavailable sd 17:0:0:0: [sdd] Assuming drive cache: write through sd 17:0:0:0: [sdd] Cache data unavailable sd 17:0:0:0: [sdd] Assuming drive cache: write through sdd: ATL1E 0000:02:00.0: irq 32 for MSI/MSI-X ADDRCONF(NETDEV_UP): eth0: link is not ready EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 ATL1E 0000:02:00.0: ATL1E: eth0 NIC Link is Up<100 Mbps Full Duplex> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready sdd1 sd 17:0:0:0: [sdd] Cache data unavailable sd 17:0:0:0: [sdd] Assuming drive cache: write through sd 17:0:0:0: [sdd] Attached SCSI disk kjournald starting. Commit interval 5 seconds EXT3-fs (sdd1): warning: maximal mount count reached, running e2fsck is recommended EXT3-fs (sdd1): using internal journal EXT3-fs (sdd1): recovery complete EXT3-fs (sdd1): mounted filesystem with ordered data mode SELinux: initialized (dev sdd1, type ext3), uses xattr eth0: no IPv6 routers present The label, however, seems to be the same (in fairness, it took me quite some time to issue the ls command): muelli@bigbox ~ $ ls -lZ /dev/sdd1 brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sdd1 muelli@bigbox ~ $ ls -lZ /dev/sdd brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sdd muelli@bigbox ~ $ This looks like a race condition. When suspend comes up, for a small amount of time, devices must not have labels on them, then udev starts up and fixes everything. Since mount can getattr all blk devices, there is no reason not to add dev_getattr_generic_blk_files(mount_t) Fixed in selinux-policy-3.7.19-31.fc13. If this is supposed to work without a reboot than it didn't work. I'll try to report back after I've rebooted. Doesn't work after a reboot: bug 608403. Oh I just realised in this moment that I don't have selinux-policy-3.7.19-31.fc13 installed. I apparently has not been propagated for updates. Sorry for the noise. I'll wait until the package becomes available. *** Bug 608403 has been marked as a duplicate of this bug. *** |