Bug 624540
| Summary: | (staff_u) SELinux is preventing /usr/bin/nautilus (deleted) "write" access on /media/TerraVolume. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Matěj Cepl <mcepl> | |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Milos Malik <mmalik> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | low | |||
| Version: | 6.1 | CC: | dwalsh, eparis, ksrot, mgrepl, mmalik, pvrabec, ssekidde | |
| Target Milestone: | rc | Keywords: | Reopened, RHELNAK, SELinux | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 723722 (view as bug list) | Environment: | ||
| Last Closed: | 2015-07-16 11:30:08 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 723722 | |||
|
Description
Matěj Cepl
2010-08-16 19:24:13 UTC
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. ** Thank you for your bug report. This issue was evaluated for inclusion in the current release of Red Hat Enterprise Linux. Unfortunately, we are unable to address this request in the current release. Because we are in the final stage of Red Hat Enterprise Linux 6 development, only significant, release-blocking issues involving serious regressions and data corruption can be considered. If you believe this issue meets the release blocking criteria as defined and communicated to you by your Red Hat Support representative, please ask your representative to file this issue as a blocker for the current release. Otherwise, ask that it be evaluated for inclusion in the next minor release of Red Hat Enterprise Linux. Does this still happen in an fully updated system? What filesystems do you have on the device? I could imagine spawning some external helper would cause the denial. If you're not sure, can you please attach output of the `udisks --dump` command? (In reply to comment #4) > Does this still happen in an fully updated system? What filesystems do you have > on the device? I could imagine spawning some external helper would cause the > denial. It was never mine, just something halfline loaned me to backup when I was in Boston. It had ext3 as a filesystem, I believe (as much as I dimly remember). > If you're not sure, can you please attach output of the `udisks --dump` > command? does it make any sense when I have different operating system (Rawhide) and no access to the particular drive? (In reply to comment #5) > It was never mine, just something halfline loaned me to backup when I was in > Boston. It had ext3 as a filesystem, I believe (as much as I dimly remember). I've just tried to plug an USB stick with three partitions, all formatted with ext3. No denials, automounted just fine. (In reply to comment #0) > node=johanka.ceplovi.cz type=AVC msg=audit(1281986350.996:2003): avc: denied > { write } for pid=2137 comm="nautilus" name="/" dev=sdb2 ino=2 > scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir I've just noticed the "staff_u" context - is this something you've changed? I'm running unconfined. (In reply to comment #6) > I've just noticed the "staff_u" context - is this something you've changed? I'm > running unconfined. http://danwalsh.livejournal.com/18312.html I think Dan could explain more. Yes this is an issue with confined users. Unconfined users would not generate the AVC. This is an SELinux issue. nautilus is doing the correct thing. Nautilus is asking what access is available on all files/devices that it is displaying, the problem is SELinux originally could not tell the difference between access(/dev/foo, W_OK) and write(/dev/foo, 1) In Rawhide we now have a mechanism to say dontaudit the access checks, while I am not sure we have this in RHEL6 yet. This is not available in RHEL6. If you feel this should be backported, you're going to need to open a kernel bug, but at this point, unless we have a customer asking for it, it's going to be defered to 6.2.... (In reply to comment #7) > http://danwalsh.livejournal.com/18312.html Thanks, able to reproduce it now. I'll keep my user under staff_u for some time, just for curiosity. On a sidenote, small design issue - after creating new ext3 filesystem I was unable to access it right away, even having proper permissions. Mounted fine, but denied listing. Had to do restorecon manually. Either this should be done automatically by palimpsest/udisks or mkfs (this is rather intrusive). What was not able to access it? unconfined_t should have been, staff_t would not be able to. I think 6.2 is fine for this, as it is not a huge problem and most people using confined users probably are using nautilus to look at random locations. (In reply to comment #11) > What was not able to access it? unconfined_t should have been, staff_t would > not be able to. Yeah, bash running in staff_t context. *** Bug 571460 has been marked as a duplicate of this bug. *** This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4. |