ACL inheritance problem

Corinna Vinschen
Fri Oct 30 13:35:00 GMT 2009

Hi guys,

I'm somewhat in trouble and I could need some input.

Here's the problem:

So it all started with finding out that ACL inheritance for files didn't
work, even though it should.

So I changed fhandler_base::open() to create files with a NULL
descriptor to get Windows to create the file with inheritance, and then
writing the POSIX permisions for user, group, and others.

Today I found that this isn't sufficient.  First of all, the same change
has to be done in three other places in the DLL (mkdir, for instance),
but that's just a minor problem.

What happens when a file or directory is created is this:

- If a security descriptor is given, create the file using that

- If a NULL descriptor is given, create the file using the inheritable
  permissions from the parent directory.

- And now the problem: If the parent directory has no inheritable
  permissions, use the default DACL of the processes user token to
  create default rights.

The default DACL depends on the process type.  Windows processes have a
default dacl like this:

  user SID, all access
  SYSTEM SID, all access
  Logon session SID, read/execute

Cygwin processes replace the logon session SID with the administrators
group and all access.

Directories have no inheritable permissions by default, so the default
DACL is used when creating a file in that dir.  That's the result:

  $ getfacl subdir
  # file: subdir
  # owner: corinna
  # group: vinschen
  $ touch subdir/file
  $ getfacl subdir/file
  # file: subdir/file
  # owner: corinna
  # group: vinschen

Argh!  So the new file has full permissions for SYSTEM and Admins group.
That sort of DACL is not exactly desired.

What are the options to get this fixed?

1. Revert the change I'm talking about in and forget
   ACL inheritance for now.

   - Incorrect.
   - No ACL inheritance.
   - Doesn't help for native Win32 apps which will continue to create
     files with a DACL containing SYSTEM and the Logon session SID.

2. After the file has been created, the set_file_attribute function is
   called anyway to set the POSIX permissions.  The DACL is fetched from
   the file and used for certain tests.  An additional test would be to
   check if the DACL contains ACEs which are not inherited from the
   parent, and are not one of the user SID, the group SID, or the
   everyone SID.  Such an ACE must have been part of the default DACL
   and can simply not written back to the file's DACL.

   - Must use GetSecurityInfo instead of NtQuerySecurityObject, otherwise
     inheritance info is missing.
   - Doesn't help for native Win32 apps which will continue to create
     files with a DACL containing SYSTEM and the Logon session SID.

3. Change the default DACL for the Cygwin process temporarily to NULL
   every time we call NtCreateFile to avoid extraneous ACL entries.

   - The cost of calling SetTokenInformation twice per file creation.
   - Doesn't help for native Win32 apps which will continue to create
     files with a DACL containing SYSTEM and the Logon session SID.

4. Re-enable (I disabled this code back in February) the code which
   always creates directories with inherit-only CREATOR OWNER and
   CREATOR GROUP entries.  That means, if I create a file in such a
   directory, it will create default owner/group entries since the
   parent directory has inheritable permissions.  The default DACL is no
   problem anymore.  Native Win32 processes will create files using the
   same inherited permissions.

   - As in 1.5 times, directories are always created with extra ACEs,
     so every directory has a '+' in the `ls -l' output.
   - This only helps for newly created directories.  Creating files
     in existing directories will continue to suffer from the described
   - setup-1.7.exe would have to be changed as well, since right now 
     it creates plain, non-inheritable POSIX permissions for directories.

I'm a bit at a loss to decide what's the best solution.  I'm leaning to
solution 2 because it's the least extra processing.  OTOH, it's probably
not really nice to shrug away native Win32 processes, so maybe
additionally re-enabling the Cygwin part of solution 4 would produce
less trouble in the long run.

What do you think?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list