Bug 760152

Summary: SELinux is preventing /usr/sbin/sshd from 'search' accesses on the directory /home/dev.
Product: [Fedora] Fedora Reporter: Mads Kiilerich <mads>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:1a98ef2f37bac5a57b673c224d5f15b368f9470a0700807f62f596e8963ac4c9
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-05 20:58:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: description none

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.