unionfs, tmpfs, and xattrs

[Bill Nottingham]

So, I'm playing some with unionfs
(http://www.fsl.cs.sunysb.edu/project-unionfs.html),
which works fine with SELinux as long as the underlying filesystems that you're
using in the union all support xattrs.

Which brings us to tmpfs.

The way xattrs appear to work on tmpfs is that the VFS tries the getxattr
op of tmpfs (which fails, as it doesn't exist), and then does an end-run
around in the selinux code to get an attribute, as long as you're only
looking for the security xattr.

This means that anything on tmpfs can have a xattr retrieved from userspace
just fine with getxattr(2), but if you try and get it in the kernel via
'normal' means (such as the inode's getxattr method), it will fail. This
breaks tmpfs as part of a unionfs branch pretty badly.

Why was xattrs-on-tmpfs done this way? It seems somewhat hackish.

I could theoretically patch unionfs to call the vfs method, but... ew.

Bill

[James Morris]

On Tue, 7 Feb 2006, Bill Nottingham wrote:

>  The way xattrs appear to work on tmpfs is that the VFS tries the
> getxattr
>  op of tmpfs (which fails, as it doesn't exist), and then does an end-run
>  around in the selinux code to get an attribute, as long as you're only
>  looking for the security xattr. 
What it's doing is checking if the fs can supply a security xattr, and if 
not, allows the kernel to supply one.

>  This means that anything on tmpfs can have a xattr retrieved from
> userspace
>  just fine with getxattr(2), but if you try and get it in the kernel via
>  'normal' means (such as the inode's getxattr method), it will fail. This
>  breaks tmpfs as part of a unionfs branch pretty badly.
>  
>  Why was xattrs-on-tmpfs done this way? It seems somewhat hackish. 
So xattrs do not have to be implemented for every type of psudo fs.

What is the upstream status of unionfs?

>  I could theoretically patch unionfs to call the vfs method, but...
> ew. 

-- 
James Morris
<jmorris(a)namei.org&gt;

[Bill Nottingham]

James Morris (jmorris(a)namei.org) said: 
>  > This means that anything on tmpfs can have a xattr retrieved
> from userspace
>  > just fine with getxattr(2), but if you try and get it in the kernel via
>  > 'normal' means (such as the inode's getxattr method), it will fail.
> This
>  > breaks tmpfs as part of a unionfs branch pretty badly.
>  > 
>  > Why was xattrs-on-tmpfs done this way? It seems somewhat hackish.
>  
>  So xattrs do not have to be implemented for every type of psudo fs. 
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.

Can you, in userspace, remove xattrs? No.

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.

>  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...

>  > 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.

Bill

[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

[James Morris]

On Tue, 7 Feb 2006, Bill Nottingham wrote:

>  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 doesn't "make one up", the kernel has an xattr because the data is 
always labeled.  What it's saying is, if the fs doesn't implement it's own 
xattr code, we return what the kernel is maintaining anyway.

>  It would seem preferable to just have the security labels be done via
> an
>  explicit mechanism rather than to incompletely overload xattrs. 
It is explicit, but there's a fallback if the fs doesn't implement xattrs.  
You can still override this by implementing xattrs for a psuedo fs.

>  
>  > What is the upstream status of unionfs?
>  
>  It's not upstream yet, although it's used in a variety of projects. 
It's really best for everyone if the code is posted for upstream merge.



- James
-- 
James Morris
<jmorris(a)namei.org&gt;

[Bill Nottingham]

Stephen Smalley (sds(a)tycho.nsa.gov) said: 
>  > 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. 
Then the filesystem should have a getxattr() method... that's all
that I'm saying here. Having filesystems that return xattrs, but,
claim they don't in their own methods, is somewhat disingenious.

>  > > > 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. 
Locks. Could be some other stuck locks, will investigate some more.

>  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. 
If we're going to have the filesystem's own getxattr() methods not
actually tell whether the FS returns an xattr, I think wrapping all
the calls is needed...

Bill