On Mon, Jan 07, 2008 at 10:34:04PM -0500, Trond Myklebust wrote:
>
> On Mon, 2008-01-07 at 22:14 -0500, Erez Zadok wrote:
> > Trond, I've discovered an asymmetry in how nfs4 (in v2.6.24-rc7) handles
> > listxattr vs. setxattr for special files. I caught this with Unionfs when
> > testing a copyup of a character device from a readonly nfs4 mount to a
> > writable nfs4 mount.
> >
> > nfs4_setxattr returns -EPERM if the inode isn't a regular file or a (sticky)
> > dir. However, nfs4_listxattr returns XATTR_NAME_NFSV4_ACL (16 bytes,
> > "system.nfs4_acl") regardless of the type of the inode. So during copyup, I
> > can ->listxattr fine from the source inode, but I get EPERM trying to
> > ->setxattr on the destination branch of of the copyup. (I already handle
> > the case when copying-up from a f/s which supports xattr's to one which
> > doesn't, but when both file systems are the same and mounted the same, there
> > typically should not be difference).
I do wonder about relying on this, though. The user.* attributes may
work that way, but I don't know if there are any rules you can count on
for the system.* or other xattrs--is there any guarantee a particular
system.* attribute couldn't be readonly, for example?
--b.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
In message <[email protected]>, "J. Bruce Fields" writes:
> On Mon, Jan 07, 2008 at 10:34:04PM -0500, Trond Myklebust wrote:
> >
> > On Mon, 2008-01-07 at 22:14 -0500, Erez Zadok wrote:
> > > Trond, I've discovered an asymmetry in how nfs4 (in v2.6.24-rc7) handles
> > > listxattr vs. setxattr for special files. I caught this with Unionfs when
> > > testing a copyup of a character device from a readonly nfs4 mount to a
> > > writable nfs4 mount.
> > >
> > > nfs4_setxattr returns -EPERM if the inode isn't a regular file or a (sticky)
> > > dir. However, nfs4_listxattr returns XATTR_NAME_NFSV4_ACL (16 bytes,
> > > "system.nfs4_acl") regardless of the type of the inode. So during copyup, I
> > > can ->listxattr fine from the source inode, but I get EPERM trying to
> > > ->setxattr on the destination branch of of the copyup. (I already handle
> > > the case when copying-up from a f/s which supports xattr's to one which
> > > doesn't, but when both file systems are the same and mounted the same, there
> > > typically should not be difference).
>
> I do wonder about relying on this, though. The user.* attributes may
> work that way, but I don't know if there are any rules you can count on
> for the system.* or other xattrs--is there any guarantee a particular
> system.* attribute couldn't be readonly, for example?
>
> --b.
A few months ago I looked into the issue of xattrs and copyup in more
detail, when I was tracking a problem for a user using an SE-linux enabled
livecd with unionfs. I didn't realize before then that selinux made such a
heavy use of xattrs. After tracking down the code maze I found out that the
list of xattrs being defined/used depends on your overall security mode and
global security ops.
Anyway, xattrs can be used for security reasons, and really any semantics
could be attached to them. So in Unionfs I take the conservative approach:
if unionfs is compiled with xattr support, then during copyup I try to copy
the xattrs too (if any exist). If unionfs fails to copyup the xattrs, then
I abort the copyup. I figured it's safer to abort the copyup (which is
typically initiated when trying to modify a file on a readonly
branch/media), than to potentially open up a security hole by giving a
copied-up file more permissions than its source file may have had. This
policy has so far worked for unionfs, at least for those users who use
xattrs/selinux, and in my limited testing. But maybe I've got to rethink
it?
NFS in some sense shares some common traits with a stackable file system, in
that it has three "layers": client -> server -> backing-store f/s. I'm
curious how does nfs/d handle xattrs (and selinux's use of them)? Does the
client depend on having xattr support of any sort? Does the server depend
on having xattr support in the export f/s? How do you handle mixes of those
when one of the three layers has xattr support and another doesn't?
Thanks,
Erez.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs