On Thu, 8 Mar 2001, der Mouse wrote:

> >> I too think the NetBSD kernel is not the right place to solve this
> >> problem.  It may be possible to do it in userland (eg, a userland
> >> Samba or WINS server that keeps ACLs in a parallel filesystem tree),
> >> but I really don't think it belongs in the kernel.
> 
> > ACL support needs to be where access decisions are made for the file
> > system.
> 
> Yes.
> 
> > For FFS (and for all of the other in-kernel file systems), those
> > decisions are made in the kernel,
> 
> Yes.
> 
> > thus ACL support needs to be in the kernel.
> 
> No.
> 
> You are making an unstated assumption in this argument: you are
> assuming that the ACLified filesystem must be an entirely in-kernel
> filesystem.  I said - am saying - I don't think it should be.

(I was actually bringing this up in an answer to your other note :-)

Ok, let's talk about how we would do this. We get down to a VOP_ACCESS()
call in the ffs code. It goes to decide if user blah of groups foo has
access Z (read, write, execute) on inode X. For ACLs to work at all,
_shomething_ in the kernel code has to know about ACLs. :-) Otherwise the
ckeck will proceed w/o any ACL clue.

We could have the file systems go off and ask a userland daemon if this
user has access. And for development, that might be a good thing to
do. But it will be an expensive process - we have to send a message to
whatever process is doing acl verification, and sleep for its answer. We
then context switch to the ACL daemon, wake it up, have it read the
message, do its thing. Then the ACL daemon has to send a message back to
the sleeping process. We then go back into the kernel, and switch to the
other process. Oh, and since VOP_ACCESS() gets handed a locked vnode, we
have to unlock before sleep and re-lock after.

That's not something that sounds fun for a busy server. Granted we don't
call VOP_ACCESS() every read or write, but still, it's expensive.

Oh, and about your other point:

> As for technical merits...I can't see any way an ACLified FFS
> filesystem could possibly interoperate with a completely non-ACLified
> FFS kernel; almost by definition, the non-ACLified kernel won't know   
> about however it is that the ACLs are stored and hence won't, for
> example, be able to free it when an object with ACLs is destroyed.
> You'll have to either bloat the mainline or lose interoperability.

Yes, it'd be a pain for an ACL-aware ffs to pick up after a non-ACL-aware
ffs had at the filesystem, but it wouldn't be impossible. We'd need a way
for the ACL ffs to realize that a non-ACL version used the drive. That's a
matter of mount flags of some sort. I think the superblock has tons of
space, so we can do things. Then fsck needs to know how to clean things
up. The main things to look for are ACLs for free'd inodes. The other
thing is that the ACL for an inode needs to record which generation number
it was for. If we get a case where the ACL for an inode is for a different
generation, then we toss the ACL. That should cover it.

Also, think about what we're talking about. Under what circumstances would
an ACL'd ffs get handed to a non-ACL'd kernel? Either 1) it's a file
system that moves around a lot (like a floppy), or 2) the proverbial dung
and fan have met. These both strike me as cases where we can take whatever
hit this (ACL-ffs supporting accesed by non-ACL-ffs) would entail. :-)

Take care,

Bill