Pavel Machek wrote: > 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 > 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? 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? The path name is an ethereal convenience and once traversed has no bearing on the security state of the object. You need to change the semantics of Linux (and Unix) file systems for your concern to make any sense at all. -- 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
