Re: ACLs, umask and shared directories

Hi Gary,

Directory group inheritance is the default in FreeBSD - see open(2):

When a new file is created it is given the group of the
directory which contains it.

In SysV, this behaviour is controlled by the setgid bit.

So the file has the correct group, but it's not writeable by other users
unless it has g+w permissions. The way to guarantee this is to set
everyone's umask to 002 - but then they can write each other's files
anywhere else in the filesystem, because they're all in the same primary

I just can't see a tidy solution.


On 09/03/2010, at 10:34 AM, Gary Gatten wrote:

chmod g+s "ParentDirectory"

Files created in the dir now have the group of the dir.

Not sure if this will help or not, as it appears the new files do not
inherit the perms of the group, the umask still over-rides so....

What about a secondary group + SGID + umask 002? The users that need to
edit each others files in this directory are in a secondary group
(ShareMe). This same group owns the parent directory and the SGID bit
is set. This should allow you to set the umask to 002 correct? Maybe?


www1 primary group = domain_users;

www1$ pwd

drwxrws--- 4 root ShareMe 0 Mar 8 03:11 .
www1$ touch file1
drwxrws--- 4 www1 ShareMe 0 Mar 8 03:11 file1

umask of 002 should give files 664 (I'd change umask to 004, group
"ShareMe" should get rw perms, right?

I think this will work?


-----Original Message-----
From: Gary Gatten
Sent: Monday, March 08, 2010 4:49 PM
To: 'listone@xxxxxxxxxxxxxxxxxxxx'
Subject: RE: ACLs, umask and shared directories

This may also work:

SGID (set group ID) on a directory: in this special case every file
created in the directory will have the same group owner as the directory
itself (while normal behavior would be that new files are owned by the
users who create them). This way, users don't need to worry about file
ownership when sharing directories:


-----Original Message-----
From: Gary Gatten
Sent: Monday, March 08, 2010 4:13 PM
To: Gary Gatten; 'listone@xxxxxxxxxxxxxxxxxxxx'
Subject: RE: ACLs, umask and shared directories

What about sticky bit on the parent directory - in combination with
appropriate owner and group perms. I used sticky in my ftpd solution,
HOWEVER, this was on SCO Unix and sticky may have different behavior on
FBSD. Worth a look though!


-----Original Message-----
From: Gary Gatten
Sent: Monday, March 08, 2010 8:25 AM
To: 'listone@xxxxxxxxxxxxxxxxxxxx'
Subject: Re: ACLs, umask and shared directories

I ran into a similar issue long ago with an ftp folder and "shared"
files. If I recall umask solved my issue for me but understand it
doesn't solve yours.

If nothing else, could you write a shell script that "monitors" the
directory/directories for writes and then sets the perms as needed?

----- Original Message -----
From: owner-freebsd-questions@xxxxxxxxxxx
To: freebsd-questions@xxxxxxxxxxx <freebsd-questions@xxxxxxxxxxx>
Sent: Mon Mar 08 06:41:03 2010
Subject: ACLs, umask and shared directories

Hi Folks,

I need to give a group of users write access to a shared directory. The
problem is, when one user creates a file,

www1$ touch file1
www1$ ll
total 8
drwxrwxr-x 2 root domain_users 512 Mar 8 03:11 .
drwxr-xr-x 4 root wheel 512 Mar 8 03:10 ..
-rw-r--r-- 1 www1 domain_users 0 Mar 8 03:11 file1

other users can't edit it.

Solution 1

Change everyone's umask to 002. Unfortunately, these users are defined
in Active Directory and they're all in the same primary group - 002 is
not secure in this scenario.

Solution 2

Set a default ACL on the parent directory,

www1$ getfacl -d .
# file: .
# owner: root
# group: domain_users

but it doesn't have the desired effect,

www1$ touch file1
www1$ getfacl file1
# file: file1
# owner: www1
# group: domain_users
group::rwx # effective: r--

as the umask seems to override it - this was confirmed by Robert
Watson[1] in 2005.

So does anyone have a better idea?


freebsd-questions@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to

<font size="1">
<div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'>
"This email is intended to be reviewed by only the intended recipient
and may contain information that is privileged and/or confidential.
If you are not the intended recipient, you are hereby notified that
any review, use, dissemination, disclosure or copying of this email
and its attachments, if any, is strictly prohibited. If you have
received this email in error, please immediately notify the sender by
return email and delete this email from your system."

freebsd-questions@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: ACLs, umask and shared directories
    ... With a umask of 002, one user can modify another user's file in these ... The cronjobs and so forth would work - but functional ACLs would be so ... ACLs, umask and shared directories ... www1 primary group = domain_users; ...
  • default ACLs permission problems
    ... This applies to FreeBSD 5.3 Release: ... 'Working With ACLs in FreeBSD 5.x' ... and it is mentions that the file will be masked with umask. ... dirs/files created in that directory regardless of umask? ...
  • Re: [opensuse] script to modify file permissions
    ... Some file system types allow a umask to be specified, ... with spaces in them is difficult for shell scripts to process. ... collectfs - a fuse folder protecting file system, ... The reason I need the script is because I'm exporting the directory over NFS and even though the acls are translated to nfs4 acl's correctly: ...
  • Re: [SLE] How can I do this?
    ... >>ACLs will do what he wants. ... I came over from RedHat which used a default umask of 002 and private ... find a way to get NFS to honor the ACL set umask, ...