On 24.10.2009 10:47, Anton Ivanov wrote:
I didn't affirm that. I only told, that directory permissions can't in fact restrict access to the file it contains, they can only hamper accessing that file via that directory.Following your logic we should all abandon directory permissions and stick to file-only ones. Hmm... Dunno, probably the blood level in my coffee subsystem is too high this morning, but I do not quite relish that idea.
If the application sets wrong permissions on files, it is by definition broken. Yes, setting more restrictive directory permissions can to some extent mitigate the problem, but not really fix it. What if that application is used by multiple users? The problem raised in the original mail is to some extent artificial, as the only users able to access /proc/<PID>/fd/ are the user with the same UID, as the process EUID, and root, and if the process is either setuid or setgid, /proc/<PID>/fd of that process is accessible only by root. Not to tell about that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't understand, how the original reporter managed to gain access to the file in the restricted directory using that symlink.There is a very valid case of trying to restrict access via directory permissions. Suppose you have a binary program that uses its own directory but for whatever reason keeps scribbling in files with wrong permission in it. While I cannot think of a current example, out of the older ones at least one of the Word Perfect versions for linux used to do that. By tightening up the protection on the directory the sysadmin can mitigate the problem. It is in fact the standard way of doing this.
-- Sincerely Your, Dan.