I finally got it, I think. Somebody (with deep and intimate knowledge of ZFS development) please tell me if I've been hitting the crack pipe too hard. But .
Part 1 of this email: Netapp snapshot security flaw. Inherent in their implementation of .snapshot directories. Part 2 of this email: How ZFS could do this, much better. (#1) Netapp snapshot security flaw. Inherent in their implementation of .snapshot directories. (as root) # mkdir -p a/b/c # echo "secret info" > a/b/c/info.txt # chmod 777 a # chmod 700 a/b # chmod 777 a/b/c # chmod 666 a/b/c/info.txt # rsh netappfiler snap create vol0 test creating snapshot... # echo "public info" > a/b/c/info.txt # mv a/b/c a/c (as a normal user) $ cat a/c/info.txt public info $ cat a/c/.snapshot/test/info.txt secret info D'oh!!! By changing permissions in the present filesystem, the normal user has been granted access to restricted information in the past. (#2) How ZFS could do this, much better. First let it be said, ZFS doesn't have this security flaw. (Kudos.) But also let it be said, the user experience of having the .snapshot always conveniently locally available, is a very positive thing. Even if you rename and move some directory all over the place like crazy, with zillions of snapshots being taken in all those locations, when you look in that directory's .snapshot, you still have access to *all* the previous snapshots of that directory, regardless of what that directory was formerly named, or where in the directory tree it was linked. In short, the user experience of .snapshot is more user friendly. But the .zfs style snapshot requires less development complexity and therefore immune to this sort of flaw. So here's the idea, in which ZFS could provide the best of both worlds: Each inode contain a link count. In most cases, each inode has a link count of 1, but of course that can't be assumed. It seems trivially simple to me, that along with the link count in each inode, the filesystem could also store a list of which inodes link to it. If link count is 2, then there's a list of 2 inodes, which are the "parents" of this inode. In which case, it would be trivially easy to walk back up the whole tree, almost instantly identifying every combination of paths that could possibly lead to this inode, while simultaneously correctly handling security concerns about bypassing security of parent directories and everything. Once the absolute path is generated, if the user doesn't have access to that path, then the user simply doesn't get that particular result returned to them. It seems too perfect and too simple. Instead of a one-directional directed graph, simply make a bidirectional. There's no significant additional overhead as far as I can tell. It seems like it would even be easy. By doing this, it will be very easy for zhist (or anything else) to instantly produce all the names of all the snapshot versions of any file or directory, even if that filename has been changing over time . even if that file is hardlinked in more than one directory path . Then ZFS has a technique, different from ".snapshot" directories, which perform more simply, more reliably, more securely than the netapp implementation. This technique works equally well for files or directories (unlike the netapp method.) And there is no danger of legal infringement upon any netapp "invention."
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
