Hello!
The approach you described is obviously *valid* although it's rather
complicated compared to simply calling getxattr(). Another concern in
this case would be performance..
Hooking all open() calls of which only 20% shall be handled in a
different manner, and, for each open() call , communicating with
userspace is a bit too much of an overhead - that's why I'd still like
to use v_op.
On 7/26/07, Terry Lambert <email@hidden> wrote:
On Jul 25, 2007, at 4:52 AM, Standard Azi 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)
- open is trapped by a kauth module
- the kauth module send a message to a user space daemon that has
registered with the kauth module earlier so that the module knows
it's
there and alive
- the user space daemon looks at the extended attribute information,
and makes a decision
- if the user space daemon has to call any operations on the file
that
are trapped by the kauth module, then because it has registered with
the module, it's operations are simply permitted, rather than
recursively calling back out to user space
- the user space daemon igures out an answer
- the user spce daemon returns the answer to the kauth module
- the kauth module permits/denies the operation based on the answer
it
has received
> 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?
See above.
>> In almost every case, what you are trying to do should be
handled in
>> user space.
>
> I'd say this is an exception.
I'd say it wasn't; most work, particularly work that could take a
long
time or block things long enough that they get a spinny beach ball/
wheel of fortune/pizza of death/whatever you like to call the cursor
for an unresponsive application.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
This email sent to email@hidden
