ACL not working properly?

[PatRoy]

Hi fellows.

I'm trying (first time here!) to set some ACL access on some folders, but it seems to the rights aren't working as I expected. They aren't properly being inherited.... (??)

This is my ACL file : test.acl

user::rwx
group::---
group:proygrp:rwx
class:rwx
other:---
default:group:proygrp:rwx


Who I'm logged in as:
$ whoami => proy

My test folder:
$ ll -d /tmp/proy
drwxrwxr-x 2 proy proygrp 96 Jun 11 14:18 proy

I than applied my acl:

$ setacl -f test.acl /tmp/proy

Then,
$ ll -d proy
drwxrwx---+ 2 proy proygrp 96 Jun 11 14:18 proy

and

$ getacl /tmp/proy
# file: /tmp/proy
# owner: proy
# group: proygrp
user::rwx
group::---
group:proygrp:rwx
class:rwx
other:---
default:group:proygrp:rwx

So far, seems right!

If I now create a file under /tmp/proy, I get the following rights:

$ touch /tmp/proy/file1
$ ll /tmp/proy/file1
-rw-rw-r--+ 1 proy proygrp 0 Jun 11 14:39 /tmp/proy/file1

$ getacl /tmp/proy/file1
# file: /tmp/proy/file1
# owner: proy
# group: proygrp
user::rw-
group::rw-
group:proygrp:rwx #effective:rw-
class:rw-
other:r--

Why is it that the default group gets rw- and that even other gets read access??? Thought my ACL said to remove all access to others??

Same kinda thing happens when creating a subdir..:

$ mkdir /tmp/proy/folder
$ ll -d /tmp/proy/folder
drwxrwxr-x+ 2 proy proygrp 96 Jun 11 14:43 /tmp/proy/folder

$ getacl /tmp/proy/folder
# file: /tmp/proy/folder
# owner: proy
# group: proygrp
user::rwx
group::rwx
group:proygrp:rwx
class:rwx
other:r-x
default:group:proygrp:rwx

Seems wrong to me... or is it? Could this be because of some umask thing? My 'proy' user's umask is "02"

Can anyone clarify??

Thanks a lot!

Pat.

[Jeff_Traigle · Accepted solution]

It's acting normally and, as you guessed, what you're seeing is because the umask is set to 002. The permissions on a directory have absolutely nothing to do with the permissions that will be assigned to files created in that directory. Change the umask to 007 and I'm sure you'll see the results you expected. Of course, that may have undesirable consequences depending what else this user account does. Changing umask to a more restrictive value can have adverse effects in a production environment so best to investigate potential issues before changing it in those situations.

[Steven E. Protter]

Shalom Pat,

Its a feature, its working just like you told it to work.

SEP

[PatRoy]

As I thought!

Thanks all!