Casey Schaufler wrote: > Pavel Machek wrote: > > The actual permissions of the file are not ignored, but permissions of > > the containing directory _are_. If there's 666 file in 700 directory, > > you can reopen it read-write, in violation of directory's 700 > > permissions. > > Pavel > > There is no security violation here. Consider the case where > the file is unlinked after it is opened. What directory permissions > would matter in that case? That's an even worse security violation. If you have a file opened read-only which is unlinked (and there's no other file descriptors to it), it is impossible to modify the file except through this quirk of /proc/NN/fd. In traditional unix, it is impossible to modify full stop. Even root can't write to it. Paths are in this discussion as an *example* of something that cannot be done except through /proc/NN/fd. Paths are not the issue. As you've noticed, the same security hole occurs for files which have been unlinked and don't have any path. The real issue is gaining more access to an open file than you had before. > Or what about the case where the file > has a link count of 2, say /a/foo and /b/ish are hard links. If > /a is 777 and /b is 700 what would your position be regarding > the file descriptor obtained by opening /b/ish? It depends on the flag passed to open() when the file descriptor is obtained. That's where the pseudo-symlink permission comes from, which is what Pavel is getting it. > The path name is an ethereal convenience and once traversed has no > bearing on the security state of the object. That's right. The security state should depend _only_ on the file open mode, that is O_RDONLY/WRONLY/RDWR/APPEND. That is more or less what Pavel is saying too, because the pseudo-symlink permission is calculated from the file open mode (except for O_APPEND, which is why it shouldn't be done using the pseudo-symlink permission). Ignore the path aspect, it's just a distraction. -- Jamie -- 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
