Pawel Jakub Dawidek wrote: [ ... obtaining file names from open file instances ... ]
> But as You can see, now, if I want to get functionaly what I want, > I need to be _very_ nasty (and evil of course):) There are a lot of bad reasons to do this, and a few good reasons, most of which are really hard to justify. If this were my job to do, I would either take the approach of changing how hard links and vmobject_t references are implemented, or I would disallow hard links, and add a "parent inode" field in one of the spare fields in each inode. If you did either one of these, then you chould always ask the open file for the vnode, and add a VOP that took the vnode, got the inode, amd then traversed to the root, looking in the parent for the inode of the object itself. Basically, you could always find the one and only path to any object. > This could be useful in a future, for example in MAC functionality. You claim this, but it's not true, unless you disallow aliases, and you can only do that by disallowing hard links on files, or by making hard links into FS objects, instead of having them merely be entries in a directory. IMO, this is not useful for an application for Mandatory Access Controls unless you change the way hard links happen, because if I can subvert it, other people can, too. > So I'm not able to create policy rules based on filenames. That's precisely correct: you are unable to create policy rules based on file names, because file names are references to files, and are not themselves file insteances. This is not FAT32, where there is a 1:1 identity relationship between a directory entry and an inode. And that's the origin of your problem. The place I personally would use "knowing the path to an open file instance", FWIW, is in a "resume from suspend to disk" software; that's much more useful, and it doesn't have to care about the inherited rights problems that happen because of hard links -- it only needs *a* path, as opposed to needing *the* path. The way you are proposing to use this, however, needs *the* path -- just having *a* path is not good enough. In any case, the directory name lookup cache is not the place to get the path information, or keep it, for that matter; a device/inode pair, component name, and vnode reference, which is the only object for which names may be cached in that cache, is not sufficient to uniquely identify *the* path to a file, only to identify *a* path. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
