In message 2407.798403536@austin  Tobias Weingartner told

}-Example:
}---------
}-+rwxr-xr--   foo   bar   ./testfile
}-	wendy.*      r-x
}-	*.sys        r-x
}-	*.noaccess   ---

}-Any user with the UID of 'wendy' will have read, write, and execute
}-access to this file.

}-Any user with the GID of 'sys' and not GID 'noaccess' will also have
}-read, write, and execute access to this file.

Excuse me, but where do wendy.* and *.sys get write access from?

}-Any user with the GID of 'noaccess' and not GID 'sys' will have no
}-access to this file whatsoever.

}-Another nice thing to have, would be the ability to have 'extra' bits
}-in the ACL entries, a bit to allow protection changes 'p' could be very
}-usefull.  Also, a bit 'd', to allow deletions could allso be usefull, etc...

IMHO 'd'-bit in Amigas was the thing that made them worth while against
UNIXes ,-) [My SysAdmin once tried to delete a file be moving it into
/dev/null ... later he had discovered that he had actually moved it
in place of /dev/null ... And the 'd'-bit would have saved the day again]

This isn't really necessary (or even elegant), but a "hidden bit" could
also be introduced. I could even be made specific, like "Hidden from
wendy.*" and (this would be nice) "Hidden from all but *.wheel".

To go into even more useless ramblings how about a "file locked"-bit?

}-Also, to make the lookup faster (for the case where a file does not have
}-an ACL), the same place where the imutable flag is set in the inode, we
}-could have an ACL present flag.  Only if this bit is set on an inode, do 
}-we have to check the ACL lists...

Why not have a simple pointer to another inode that contains the actual
ACL and if the pointer is NULL we don't have an ACL ...

--
	Aleksi Suhonen