> Most ACL implementations for ffs use a cheap flag that indicates presence of
> extended ACL information, which would trigger further permissions checks on
> an inode access (only when ACL support is available and/or activated for the
> mount point).

This is only the tip of the iceberg.  Think of all the userland and
protocol changes needed just to support ACLs well.  For starters:

        rcp -p      (protocol change needed)
        nfs         (protocol change needed)
        tar         (protocol change needed)

Now that doesn't include all the userland programs that create new
files.  Creating files with empty acl lists is usually not what the
folks that want ACLs want.  They usually want the program to DTRT and
fill-in the ACL this way for here and that way for there.
        
I once did a few months hard-labor in a team porting effort to port
all of the 4.3BSD (and SystemV.3) userland to a non-unix system that
had ACLs.  While at first it seems that one can get away with treating
ACLs as "invisible baggage on the side", it doesn't really turn out
that way.  It is sort of like tty's being just like files, but with
some extra goop on the side.  Just like most program that use ttys
ending up having to know about the invisible tty baggage, most
programs that creates files end up having to know about ACLs.  Thats a
lot of code.  It will be an uphill battle to get third-party
developers to add the ACL support.

-wolfgang
-- 
       Wolfgang Rupprecht <wolfgang+gnus@dailyplanet.wsrcc.com>
		    http://www.wsrcc.com/wolfgang/
Coming soon: GPS mapping tools for Open Systems. http://www.gnomad-mapping.com/