acl confusion

[Paul Rudin]

Not sure if this is the correct group for this... but still.

I'm a bit confused by the following behaviour. Here's the acl for a
file:

$ sudo nfs4_getfacl secure/test_file_01.odt
D::OWNER@:
A::OWNER@:rwaxTNCo
D:g:GROUP@:
A:g:GROUP@:rwax
D::EVERYONE@:waTC
A::EVERYONE@:rxtncy

We can see that this acl grants read access to everyone at . So I try to
read it as any old user:

$ tail secure/test_file_01.odt
tail: cannot open `secure/test_file_01.odt' for reading: Permission denied

It's been suggested to me that the acl for the containing directory is
relevant (although I don't understand why if this is so - I was under
the impression that the file's acl was all I needed to look at):

$ sudo nfs4_getfacl secure
D::OWNER@:
A::OWNER@:rwaxTNCo
D:g:GROUP@:
A:g:GROUP@:rwax
D::EVERYONE@:rwaxTC
A::EVERYONE@:tncy

Here we see that everyone@ is denied read access - but it's a permission
on a directory - so what this really means is that you can't list the
directory contents.

My question is... should I be able to read the file, and if not, why
not, given that the file's acl grants read access to everyone@?

FWIW the file system is actually hosted on a solaris 10 box (zfs) and mounted
on a linux box as type nfs4.

TIA.

[J. Bruce Fields]

Post by Paul Rudin
Not sure if this is the correct group for this... but still.
I'm a bit confused by the following behaviour. Here's the acl for a
$ sudo nfs4_getfacl secure/test_file_01.odt
We can see that this acl grants read access to everyone at . So I try to
$ tail secure/test_file_01.odt
tail: cannot open `secure/test_file_01.odt' for reading: Permission denied
It's been suggested to me that the acl for the containing directory is
relevant (although I don't understand why if this is so - I was under
$ sudo nfs4_getfacl secure
on a directory - so what this really means is that you can't list the
directory contents.

Yes, read permissions on a directory are permissions to list the
contents of that directory. But traditionally execute permissions on a
directory are required to do a lookup in a directory. (So looking up
test-file_01.odt in secure/ requires "x" permissions on secure/.)

So I suspect giving EVERYONE@ "x" permission to secure/ will cause that
tail command to succeed.

--b.

Post by Paul Rudin
My question is... should I be able to read the file, and if not, why
FWIW the file system is actually hosted on a solaris 10 box (zfs) and mounted
on a linux box as type nfs4.
TIA.
_______________________________________________
NFSv4 mailing list
NFSv4 at linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

[Paul Rudin]

Post by J. Bruce Fields
Yes, read permissions on a directory are permissions to list the
contents of that directory. But traditionally execute permissions on a
directory are required to do a lookup in a directory. (So looking up
test-file_01.odt in secure/ requires "x" permissions on secure/.)

OK - thanks for that.

So - given these permissions is there any way at all that a user (not
the owner or member of the group) can read the contents of that file?

(I'm a bit disturbed by the idea that I need to look at the permissions
for both the directory and the file in order to figure out what can be
done with the file, but if that's the way it is then that's the way it
is...)

[J. Bruce Fields]

Post by Paul Rudin

Post by J. Bruce Fields
Yes, read permissions on a directory are permissions to list the
contents of that directory. But traditionally execute permissions on a
directory are required to do a lookup in a directory. (So looking up
test-file_01.odt in secure/ requires "x" permissions on secure/.)

OK - thanks for that.
So - given these permissions is there any way at all that a user (not
the owner or member of the group) can read the contents of that file?

There could be:

- if the same file is hard-linked from another directory which
the user has access to, then a user could get access through
that directory.
- if the user already has the file open, then changing
permissions on a parent directory won't suddenly result in
read errors; further access through an existing file
descriptor will be permitted.

Also, be aware that most NFS servers won't check whether a client would
have been able to look up a filehandle before allowing the client to use
it. A rogue client could probably easily access a file which it
wouldn't have been able to look up.

So you need those directory permissions, but you shouldn't *depend* on
their absence to hide sensitive information.

Post by Paul Rudin
(I'm a bit disturbed by the idea that I need to look at the permissions
for both the directory and the file in order to figure out what can be
done with the file, but if that's the way it is then that's the way it
is...)

Yup. And this is the standard unix behavior, nothing new or special to
nfsv4.

--b.

[David Brodbeck]

Post by Paul Rudin

Post by J. Bruce Fields
Yes, read permissions on a directory are permissions to list the
contents of that directory. But traditionally execute permissions on a
directory are required to do a lookup in a directory. (So looking up
test-file_01.odt in secure/ requires "x" permissions on secure/.)

OK - thanks for that.
So - given these permissions is there any way at all that a user (not
the owner or member of the group) can read the contents of that file?
(I'm a bit disturbed by the idea that I need to look at the permissions
for both the directory and the file in order to figure out what can be
done with the file, but if that's the way it is then that's the way it
is...)

You actually need execute permission on all the directories above it in the tree. This applies to standard permissions, too, not just ACLs:

brodbd at dryas:~$ ls -ld ~test/test1
drwxr-xr-x 3 test test 3 Mar 26 09:25 /home2/test/test1
brodbd at dryas:~$ ls -ld ~test/test1/test2
drwxr-xr-x 2 test test 3 Mar 26 09:26 /home2/test/test1/test2
brodbd at dryas:~$ ls -ld ~test/test1/test2/test.txt
-rw-r--r-- 1 test test 16 Mar 26 09:26 /home2/test/test1/test2/test.txt
brodbd at dryas:~$ cat ~test/test1/test2/test.txt
This is a test.
test at dryas:~$ chmod og-x ~/test1
brodbd at dryas:~$ cat ~test/test1/test2/test.txt
cat: /home2/test/test1/test2/test.txt: Permission denied

[Lukas Hejtmanek]

Post by David Brodbeck
brodbd at dryas:~$ ls -ld ~test/test1
drwxr-xr-x 3 test test 3 Mar 26 09:25 /home2/test/test1
brodbd at dryas:~$ ls -ld ~test/test1/test2
drwxr-xr-x 2 test test 3 Mar 26 09:26 /home2/test/test1/test2
brodbd at dryas:~$ ls -ld ~test/test1/test2/test.txt
-rw-r--r-- 1 test test 16 Mar 26 09:26 /home2/test/test1/test2/test.txt
brodbd at dryas:~$ cat ~test/test1/test2/test.txt
This is a test.
test at dryas:~$ chmod og-x ~/test1
brodbd at dryas:~$ cat ~test/test1/test2/test.txt
cat: /home2/test/test1/test2/test.txt: Permission denied

in my case, chmod changes also ACLs. mainly it adds mask if you change group
permissions. Check ACL one more time and watch effective keyword.

[David Brodbeck]

Post by Lukas Hejtmanek

Post by David Brodbeck
brodbd at dryas:~$ ls -ld ~test/test1
drwxr-xr-x 3 test test 3 Mar 26 09:25 /home2/test/test1
brodbd at dryas:~$ ls -ld ~test/test1/test2
drwxr-xr-x 2 test test 3 Mar 26 09:26 /home2/test/test1/test2
brodbd at dryas:~$ ls -ld ~test/test1/test2/test.txt
-rw-r--r-- 1 test test 16 Mar 26 09:26 /home2/test/test1/test2/test.txt
brodbd at dryas:~$ cat ~test/test1/test2/test.txt
This is a test.
test at dryas:~$ chmod og-x ~/test1
brodbd at dryas:~$ cat ~test/test1/test2/test.txt
cat: /home2/test/test1/test2/test.txt: Permission denied

in my case, chmod changes also ACLs. mainly it adds mask if you change group
permissions. Check ACL one more time and watch effective keyword.

That's true. But when I try this on a filesystem without ACLs enabled, I get the same result.