Bug 476964 - Mount /var/tmp with tmpfs creates denials
Mount /var/tmp with tmpfs creates denials
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: util-linux-ng (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-18 06:03 EST by Till Maas
Modified: 2011-02-09 04:05 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-01 04:58:35 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 Till Maas 2008-12-18 06:03:28 EST
Description of problem:
When I use tmpfs for /var/tmp, there are some denials, e.g. for postfix.
/var/tmp has then this context:
system_u:object_r:tmpfs_t:s0
but it should be
system_u:object_r:tmp_t:s0


Version-Release number of selected component (if applicable):
selinux-policy-3.5.13-30.fc10

How reproducible:
Happens after every reboot.

Additional info:
rc.sysinit contains this, which makes it probably not a problem:
[ -n "$SELINUX_STATE" ] && restorecon /tmp
Adding this for /var/tmp would "fix" it probably, too, but this does not really scale. Can maybe some context mount option help here? What seems to help here, is to use a tmpfs helper program that always runs restorecon. But I only tested it yet for mounting tmpfs in /mnt/foo, where it changes the context from tmpfs_t to mnt_t:

# cat /sbin/mount.tmpfs
#! /bin/bash

/bin/mount "$@" -i -t tmpfs
/sbin/restorecon "$2"
Comment 1 Daniel Walsh 2008-12-18 10:21:02 EST
This would work for a destination where there is default labeling,  I kind of like the idea.  What do you think Bill?

Unfortunately this does not work on subdirs of /var/tmp and /tmp, since we set the labeling for the contents of these directories to <<none>>  meaning we have no idea what the label should be.
Comment 2 Bill Nottingham 2008-12-18 10:59:42 EST
Wouldn't/shouldn't this be genericized to any filesystem that doesn't support SELinux xattrs? Maybe call the restorecon directly from mount(8) itself?
Comment 3 Daniel Walsh 2008-12-18 11:19:17 EST
Well tmpfs_t does support xattrs
Comment 4 Daniel Walsh 2008-12-18 11:21:00 EST
Also we want to check for a context mount in the script,  So only run the restorecon in the case where the tmpfs mount does not include a context mount command

mount -t tmpfs -o context="system_u:object_r:httpd_sys_content_t:s0" /dev/shm /myweb

For example.
Comment 5 Eric Paris 2008-12-18 11:28:05 EST
Who cares if it has a context= mount option?  restorecon won't be able to change it so it doesn't hurt anything to try.

I think it's a good idea that any time a tmpfs ramfs blah blah is mounted which supports labeling but not persistant labeling we should just call restorecon right after we lay it down.  I think that makes sense for 99% of people out there.
Comment 6 Eric Paris 2008-12-18 11:28:55 EST
maybe we should be checking and not calling if it was mounted with rootcontext= since that means the mounting process knew what it was doing, already "solved" the problem and restorecon could screw it up....
Comment 7 Eric Paris 2008-12-18 11:31:37 EST
actually that could solve it.   have mount check matchpathcon on the mount point.  if it doesn't get a response look at the context of the parent.  then add rootcontext= blah if it isn't already set.  (rootcontext= and context= together aren't going to work, so you gotta test that too....)

it solves "all" the issues   :)
Comment 8 Daniel Walsh 2008-12-18 11:43:01 EST
You volunteering to write the script for this?
Comment 9 Stephen Smalley 2008-12-18 12:12:24 EST
FWIW, over in OpenSolaris land, tmpfs mounts inherit the uid/gid/mode attributes from the underlying mount point directory by default, and thus we did the same for the security context.  So by labeling the mount point directories correctly, we get the tmpfs mounts labeled correctly automatically.
Linux tmpfs doesn't take that approach for uid/gid, so perhaps it isn't suitable there, but it is a possible approach for the context.
Comment 10 Daniel Walsh 2008-12-18 13:55:26 EST
#! /bin/bash
/bin/mount "$@" -i -t tmpfs
target="$2"
shift 2
if ! echo "$@" | grep -q -E '(fs|def|root)?context='; then
	test -x /sbin/restorecon && /sbin/restorecon "$target" 
fi
Comment 11 Bill Nottingham 2008-12-18 14:02:56 EST
Again, though - is there any reason this couldn't be integrated directly in mount? What filesystems does this apply for aside from tmpfs?
Comment 12 Till Maas 2008-12-18 14:27:43 EST
Btw. my /sbin/mount.tmpfs script is not working at bootime, i.e. /var/tmp is not restoreconed and after I managed to store the output of mount in a file in /var/log, it said permission denied for restorecon. But it works fine if I manually umount /var/tmp as root and mount it.
Comment 13 Daniel Walsh 2008-12-18 14:43:28 EST
This would need to have policy changes to make it work on an enforcing machine.  mount is not allowed to relabelfrom/relableto certain context.  So it would need to be modified.  If you reboot in permissive mode, the changes should work.

Bill ramfs and tmpfs are the the only ones I would guess.

I guess we could get these two file systems to automatically query the mountpoint and then specify the rootcontext, within the mount command, eliminating the restorecon, iff *context= was not specified.
Comment 14 Stephen Smalley 2008-12-18 15:12:05 EST
I think this only applies to tmpfs.
ramfs is presently a genfscon-labeled filesystem (i.e. single fixed label for all inodes).
If you mount with rootcontext=, you don't have to use restorecon afterward.
Permissions are required in order to use rootcontext= (or to apply restorecon), but mount_t should have the requisite permissions for the former.
Comment 15 Daniel Walsh 2008-12-19 15:37:01 EST
I think this one would work best if we move matchpathcon to /sbin

#! /bin/bash -x
if ! echo "$@" | grep -q -E '(fs|def|root)?context='; then
    if con=`/sbin/matchpathcon -n "$2"`; then 
	/bin/mount "$@" -o rootcontext=$con -i -t tmpfs
	exit $?
    fi
fi
/bin/mount "$@" -i -t tmpfs
Comment 16 Karel Zak 2008-12-19 19:21:14 EST
I think the selinux mount option(s) must be quoted:

  /bin/mount "$@" -o rootcontext=\"$con\" -i -t tmpfs

BTW, it seems that mount(8) knows nothing about rootcontext=, it means this option wont be translated to the raw selinux context (context=, fscontext= and defcontext= are translated and quoted) -- to see translation from human to raw format use verbose mode (mount -v). The option is also not documented in the mount.8 man page. I guess we need to fix this problem.
Comment 17 Eric Paris 2008-12-21 23:24:24 EST
I like sds's opensolaris idea of just inheriting the rootcontext from the target inode.  How about a script like this....

#! /bin/bash -x
if ! echo "$@" | grep -q -E '(fs|def|root)?context='; then
    if con=`ls -Zd "$2" | cut -f 5 -d ' '`; then 
	/bin/mount "$@" -o rootcontext=\"$con\" -i -t tmpfs
	exit $?
    fi
fi
/bin/mount "$@" -i -t tmpfs
Comment 18 Daniel Walsh 2008-12-22 11:59:30 EST
That is fine with me also.

Seems to work for bind mounts and not succeptible to the failure when matchpathcon returns <<none>>.  Also ls and cut are available on /bin so /usr can not be mounted, when the mount command is run.
Comment 19 Daniel Walsh 2009-03-04 14:51:52 EST
Krel can we get this into Rawhide to see if it causes any problems?
Comment 20 Karel Zak 2009-03-19 05:39:00 EDT
Applied.

Do we want to add the script to F-10? ..or rawhide is enough?
Comment 21 Daniel Walsh 2009-03-19 09:03:26 EDT
I would rather keep it in rawhide for now, to make sure we did not screw up.  :^)
Comment 22 Karel Zak 2009-03-20 04:10:38 EDT
We have a first bug report:
   bug #491175 -  mount of tmpfs FSs fail at boot
Comment 23 Karel Zak 2011-02-09 04:05:45 EST
I'd like to move whole mount.tmpfs functionality to mount(8) to avoid unnecessary shell script execution. Please, for more details see

https://bugzilla.redhat.com/show_bug.cgi?id=676100

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