Am 26.07.2016 um 23:07 schrieb László Házy: > 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.
Does user2 have rx access to /home/user1? -- Reuti > From experimenting, it appears that only the user who created the symlink > will get true for the file test. > > Thank you. > > > > > On Tue, 2016-07-26 at 15:06 -0400, Grisha Levit wrote: >> Are you sure "file" is a link to an actual file, not, say, a directory? >> >> $ rpm -q bash; echo $BASH_VERSION; cat /etc/redhat-release >> bash-4.3.42-3.fc23.x86_64 >> 4.3.42(1)-release >> Fedora release 23 (Twenty Three) >> >> $ touch file; ln -s file link; [[ -f link ]]; echo $? >> 0 >> >> On Tue, Jul 26, 2016 at 12:58 PM, László Házy <haz...@yahoo.com> wrote: >>> I am running bash 4.3.42-3 on Fedore Core 23. >>> >>> I noticed that the [ -f file ] test returns false if "file" is a symlink. >>> Given the intended behavior (from a long time ago), this is wrong as the >>> symlinks are supposed to be followed. It certainly brakes functionality in >>> certain existing software. >>> >>> Has the default behavior been changed somewhere along the time line and I >>> am not aware of it? >>> >>> >>
