Hi! > >> > 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. Please see the bugtraq discussion. It works even if you would not have permission to write to it with /proc unmounted. > >> 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. So, there's "surprise" that gives _you_ write access to my files. You agree that it is surprising, and you would not have write access to my file if /proc was not mounted. Call it "security surprise" if you prefer. But many people call it "security hole". > Do you know of any cases where this difference matters in practice? No. Do you have a proof that it does not matter anywhere? > 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. Unix compatibility? 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
