Re: problems with tmpfs and relabeling

[Stephen Smalley <sds tycho nsa gov>]

On Wed, 2006-04-26 at 11:19 -0400, Bill Nottingham wrote:
> Stephen Smalley (sds tycho nsa gov) said: 
> > On Fri, 2006-04-21 at 07:51 -0400, Stephen Smalley wrote:
> > > On Thu, 2006-04-20 at 14:38 -0400, Bill Nottingham wrote:
> > > 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?  
> > 
> > Sorry, not enough caffeine here.  They already do follow that behavior
> > (via inode_init_security hook call from tmpfs).  Only problem here is
> > getting the right label on the root directory inode in the first place,
> > which likely just requires allowing restorecon to fix it up, as is done
> > for /dev as well.  This does suggest however that a rootcontext= option
> > to mount would be helpful.
> 
> Sorry to be dense, but if I were to be writing down what specifically needs
> done, that would be:
> 
> - rootcontext= support in mount?
> - a way to get the root label inode right on tmpfs (is this a policy
>   or kernel change?)
> 
> Just trying to clearly articulate what I'm blocking on.

In the short term, I think you are just blocking on a policy change to
allow you to fix the root inode label via restorecon after mounting the
fs with the fscontext= option.  In the long term, I think we want some
changes/extensions to context mount options and their handling in the
kernel to allow things like:
- rootcontext= option for specifying root inode label separate from
fscontext label for fs_use_trans filesystems (like tmpfs), and
- combined use of context= and fscontext= options (requested separately
by Russell Coker).

And then separately there are issues like the devpts root and its MLS
label, which requires range_transition support on objects.

-- 
Stephen Smalley
National Security Agency