Bug 760152 - SELinux is preventing /usr/sbin/sshd from 'search' accesses on the directory /home/dev.
Summary: SELinux is preventing /usr/sbin/sshd from 'search' accesses on the directory ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:1a98ef2f37bac5a57b673c224d5...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-05 14:41 UTC by Mads Kiilerich
Modified: 2011-12-05 21:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-05 20:58:00 UTC
Type: ---


Attachments (Terms of Use)
File: description (2.54 KB, text/plain)
2011-12-05 14:41 UTC, Mads Kiilerich
no flags Details

Description Mads Kiilerich 2011-12-05 14:41:16 UTC
libreport version: 2.0.7
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.1.2-1.fc16.x86_64
reason:         SELinux is preventing /usr/sbin/sshd from 'search' accesses on the directory /home/dev.
time:           Mon 05 Dec 2011 03:40:43 PM CET

description:    Text file, 2606 bytes

Comment 1 Mads Kiilerich 2011-12-05 14:41:19 UTC
Created attachment 540946 [details]
File: description

Comment 2 Mads Kiilerich 2011-12-05 14:48:28 UTC
Apparently a regression since -61.

(Don't get confused - the username is 'dev')

Comment 3 Miroslav Grepl 2011-12-05 19:51:55 UTC
Any idea how it could get this mislabeling? 

# restorecon -R -v /home/dev

Comment 4 Mads Kiilerich 2011-12-05 20:27:23 UTC
Oh, right, sandbox_file_t - I hadn't noticed that. I have been playing with sandbox, so it is probably my own fault that it ended up that way.

I had verified that restorecon didn't report any problems - and as far as I can see I haven't messed it up so bad that I have redefined what the right context is.

Is it intentional that the policy accepts sandbox_file_t for /home/* ? Your question indicates that you wouldn't expect that.

I can see how something like this could make sense for sandboxing arbitrary users, but I would expect a label for a sandboxed home to be something like sandbox_home_t.

If that is 'works as designed' them I am happy - except that I am sorry to have filed a bogus bug report ;-)

Comment 5 Daniel Walsh 2011-12-05 20:58:00 UTC
sandbox_file_t is a customizable type.  Meaning restorecon will not modify it unless forced.

This allows you to setup permanent homedirs/tmpdirs that sandboxes in random locations and restorecon will ignore them.

Comment 6 Miroslav Grepl 2011-12-05 21:06:08 UTC
Oops, I missed "-F" switch.


Note You need to log in before you can comment on or make changes to this bug.