> From: Peter Jeremy [mailto:peter.jer...@alcatel-lucent.com] > > Whilst it's trivially easy to get from the file to the list of > directories containing that file, actually getting from one directory > to its parent is less so: A directory containing N sub-directories has > N+2 links. Whilst the '.' link is easy to identify (it points to its > own inode), distinguishing between the name of this directory in its > parent and the '..' entries in its subdirectories is rather messy
Oh. Duh. This should have been obvious from the moment you said '..' Given: There is exactly one absolute path to every directory. You cannot hardlink subdirectories into multiple parent locations. You can only hardlink files. Every directory has exactly one parent, and the parent inode number is already stored in every directory inode. Given: There is already the '..' entry in every directory. Which means it is already trivially easy to identify the absolute path of any directory, given that you know its inode number, and you have some method to open an arbitrary inode by number. Which implies it can only be implemented in kernel, or perhaps by root. (A regular user cannot open an inode by number, due to security reasons, the parent directories may block permission for a regular user to open that inode.) But the fact remains: No change to filesystem or inode structure is necessary, in order to quickly identify the absolute path of an arbitrary directory, when your initial knowledge is only the inode number of the directory. Therefore, it should be very easy to implement proof of concept, by writing a setuid root C program, similar to "sudo" which could then become root, identify the absolute path of a directory by its inode number, and then print that absolute path, only if the real UID has permission to "ls" that path. Fundamentally, the only difficulty is to extend inodes of files, to include a list of parent inode directories. And, how to make all this information available over NFS and CIFS. While not trivial, it's certainly possible to extend inodes of files, to include parent pointers. Also not trivial, it's certainly possible to make all this information available under proposed directories, ".zfs/inodes" or something similar. (Again, considering that the ".zfs/inodes" directory would be sufficient for NFS, but some more information would be necessary to support CIFS, because CIFS, as far as I know, has no knowledge of inode numbers, and therefore cannot even begin to look for an inode under the .zfs/inodes directory.) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
