Re: Classify VNODE SCOPE actions for file operations
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com
I think this discussion is probably moot anyway because even if you get a name, you can't depend on using it to find a vnode again (consider renaming, deleting, etc). You could use it for logging purposes I suppose.
Well, if you wanted to make a kauth decision based on the name (which I admit is a bit weird to me, but hey, whatever), then you could use it at that time. The original poster wasn't exactly specific on what they were interested in doing.
True for KAUTH_VNODE_ADD_FILE - you have different combos of vnodes depending on the real operation. The vfs may not be trying to create a file at all - see access1, rename.
I guess it really should be labelled "ADD_FILE_TO_DIRECTORY".
I don't know about all filesystems, but HFS, Apple's SMB , Thursby's CIFS vfs return it. NFS doesn't, but I would bet that AFP does. I know va_name is used by coreservicesd, and is how FSGetCatalogInfo calls get the name.
Sure, but getattrlist_internal() will simply use vnode_getname() if the underlying VNOP_GETATTR() doesn't return anything for va_name. My point is that you can't rely on it; I guess to be portable, you should try seeing if the filesystem returns va_name and if it doesn't then you should fall back on vnode_getname(). Although from private conversatons I've had with Apple people, they hinted that vnode_getname() was actually pretty reliable. --Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com
participants (1)
-
Ken Hornstein