Re: Kernel authorization (Kauth) from user space
Re: Kernel authorization (Kauth) from user space
- Subject: Re: Kernel authorization (Kauth) from user space
- From: "Liviu Andron" <email@hidden>
- Date: Fri, 12 Oct 2007 13:37:38 +0300
On 10/11/07, Jernej Azarija <email@hidden> wrote:
>
> > 1) The recommended way from the technical documentation is to read/write
> in
> >kernel, but all the mailing lists discussions say to do it in user space.
> In userspace? It depends on what you need to accomplish.
I need to read and/or write from/to files in both fileop scope and
vnode scope listeners.
>
> > 2) Assuming that I send the path from kernel to the user space daemon
> >(returned by vn_getpath from the vnode parameter) , I have the following
> >issues:
>
> Actually, one of the kauth hook function arguments is the relevant path
> name -
> you just have to cast it to (char *).
>
>
> > - for files with paths longer than MATXPAHTLEN (1024) , which can
> be
> >created with Finder:
> > - vn_getpath returns error 28 (KERN_INVALID_POLICY)
> > - the callback for OPEN/CLOSE actions is called with empty
> >path (arg1) or it's not called at all
>
> Use the supplied path as said. You'll only have to play about transfering
> the path to userspace.
In the vnode listener you have no path. Please read all the message.
>
> > 4) Another possible solution seems to be using VNOP_READ/VNOP_WRITE in
> >kernel space and transfer data to daemon
>
> If you only need to hook open/close, use KAUTH_SCOPE_FILEOP. It's not
> reasonable to hook VNODE operations - at last from the performance view.
I don't want to hook the operations, I want to use them for read or
write from/to files.
Opening a path in user mode is ok if the paths can be always retrieved
(vn_getpath or listener argument), are limited and the userland's open
doesn't have problems with exclusive accesses.
If not then a different approach is needed, the points 3) and 4) from
the initial post are possible solutions. Or maybe there's another one
!?
Thanks,
Liviu
_______________________________________________
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