On Dec 06, 2006 15:17 -0700, Matthew Wilcox wrote: > On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote: > > Considering that filesystems like GFS and OCFS allow clients DIRECT > > ACCESS to the block device itself (which no amount of authentication > > will fix, unless it is in the disks themselves), the risk of passing a > > file handle around is pretty minimal. > > That's either disingenuous, or missing the point. OCFS/GFS allow the > kernel direct access to the block device. openg()&sutoc() are about > passing around file handles to untrusted users. Consider - in order to intercept the file handle on the network one would have to be root on a trusted client. The same is true for direct block access. If the network isn't to be trusted or the clients aren't to be trusted, then in the absence of strong external authentication like kerberos the whole thing just falls down (i.e. root on any client can su to an arbitrary UID/GID to access files to avoid root squash, or could intercept all of the traffic on the network anyways). With some network filesystems it is at least possible to get strong authentication and crypto, but with shared block device filesystems like OCFS/GFS/GPFS they completely rely on the fact that the network and all of the clients attached thereon are secure. If the server that did the original file open and generates the unique per-open file handle can do basic sanity checking (i.e. user doing the new open is the same, the file handle isn't stale) then that is no additional security hole. Similarly, NFS passes file handles to clients that are also used to get access to the open file without traversing the whole path each time. Those file handles are even (supposed to be) persistent over reboots. Don't get me wrong - I understand that what I propose is not secure. I'm just saying it is no LESS secure than a number of other things which already exist. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
