| Hi all,
There seem to be some problems with KAUTH_FILEOP_LINK, KAUTH_FILEOP_DELETE and hard links. These results come from an HFS+ file system on OS X 10.6.7, 32 bit kernel.
KAUTH_FILEOP_DELETE on hard links to directories: [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% mkdir adir
[Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% mkdir adir/anotherdir
[Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% hlink adir/anotherdir link-anotherdir
[Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ls -l -i
total 8
19312680 drwxr-xr-x 3 chrisc wheel - 102 May 20 09:55 adir/
15658805 -rw-r--r--@ 1 chrisc wheel - 35 May 17 13:19 file1-xattr.txt
19312689 drwxr-xr-x 2 chrisc wheel - 68 May 20 09:55 link-anotherdir/
[Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ls -l -i adir
total 0
19312689 drwxr-xr-x 2 chrisc wheel - 68 May 20 09:55 anotherdir/
[Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% rmdir adir/anotherdir
[Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ls -l -i total 8 19312680 drwxr-xr-x 2 chrisc wheel - 68 May 20 09:56 adir/ 19312689 drwxr-xr-x 2 chrisc wheel - 68 May 20 09:55 link-anotherdir/ [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ls -l -i adir [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc%
The rmdir command generates the following KAUTH_FILEOP_DELETE information which I've logged in my kernel extension in my KAuth FileOp callback: 2011-05-20 09:56:57.865 TestStoreFuse[84256,0xb030b000] Trace Server: BoxMONServiceFSMon[0xd746000] INFORMATION: static int BoxMONListenerKAuthFileOp::CallbackListenerKAuthFileOp(ucred*, void*, kauth_action_t, uintptr_t, uintptr_t, uintptr_t, uintptr_t), BoxMONListenerKAuthFileOp.cpp{577}: KAUTH_FILEOP_DELETE: UID 501. PID 84281. VNode: 0x1a0c7e74. -> 0x20. PathName '/Users/chrisc/ChrisC_Life.Qweeg/tmp/test-BoxOS-monitor/native-attach/adir/link-anotherdir'
As you can see, KAUTH_FILEOP_DELETE has provided a non-existent path, referring to the second hard link's name, but in the first hard link's directory, even though the directory listing is correct. This is always repeatable, and does not seem to happen with hard links to files. The "hlink" program just calls link(2) like ln(1) but without the check that prevents the creation of a hard link on a directory that makes ln POSIX compliant.
KAUTH_FILEOP_LINK on hard links to files: [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% touch empty.txt [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ln empty.txt link1-empty.txt [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ls -l -i total 8 19317340 -rw-r--r-- 2 chrisc wheel - 0 May 20 10:23 empty.txt 19317340 -rw-r--r-- 2 chrisc wheel - 0 May 20 10:23 link1-empty.txt [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ln link1-empty.txt link2-empty.txt [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ls -l -i total 8 19317340 -rw-r--r-- 3 chrisc wheel - 0 May 20 10:23 empty.txt 19317340 -rw-r--r-- 3 chrisc wheel - 0 May 20 10:23 link1-empty.txt 19317340 -rw-r--r-- 3 chrisc wheel - 0 May 20 10:23 link2-empty.txt [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% rm empty.txt [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ln link1-empty.txt link3-empty.txt [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc% ls -l -i total 8 19317340 -rw-r--r-- 3 chrisc wheel - 0 May 20 10:23 link1-empty.txt 19317340 -rw-r--r-- 3 chrisc wheel - 0 May 20 10:23 link2-empty.txt 19317340 -rw-r--r-- 3 chrisc wheel - 0 May 20 10:23 link3-empty.txt [Qweeg:~/tmp/test-BoxOS-monitor/native-attach] chrisc%
The first ln command generates the correct KAUTH_FILEOP_LINK notification, but the second uses the wrong source path, and if the source path is deleted, a third attempt now generates a non-existent source path:
2011-05-20 10:24:02.667 TestStoreFuse[84619,0xb040f000] Trace Server: BoxMONServiceFSMon[0x129b83d4] INFORMATION: static int BoxMONListenerKAuthFileOp::CallbackListenerKAuthFileOp(ucred*, void*, kauth_action_t, uintptr_t, uintptr_t, uintptr_t, uintptr_t), BoxMONListenerKAuthFileOp.cpp{549}: KAUTH_FILEOP_LINK: UID 501. PID 84632. -> FSMON_ON_LINK_HARD. PathName '/Users/chrisc/ChrisC_Life.Qweeg/tmp/test-BoxOS-monitor/native-attach/empty.txt'. PathNameLink '/Users/chrisc/ChrisC_Life.Qweeg/tmp/test-BoxOS-monitor/native-attach/link1-empty.txt'
2011-05-20 10:24:23.074 TestStoreFuse[84619,0xb040f000] Trace Server: BoxMONServiceFSMon[0x1f238b7c] INFORMATION: static int BoxMONListenerKAuthFileOp::CallbackListenerKAuthFileOp(ucred*, void*, kauth_action_t, uintptr_t, uintptr_t, uintptr_t, uintptr_t), BoxMONListenerKAuthFileOp.cpp{549}: KAUTH_FILEOP_LINK: UID 501. PID 84635. -> FSMON_ON_LINK_HARD. PathName '/Users/chrisc/ChrisC_Life.Qweeg/tmp/test-BoxOS-monitor/native-attach/empty.txt'. PathNameLink '/Users/chrisc/ChrisC_Life.Qweeg/tmp/test-BoxOS-monitor/native-attach/link2-empty.txt'
2011-05-20 10:24:41.426 TestStoreFuse[84619,0xb040f000] Trace Server: BoxMONServiceFSMon[0x1ddc77a8] INFORMATION: static int BoxMONListenerKAuthFileOp::CallbackListenerKAuthFileOp(ucred*, void*, kauth_action_t, uintptr_t, uintptr_t, uintptr_t, uintptr_t), BoxMONListenerKAuthFileOp.cpp{577}: KAUTH_FILEOP_DELETE: UID 501. PID 84637. VNode: 0x171fdbc0. -> 0x10. PathName '/Users/chrisc/ChrisC_Life.Qweeg/tmp/test-BoxOS-monitor/native-attach/empty.txt'
2011-05-20 10:24:55.219 TestStoreFuse[84619,0xb040f000] Trace Server: BoxMONServiceFSMon[0xde1e7a8] INFORMATION: static int BoxMONListenerKAuthFileOp::CallbackListenerKAuthFileOp(ucred*, void*, kauth_action_t, uintptr_t, uintptr_t, uintptr_t, uintptr_t), BoxMONListenerKAuthFileOp.cpp{549}: KAUTH_FILEOP_LINK: UID 501. PID 84638. -> FSMON_ON_LINK_HARD. PathName '/Users/chrisc/ChrisC_Life.Qweeg/tmp/test-BoxOS-monitor/native-attach/empty.txt'. PathNameLink '/Users/chrisc/ChrisC_Life.Qweeg/tmp/test-BoxOS-monitor/native-attach/link3-empty.txt'
I'm not sure exactly how I did it, but with other combinations of ln and mv, I've managed to make KAUTH_FILEOP_LINK provide the same path twice - the destination - as well. I had a look in the kernel source code. You use vn_getpath() to get the source path EG: vfs_syscalls.c, line 3337, but the official documentation states that vn_getpath() can be unreliable.
KAUTH_FILEOP_SYMLINK: Please enable KAUTH_FILEOP_SYMLINK at vfs_syscalls.c, line 3492. Notification of symbolic link creation is useful.
Would you like me to file a bug report?
|