On Thu, 8 Mar 2001, der Mouse wrote:
> I think isildur's point is that putting ACLs into the main FFS code
> cannot be "doing [it] correctly", regardless of how good an
> implementation of ACLs it may be.  (But see below.)

yes, it's a feature that i personally think superfluous. However, if it's 
going in, then i had my comments about how it should..

> Since "correct" is not a thing that can be settled as a question of
> fact, here, this will always remain opinion.  It won't help anything to
> treat it otherwise - such as by asking for "a real technical reason"
> and then calling the offered opinion a "crusade" and using words like
> "rant", for no visible reason except your disagreement with the offered
> opinion.

*grin* i have to agree here. it's all a matter of opinion. some of us want,
as der mouse put it, to keep netbsd as BSD. 

> Your (tv's) opinion on this matter may have enough of the NetBSD
> community behind it to ram it through in spite of our (isildur's, mine,
> possibly others') disagreement.  That doesn't make our opinion any more
> of a rant or crusade than yours.

> 
> 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.

Actually, there are ways. It should not be too difficult to find a bit 
somewhere to specify that a given file has an ACL. A non-ACLified
FFS can ignore it. An ACLified one can then worry about where to find and 
store the ACL in a nonconflicting manner. A non-ACl kernel writing to an
ACLified filesystem won't be adding any ACLs when new files are created, 
so it wont set the bit. 
An ACL kernel reading a non-ACL filesystem would see no files that have ACLs
and wouldnt worry itself over them. Any files created  by this one, however,
must also not have ACLs since the silesystem wont have anywhere to put 
them. So, the filesystem itself must have a bit also (it shouldnt be so hard
to find a bit in, say, the superblock, for this) to indicate an ACL 
filesystem. Thus also, in an ACL filesystem where a non-ACL ffs kernel 
code has written a file, thus lacking an ACL and the accompanying bit, the
ACL kernel can then make some choices like 'hey this is an ACL 
filesystem, here is a file which has no ACL bit set and thus has no ACL, 
i will assume the parent directory's ACL for this file' or whatnot. 
Now, as for actually storing the ACL info, this scheme would sort of preclude
storing it in directories. I dont htink theres enough space to store a
pointer to ACL info in a directory entry, and we cannot change those
structures or else we break existing FSS filesystems' being supported
so, an ACLified FFS must read ACL directory information from somewhere 
else. An ACLified newfs should create some space for this somewhere, or 
create a file in the filesystem to contain the ACL information, which 
would be protected naturally. The ACL info , being slow and ponderous, should
be organized carefully. it's even more obviously a database than the 
filesystem itself. 


Isildur
> 
> I don't know what "we" you think you're speaking for here (I don't
> think I've seen more than one voice raised, besides yours, in support
> of doing ACLs), but this *is* discussing the technical aspects of ACLs
> - specifically, whether (not how) they should be added to the main
> NetBSD tree.  It sounds to me as though you've already made up your
> mind that they should be and are not interested in any possible
> arguments that disagree with that, preferring instead to use words like
> "nonsense" and "rant" to attack any such arguments.
> 
> It may work, in that you may get your way; it wouldn't be the first
> time objections have been ignored.  But calling the objections invalid
> doesn't make them so.

 This is a good point. A lot of decisions have been made recently which i 
think ran counter to what a lot of the BSD community woudl have liked. 
All of them seemed to be directly motivated by pressures from outside, 
notably the linux community, to be more like them. Myself and others raised
large objections to this, but it was too late. 

> 
> Since it appears the decision that ACLs will go in has already been
> made, somehow, apparently without any public discussion and debate (in
> that all arguments advanced for the "con" side have been dismissed as
> rants and nonsense, even though the whole discussion boils down to "I
> like it" and "I want it" versus "I don't like it" and "I don't want
> it" - the onus seems to have somehow been shifted from those who want
> to make a change to those who want to prevent it), I don't expect to be
> saying much more on the subject.  But I can't let this sort of
> "argument" pass without pointing out what it really is.

The feature pressure is on very high these days. I think most of the 
final decision makers dont ask the question 'should this feature makeits 
way into NetBSD' but instead ask 'how should it make its way into NetBSD'.
Luckily, when this happens, the implementation that we end up with in 
NetBSD is superior to any other implementation around, but i personally 
dont like all these creeping features. i think sometimes we just need to 
sit back and ask 'why' more often when we contemplate adding things, instead
of just coming up with the best way to do it. (which we're already very 
good at)

Isildur