This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ACL inheritance problem


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]