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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
