Re: Kernel authorization (Kauth) from user space
Re: Kernel authorization (Kauth) from user space
- Subject: Re: Kernel authorization (Kauth) from user space
- From: Terry Lambert <email@hidden>
- Date: Fri, 12 Oct 2007 15:00:02 -0700
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-).
- 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.
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.
-- 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