On Nov 29, 2005, at 9:26 AM, Oliver Donald wrote:
Thanks for the clarification! I found most of this out myself reading the docs more carefully, but I was still interested to hear why the FILEOP scope was only for notification.
The fundamental reason is that KAUTH_SCOPE_VNODE callouts are performed for operations for which explicit authorisation was traditionally required.
All other operations, including many of those for which KAUTH_SCOPE_FILEOP callouts are made, are implicitly authorised. As Terry notes, the KAUTH_SCOPE_FILEOP callout was added as a concession to folks that need a fast, inline notification of certain related filesystem operations; it is not particularly architecturally clean and only uses the kauth infrastructure because it was convenient at the time.
Permitting handlers being called for these operations to deny them would have required introducing the concept of revocation to many existing interfaces.
= Mike
At 10:29 +0000 29/11/05, Oliver Donald wrote:
But my main question is, why does the KAUTH_SCOPE_FILEOP scope not allow me to deny?
That's just the way it's designed. KAUTH_SCOPE_FILEOP is for notification, KAUTH_SCOPE_VNODE is for checking.
Is there any chance of this being implemented in the future?
No.
My second plan would be to use the KAUTH_SCOPE_VNODE scope, but this is too late,
Why do you say that? Vnode scope authorization is requested when the file is opened, not for each individual read or write (that would be /way/ too expensive). A vnode scope listener is the correct place to add extra security checks. In fact, the default listener for the vnode scope is responsible for implementing the system's built-in permissions checking.
S+E
--
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden