On Mon, 28 Sep 2009, Jamie Lokier wrote: > Miklos Szeredi wrote: > > BTW I just checked, and it is possible to re-open or promote an fd > > opened with O_NODE like this: > > > > char tmp[64]; > > > > fd = open(filename, O_NODE | O_NOACCESS); > > /* ... */ > > sprintf(tmp, "/proc/self/fd/%i", fd); > > fd_rw = open(tmp, O_RDWR); > > > > Now fd_rw is guaranteed to refer to the same inode as fd. > > If someone passes you a file descriptor opened with O_RDONLY, you > shouldn't be able to upgrade it to O_RDWR unless you have access to > the file and could do a normal open() on the file. > > I hope the above cannot convert O_NOACCESS to O_RDWR without checking > that you have access to the file. The permissions are checked on the inode at open. It doesn't matter how the inode came to be looked up, via a normal path or via a file descriptor in proc, the results are the same. > Hmm. I have just tried, and you _can _use open("/proc/self/fd/%d", > O_RDWR) to re-open with more permissions when you can't access the > path which /proc/self/fd/%d pretends to link to. It looks a bit > dubious, as you might have been passed an O_RDONLY descriptor with the > intention that you can't write to it... Oh well! True, /proc gives you access to the underlying "path" of an open file descriptor. If you don't want that, don't mount /proc in your limited namespace. 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