Re: Vnode scope

[Elad Efrat <elad%NetBSD.org@localhost>]

On Tue, May 12, 2009 at 6:09 AM, David Holland 
<dholland-tech%netbsd.org@localhost> wrote:
> On Tue, May 12, 2009 at 04:22:55AM +0300, Elad Efrat wrote:
>  > Well, that's half true, and I've stated this as a shortcoming of my
>  > proposal. However, keep in mind that we don't have NFSv4 (yet), nor
>  > UFS extended attributes are getting used (I'm willing to bet that
>  > nobody is using NetBSD with ACLs in extattrs). Can't comment on what
>  > sort of access control AFS provides, but I'm pretty sure that if NTFS
>  > had ACL support it would not be listed as the last item in its TODO
>  > list along with a comment that states "though usefullness of such
>  > feature is arguable".
>
> These are all things we *should* have, and rearchitecting the system
> so they won't work is not a step in the right direction.

The system isn't "rearchitected" in a way that won't make them work.
I've stated that several times. It's rearchitected in a way that will
make them work in the best and most common case (and 100% of the cases
*now*) and in the second-best way in the worst case, where second best
means that "listeners will not be able to make decisions based on the
permissions, but will *only* have the file-system's decision".

This is far beyond the scope of this discussion, but I can't help by
comparing what you suggest to asking someone if they'd rather have $90
now, or $100 in N years from now, where N is unknown (and according to
history, which might be meaningless, can be "at least" 16). The
theoretical discussions about what we could and should have in the
future, provided Someone does the work, as opposed to what we can have
right now (where I do the work) don't take into account so many
factors beyond the bottom-line technicalities... but anyway, since we
don't prevent what you think we prevent, it's not a step in the wrong
direction. :)

(I'm not sure if you're aware, but if the vnode scope is implemented,
and all file-system access is authorized through it, I can implement
extensible ACLs for *all* file-systems with *any* features I want,
*today*. Kauth(9), fileassoc(9), and for the truly brave proplib(3)
can together do amazing things. :)

>  > I'm not aware of the complete details of what the parties who
>  > discussed this idea decided, but I will point out that people expect a
>  > way to write code that goes like "if (this_is_allowed) { do_it(); }",
>  > and taking that a way is a serious regression (think TOCTOU races).
>
> Yes, that's the point. The intent is to move a lot more locking
> operations inside the FSes and out of VFS code; the associated access
> checks need to be done inside the lock scope and therefore would need
> to be in the FS.

I can't comment on the locking protocol you propose without knowing
its details (where was it discussed?), but what you suggest seems like
opening the door for some more copy/pasting across file-systems, since
we always need the secmodel to give the last word... if that's not a
problem, then sure, it can be inside the file-system. That doesn't
change anything about the other parts of the discussion about
normalizing permissions (for decisions based on them that might be
made by listeners), passing the decision to the secmodel, or making
sure that the secmodel code can always flip the decision.

Thanks,

-e.