ACL inheritance problem

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Oct 30 19:59:00 GMT 2009


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.


Corinna

-- 
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