Re: Blocking file access within KAUTH
Re: Blocking file access within KAUTH
- Subject: Re: Blocking file access within KAUTH
- From: "Damir Dezeljin" <email@hidden>
- Date: Sun, 25 Nov 2007 16:19:45 +0100
Hi all,
Thanks once again for all the great help you provided. I did my testing and I'm back with the promised questions :)
Basically I bumped into two and a half issues :):
1. Hard links - path resolution
I'm considering implementing kind of exclude directory filtering in kernel itself. I guess this would help lower the overhead until when the 'filtering code' is small and fast as this will reduce kernel <-> user communication by > 50%. The problem are hard links:
I created p1.src as a regular file in a directory I'm scanning (is not excluded). Than I created two hard links to this file (p2.src.hrd and p3.src.hrd) in the same directory. Afterwards I moved the p2.src.hrd to an excluded directory. By doing this I was not getting any notification for the other two hard links (well, the original file and one hard link) that were still in a not-excluded directory. So, suppose the excluded directory is /test/excluded. Doing 'cat /test/excluded/p2.src.hrd' doesn't trigger a notification.
After some more investigation I found out the vnode_vfsname() always resolves to the last modified hard link (or original file) instance. I found such a behavior a bit bizarre; however, I'm sure there should be a good reason for this (name resolving cache?).
Is there any way to workaround this problem -> so to get the actual path of the file (hard link) that was accessed?
2. Denial hard link creation
Is there a way to prevent creation of hard links -> heh, this would be a dirty work around for the first case :)
3. File movements
This is my KEXT debug trace of a 'mv /test/p1.src /test/p1.src.renamed':
----
DELETE on file '/test/p2.src.hdr'
READ_ATTRIBUTES READ_SECURITY on file '/test/p1.src.renamed'
READ_DATA on file '/test/p1.src.renamed'
READ_ATTRIBUTES READ_SECURITY on file '/test/p1.src.renamed'
READ_ATTRIBUTES on file '/test/p1.src.renamed'
READ_ATTRIBUTES on file '/test/p1.src.renamed'
READ_DATA on file '/test/p1.src.renamed'
----
I'm confused and concerned about "READ_DATA on file '/test/p1.src.renamed'" outputs. Does a move (rename) operation really need to read the new file data. Is there an easy way to distinguish renames from normal file access (reading)? Well, I know the KAUTH_SCOPE_FILEOP offers a mechanism to get notified of renames; however as I understood, the KAUTH_SCOPE_VNODE authorization operations happen before the FILEOP and so I see no way to pass thru renames and process (and if needed block) only really data access requests. Any hint?
Thanks again,
Damir
_______________________________________________
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