acl_extended_file and NFSv4

[J. Bruce Fields]

On Thu, Aug 24, 2006 at 01:04:57PM +0200, Christophe Saout wrote:
> the patch to extent libacl for NFSv4 client support seems to work quite
> well. I've extended the patch to also include NFSv4 support in the
> acl_extended_file function, so that "ls -l" (the version patches in some
> distros to support libacl) can show that neat plus sign after the unix
> permissions if additional ACLs are set.

Cool, thanks.

> I have added a bug on Gentoo Bugzilla asking them to add optional
> support for you patch in their official libacl ebuild (and the
> maintainer asked me back if my additional patch is ok with you).
> 
> I'm aware for the dislike of the way NFSv4 and POSIX ACLS currently
> handled in libacl side by side as I just added my code below the
> following comment:
> 
>          * Also I'm a little uncomfortable with the amount of #ifdef
>          * NFS4 stuff that's going on.  We need a cleaner separation. */
> 
> But that's just an implementation issue, not a general problem, and can
> be fixed later, right?

Yes.

The bigger problem for the current libacl patches is that we'd really
like to do long-term is move people to pure NFSv4 ACL interfaces,
instead of doing this translation.

We've got some work underway on client-side pure NFSv4 ACL tools, and
Andreas Gruenbacher has patches to implement them in local filesystems
(which will help the server).

That said, there are also some advantages to keeping the libacl stuff on
life-support, and another interesting thing to do would be to replace
the NFSv4->POSIX ACL translation by something less fragile; the current
translation only accepts a very limited set of NFSv4 ACLs, hence
interoperates with other servers poorly.  We have a more robust
algorithm implemented on the server side, so it'd just need porting; let
me know if you want the details.

--b.