Re: bug in [ -f file ] test

[Chet Ramey]

On 7/26/16 5:07 PM, László Házy wrote:
> Hmm, interesting. I can reproduce your results. Thanks.
> However, note the following:
> 
> [user1]$ chmod g+rx /home/user1
> [user1]$ touch file; ls -l file
> -rw-r--r--. 1 user1 users    0 Jul 26 15:24 file
> 
> [user1]$ su user2 -c "ln -s /home/user1/file /var/tmp/link"
> [user1]$ ls -l /var/tmp/link
> lrwxrwxrwx. 1 user2 users 17 Jul 26 15:26 /var/tmp/link -> /home/user1/file
> 
> [user1]$ [[ -f /var/tmp/link ]]; echo $?
> 1
> 
> [user1]$ su user2
> [user2]$ [[ -f /var/tmp/link ]]; echo $?
> 0
> 
> Something does not add up.
> From experimenting, it appears that only the user who created the symlink
> will get true for the file test.

It's virtually certain that this is not a bug in bash, since bash just
calls stat(2) on the filename supplied as an argument to -f.

It's probably the case that SELinux is affecting the permissions beyond
what the file and directory permissions indicate.  I spun up a Fedora 23
VM and created two users (user1 and user2), with the files set up as you
describe above.  When you're running as user2, no tool has access to
/home/user1 and /home/user1/file: I tried getfacl, ls, cd, and cat.

You should experiment with temporarily disabling SELinux on the machine,
or using SELinux options to disable it on /home/user1 and its contents.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/