Re: bug in [ -f file ] test

[Chet Ramey]

On 7/28/16 12:52 PM, László Házy wrote:
> Thanks for the effort Chet. Here are the results of some tests I have done,
> including what you requested. Note that I have SELinux as disabled.
> 

> [user1]# cat /var/tmp/link
> cat: /var/tmp/link: Permission denied

This is consistent with my results.

> [user1]# stat /var/tmp/link
>   File: ‘/var/tmp/link’ -> ‘/home/user1/file’
>   Size: 17              Blocks: 0          IO Block: 4096   symbolic link
> Device: 808h/2056d      Inode: 131183      Links: 1
> Access: (0777/lrwxrwxrwx)  Uid: (  500/  user2)   Gid: (  100/   users)
> Access: 2016-07-27 12:17:07.899994243 -0400
> Modify: 2016-07-27 12:17:07.398991028 -0400
> Change: 2016-07-27 12:17:07.398991028 -0400
>  Birth: -

You can interrogate the link itself, but not follow it when performing
name resolution.


> Then, I created the /home/user1/test.sh script with the following content:
> #!/bin/bash
> 
> [[ -f /var/tmp/link ]]
> echo $?
>  
> End of /home/user1/test.sh.
>  
>  
>  
> [user1]$ strace ./test.sh
        [ ... ]
> read(255, "#!/bin/bash\n\n[[ -f /var/tmp/link"..., 45) = 45
> stat64("/var/tmp/link", 0xbfaeb038)     = -1 EACCES (Permission denied)

So we find that bash is accurately reporting what the kernel and glibc
tell it.

-- 
``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/