Two questions: KAUTH filename discovery on creation and process "coloring"
Two questions: KAUTH filename discovery on creation and process "coloring"
- Subject: Two questions: KAUTH filename discovery on creation and process "coloring"
- From: Misha Pak <email@hidden>
- Date: Thu, 13 Feb 2014 20:48:18 +0200
Guys
1. KAUTH:
We've been trying in vain to discover an easy method of capturing a specific file creation in a certain folder. It seems (from reading the XNU sources) that when a new file is added, the kauth callback is called BEFORE the vnode's creation and hence the new filename is not passed to the callback, just the original folder where I wanted my file to be created (it seems, though, that the kernel developers COULD have passed the file name since it is known when the vnode_authorize() call is made...)
Apparently this totally disables the ability to discriminate between file names. I need to be able to block the ability to create files with a certain pattern in their name, while allowing others.
Is there still any way I can get the newly created file name in KAUTH_VNODE_ADD_FILE scenario?
2.
(Not KAUTH related):
Is there any way my driver can distinguish between two different processes, both of whom being fork()-ed from a single parent and NO "execve" has been done? I need to be able to fork a process several times and some of the forks should be treated differently by my driver from other forks.
In other words, is there any method I can do something after the fork, which will be able to distinguish ("color" in our terms) between the two processes in my driver without changing their text?
I prefer NOT to use any ioctls or use the socket APIs and therefore, I was looking for some method to set a global variable after the fork and then, from within my driver, read its contents. I found absolutely no easy way of doing it apart from using "mlock"ed areas which turned out to be cumbersome (unless I miss something, and perhaps I will have to resort to this anyway)
Conversely, I tried looking at the "proc" struct, and see which fields can be controlled from user-space which will be readable in my driver. Apart from doing tricks with sigsets, I didn't find any "stateless" method of doing that.
Anyone has ideas?
Thanks a lot in advance!
Misha.
_______________________________________________
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