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, 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