Pavel Machek <pavel@xxxxxx> writes: > On Tue 2009-10-27 21:15:54, Eric W. Biederman wrote: >> Pavel Machek <pavel@xxxxxx> writes: >> >> > On Mon 2009-10-26 13:57:49, Trond Myklebust wrote: >> >> On Mon, 2009-10-26 at 18:46 +0100, Jan Kara wrote: >> >> > That's what I'd think as well but it does not as I've just learned and >> >> > tested :) proc_pid_follow_link actually directly gives a dentry of the >> >> > target file without checking permissions on the way. >> > >> > It is weider. That symlink even has permissions. Those are not >> > checked, either. >> > >> >> I seem to remember that is deliberate, the point being that a symlink >> >> in /proc/*/fd/ may contain a path that refers to a private namespace. >> > >> > Well, it is unexpected and mild security hole. >> >> /proc/<pid>/fd is only viewable by the owner of the process or by >> someone with CAP_DAC_OVERRIDE. So there appears to be no security >> hole exploitable by people who don't have the file open. > > Please see bugtraq discussion at > http://seclists.org/bugtraq/2009/Oct/179 . > > (In short, you get read-only fd, and you can upgrade it to read-write > fd. Yes, you are the owner of the process, but you are not owner of > the file the fd refers to.) Assuming you have permission to open it read-write. >> > 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. >> >> Openly if you actually have permission to open the file again. The actual >> permissions on the file should not be ignored. > > 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. I can see how all of this can come as a surprise. However I don't see how any coder who is taking security seriously and being paranoid about security would actually write code that would have a problem with this. Do you know of any cases where this difference matters in practice? It looks to me like it has been this way for better than a decade without problems so there is no point in changing it now. Eric -- 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
