ACL inheritance problem

[Larry Hall (Cygwin Developers)]

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. :-)

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?