If a directory has a sticky bit set, root cannot use anything that makes the stat system call on any of the links there. Example: > $ ls -ld /tmp/ > drwxrwxrwt 17 root root 4825088 Aug 1 10:50 /tmp/ > $ mkdir /tmp/testdir > $ touch /tmp/testdir/testfile > $ ln -s /tmp/testdir/ /tmp/testlink > $ ls /tmp/testlink/ > testfile > $ su > # ls /tmp/testlink ls: cannot access /tmp/testlink: Permission denied > # ls /tmp/testdir > testfile I can see how having root blindly follow links in a sticky directory could be a bad idea, but this goes against the behavior described by the man pages.
On Thu, Aug 01, 2013 at 03:02:36PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > > If a directory has a sticky bit set, root cannot use anything that makes the > stat system call on any of the links there. > > Example: > > $ ls -ld /tmp/ > > drwxrwxrwt 17 root root 4825088 Aug 1 10:50 /tmp/ > > $ mkdir /tmp/testdir > > $ touch /tmp/testdir/testfile > > $ ln -s /tmp/testdir/ /tmp/testlink > > $ ls /tmp/testlink/ > > testfile > > $ su > > # ls /tmp/testlink > ls: cannot access /tmp/testlink: Permission denied > > # ls /tmp/testdir > > testfile Works for me: <tytso.root@lambda> {/tmp}, level 2 509# ls -aldg /tmp 0 drwxrwxrwt 18 root 1840 Aug 1 11:10 /tmp/ <tytso.root@lambda> {/tmp}, level 2 510# stat /tmp/testdir File: tmp/testdir' Size: 60 Blocks: 0 IO Block: 4096 directory Device: 12h/18d Inode: 3290419 Links: 2 Access: (0700/drwx------) Uid: (15806/ tytso) Gid: (15806/ tytso) Access: 2013-08-01 11:10:01.141462969 -0400 Modify: 2013-08-01 11:09:53.301463057 -0400 Change: 2013-08-01 11:10:51.261462406 -0400 Birth: - <tytso.root@lambda> {/tmp}, level 2 511# stat /tmp/testfile File: tmp/testfile' -> stdir/testfile' Size: 16 Blocks: 0 IO Block: 4096 symbolic link Device: 12h/18d Inode: 3288475 Links: 1 Access: (0777/lrwxrwxrwx) Uid: (15806/ tytso) Gid: (15806/ tytso) Access: 2013-08-01 11:10:04.701462929 -0400 Modify: 2013-08-01 11:10:03.691462941 -0400 Change: 2013-08-01 11:10:03.691462941 -0400 Birth: - <tytso.root@lambda> {/tmp}, level 2 512# uname -a Linux lambda 3.11.0-rc2-00261-g316da4e #50 SMP Fri Jul 26 08:41:29 EDT 2013 x86_64 GNU/Linux <tytso.root@lambda> {/tmp}, level 2 513# I suspect you are using SELinux? (You have a security problem. So you install SELinux; now you have 6+ megabytes worth of problems when you try to decipher the SELinux policy definitions. :-) - Ted
The stat command (stat(1)) works on the link itself (but you can't go further down the filesystem hierarchy). So, in my previous example, calling "stat /tmp/testlink" and "stat /tmp/testdir/testfile" both work, but "stat /tmp/testlink/testfile" gives a permission error if you are root: > stat: cannot stat `/tmp/testlink/testfile': Permission denied The glibc stat function (stat(2)) does not even work on the link itself. I'm not using SELinux.
On Thu, Aug 01, 2013 at 11:21:16AM -0700, Christoph Hellwig wrote: > Try reverting 800179c9b8a1e796e441674776d11cd4c05d61d7 Or just do: echo 0 > /proc/sys/fs/protected_hardlinks echo 0 > /proc/sys/fs/protected_symlinks (or put the equivalent in /etc/sysctl.conf). There is a **very** detailed description of the design decision behind this change (which went in as of 3.6) in the commit description. See: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7 In any case, it's "working as designed". - Ted
That makes sense. Thanks! It looks like the man pages just need to be updated.