Inconsistent behaviour with linux ACLs

Today I've found that linux ACLs have a small glitch ... or it's just me not understanding how it works.

If you use a filesystem without ACLs, then new files never get an execute permission upon creation. You've to add execute permission explicitly.

Eg.

myserver$ umask
007
myserver$ mkdir test
myserver$ ls -ald test
drwxrwx--- 2 testuser testuser 4096 Sep  1 18:30 test
myserver$ touch test/t
myserver$ ls -al test/t
-rw-rw---- 1 testuser testuser 0 Sep  1 18:30 test/t

So far so good.

If you use ACLs and assign default ACLs to a directory for a named group, then things change a little bit:

myserver$ umask
007
myserver$ mkdir test
myserver$ ls -ald test
drwxrwx--- 2 testuser testuser 4096 Sep  1 18:32 test
myserver$ setfacl -m d:g:testuser:rwx test
myserver$ getfacl test
# file: test
# owner: testuser
# group: testuser
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:group:testuser:rwx
default:mask::rwx
default:other::---
myserver$ touch test/t
myserver$ ls -al test/t
-rw-rw---- 1 testuser testuser 0 Sep  1 18:32 test/t
myserver$ getfacl test/t
# file: test/t
# owner: testuser
# group: testuser
user::rw-
group::rwx                        #effective:rw-
group:testuser:rwx                #effective:rw-
mask::rw-
other::---

Notice the execute permission both in the ACL_GROUP_OBJ entry and in the "testuser" ACL_GROUP entry.
However the ls command does not show the execute permission and getfacl shows the effective group permissions as rw- too.
But if you do an additional change in the ACL of the file or force setfacl to recalculate the ACL mask value, then that execute permission becomes effective:

myserver$ getfacl test/t | setfacl --mask --set-file=- test/t
myserver$ ls -ald test/t
-rw-rwx---+ 1 testuser testuser 0 Sep  1 18:33 test/t
myserver$ getfacl test/t
# file: test/t
# owner: testuser
# group: testuser
user::rw-
group::rwx
group:testuser:rwx
mask::rwx
other::---

If I use only a file group ACL (setfacl -m d:g::rwx test) instead of a named group ACL (setfacl -m d:g:testuser:rwx test) on the directory, then the execute permission does not appear on the "t" file created inside the directory:

myserver$ umask
007
myserver$ mkdir test
myserver$ ls -ald test
drwxrwx--- 2 testuser testuser 4096 Sep  1 18:32 test
myserver$ setfacl -m d:g::rwx test
myserver$ getfacl test
# file: test
# owner: testuser
# group: testuser
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
myserver$ touch test/t
myserver$ ls -al test/t
-rw-rw---- 1 testuser testuser 0 Sep  1 18:34 test/t
myserver$ getfacl test/t
# file: test/t
# owner: testuser
# group: testuser
user::rw-
group::rw-
other::---

I'd understand if the "t" file got the execute permission in both cases: it would mean that even files inherit the default execute permission from their parent directories (which would be a little bit odd imho).
I'd also understand the opposite behaviour: it would mean that files do not inherit the execute permission of their parent directories (I'd find this the proper behaviour).

But how comes that in one case the execute permission was inherited, in the other case not?

This definitely looks like a bug to me.

The above case was examined on an Ubuntu 8.04.1 server running the 2.6.24-19 (x86_64) kernel, using ext3 filesystem and the v2.2.45-1 acl package.

Comments

Mon, 2008.09.01 - 18:50 — müzso

Re: Inconsistent behaviour with linux ACLs

I could successfully reproduce the same behaviour on a Debian 4.x system running kernel v2.6.18-6 (i386 arch.) and acl package v2.2.41-1. This is either an expected behaviour (and maybe just not trivial from the docs), or it's a long-term bug.

Thu, 2008.11.20 - 21:24 — Anonymous (not verified)