public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Duplicate ACLs? - Can't copy file even with Admin permissions
Date: Wed, 12 Jan 2022 10:33:59 +0100	[thread overview]
Message-ID: <Yd6ghzC7GybqYIfe@calimero.vinschen.de> (raw)
In-Reply-To: <Ydw4stFxX+he1A6b@calimero.vinschen.de>

On Jan 10 14:46, Corinna Vinschen wrote:
> On Jan 10 11:07, Corinna Vinschen wrote:
> > On Jan  7 15:56, cyg...@kosowsky.org wrote:
> > > > Corinna Vinschen wrote:
> > > > On Jan  6 16:11, cyg...@kosowsky.org wrote:
> > > > It is.  I realized belatedly, that 3da9e136.acl is apparently a
> > > > directory, not a file.
> > > 
> > > It's actually a file...
> > 
> > This is weird.  The meaning of the OI and CI markers are "Object
> > inheritance" and "Container inheritance".  These bits only make sense
> > for directories and they control how ACEs are inherited by child objects
> > (files) and child containers (subdirs).
> > [...]
> > I'll have a look into the sources later, but I sure would prefer if
> > I could create such a file locally.
> 
> I tried to create a file with equivalent ACL including the inheritence
> flags on W7, W10 and W11, but to no avail.

Success!  I hacked a Q&D application which opens a file, reads its
security descriptor (SD) and just adds the object and container inherit
flags to all its DACL' ACEs and writes the SD back.  Albeit Windows
tools and some of the security functions under the hood don't allow to
add inherit flags to files, some functions just write the SD verbatim
without checking.

So I was finally able to reproduce your issue:

  $ ./hackup acltest
  $ icacls acltest
  acltest NT AUTHORITY\SYSTEM:(OI)(CI)(F)
          Everyone:(OI)(CI)(RX)
          BUILTIN\Administrators:(OI)(CI)(F)

  Successfully processed 1 files; Failed processing 0 files
  $ getfacl acltest
  # file: acltest
  # owner: Administrators                                                   
  # group: SYSTEM                                                           
  user::rwx                                                                 
  group::rwx                                                                
  other::r-x                                                                
  user::rwx                                                                 
  group::rwx                                                                
  group:SYSTEM:rwx                                                          
  mask::rwx                                                                 
  other::r-x                                                                

The Cygwin DLL reads the DACL and converts it to a POSIX ACL.  An ACE
with inherit flags set is converted to a POSIX access ACE and
additionally to a POSIX default ACE.  The latter is done independently
of the file type.  The calling function (still in Cygwin) doesn't expect
default ACEs for files and treats them as access ACEs.  That's what
you see in the getfacl output above.

I fixed this in Cygwin by ignoring inheritance flags unless the object
is a directory, so the core function in Cygwin only creates default
ACEs for directories.  The result when calling getfacl on such a file
is thus:

  $ getfacl acltest
  # file: acltest
  # owner: Administrators                                                   
  # group: SYSTEM                                                           
  user::rwx                                                                 
  group::rwx                                                                
  other::r-x                                                                

I uploaded a developer snapshot to https://cygwin.com/snapshots
Please give it a try.


Corinna

  reply	other threads:[~2022-01-12  9:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-03 15:51 cygwin
2022-01-05 11:34 ` Corinna Vinschen
2022-01-06 11:12   ` Achim Gratz
2022-01-06 21:11     ` cygwin
2022-01-07 13:22       ` Corinna Vinschen
2022-01-07 20:56       ` cygwin
2022-01-10 10:07         ` Corinna Vinschen
2022-01-10 13:46           ` Corinna Vinschen
2022-01-12  9:33             ` Corinna Vinschen [this message]
2022-01-19  2:26             ` cygwin
2022-01-19  8:00               ` Corinna Vinschen
2022-01-21 13:57                 ` cygwin
2022-01-25 19:19                   ` Corinna Vinschen
2022-01-26  1:11                     ` cygwin
2022-01-06 18:05   ` Andrey Repin
2022-01-06 19:42     ` Franz Fehringer
2022-01-06 20:35     ` cygwin
2022-01-06 20:46       ` Eliot Moss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yd6ghzC7GybqYIfe@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).