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