Bug 167433 - restorecon can't traverse autofs (unlabeled) /home
restorecon can't traverse autofs (unlabeled) /home
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-02 12:17 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: policy-1.27.1-2.10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-03 18:03:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2005-09-02 12:17:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b3) Gecko/20050827 Fedora/1.1-0.2.8.deerpark.alpha2 Firefox/1.0+

Description of problem:
I've had trouble to enable a user to export her public_html directory over http.  Creating the directory in her home dir didn't get it the correct context, and restorecon would say not even an unrestricted root session could set the context for that directory correctly.

As it turned out, the problem is that restorecon needs permission to traverse unlabeled directories, since they can be created by automount.  This is the case of /home at this site.

Version-Release number of selected component (if applicable):
policycoreutils-1.23.11-3.2 selinux-policy-targeted-1.25.4-10

How reproducible:
Always

Steps to Reproduce:
1.Have a user's home dir within a subdirectory of an automount-controlled mount point
2.mkdir ~user/public_html
3.restorecon -R ~user/public_html
  

Actual Results:  restorecon says permission denied

Expected Results:  The operation should be permitted.  I'm pretty sure it was at some point in the past (probably FC3ish)

Additional info:

This is what gets logged to /var/log/audit/audit.log when the operation fails:

type=AVC msg=audit(1125638794.385:129733): avc:  denied  { search } for  pid=5336 comm="restorecon" name="/" dev=autofs ino=19296 scontext=root:system_r:restorecon_t tcontext=system_u:object_r:autofs_t tclass=dir
type=SYSCALL msg=audit(1125638794.385:129733): arch=40000003 syscall=196 success=no exit=-13 a0=8b18280 a1=bf841e18 a2=3ceff4 a3=8b18280 items=1 pid=5336 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="restorecon" exe="/sbin/restorecon"
type=CWD msg=audit(1125638794.385:129733):  cwd="/home/lsd/mantonia/public_html"type=PATH msg=audit(1125638794.385:129733): item=0 name="/home/lsd/mantonia" flags=0  inode=19296 dev=00:18 mode=040755 ouid=0 ogid=0 rdev=00:00
Comment 1 Daniel Walsh 2005-09-19 11:48:48 EDT
Labels on NFS file systems are not supported.  I you want to allow for
public_html on a NFS mounted file system you need to set the boolean
setsebool -P use_nfs_home_dirs=1
Comment 2 Alexandre Oliva 2005-09-19 16:58:41 EDT
I didn't mention NFS because there was not any NFS involved.  autofs binds its
sub-directory from a different local directory.  The problem is that the autofs
filesystem itself is unlabeled.
Comment 3 Daniel Walsh 2005-09-20 11:11:54 EDT
Ok can you 
setenforce 0
Then try your restorecon call, and see if any additional avc messages appear.

I will add

allow restorecon_t autofs_t:dir search;

to policy

Comment 4 Alexandre Oliva 2005-09-20 13:08:13 EDT
With setenforce 0, the operation suceeds, and nothing other than the above is
added to the logs, so this change should be enough to fix the problem.  Thanks,
Comment 5 Daniel Walsh 2005-09-27 15:43:54 EDT
Fixed in selinux-policy-targeted-1.27.1-2.3
Comment 6 Alexandre Oliva 2005-10-28 10:28:48 EDT
'fraid this one doesn't work yet.

 # ls -lZd / /home /home/lsd /home/lsd/test /home/lsd/test/public_html
drwxr-xr-x  root     root     system_u:object_r:root_t         /
drwxr-xr-x  root     root                                      /home
drwxr-xr-x  root     root     system_u:object_r:home_root_t    /home/lsd
drwxr-xr-x  root     root     root:object_r:user_home_dir_t    /home/lsd/test
drwxr-xr-x  root     root     root:object_r:user_home_t       
/home/lsd/test/public_html

# tail -f /var/log/audit/audit.log
[...]
^Z
# restorecon -R /home/lsd/test/public_html
realpath(/home/lsd/test/public_html) failed Permission denied
# fg
type=AVC msg=audit(1130509655.950:21146): avc:  denied  { getattr } for 
pid=23926 comm="restorecon" name="/" dev=autofs ino=6087
scontext=root:system_r:restorecon_t tcontext=system_u:object_r:autofs_t tclass=dir
type=SYSCALL msg=audit(1130509655.950:21146): arch=40000003 syscall=196
success=no exit=-13 a0=bfeb8003 a1=bfeb7f4c a2=3ceff4 a3=9190285 items=1
pid=23926 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="restorecon" exe="/sbin/restorecon"
type=AVC_PATH msg=audit(1130509655.950:21146):  path="/home"
type=CWD msg=audit(1130509655.950:21146):  cwd="/home/lsd/test"
type=PATH msg=audit(1130509655.950:21146): item=0 name="/home" flags=0 
inode=6087 dev=00:18 mode=040755 ouid=0 ogid=0 rdev=00:00

Looks like we need getattr as well.  Yep, that fixes it.

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