Re: Vnode scope

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

On Tue, May 12, 2009 at 1:07 AM, Andrew Doran <ad%netbsd.org@localhost> wrote:
> On Sat, May 09, 2009 at 04:42:16PM +0300, Elad Efrat wrote:
>
>> I would like to implement the vnode scope so we can use kauth(9) to
>> authorize file-system related operations.
>>
>> There are generally two ways we can go about that:
>>   - Move access control to the VFS layer
>>   - Keep access control in file-system specific code
>
> Perhaps with tightly-controlled exceptions for performance reasons, I think
> it needs to remain in the file-system specific code because:
>
> - There are lots of different conventions and capabilities in this area,
>  consider AFS, NFSv4, UFS+extattr, NTFS, ??. Without a plan to handle them
>  all, pulling access control into VFS diminishes its generality in the
>  short term.

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

All that said, ideally I'd like the file-system to provide two
functions: one that checks if the operation is even possible (ie., if
write support does not exist, it doesn't matter if you're root) and
one that checks for real permissions access (without exceptions that
are based on secmodel assumptions: think uid/gid matching and that's
it). In that second function, the common vaccess() call can be for
file-systems without ACLs etc.

The flow then becomes: vnode_authorize -> fs_check_possible -> get
permissions decision from fs -> pass decision and context for final
ruling of secmodel. That way we don't force ourselves to create one
unified format (although that shouldn't be *too* hard :), we don't
lose file-system specific ACL decisions, and the secmodel gets the
final word (to make exceptions for root, take securelevel into
consideration, etc.) -- I really think that's a win-win, and am
willing to implement/document everything related to it, unless there
are reasons not to.

> - We have been discussing, and most of the interested parties agree, that we
>  should take some portion of concurrency and lifecycle management off VFS,
>  and put them back into the file systems. In that case VOP_ACCESS() would
>  exist primarily to service the access() system call. There would be no
>  immediate, cheap and easy way to ensure correct serialization across
>  multiple operations (use VOP_ACCESS() to check ok, perform operation).

Like I've stated, VOP_ACCESS() will no longer be used throughout the
code to make decisions, so serialization isn't an issue -- or at least
an isolated one.

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).
It's almost as bad as replacing returned error codes under their feet.
;)

Can you elaborate a bit on what implications that would have, for
example, on opening files? what will replace VOP_ACCESS() usage
throughout the kernel? or  tell a bit more about it in general?

Thanks,

-e.