Duplicate ACLs? - Can't copy file even with Admin permissions

[cygwin@kosowsky.org]

On Jan 04:14 Corinna Vinschen wrote:
> 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.
> 

Sorry but I was on vacation last week and didn't have a chance to try the new cygwin dll until now.

Indeed, the new cygwin.dll does allow me to copy the files and it does
preserve the 'getfacl' (POSIX) acl's (as above).
However, it does *not* preserve the full ACL's as reported by 'icacls'.

    #cp -a 3da9e136.rbf temp
    
    #getfacl temp
    # file: temp
    # owner: Administrators
    # group: SYSTEM
    user::rwx
    group::rwx
    other::r-x

    #icacls 3da9e136.rbf
    3da9e136.rbf NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                 Everyone:(OI)(CI)(RX)
                 BUILTIN\Administrators:(OI)(CI)(F)

    #icacls temp
    temp BUILTIN\Administrators:(F)
         NT AUTHORITY\SYSTEM:(RX,W)
         Everyone:(RX)

Similarly,
    #icacls 3da9e136.rbf /save/ 3da9e136.acl
    #icacls temp /save temp.acl

    #cat 3da9e136.acl
    3da9e136.rbf
    D:P(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;WD)(A;OICI;FA;;;BA

    #cat temp.acl
    temp
    D:P(A;;FA;;;BA)(A;;0x1201bf;;;SY)(A;;0x1200a9;;;WD)

So, the full Windows ACLs as indicated by 'icacls' differ.
Is this the expected behavior??? If so, why???

Interestingly, the windows 'xcopy' command (using the /X or /O flags)
doesn't copy the full ACLs correctly either

    C:\Config.Msi>xcopy /X 3da9e136.rbf temp2
    #icacls temp2
    temp3 NT AUTHORITY\SYSTEM:(F)
          Everyone:(RX)
	  BUILTIN\Administrators:(F)
      
    #icacls temp2 /save temp2.acl

    #cat temp2.acl
    D:PAI(A;;FA;;;SY)(A;;0x1200a9;;;WD)(A;;FA;;;BA)    

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


Even using Powershell, I am not able to copy the ACLs exactly:

PS C:\CONFIG.MSI> Copy-Item .\3da9e136.rbf temp3
    PS C:\CONFIG.MSI> Get-Acl .\3da9e136.rbf | Set-Acl temp3

    #icacls.exe temp3
    temp6 Everyone:(RX)
          NT AUTHORITY\SYSTEM:(F)
	  BUILTIN\Administrators:(F)
		
    #icacls temp3 /save temp3.acl

    #cat temp3.acl
    temp6
    D:PAI(A;;0x1200a9;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)S:PAINO_ACCESS_CONTROL

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

Really not sure what is going on here... and why it is seemingly so
hard to precisely copy a file and its ACLs -- whether using native
Windows or native Cywin tools.
(though the output of getfacl is consistent)

Anybody able to enlighten me on what is going on?

Jeff