This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: ACL inheritance problem
- From: "Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>
- To: <cygwin-developers at cygwin dot com>
- Date: Sun, 01 Nov 2009 16:07:34 -0500
- Subject: Re: ACL inheritance problem
- References: <20091030133528.GW28753@calimero.vinschen.de> <20091030195901.GZ28753@calimero.vinschen.de> <4AECF1A6.1020902@cygwin.com>
----- Original Message -----
From: "Larry Hall (Cygwin Developers)"
To: <cygwin-developers>
Sent: Saturday, October 31, 2009 21:25
Subject: Re: ACL inheritance problem
| On 10/30/2009 03:59 PM, Corinna Vinschen wrote:
| > On Oct 30 14:35, Corinna Vinschen wrote:
| >> 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.
| >
| > I've applied a patch to implement #2 above. I'd still be interested
| > if anybody thinks it's a good idea to re-enable the #4 code and, maybe,
| > to tweak setup to generated inheritable CREATOR OWNER and CREATOR GROUP
| > entries to be more friendly to Win32 applications. Not even Interix is
| > doing that, but they can excuse themselves by being their own POSIX
| > subsystem rather than running in the Win32 subsystem.
|
| I still like the idea of #4, if we're voting. :-)
Same here.
Pierre