Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 118948
Summary: | make relabel labels bind mount points twice | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> |
Component: | policy | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | jmorris, pgraner, sdsmall, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-05-19 19:57:25 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 122683 |
Description
Alexandre Oliva
2004-03-23 01:56:36 UTC
Fixed in policycoreutils-1.9-12 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. 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. 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. 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'. 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. Should be removed in policy- 1.11.3-3 and policycoreutils-1.11-2 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(,.*|)\)'? I made the change to use you egrep command. Should be available in latest policy. Fixed in Rawhide. |