[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 16:48:55 -0400

I had disabled SELinux, and got the same results. So it is not SELinux.

I am afraid Chet did not set the permissions to /home/user1 as per the command list I had given. As I said before, it does not affect cd, ls nor cat on my system since /home/user1 and file have the required permissions for the group.

On Wed, 2016-07-27 at 15:49 -0400, Greg Wooledge wrote:
On Wed, Jul 27, 2016 at 03:34:19PM -0400, László Házy wrote:
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.
You're misunderstanding. We're ("they're", though I was thinking the same thing and simply hadn't spoken up yet) saying that what you have described is not reproducible in a regular Unix operating system. You are encountering something unique to your special non-Unix operating system. The most likely theory at this point is that it's got something to do with SELinux. Figure out how SELinux works and how it is affecting this situation, or simply turn it off. It's not a bash issue. As Chet states below, it affects *every* program.
On Wed, 2016-07-27 at 15:16 -0400, Chet Ramey wrote:
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]