You have probably not done the first command: "[user1]$ chmod g+rx /home/user1". In my case, there is no access problem. I can ls and cd. Thing is, even root gets the wrong answer if it does the "is file?" query.
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