Thus spake Pawel Jakub Dawidek <[EMAIL PROTECTED]>: > +> It sounds like you're trying to do something complicated with > +> chdir, and that could make things harder. First of all, you > +> should be comparing vnodes instead of pathnames when possible, in > +> order to avoid canonicalization bugs. Second, it only makes sense > +> to ask for the path of a directory vnode, since ordinary files can > +> have multiple hard links. For directories, you can get the full > +> path by walking up the '..' pointers, sort of like vn_fullpath(), > +> except that you have to do a lookup if something is missing from > +> the cache. I expect locking would be a pain as well. > > Yes, I know that already. Soon I'll send announce of what I'm doing, > for now I'll use my ugly way. > > Not always is chance to operate only on vnodes. When You (for example) > want to denied mode changes for some file, You can do this through catching > chmod(2), but when someone open this file how You get file name when You want > create policy rules for fchmod(2)? Remember that files could have temporary > names, so You can't compare vnode from file descriptor with some file that > You're expecting.
I'm telling you, you almost certainly will run into canonicalization problems unless you compare the vnodes, rather than the paths. Can't you just namei the paths in your policy rules and use the resulting vnodes to match relevant system calls? I'm not sure what you mean by ``temporary names''. Do you mean that your policy specification permits wildcards in any pathname component? In that case, you might have to hack the lookup routines to point to all the possible rule matches as you iterate down the pathname, so by the time you have a vnode, you also know what rules match. Scary. Keep in mind that if you're willing to bite the performance bullet, you may be able to implement a userland solution far more easily. http://www.cs.berkeley.edu/~daw/janus/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message