unionfs, tmpfs, and xattrs

[Stephen Smalley]

On Tue, 2006-02-07 at 22:44 -0500, Bill Nottingham wrote:
> Well, yes, but it means the xattrs implemented for these pseudo fses
> are somewhat incomplete, if not broken.
> 
> Can you, in the kernel, easily check to see if xattrs are supported for a
> filesystem? No.

SELinux xattrs are _always_ supported for every filesystem by
definition, because their values are actually provided by the SELinux
module.  All data must be labeled.

> Can you, in userspace, remove xattrs? No.

Removal of SELinux xattrs (or more generally, MAC labels) is not
allowed, even for conventional filesystems like ext3, as long as SELinux
is operating/enabled.  No unlabeled data.
> 
> It just seems like a hacky interface to say "filesystems need to provide their
> own xattr code, but if they don't the security module might decide to make one up."
> It would seem preferable to just have the security labels be done via an
> explicit mechanism rather than to incompletely overload xattrs.

I think you need to look at the history here:  We started with our own
APIs for SELinux separate from the xattr API, but were told to migrate
to using the xattr API for upstream merging of SELinux into Linux 2.6.
We then individually patched various filesystems like tmpfs and devpts
on an as-needed basis to support the security xattrs, but the real
processing for such filesystems simply consisted of calling back into
the SELinux module to get/set the incore inode security information.
For LSPP (and as a widely desired functional enhancement by people who
wanted to see labels on other filesystems like /proc and were used to
being able to do that with the old SELinux), we needed to support at
least the ability to get the security attributes on all filesystem types
(and to get the actual security attribute as seen by SELinux, including
for filesystems labeled via context mounts, genfs_contexts, etc).  So we
introduced a generic fallback for security xattrs in the VFS in 2.6.14
so that we didn't need to patch every filesystem type, and then we
introduced support for canonicalization of getxattr results in 2.6.15 so
that userspace could see the same label being used actively by
SELinux.  

> > What is the upstream status of unionfs?
> 
> It's not upstream yet, although it's used in a variety of projects.
> Moreover, trying to fix it to work around this, doesn't work, as...

Over on redhat-lspp, during early discussions of polyinstantiated
directories and potential use of unionfs there, Viro said that unionfs
was nowhere near ready for merging and had a lot of nasty corner
cases.  
> 
> > > I could theoretically patch unionfs to call the vfs method, but... ew.
> 
> listxattr isn't exported as a vfs method, and even just using the vfs_get/setxattr
> methods doesn't appear to work correctly.

Not sure what issue you are encountering with using vfs_getxattr; nfsd
uses it.  For listxattr, introducing a vfs_listxattr should be
straightforward and reasonable if there is a user for it; I think the
absence is just due to a lack of a user.

-- 
Stephen Smalley
National Security Agency