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 19:33:12 +0300
On 10/13/07, Terry Lambert <email@hidden> wrote:
> On Oct 12, 2007, at 3:37 AM, Liviu Andron wrote:
> > 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.
>
>
> I'm actually unaware of any technical documentation from Apple that
> recommends reading or writing files from within the kernel. If you
> can point me at the documentation for this, I can grab the other
> members of the CoreOS kernel team, and we can go beat the author up.
> 8-).
ADC Home > Reference Library > Technical Notes > Darwin > Kernel
Technical Note TN2127
"Kernel Authorization"
"In this case the only correct solution is for the scanner to operate
entirely within the kernel."
> >>> - 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.
>
> KERN_INVALID_POLICY is a Mach error return code that generally only
> every gets seen when you attempt to select an unsupported scheduling
> policy for a mach task or mach thread.
>
> vn_getpath() on the other hand is a BSD function that only returns the
> result of a build_path(). Its possible return codes are:
>
> EINVAL
> ENOENT
> ENOSPC
>
> and the results of vnode_getattr() and of VFS_GET(). Since you are
> seeing 28, you are seeing:
>
> #define ENOSPC 28 /* No space left on device */
>
> ...which means that the buffer you have supplied to contain the path
> information you are requesting is too small. Use a correctly sized
> buffer, and the problem will go away. Most likely,you are only
> reserving sufficient space for the terminal path component, rather
> than the entire path to the file.
>
Sorry for the confusion, I should have imagined. I also did a
little research (
http://fxr.watson.org/fxr/source/bsd/vfs/vfs_cache.c?v=xnu-792.6.70#L134)
and now I understand. http://fxr.watson.org seems to be the best
kernel documentation, it's not Darwin 8.10, but I think it is close
enough since it includes kernel authorization.
So I have to do something like "while (ENOSPC == err) { size *=
2; <allocate size (a lot of memory)>; err = vn_getpath(....); }
>
> >>> 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.
>
> This is strongly discouraged, if you are talking about reading or
> writing files from the kernel.
Thanks for the answer. I don't need to try it then.
>
> -- Terry
>
_______________________________________________
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