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

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

[cygwin]

To: 
Subject:
X-Mailer: VM 8.2.0b under 25.2.2 (x86_64-pc-linux-gnu--text follows this line--
I have a file: /c/Config.Msi/3da9e136.rbf that I cannot copy, even when
I run bash as an administrator -- seemingly due to perm/acl errors.

Specifically:
	# mv 3da9e136.rbf newfile: works
	# cp 3da9e136.rbf newfile: works

But,
	# cp -a 3da9e136.rbf newfile
	cp: preserving permissions for ‘newfile’: Permission denied
	(though the file is created)

If I then do
	# getfacl 3da9e136.rbf | setfacl -f - newfile
	setfacl: more than one user entry.

And:
	# getfacl 3da9e136.rbf
	# file: 3da9e136.rbf
	# owner: Administrators
	# group: SYSTEM
	user::rwx
	group::rwx
	other::r-x
	user::rwx
	group::rwx
	group:SYSTEM:rwx
	mask::rwx
	other::r-x

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


So the problem seems to be that the 'user' (and presumably also the
'group' and 'other') ACLs are duplicated.

Note that 'subinacl' shows:
=================================
+File C:\Config.Msi\3da9e136.rbf
=================================
/control=0x0
/owner             =builtin\administrators
/primary group     =system
/audit ace count   =0
/perm. ace count   =3
/pace =system  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
/pace =everyone  Type=0x0 Flags=0x3 AccessMask=0x1200a9
/pace =builtin\administrators  Type=0x0 Flags=0x3 AccessMask=0x1f01ff


-----------------------------------------
Not sure if this is an NTFS bug (or feature???) or a problem with
Cygwin file manipulation tools.

Either way:
- Is this a bug? (or a feature????)
- Any idea how or why this happened?
- Any idea how (or whether) to fix this so that I don't have duplicate
  ACLs?

Ideally, I would like to "fix" the problem with Cygwin tools...

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

[Corinna Vinschen]

On Jan  3 10:51, cygwin@kosowsky.org wrote:
> I have a file: /c/Config.Msi/3da9e136.rbf that I cannot copy, even when
> [...]
> 	# getfacl 3da9e136.rbf
> 	# file: 3da9e136.rbf
> 	# owner: Administrators
> 	# group: SYSTEM
> 	user::rwx
> 	group::rwx
> 	other::r-x
> 	user::rwx
> 	group::rwx
> 	group:SYSTEM:rwx
> 	mask::rwx
> 	other::r-x
> [...]
> Note that 'subinacl' shows:
> =================================
> +File C:\Config.Msi\3da9e136.rbf
> =================================
> /control=0x0
> /owner             =builtin\administrators
> /primary group     =system
> /audit ace count   =0
> /perm. ace count   =3
> /pace =system  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
> /pace =everyone  Type=0x0 Flags=0x3 AccessMask=0x1200a9
> /pace =builtin\administrators  Type=0x0 Flags=0x3 AccessMask=0x1f01ff

I don't see a reliable, trustable source for downloading subinacl, so
let's do this with builtin tools.

I'm not sure what's going on on your machine.  I tried to reproduce your
issue by creating a file with the exact same DACL:

  $ cat aclfile.sav
  acltest
  D:P(A;;FA;;;SY)(A;;0x1200a9;;;WD)(A;;FA;;;BA)

Note that the file is in UTF-16, the first two bytes are the BOM.

  $ icacls . /restore aclfile.sav
  processed file: .\acltest
  Successfully processed 1 files; Failed processing 0 files
  $ icacls acltest
  acltest NT AUTHORITY\SYSTEM:(F)
	  Everyone:(RX)
	  BUILTIN\Administrators:(F)

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

Would you mind to run `icacls 3da9e136.rbf /save 3da9e136.acl
and paste the content of 3da9e136.acl into your reply?

Please use "reply-to" to keep mail threading intact.  Your two
mails in terms of this problem are disconnected for some reason.


Thanks,
Corinna

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

[Achim Gratz]

Corinna Vinschen writes:
> I don't see a reliable, trustable source for downloading subinacl, so
> let's do this with builtin tools.

This program was part of the Resource Kit for Windows Server (2003?).
At least about five years ago you could get an official download link
via the M$ Knowledge base without installing the old RK.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Andrey Repin]

Greetings, Corinna Vinschen!

> On Jan  3 10:51, cygwin@kosowsky.org wrote:
>> I have a file: /c/Config.Msi/3da9e136.rbf that I cannot copy, even when
>> [...]
>>       # getfacl 3da9e136.rbf
>>       # file: 3da9e136.rbf
>>       # owner: Administrators
>>       # group: SYSTEM
>>       user::rwx
>>       group::rwx
>>       other::r-x
>>       user::rwx
>>       group::rwx
>>       group:SYSTEM:rwx
>>       mask::rwx
>>       other::r-x
>> [...]
>> Note that 'subinacl' shows:
>> =================================
>> +File C:\Config.Msi\3da9e136.rbf
>> =================================
>> /control=0x0
>> /owner             =builtin\administrators
>> /primary group     =system
>> /audit ace count   =0
>> /perm. ace count   =3
>> /pace =system  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
>> /pace =everyone  Type=0x0 Flags=0x3 AccessMask=0x1200a9
>> /pace =builtin\administrators  Type=0x0 Flags=0x3 AccessMask=0x1f01ff

> I don't see a reliable, trustable source for downloading subinacl, so
> let's do this with builtin tools.

https://download.microsoft.com/download/1/7/d/17d82b72-bc6a-4dc8-bfaa-98b37b22b367/subinacl.msi
Since installer is signed, you can verify its integrity.


-- 
With best regards,
Andrey Repin
Thursday, January 6, 2022 21:05:06

Sorry for my terrible english...

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

[Franz Fehringer]

I get 404 with this link.

Am 06.01.2022 um 19:05 schrieb Andrey Repin:
> Greetings, Corinna Vinschen!
> 
>> On Jan  3 10:51, cygwin@kosowsky.org wrote:
>>> I have a file: /c/Config.Msi/3da9e136.rbf that I cannot copy, even when
>>> [...]
>>>        # getfacl 3da9e136.rbf
>>>        # file: 3da9e136.rbf
>>>        # owner: Administrators
>>>        # group: SYSTEM
>>>        user::rwx
>>>        group::rwx
>>>        other::r-x
>>>        user::rwx
>>>        group::rwx
>>>        group:SYSTEM:rwx
>>>        mask::rwx
>>>        other::r-x
>>> [...]
>>> Note that 'subinacl' shows:
>>> =================================
>>> +File C:\Config.Msi\3da9e136.rbf
>>> =================================
>>> /control=0x0
>>> /owner             =builtin\administrators
>>> /primary group     =system
>>> /audit ace count   =0
>>> /perm. ace count   =3
>>> /pace =system  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
>>> /pace =everyone  Type=0x0 Flags=0x3 AccessMask=0x1200a9
>>> /pace =builtin\administrators  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
> 
>> I don't see a reliable, trustable source for downloading subinacl, so
>> let's do this with builtin tools.
> 
> https://download.microsoft.com/download/1/7/d/17d82b72-bc6a-4dc8-bfaa-98b37b22b367/subinacl.msi
> Since installer is signed, you can verify its integrity.
> 
> 

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

[cygwin]

Subinacl is pre-installed on the version of Win10 I got from MSFT.

Andrey Repin wrote at about 21:05:48 +0300 on Thursday, January 6, 2022:
 > Greetings, Corinna Vinschen!
 > 
 > > On Jan  3 10:51, cygwin@kosowsky.org wrote:
 > >> I have a file: /c/Config.Msi/3da9e136.rbf that I cannot copy, even when
 > >> [...]
 > >>       # getfacl 3da9e136.rbf
 > >>       # file: 3da9e136.rbf
 > >>       # owner: Administrators
 > >>       # group: SYSTEM
 > >>       user::rwx
 > >>       group::rwx
 > >>       other::r-x
 > >>       user::rwx
 > >>       group::rwx
 > >>       group:SYSTEM:rwx
 > >>       mask::rwx
 > >>       other::r-x
 > >> [...]
 > >> Note that 'subinacl' shows:
 > >> =================================
 > >> +File C:\Config.Msi\3da9e136.rbf
 > >> =================================
 > >> /control=0x0
 > >> /owner             =builtin\administrators
 > >> /primary group     =system
 > >> /audit ace count   =0
 > >> /perm. ace count   =3
 > >> /pace =system  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
 > >> /pace =everyone  Type=0x0 Flags=0x3 AccessMask=0x1200a9
 > >> /pace =builtin\administrators  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
 > 
 > > I don't see a reliable, trustable source for downloading subinacl, so
 > > let's do this with builtin tools.
 > 
 > https://download.microsoft.com/download/1/7/d/17d82b72-bc6a-4dc8-bfaa-98b37b22b367/subinacl.msi
 > Since installer is signed, you can verify its integrity.
 > 
 > 
 > -- 
 > With best regards,
 > Andrey Repin
 > Thursday, January 6, 2022 21:05:06
 > 
 > Sorry for my terrible english...
 > 
 > 
 > -- 
 > 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

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

[Eliot Moss]

On 1/6/2022 3:35 PM, cygwin@kosowsky.org wrote:
> Subinacl is pre-installed on the version of Win10 I got from MSFT.

Not on mine, and the general information around the Web is that you have
to download it.  Also, the speculation is that it is not being maintained,
while icacls is ...

Regards - Eliot

> Andrey Repin wrote at about 21:05:48 +0300 on Thursday, January 6, 2022:
>   > Greetings, Corinna Vinschen!
>   >
>   > > On Jan  3 10:51, cygwin@kosowsky.org wrote:
>   > >> I have a file: /c/Config.Msi/3da9e136.rbf that I cannot copy, even when
>   > >> [...]
>   > >>       # getfacl 3da9e136.rbf
>   > >>       # file: 3da9e136.rbf
>   > >>       # owner: Administrators
>   > >>       # group: SYSTEM
>   > >>       user::rwx
>   > >>       group::rwx
>   > >>       other::r-x
>   > >>       user::rwx
>   > >>       group::rwx
>   > >>       group:SYSTEM:rwx
>   > >>       mask::rwx
>   > >>       other::r-x
>   > >> [...]
>   > >> Note that 'subinacl' shows:
>   > >> =================================
>   > >> +File C:\Config.Msi\3da9e136.rbf
>   > >> =================================
>   > >> /control=0x0
>   > >> /owner             =builtin\administrators
>   > >> /primary group     =system
>   > >> /audit ace count   =0
>   > >> /perm. ace count   =3
>   > >> /pace =system  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
>   > >> /pace =everyone  Type=0x0 Flags=0x3 AccessMask=0x1200a9
>   > >> /pace =builtin\administrators  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
>   >
>   > > I don't see a reliable, trustable source for downloading subinacl, so
>   > > let's do this with builtin tools.
>   >
>   > https://download.microsoft.com/download/1/7/d/17d82b72-bc6a-4dc8-bfaa-98b37b22b367/subinacl.msi
>   > Since installer is signed, you can verify its integrity.
>   >
>   >
>   > --
>   > With best regards,
>   > Andrey Repin
>   > Thursday, January 6, 2022 21:05:06
>   >
>   > Sorry for my terrible english...
>   >
>   >
>   > --
>   > 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
> 

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

[cygwin]

Hi Corinna,

Corinna Vinschen wrote:
> On Jan  3 10:51, cyg...@kosowsky.org wrote:
> > I have a file: /c/Config.Msi/3da9e136.rbf that I cannot copy, even when
> > [...]
> >       # getfacl 3da9e136.rbf
> >       # file: 3da9e136.rbf
> >       # owner: Administrators
> >       # group: SYSTEM
> >       user::rwx
> >       group::rwx
> >       other::r-x
> >       user::rwx
> >       group::rwx
> >       group:SYSTEM:rwx
> >       mask::rwx
> >       other::r-x
> > [...]
> > Note that 'subinacl' shows:
> > =================================
> > +File C:\Config.Msi\3da9e136.rbf
> > =================================
> > /control=0x0
> > /owner             =builtin\administrators
> > /primary group     =system
> > /audit ace count   =0
> > /perm. ace count   =3
> > /pace =system  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
> > /pace =everyone  Type=0x0 Flags=0x3 AccessMask=0x1200a9
> > /pace =builtin\administrators  Type=0x0 Flags=0x3 AccessMask=0x1f01ff
> 
> I don't see a reliable, trustable source for downloading subinacl, so
> let's do this with builtin tools.
> 
> I'm not sure what's going on on your machine.  I tried to reproduce your
> issue by creating a file with the exact same DACL:
> 
>   $ cat aclfile.sav
>   acltest
>   D:P(A;;FA;;;SY)(A;;0x1200a9;;;WD)(A;;FA;;;BA)
> 
> Note that the file is in UTF-16, the first two bytes are the BOM.
> 
>   $ icacls . /restore aclfile.sav
>   processed file: .\acltest
>   Successfully processed 1 files; Failed processing 0 files
>   $ icacls acltest
>   acltest NT AUTHORITY\SYSTEM:(F)
>           Everyone:(RX)
>           BUILTIN\Administrators:(F)
> 
>   Successfully processed 1 files; Failed processing 0 files
>   $ getfacl acltest
>   # file: acltest
>   # owner: Administrators
>   # group: SYSTEM
>   user::rwx
>   group::rwx
>   other::r-x
> 
> Would you mind to run `icacls 3da9e136.rbf /save 3da9e136.acl
> and paste the content of 3da9e136.acl into your reply?

I ran the code you suggested:
  #icacls 3da9e136.rbf /save 3da9e136.acl
  processed file: 3da9e136.rbf
  Successfully processed 1 files; Failed processing 0 files

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

Not sure how to interpret the above but hope it's helpful...

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

  Successfully processed 1 files; Failed processing 0 files

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

> Please use "reply-to" to keep mail threading intact.  Your two
> mails in terms of this problem are disconnected for some reason.


Not sure why my MTA has not been threading properly but for some
reason I didn't receive your response either.

Hopefully this gets attached to the correct thread.

Jeff

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

[Corinna Vinschen]

On Jan  6 16:11, cygwin@kosowsky.org wrote:
> Corinna Vinschen wrote:
> > On Jan  3 10:51, cyg...@kosowsky.org wrote:
> > > I have a file: /c/Config.Msi/3da9e136.rbf that I cannot copy, even when
> > > [...]
> > >       # getfacl 3da9e136.rbf
> > >       # file: 3da9e136.rbf
> > >       # owner: Administrators
> > >       # group: SYSTEM
> > >       user::rwx
> > >       group::rwx
> > >       other::r-x
> > >       user::rwx
> > >       group::rwx
> > >       group:SYSTEM:rwx
> > >       mask::rwx
> > >       other::r-x
> > > [...]
> > [...]
> > Would you mind to run `icacls 3da9e136.rbf /save 3da9e136.acl
> > and paste the content of 3da9e136.acl into your reply?
> 
> I ran the code you suggested:
>   #icacls 3da9e136.rbf /save 3da9e136.acl
>   processed file: 3da9e136.rbf
>   Successfully processed 1 files; Failed processing 0 files
> 
>   #cat 3da9e136.acl
>   3da9e136.rbf
>   D:P(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;WD)(A;OICI;FA;;;BA)
> 
> Not sure how to interpret the above but hope it's helpful...

It is.  I realized belatedly, that 3da9e136.acl is apparently a
directory, not a file.  So I tweaked my local test accordingly, and
here's my session output:

  $ mkdir acltest
  $ chown Administrators.SYSTEM acltest
  $ cat aclfile.sav
  acltest
  D:P(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;WD)(A;OICI;FA;;;BA)
  $ icacls . /restore aclfile.sav
  processed file: .\acltest
  Successfully processed 1 files; Failed processing 0 files
  $ 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

>   #icacls 3da9e136.rbf
>   3da9e136.rbf NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>              Everyone:(OI)(CI)(RX)
>              BUILTIN\Administrators:(OI)(CI)(F)
> 
>   Successfully processed 1 files; Failed processing 0 files

So the DACL is now identical to yours.  Let's try getfacl:

  $ getfacl --version | head -1
  getfacl (cygwin) 3.3.3
  $ getfacl acltest
  # file: acltest
  # owner: Administrators
  # group: SYSTEM
  user::rwx
  group::rwx
  other::r-x
  default:user::rwx
  default:group::rwx
  default:group:SYSTEM:rwx
  default:mask::rwx
  default:other::r-x

Ok, that looks correct.  Now compare with the output of your getfacl:

>   #getfacl 3da9e136.rbf
>   # file: 3da9e136.rbf
>   # owner: Administrators
>   # group: SYSTEM
>   user::rwx
>   group::rwx
>   other::r-x
>   user::rwx
>   group::rwx
>   group:SYSTEM:rwx
>   mask::rwx
>   other::r-x

It's exactly the same as the one my gefacl prints above, except the
"default:" specifier for default ACEs is missing in the output.

I can't explain that, sorry.  Old getfacl version?  Running an output
filter of some sort?  Clutching at straws here....

> > Please use "reply-to" to keep mail threading intact.  Your two
> > mails in terms of this problem are disconnected for some reason.
> 
> Not sure why my MTA has not been threading properly but for some
> reason I didn't receive your response either.

By default I'm using "list-reply-to" in mutt, so replies are only
going to the mailing list.  I added you to the CC for this reply.

> Hopefully this gets attached to the correct thread.

It did, thanks.


Corinna

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

[cygwin]

> 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...
     # ls -al 3da9e136.rbf
     -rwxrwxr-x+ 1 Administrators SYSTEM 96728 Jul  8  2018 3da9e136.rbf*

     #file 3da9e136.rbf
     3da9e136.acl: data
     3da9e136.rbf: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Window

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

    Successfully processed 1 files; Failed processing 0 files

But:
    #icacls 3da9e136.rbf /save 3da9e136.acl
    processed file: 3da9e136.rbf
    Successfully processed 1 files; Failed processing 0 files

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


> So I tweaked my local test accordingly, and
> here's my session output:
> 
>   $ mkdir acltest
>     $ chown Administrators.SYSTEM acltest
>       $ cat aclfile.sav
>         acltest
> 	  D:P(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;WD)(A;OICI;FA;;;BA)
> 	    $ icacls . /restore aclfile.sav
> 	      processed file: .\acltest
> 	        Successfully processed 1 files; Failed processing 0
>     files
>       $ 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
> 
> >   #icacls 3da9e136.rbf
> >   3da9e136.rbf NT AUTHORITY\SYSTEM:(OI)(CI)(F)
> >              Everyone:(OI)(CI)(RX)
> >              BUILTIN\Administrators:(OI)(CI)(F)
> >
> >   Successfully processed 1 files; Failed processing 0 files
> 
> So the DACL is now identical to yours.  Let's try getfacl:
> 
>   $ getfacl --version | head -1
>     getfacl (cygwin) 3.3.3
>       $ getfacl acltest
>         # file: acltest
> 	  # owner: Administrators
> 	    # group: SYSTEM
> 	      user::rwx
> 	        group::rwx
> 		  other::r-x
> 		    default:user::rwx
> 		      default:group::rwx
> 		        default:group:SYSTEM:rwx
> 			  default:mask::rwx
> 			    default:other::r-x
> 
> Ok, that looks correct.  Now compare with the output of your getfacl:
> 
> >   #getfacl 3da9e136.rbf
> >   # file: 3da9e136.rbf
> >   # owner: Administrators
> >   # group: SYSTEM
> >   user::rwx
> >   group::rwx
> >   other::r-x
> >   user::rwx
> >   group::rwx
> >   group:SYSTEM:rwx
> >   mask::rwx
> >   other::r-x
> 
> It's exactly the same as the one my gefacl prints above, except the
> "default:" specifier for default ACEs is missing in the output.

Could that because yours is a directory and mine is a file

> I can't explain that, sorry.  Old getfacl version?  Running an output
> filter of some sort?  Clutching at straws here....

  #getfacl --version | head -1
  getfacl (cygwin) 3.3.3

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

[Corinna Vinschen]

On Jan  7 15:56, cygwin@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).

Consequentially, if I use `icacls /restore' on a file with the DACL
saved by you, the OI and CI bits are simply ignored.  After /restore,
if I call /save again the resulting file looks like this:

  $ cat aclfile-after-restore.sav
  acltest
  D:PAI(A;;FA;;;SY)(A;;0x1200a9;;;WD)(A;;FA;;;BA)

However, this gave me a clue.  If this is really a file, it's a good
chance that the inheritance flags are restricted to directories at
one point in either the Cygwin DLL itself, or the getfacl tool.

I'll have a look into the sources later, but I sure would prefer if
I could create such a file locally.


Thanks,
Corinna

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

[Corinna Vinschen]

On Jan 10 11:07, Corinna Vinschen wrote:
> On Jan  7 15:56, cygwin@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).
> 
> Consequentially, if I use `icacls /restore' on a file with the DACL
> saved by you, the OI and CI bits are simply ignored.  After /restore,
> if I call /save again the resulting file looks like this:
> 
>   $ cat aclfile-after-restore.sav
>   acltest
>   D:PAI(A;;FA;;;SY)(A;;0x1200a9;;;WD)(A;;FA;;;BA)

FTR, it's even worse.  Windows ACEs with inheritence flags result in
equivalent POSIX default ACEs.  Per Linux (or better, POSIX 1003.1e
draft 17), it's an error trying to set default ACEs on files.
Therefore, a process trying to set the permissions as in your case
would result in getting errno EACCES.  Cygwin follows suit.

> However, this gave me a clue.  If this is really a file, it's a good
> chance that the inheritance flags are restricted to directories at
> one point in either the Cygwin DLL itself, or the getfacl tool.
> 
> 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.  After running icacls
/restore the resulting DACL does not contain inheritance flags on none
of the systems.  Neither do the different Windows GUIs allow setting
inheritance flags on files.

I also ran getfacl under GDB and manipulated getfacl into believing that
a directory with matching ACL is actually a file, but the output generated
by getfacl was not showing the default ACEs at all:

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


¯\_(ツ)_/¯
Corinna

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

[Corinna Vinschen]

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

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

[cygwin]

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

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

[Corinna Vinschen]

On Jan 18 21:26, cygwin@kosowsky.org wrote:
> On Jan 04:14 Corinna Vinschen wrote:
> > I uploaded a developer snapshot to https://cygwin.com/snapshots
> > Please give it a try.
> 
> 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'.
> [...]
> So, the full Windows ACLs as indicated by 'icacls' differ.
> Is this the expected behavior??? If so, why???

Cygwin converts the DACL into a a POSIX ACL on the API level and Cygwin
tools consequentially read and write POSIX ACLs, which differ from
Windows ACLs.


Corinna

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

[cygwin]

Hi Corinna,
I found another file with ACLs that fail even under the new snapshot
cygwin1.dll.

#getfacl setup.ilg
# file: setup.ilg
# owner: Administrators
# group: None
getfacl: setup.ilg: Invalid argument

#icacls.exe setup.ilg
setup.ilg NT SERVICE\TrustedInstaller:(I)(F)
          NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
          NT AUTHORITY\SYSTEM:(I)(F)
          NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
          BUILTIN\Administrators:(I)(F)
          BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
          BUILTIN\Users:(I)(RX)
          BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
          CREATOR OWNER:(I)(OI)(CI)(IO)(F)

#icacls.exe setup.ilg /save setup.acl
#cat setup.acl
setup.ilg
D:(A;ID;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;CIIOID;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;0x1200a9;;;BU)(A;OICIIOID;GXGR;;;BU)(A;OICIIOID;GA;;;CO)

-------------
Any thoughts on what might be wrong here?

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

[Corinna Vinschen]

On Jan 21 08:57, cygwin@kosowsky.org wrote:
> Hi Corinna,
> I found another file with ACLs that fail even under the new snapshot
> cygwin1.dll.
> 
> #getfacl setup.ilg
> # file: setup.ilg
> # owner: Administrators
> # group: None
> getfacl: setup.ilg: Invalid argument
> 
> #icacls.exe setup.ilg
> setup.ilg NT SERVICE\TrustedInstaller:(I)(F)
>           NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
>           NT AUTHORITY\SYSTEM:(I)(F)
>           NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
>           BUILTIN\Administrators:(I)(F)
>           BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
>           BUILTIN\Users:(I)(RX)
>           BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
>           CREATOR OWNER:(I)(OI)(CI)(IO)(F)
> 
> #icacls.exe setup.ilg /save setup.acl
> #cat setup.acl
> setup.ilg
> D:(A;ID;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;CIIOID;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;0x1200a9;;;BU)(A;OICIIOID;GXGR;;;BU)(A;OICIIOID;GA;;;CO)
> 
> -------------
> Any thoughts on what might be wrong here?

Again, the permissions don't make sense.  However, that's no good reason
for Cygwin to bail out like this.  I found the culprit, the core function
was still setting a certain indicator value for default ACEs even on
files.  I pushed a patch and created new developer snapshots.


Thanks,
Corinna

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

[cygwin]

Corinna Vinschen wrote at about 20:19:42 +0100 on Tuesday, January 25, 2022:
 > On Jan 21 08:57, cygwin@kosowsky.org wrote:
 > > Hi Corinna,
 > > I found another file with ACLs that fail even under the new snapshot
 > > cygwin1.dll.
 > > 
 > > #getfacl setup.ilg
 > > # file: setup.ilg
 > > # owner: Administrators
 > > # group: None
 > > getfacl: setup.ilg: Invalid argument
 > > 
 > > #icacls.exe setup.ilg
 > > setup.ilg NT SERVICE\TrustedInstaller:(I)(F)
 > >           NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
 > >           NT AUTHORITY\SYSTEM:(I)(F)
 > >           NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
 > >           BUILTIN\Administrators:(I)(F)
 > >           BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
 > >           BUILTIN\Users:(I)(RX)
 > >           BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
 > >           CREATOR OWNER:(I)(OI)(CI)(IO)(F)
 > > 
 > > #icacls.exe setup.ilg /save setup.acl
 > > #cat setup.acl
 > > setup.ilg
 > > D:(A;ID;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;CIIOID;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;0x1200a9;;;BU)(A;OICIIOID;GXGR;;;BU)(A;OICIIOID;GA;;;CO)
 > > 
 > > -------------
 > > Any thoughts on what might be wrong here?
 > 
 > Again, the permissions don't make sense.  However, that's no good reason
 > for Cygwin to bail out like this.  I found the culprit, the core function
 > was still setting a certain indicator value for default ACEs even on
 > files.  I pushed a patch and created new developer snapshots.
 > 

Thanks Corinna!
That fixed it -- and eliminates pesky 'rsync' errors that I was
encountering on my backup program.

Jeff