Re: Using VFS operations for a given nod
Re: Using VFS operations for a given nod
- Subject: Re: Using VFS operations for a given nod
- From: "Standard Azi" <email@hidden>
- Date: Thu, 26 Jul 2007 09:48:18 +0200
Hello,
On 7/26/07, Michael Smith <email@hidden> wrote:
When you say "holds some meaningful data for the kernel", I assume
that what you mean is that it holds some meaningful data for your
decision-making code.
Correct.
You haven't given any sort of criteria here to work with, so of
course I can't answer you.
That's true, but I can't get too much into detail for now - I hope
you understand.
If there was KPI exposed for reading extended attributes, then yes.
Unfortunately there is no such KPI exposed, and so you're in a
position where you will have to ship your operation out to user space.
As I've already mentioned in another reply related to this message, the
main concern with userspace is *performance*. Hooking KAUTH_SCOPE_FILEOP
is already a performance issue per se. Now imagine communicating with userland
for each open() call, and acting differently in only 20-30% of cases.
That's why the application design at the moment communicates with userland
only when we find the specific attribute set.
Sometimes you have to give a higher priority to performance omitting clever
design. (and, don't think I like that).
I would, however, also file an enhancement request at
bugreporter.apple.com asking for an interface to do what you want
inside the kernel. In your case, providing you're only trying to
operate on the file that's the object of the authorisation operation,
you're right - your case is a legitimate exception.
Well, if that's all that it has to be done, I could simply implement that
KPI thing by myself and then try to put it in the bug report as a patch
proposal. (it works that way in the Linux world :-) ). I'd only have to
be given a few pointers on where to proceed.
Thanks for your constructive help!
On 7/26/07, Michael Smith <email@hidden> wrote:
On Jul 25, 2007, at 12:04 PM, email@hidden wrote:
>> As a general rule, if you think you want to initiate operations on
>> files, file attributes, pathnames etc. from the kernel you have made
>> a design error and need to stop and re-evaluate what you are doing.
>
> That's usually true although I don't see any other method that is more
> elegant - maybe you do, so let me explain what I'm trying to do :
>
> ===
> - open() is hooked with Kauth
>
> - if there is some special extended attribute set on the opening file,
> handle some security issues before returning a file descriptor, else,
> return the proper fd.
> ===
>
> Do you see any other way to keep track of the files handled by the
> security module? (please note that the extended attribute holds some
> meaningful data for the kernel)
When you say "holds some meaningful data for the kernel", I assume
that what you mean is that it holds some meaningful data for your
decision-making code.
> Sure, now we can question about the purpose of the security module,
> why it has to rely on userspace data, etc... but focusing on the
> approach I've described, do you see any other solution to keep track
> about which files to handle in a special manner?
You haven't given any sort of criteria here to work with, so of
course I can't answer you.
>> In almost every case, what you are trying to do should be handled in
>> user space.
>
> I'd say this is an exception.
If there was KPI exposed for reading extended attributes, then yes.
Unfortunately there is no such KPI exposed, and so you're in a
position where you will have to ship your operation out to user space.
I would, however, also file an enhancement request at
bugreporter.apple.com asking for an interface to do what you want
inside the kernel. In your case, providing you're only trying to
operate on the file that's the object of the authorisation operation,
you're right - your case is a legitimate exception.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden