> Could the resource fork also keep ACLs? Looking up separate ACL
> data and MAC data seems like it might be slow. The space saving
> would help a great deal. So maybe rename i_*_acl and put privs
> in there.
>
I think it is a good idea to combine all these "extended attributes" into
one structure. However, in its current form, putting ACLs into the
resource fork is not a good idea. The reason is that the current ACL
implementation relies on sharing ACLs using an ACL cache in the kernel.
The resource fork is designed to hold arbitrary data for each file and
there is currently no notion of sharing.
Putting capabilities and MAC into the ACL structure would probably work
without degrading performance. There are 96 bits available in
the ACL entry.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/