On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote: > > While it could do that, I'd be interested to see how you'd construct > > the handle such that it's immune to a malicious user tampering with it, > > or saving it across a reboot, or constructing one from scratch. > > If the server has to have processed a real "open" request, say within > the preceding 30s, then it would have a handle for openfh() to match > against. If the server reboots, or a client tries to construct a new > handle from scratch, or even tries to use the handle after the file is > closed then the handle would be invalid. > > It isn't just an encoding for "open-by-inum", but rather a handle that > references some just-created open file handle on the server. That the > handle might contain the UID/GID is mostly irrelevant - either the > process + network is trusted to pass the handle around without snooping, > or a malicious client which intercepts the handle can spoof the UID/GID > just as easily. Make the handle sufficiently large to avoid guessing > and it is "secure enough" until the whole filesystem is using kerberos > to avoid any number of other client/user spoofing attacks. That would be fine as long as the file handle would be a kernel-level concept. The issue here is that they intent to make the whole filehandle userspace visible, for example to pass it around via mpi. As soon as an untrused user can tamper with the file descriptor we're in trouble. - 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
