Bug 121135 - RFE: labeling /home -> /mnt/elsewhere
RFE: labeling /home -> /mnt/elsewhere
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libselinux (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-17 16:43 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-02 14:31:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-04-17 16:43:52 EDT
My /home is a soft link to a directory within a separate filesystem. 
I'm trying to figure out how to label it properly, such that I can
setenforce 1 and be able to ssh into this box as myself using
public-key authentication.

If I setfiles /etc/security/selinux/file_contexts /home, it does
nothing.  The /home soft link and the /home/. dir remain with
default_t.  If I setfiles ... /home/., it labels /home/. as if it was
a home directory, so /home/.mozilla/* would be labeled as
user_mozilla_rw_t, but /home/aoliva/.mozilla would be labeled as just
user_home_t.

If I setfiles ... /home/aoliva, it labels things correctly.  But then,
.ssh is a soft link as well.  So I label /home/aoliva/.ssh, and it
doesn't relabel the soft link nor the directory contents.  Relabeling
/home/aoliva/.ssh/. *seems* to label things correctly, such that .ssh
and its contents are user_home_ssh_t.  However, sshd still fails to
stat64() /home/aoliva/.ssh/authorized_keys, with permission denied.

Even if I use lsetfilecon() to adjust the context of the soft links
such that they match those of the directories they point to, it still
doesn't work.  Worse yet: ssh claims it can't chdir to my home dir
after I enter a password, even though, after it lets me in, I can cd
to it.

The error I get is avc:  denied  { read } for
 pid=2920 exe=/usr/sbin/sshd name=home dev=dm-2 ino=26
scontext=system_u:system_r:sshd_t
tcontext=system_u:object_r:home_root_t tclass=lnk_file

Is there any special treatment I have to give to such soft links to
get them to work?

Anyhow, the main point of this issue was that we're missing a way to
label links in the command line.

Ideally, setfiles, if given a soft link in the command line, should
label this soft link appropriately, and then follow the link and label
the pointed-to file or directory, along with its sub-tree (not
following additional links within it, though).

Additionally, setfilecon should probably accept a command-line flag
(-h, like chown/mod/grp) to affect a soft link instead of the file
pointed-to by the link.

Version-Release number of selected component (if applicable):
libselinux-1.11.1-1
Comment 1 Daniel Walsh 2004-04-28 14:28:59 EDT
chcon is the command you are looking for.  I believe getting setfiles
to work differently on sym links could be a security problem.   One of
the things we are discussing is getting something like chcon to be
perminant,  So an admin could set file contexts the way they want on
certain files and then setfiles would not revert them back.

Dan
Comment 2 Alexandre Oliva 2004-05-06 23:47:13 EDT
I don't see how it could be a security problem, but silently
relabeling the pointed-to file instead of the soft link, and not
recursing if it turns out to be a directory, feels even more flawed to
me.  It should either not follow the soft link at all, or follow it
entirely.  Although I must admit that the current behavior is
consistent with other tools that change properties of files or
directories (chmod, chown, chgrp, etc), and that require -h to affect
the symlink, and fail to recurse just the same.  The big difference is
that, if you do mean them to recurse, you can just add a trailing
`/.', and it will have the right effect, except in the case of
setfiles, because the `/.' is not sanitized out of the pathname when
computing the file context.  Unfortunately, canonicalizing the
pathname before attempting to find a match regexp, which is the
obvious solution that springs to mind, defeats the very attempt to get
setfiles to label files following the logical access paths to the
files (i.e., through the soft links within my home dir), instead of
the physical pathnames.  Heck, this is tricky! :-(
Comment 3 Daniel Walsh 2004-09-09 13:08:23 EDT
With current policy you should be able to change homedir within
/usr/sbin/addusers and the file_context will get set correctly.
Comment 4 Alexandre Oliva 2005-02-02 14:31:07 EST
Homedirs in other locations are currently handled, chekc.

getting fixfiles/setfiles to follow soft links, on the other hand,
isn't, and it would be nice if it was.  But maybe that's to be handled
in a separate bug report...

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