Re: [RFC] POSIX ACL kernel infrastructure

[Andreas Gruenbacher <agruen@suse.de>]

On Friday 09 August 2002 04:02, Nathan Scott wrote:
> hi Andreas,
>
> On Mon, Aug 05, 2002 at 01:28:32PM +0100, Christoph Hellwig wrote:
> > On Mon, Aug 05, 2002 at 02:11:33PM +0200, Andreas Gruenbacher wrote:
> > > >From user space, yes. The get_posix_acl operation is currently used in
> > > > nfsd;
> > >
> > > going via the xattr operations would be too expensive here. The
> > > set_posix_acl operation is indeed not used so far; I think it makes
> > > sense to add it for completeness' sake.
> >
> > I'm not fully convienced.
>
> Nor am I (I don't buy either the too expensive argument or the
> need for unused ops).

The kernel NFS daemon introduces a number of interesting problems in the 
kernel that no other component requires; the ACL permission masking hack is 
one of them. The hack affects NFSv2 and NFSv3 

It is really important that encode_fattr and encode_fattr3, the functions that 
include the hack, are efficient; they are used in all the essential NFS RPCs.

The two implementation choices are:

	* Use the get_posix_acl inode operation

	On Ext2, Ext3, ReiserFS the inode operation passes a handle to the
	ACL to the caller (no copying). The handle is in the cache	after the
	first access, the cache is very effective. XFS currently seems not to
	implement the *_posix_acl inode operations. That's fine; just the
	NFS hack won't be able to mask permissions.

	* Go via the xattr ACL format

	The xattr interface uses pass-by-value by design. So this requires
	allocating a buffer, conversion from the file system into the xattr
	format, parsing the xattr format. The xattr format is in 
 (with possible reverse endianness conversion).

The get_posix_acl approach has the added benefit that other parts of the 
kernel interested in manipulating ACLs can do so easily and efficiently 
(though I don't see which ones that could be right now). If set_posix_acl 
really _must_ be removed I won't bang my head against a wall.

Is this sufficient?

> It also begins to add unnecessary stuff
> to the VFS inode ops - when capabilities, MAC labels, and misc
> other attributes come along, we don't want to be adding in ops
> for each of them too (esp. considering many filesystems do not
> support extended attributes at all). IMO getxattr() should be
> all we ever need here.

Those file systems not supporting some of the options are not affected. We 
only need to add stuff to the VFS for things that other parts of the kernel 
need to access independently of the real filesystem, in those cases where the 
accesses need to be faster than the xattr interface can be.

> MS_POSIXACL from your earlier mail is a Good Thing, I think -
> I'll switch XFS over to use that when I get some time (instead
> of the inode flag we are currently using).

Fine, I will also use that, instead of MS_NOUMASK. MS_POSIXACL is nice to have 
in the nfsd hack as well. Having it is not extremely clean design, and I will 
hate myself for giving in the day another mechanism requires the umask to be 
skipped which is not POSIX ACLs, though.

Cheers,
Andreas.

------------------------------------------------------------------
 Andreas Gruenbacher                                SuSE Linux AG
 mailto:agruen@suse.de                     Deutschherrnstr. 15-19
 http://www.suse.de/                   D-90429 Nuernberg, Germany