This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
ACL inheritance problem
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Fri, 30 Oct 2009 14:35:28 +0100
- Subject: ACL inheritance problem
- Reply-to: cygwin-developers at cygwin dot com
Hi guys,
I'm somewhat in trouble and I could need some input.
Here's the problem: http://cygwin.com/ml/cygwin/2009-10/msg00565.html
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
descriptor.
- 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
user::rw-
group::r--
mask:rwx
other:r--
$ touch subdir/file
$ getfacl subdir/file
# file: subdir/file
# owner: corinna
# group: vinschen
user::rw-
group::r--
group:SYSTEM:rwx
group:Administrators:rwx
mask:rwx
other:r--
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
http://cygwin.com/ml/cygwin/2009-10/msg00598.html and forget
ACL inheritance for now.
Drawbacks:
- 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.
Drawbacks:
- 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.
Drawbacks:
- 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.
Drawbacks:
- 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
problem.
- 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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat