problems with tmpfs and relabeling
Stephen Smalley
sds at tycho.nsa.gov
Fri Apr 21 11:51:44 UTC 2006
On Thu, 2006-04-20 at 14:38 -0400, Bill Nottingham wrote:
> Stephen Smalley (sds at tycho.nsa.gov) said:
> > It may be necessary to add allow rules to enable the fscontext= mount to
> > succeed, although I would have expected that to generate an avc denial
> > if that were the issue (unless suppressed by a dontaudit, but that seems
> > wrong). You would need to allow <processdomain>
> > <originalfstype>:filesystem relabelfrom; allow <processdomain>
> > <newfstype>:filesystem relabelto; Dan?
>
> OK, once doing this, I get:
>
> avc: denied { search } for pid=1688 comm="mount" name="/" dev=tmpfs ino=5444
> scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:fs_t:s0
> tclass=dir
Ah, yes. tmpfs / fs_use_trans is a bit different; inodes are labeled
based on transition SID computed from allocating task SID and superblock
SID.
> And, then, expectedly, after fixing that, restorecon can't getattr/read/etc
> fs_t.
>
> I seem to be stuck in a neverending cascade of AVCs. What's generally
> wrong here?
>
> The usage model is this:
>
> 1) mount a tmpfs under /var somewhere
> 2) take a predefined list of dirs and files, and for each one:
> a) copy it to that tmpfs
> b) bind mount it over its original location
> c) restrorecon @ the original location, to get the contexts right
>
> This shouldn't be *that* hard to get working with policy, should it?
This is beginning to make me think that fs_use_trans behavior isn't
quite what it needs to be, or that we need an alternate (new) behavior
for tmpfs. tmpfs has always been a bit of a sore spot because of its
multiple uses for the kernel-internal shm mount, the userspace POSIX shm
mount, and any other arbitrary use.
Possibly stupid question: Will files be created dynamically in these
tmpfs mounts at runtime? Do you expect them to follow the traditional
inherit-from-parent-directory behavior you get from ext3?
--
Stephen Smalley
National Security Agency
More information about the selinux
mailing list