Bug 118948 - make relabel labels bind mount points twice
make relabel labels bind mount points twice
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
rawhide
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks: 122683
  Show dependency treegraph
 
Reported: 2004-03-22 20:56 EST by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-19 15:57:25 EDT
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 2004-03-22 20:56:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
bind mount points are labeled based on the pathname of the primary
mount point of the filesystem, and then based on the pathname of the
bind mounts.  This is not only efficient, but it's also wrong, since
during relabeling all files in the bind mounts have incorrect labels.

Version-Release number of selected component (if applicable):
policy-sources-1.9-6

How reproducible:
Always

Steps to Reproduce:
1.Mount a filesystem in /mnt/whatever
2.Bind a subdir of it in say /l/whatever
3.make relabel
    

Actual Results:  It labels everything in /mnt/whatever as mnt_t, then
relabels everything as default_t.

Expected Results:  It should label each file only once.  I'm not sure
how to accomplish that.  One possibility is to skip bind mounts, but
this would probably not have the desired results.  Tricky.

Additional info:
Comment 1 Daniel Walsh 2004-03-24 21:13:36 EST
Fixed in policycoreutils-1.9-12
Comment 2 Alexandre Oliva 2004-03-27 21:36:05 EST
Err...  Are you sure?  I still get everything labeled as mnt_t while
processing the /mnt/whatever mount point, and then relabeled as
default_t while processing the bind mount point.
Comment 3 Stephen Smalley 2004-04-29 08:24:58 EDT
At present, setfiles maintains an inode->spec table as it traverses
each filesystem, and uses it to detect multiple hard links that match
different specifications in the file_contexts configuration, issuing
a warning if they would yield different security contexts.  But the
table is only maintained per-filesystem, and flushed when setfiles
moves on to the next filesystem.

I'm a little confused by the error report, maybe the submitter can
clarify.  setfiles is only applied to the output of `mount | grep -v
"context=" | awk '/(ext[23]| xfs).*rw/{print $3}'`, so I wouldn't
expect bind mounts to be included in the list of filesystems passed to
it, and setfiles uses nftw on each filesystem with FTW_PHYS |
FTW_MOUNT, so it is supposed to stay within the same filesystem, not
cross filesystem boundaries.  So why is it descending into bind mounts
at all?  Would it help to rewrite it to use fts instead?

We could rewrite setfiles to keep a (dev,inode)->spec table for all
filesystems it is processing, and thus detect aliasing across any of
the filesystems passed to it, but I'm not clear why this is necessary,
given that it isn't supposed to cross filesystem boundaries anyway and
should only process filesystems passed to it by the make relabel.
Comment 4 Stephen Smalley 2004-04-30 11:12:01 EDT
Ok, I did the following:
mount a physical filesystem on /mnt/whatever
mkdir /l/whatever
mount -o bind /mnt/whatever /l/whatever
fixfiles restore

End result was directories under /mnt/whatever were labeled mnt_t
and files were labeled default_t.  That is consistent with the current
file_contexts specification, which indicates that only directories
(-d) under /mnt should be labeled with mnt_t.

With regard to labeling twice, the algorithm in setfiles is to match
and label each file as it is encountered, then if it later finds
another inode in the same filesystem whose pathname matches a
different label, it issues a warning and possibly relabels the file to
the new context _if_ the specification was higher priority in the
file_contexts configuration (where higher priority is determined by
ordering with the configuration for pathname regex patterns _or_
always obeys any completely specified pathname that has no regex in it).

Note that creating a bind mount within the same physical filesytem
and then calling setfiles on the two directories separately is a
violation of the intended usage, and should not occur from make
relabel.  make relabel should likely explicitly exclude any bind
mounts from the list passed to setfiles, but it didn't appear to pass
them anyway, as the type was 'none'.  Now if you explicitly passed -t
ext3 to mount when creating the bind mount, perhaps make relabel was
then picking up the mount and passing it to setfiles wrongly.
Comment 5 Alexandre Oliva 2004-05-06 23:37:27 EDT
Hmm...  Maybe I should just change my /etc/fstab entries with `bind'
options to have fs `none' instead of `ext3'...  I didn't realize
`none' was a valid option for bind mounts (why `bind' is an option
rather than a fs type is beyond me).  Still, it would be nice if we
skipped bind mount points, even if mounted with fs types other than
`none'.
Comment 6 Stephen Smalley 2004-05-07 08:44:40 EDT
Concur - Dan, please change the policy Makefile to omit bind mounts
from the set of filesystems passed as arguments to setfiles upon a
'make relabel' (and similar targets), just as it already omits
context= mounts.
Comment 7 Daniel Walsh 2004-05-10 10:51:40 EDT
Should be removed in policy- 1.11.3-3 and policycoreutils-1.11-2
Comment 8 Alexandre Oliva 2004-05-10 12:45:09 EDT
Thanks, I can confirm that the fix works for me, but I'm a bit
concerned that `grep -v bind' might remove too much.  Consider, for
example, mountpoints whose names contain the `bind' substring.  How
about egrep -v '\((|.*,)bind(,.*|)\)'?
Comment 9 Daniel Walsh 2004-05-19 15:57:25 EDT
I made the change to use you egrep command.  Should be available in
latest policy.

Fixed in Rawhide.

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