> > 0700 mode from the origin, you would be right, and procfs wouldn't allow > > opening files in that directory too, but if you let others to traverse > > that directory and open your believed to be secure files from the origin, > > it's your fault. > > I can do the example with fd passing and 700 directory, but it would > be lot of C code. Feel free to play, my example was not nearly the > only way to demonstrate it, and no, it was not racy. Here is an example that shows the behavior where a passed read-only fd can become read-write by reopening it through /proc, when file permissions allow it (but directory permissions do not): $ sudo su # mkdir -m 0700 /dir # echo "safe" > /dir/file.txt # chmod 0666 /dir/file.txt # ls -al /dir total 12 drwx------ 2 root root 4096 2009-10-29 00:28 . drwxr-xr-x 27 root root 4096 2009-10-29 00:28 .. -rw-rw-rw- 1 root root 7 2009-10-29 00:43 file.txt # cat /dir/file.txt safe Now user "nobody" cannot read or write this file: # su nobody -c 'cat /dir/file.txt' sh: /dir/file.txt: Permission denied # su nobody -c 'echo "hacked" > /dir/file.txt' sh: /dir/file.txt: Permission denied # cat /dir/file.txt safe If we provide an open read-only file descriptor (as stdin, fd 0), they can read it: # su nobody -c 'cat <&0' < /dir/file.txt safe But they still can't write to this descriptor: # su nobody -c 'echo "hacked" >&0' < /dir/file.txt sh: line 0: echo: write error: Bad file descriptor Unless we re-open the file using the magic link in /proc: # su nobody -c 'echo "hacked" >/proc/self/fd/0' < /dir/file.txt # cat /dir/file.txt hacked Again, debatable whether this is a bug, but it's certainly non-obvious. There is no other way (that I'm aware) for the "nobody" user to gain write access to /dir/file.txt, even when given a read-only fd, without using /proc. -jim
