On Thu, 5 Nov 2009, Alan Cox wrote: > The examples on the list are not entirely theoretical but based on > accepted and normal behaviour for application programming and Unix > security models -so they are a security bug, minor or otherwise. > > Fortunately you can patch it by hand. How do you patch it by hand? > > And as for reopening O_NODE files with increased permission: that's > > feature people actually expressed interest in, so it's hardly a > > security hole, is it? > > Its a very unexpected semantic particularly for a passed file handle. All of this is about new and unexpected semantics. I don't think anything more needs to be done than document it in the manpage: "A file descriptor opened with O_NODE | O_NOACCESS may be used to re-open the same file later with increased permissions (e.g. O_RDWR) if the access mode allows. This is true even if the permissions on the path leading up to the file would prevent it" > > > Wrong way around. The defailt should be that O_NODE fails for any handle > > > which has not specifically added support. > > > > Why? O_NODE can be nicely implemented without any filesystem support. > > So that you audit the behaviour for unexpected surprises as you go. And > in most filesystem cases that consists of "dum de dum, nothing to see, > add default handler, tick". > > But that isn't the case for some things - consider CIFS and other network > file systems. Why? Why would the server need to know anything about that? O_NODE is similar to a chdir() in this respect, and chdir doesn't have a handler either. > > > You also need to address the open with no permissions pinning a removable > > > device question. > > > > The whole point of O_NODE is that it doesn't do that, it only goes as > > far as the mnt/dentry for the filesystem node and not further. It > > does not get to touch the device at all, so it can't pin it or have > > any other side effect. > > You have a reference to the mnt/dentry pinned so how will you unmount the > volume ? Oh, I see what you are getting at. So the situation is this: the root of the volume does not allow any access to the user, so normal open/chdir won't work. Yet open(O_NODE) will and so user can pin the volume. However, there's not all that much difference between the above and doing "stat()" on the mountpoint in a tight loop, except the former is a more reliable way to prevent unmounting. I don't see this as a huge issue, but ideas about handling it better are welcome. Thanks, Miklos -- 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
