Pavel Machek wrote: > On Mon 2009-10-26 14:22:16, Trond Myklebust wrote: > > On Sun, 2009-10-25 at 10:36 +0100, Pavel Machek wrote: > > > Well, it is unexpected and mild security hole. > > > > > > Part of the problem is that even if you have read-only > > > filedescriptor, you can upgrade it to read-write, even if path is > > > inaccessible to you. > > > > > > So if someone passes you read-only filedescriptor, you can still write > > > to it. > > > > If someone passes you a file descriptor, can't you in any case play > > games with, openat(fd,"",O_RDWR), in order to achieve the same thing? I > > must admit I haven't tried it yet, but at a first glance I can't see > > anything that prevents me from doing this... > > According to my documentation, openat needs directory fd. Correct. There has been something about fstatat() and similar allowing a non-directory when passed a NULL path, but openat() does not. (It's probably ok to extend openat() to allow a NULL path, if it does the equivalent of re-opening /proc/self/fd/NN). I think this whole issue is neatly solved by enforcing the file access mode for open(/proc/PID/fd/NN) to be a safe subset of the original file access mode. It should use the original file access mode so that O_APPEND can be enforced too. Checking symlink permissions wouldn't do that. Anything you can change with fcntl(F_SETFL) is fair game for changing. The ptrace permission check is nice, but even with ptrace you can't convert a read-only descriptor to a writable one (or write-only to readable, or append-only to writable, etc.) -- 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
