Subject: Re: ACL's revisited
To: Ken Cross <firstname.lastname@example.org>
From: gabriel rosenkoetter <email@example.com>
Date: 08/25/2001 23:25:32
On Sat, Aug 25, 2001 at 10:57:04PM -0400, Ken Cross wrote:
> Agreed (unless there's a more relevant group for filesystem stuff).
Well, despite what some some trolls would like to think, file
systems (even new ones) are intrinsically linked with the kernel,
> 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.
The cons include this including significantly slower for file access
(though probably not noticeable to the average user, there are
definitely things, like say large user databases, that would do well
not to have the overhead of reading an extra file). That said, this
is precisely what we do with quotas, and it seems to work just fine
> 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.
Well. Unless you move things around inside the inode or enlarge the
FS's concept of an inode with some bytes to keep track of ACLs (even
if they're just pointers within the file itself; a hideously bad
idea, probably). Doing it the way you describe (which I agree is
likely the only workable compromise) avoids that, obviously.
> 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.
Now then, if I didn't have this pesky set of classes beginning in a
It'd still be nice if someone who knows more about all this than I
do would address the issue of how this could live happily in the UFS
layer. Will moving this metadata file around on disk (LFS) cause
Incidentally, do we have quotas on LFS? If not, why not?
~ g r @ eclipsed.net