> On Sat, Aug 25, 2001 at 09:36:37PM -0400, Ken Cross wrote:
> > How it's stored on disk is implementation-dependent and varies
considerably.
>
> Which, it seems to me, is the only remaining question bearing debate
> on tech-kern.

Agreed (unless there's a more relevant group for filesystem stuff).

>
> FFS does not seem to have bits free for this. Certainly not for a
> plausibly infinite block of metadata (well, okay, you couldn't have
> more than 65536*2 sets of credentials, but that's a lot of bits).
> And (imho) it belongs at the UFS layer anyway, so that we get it
> in other file systems. (Yes, I have a specific LFS disk in mind
> where I want ACLs, thanks for not asking.)

In the current FreeBSD implementation, the ACL's are stored in a separate
file, one per filesystem.  I think the inode number is an index into the
file for where the ACL is stored (it's a fixed size and you certainly don't
want a sequential search).  The inode and the on-disk structure for the
files themselves are not changed.  This has pros and cons, but it's
straightforward and reasonably portable.

If Robert Watson and friends are lurking on the list, they can give a much
better overview than I.  http://www.trustedbsd.org/ has some info, but most
details are buried in the source code and mailing lists.

> So, then, what can we do to allow an ACL-aware kernel to still
> behave correctly with an old-style {F,U}FS partition (that's the
> easy part), and what can we do to make a non-ACL-aware kernel able
> to read a file system with ACLs (that's the hard part).

Keep in mind that ACL's are in addition to standard mode bits, so
non-ACL-aware kernels can be in blissful ignorance without modifications.

Similarly, ACL-aware kernels easily handle non-ACL files.  The library
routines specified in 1003.1e are used to get/set/evaluate the ACL's.  These
routines are supplied by the filesystem.  The kernel doesn't need to know
anything about the internal structure of the ACL itself.

Ken