[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug in [ -f file ] test

From: László Házy
Subject: Re: bug in [ -f file ] test
Date: Wed, 27 Jul 2016 15:34:19 -0400

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 Wed, 2016-07-27 at 15:16 -0400, Chet Ramey wrote:
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]