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: Sun, 14 Oct 2007 20:37:04 +0300
On 10/13/07, Michael Smith <email@hidden> wrote:
>
> On Oct 11, 2007, at 6:05 AM, Liviu Andron wrote:
>
> > I have some troubles in accessing files from user space using
> > Kauth. Access means read or write.
>
> It is not clear from what you've written here exactly what you are
> trying to do.
>
> I am going to assume that you have a KAUTH filter and a user-space
> component that communicates with this filter. In the user-space
> component, you want to read/write files that are being seen by the
> filter.
Correct.
>
> > 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.
>
> As per Terry, I am not aware of any documentation that suggests you
> should be reading/writing files from within the kernel. It is highly
> discouraged.
Answered to Terry.
>
> > 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:
> > - 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
>
> As has been noted, vn_getpath operates on an arbitrary buffer supplied
> by the caller. If you make your buffer bigger on seeing this error,
> you should be OK.
>
> Note that the close callback is only called for the last close on a
> file.
Thanks for the last tip, but it isn't what I intended to say. I'll
try to post next days more information related to long paths.
>
> > 4) Another possible solution seems to be using VNOP_READ/
> > VNOP_WRITE in kernel space and transfer data to daemon
>
> This devolves to doing file I/O in the kernel again, which is still
> highly discouraged.
>
> = Mike
>
>
Look what I understand: implementing Kauth listeners (and I need
both fileop and vnode listeners) with the need to read/write from/to
files must be done by using the path in user space.( 1) no file I/O in
kernel 2) no way to provide a file descriptor to the user space).
Problems with the paths in user space:
1) maybe the path cannot be always retrieved
2) very long paths: technical problems when transferring them in
user space (large memory allocations, IODataQueue needs a limit) (I
just say it is difficult)
( anyway , the path isn't very interesting unlike reading/writing
from/to files)
3) (?) a file descriptor might be impossible to obtain if the vnode
is created with exclusive access ;
wait for the last CLOSE ? what about a shutdown ?
(the only way I see to avoid exclusivness is to read/write from
the initial vnode, but that's kernel)
I mentioned these problems in the second reply, first 2 can be
avoided with a file descriptor retrieved from the vnode in kernel,
which also can't be done.
Thanks for the help.
_______________________________________________
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