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.) > > 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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