On Mon, 12 Mar 2001, Bill Studenmund wrote:

# > 	If so, which fs layer(s) are we going to need to modify?  Since
# > 	we're doing vfs->(every_other_fs), some vfs hooks will need to
# > 	be put in, possibly returning EINVAL if ACL is not compiled
# > 	into the kernel, for example.  We'll probably need hooks into
# > 	ffs/ufs and nfs, as well; likely others.
#
# No, we won't. We already have VOP_ACCESS(), which determines if you have
# read, write, or exec privileges. To add ACL support, all we need to do is
# add the extra flags whatever ACL method we use adds.

Okay, so how do we then handle modification of the ACL?  VOP_ACCESS()
only handles the access on the file; it does not do manipulation of
the access controls.

# All the extra flags
# I've seen (the ones on AFS) are mappable to one of the three original
# modes, so filesystems which don't do ACLs can easily be extended to deal
# with the new VOP_ACCESS() flags (for instance, read and list access would
# map to VREAD on an old-style filesystem). So we don't need a new VOP, and
# it's not hard to change the MI (well fs-independent) parts of the kernel
# to take advantage of ACLs. :-)

Okay, I'll buy that last part...

#
# > 	If not, how much will fsck, newfs, dump and restore
# > 	need to be modified to make this work, and how badly would
# > 	this mangle the existing filesystem format?  Would it be to
# > 	the extent that we'd need to invent a new filesystem to replace
# > 	ffs?
#
# Answering this question for the ffs tools will have to wait until we have
# an implimentation to talk about.

Agreed; I was jumping the gun and thinking too much inside the box.

# I doubt we will need to impliment a new ffs. We may come up with a file
# system which has a different magic number (thought bumping the superblock
# and inode numbers is more likely), but I suspect it will be 95% to 99%
# ffs.

...which means we will have 95% to 99% data integrity and portability
between two differing systems.  We need to be able to do this in a
portable way, if at all possible.  If my system craps out, I may need
to migrate disks or do a sysinst kind of deal, and ACL may not be
compiled into the kernel, in which case I'm screwed, barring asking
someone else to compile an ACL kernel for me (and then figuring out
how to get the damned thing up in single-user mode &c.).

And it also needs to be portable such that if I decide to DEactivate
ACLs at some later date, my filesystem won't be hosed, I can reclaim
the used ACL space and run ffs-plain without having to rebuild my
fs.


				--*greywolf;
--
*BSD: more is more.