Bug 60676

Summary: Stat system call gives permission denied to root for links under a sticky bit
Product: File System Reporter: James Kolb (jck)
Component: ext4Assignee: fs_ext4 (fs_ext4)
Status: RESOLVED INVALID    
Severity: normal    
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.5.0 Subsystem:
Regression: No Bisected commit-id:

Description James Kolb 2013-08-01 15:02:36 UTC
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.
Comment 1 Theodore Tso 2013-08-01 15:55:00 UTC
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
Comment 2 James Kolb 2013-08-01 18:19:08 UTC
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.
Comment 3 Theodore Tso 2013-08-02 00:44:35 UTC
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
Comment 4 James Kolb 2013-08-02 14:34:36 UTC
That makes sense. Thanks! It looks like the man pages just need to be updated.