| delorie.com/archives/browse.cgi | search |
| X-Recipient: | archive-cygwin AT delorie DOT com |
| X-Original-To: | cygwin AT cygwin DOT com |
| Delivered-To: | cygwin AT cygwin DOT com |
| DMARC-Filter: | OpenDMARC Filter v1.4.1 sourceware.org DFC3A3858032 |
| Authentication-Results: | sourceware.org; |
| dmarc=none (p=none dis=none) header.from=kosowsky.org | |
| Authentication-Results: | sourceware.org; spf=pass smtp.mailfrom=kosowsky.org |
| X-CMAE-Analysis: | v=2.4 cv=CrF6zl0D c=1 sm=1 tr=0 ts=61e776f0 |
| a=BYuR5sdBHlGgEYWvfiqr5Q==:117 a=BYuR5sdBHlGgEYWvfiqr5Q==:17 | |
| a=kj9zAlcOel0A:10 a=DghFqjY3_ZEA:10 a=Y4wjOHm_AAAA:8 a=w_pzkKWiAAAA:8 | |
| a=FzI9NfVsTI1zC3xDfBAA:9 a=CjuIK1q_8ugA:10 a=vUyUeBe4x1l68iL-zyVZ:22 | |
| a=sRI3_1zDfAgwuvI8zelB:22 | |
| X-SECURESERVER-ACCT: | inbox AT kosowsky DOT org |
| X-Spam-Checker-Version: | SpamAssassin 3.4.4 (2020-01-24) on |
| server2.sourceware.org | |
| X-Spam-Status: | No, score=-1.5 required=5.0 tests=BAYES_00, FROM_BLANK_NAME, |
| KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, | |
| RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, | |
| TXREP autolearn=no autolearn_force=no version=3.4.4 | |
| MIME-Version: | 1.0 |
| Message-ID: | <25063.30447.365452.499124@consult.pretender> |
| Date: | Tue, 18 Jan 2022 21:26:55 -0500 |
| To: | cygwin AT cygwin DOT com |
| Subject: | Re: Duplicate ACLs? - Can't copy file even with Admin permissions |
| In-Reply-To: | <Ydw4stFxX+he1A6b@calimero.vinschen.de> |
| References: | <25043 DOT 7019 DOT 643488 DOT 389876 AT consult DOT pretender> |
| <YdWCPsZOModGdRXM AT calimero DOT vinschen DOT de> | |
| <8735m12k3u DOT fsf AT Rainer DOT invalid> | |
| <25047 DOT 23325 DOT 33020 DOT 646017 AT consult DOT pretender> | |
| <25048 DOT 43238 DOT 484068 DOT 737126 AT consult DOT pretender> | |
| <YdwFc2JA5FfH1Ktr AT calimero DOT vinschen DOT de> | |
| <Ydw4stFxX+he1A6b AT calimero DOT vinschen DOT de> | |
| X-Mailer: | VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu) |
| From: | "" <cygwin AT kosowsky DOT org> |
| X-Virus-Scanned: | ClamAV using ClamSMTP |
| X-CMAE-Envelope: | MS4xfN2Tg4afhb/wnRF9fJhCYSw6AO89V54N5I2feCDsAYcxN/hO7/QgsKwWrTIF2wsXcYxW+qaIhZgRVVJNCT2d4PcBJhC6b20zQfmVbmYl2+g8PaKmu9pR |
| p6QhOneRNr/GlogxUFTLiYT8/U+8Le37dTlRQGlvIM/FTZOGsW53wAcL8CzgOwS6lD++VBlB7W+jCy3pyirJKjXZjgb9iM4Mi1Y= | |
| X-BeenThere: | cygwin AT cygwin DOT com |
| X-Mailman-Version: | 2.1.29 |
| List-Id: | General Cygwin discussions and problem reports <cygwin.cygwin.com> |
| List-Unsubscribe: | <https://cygwin.com/mailman/options/cygwin>, |
| <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe> | |
| List-Archive: | <https://cygwin.com/pipermail/cygwin/> |
| List-Post: | <mailto:cygwin AT cygwin DOT com> |
| List-Help: | <mailto:cygwin-request AT cygwin DOT com?subject=help> |
| List-Subscribe: | <https://cygwin.com/mailman/listinfo/cygwin>, |
| <mailto:cygwin-request AT cygwin DOT com?subject=subscribe> | |
| Errors-To: | cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com |
| Sender: | "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com> |
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 DOT DOT DOT AT kosowsky DOT org wrote:
> > > > > Corinna Vinschen wrote:
> > > > > On Jan 6 16:11, cyg DOT DOT DOT AT kosowsky DOT 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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |