Cygwin making files inaccessible?

Cygwin making files inaccessible?

[Jay K]

Cygwin making files inaccessible?
i.e. when Cygwin copies or writes to them, not random files.

C:\t>dir /s/b/a

C:\t>dir /q .

02/05/2022  04:11 AM    <DIR>          BUILTIN\Administrators .
02/05/2022  04:11 AM    <DIR>          NT SERVICE\TrustedInsta..

C:\t>cacls .
C:\t Everyone:(OI)(CI)F

C:\t>echo > 1.txt

C:\t>cacls 1.txt
C:\t\1.txt Everyone:F

C:\t>copy 1.txt 2.txt
        1 file(s) copied.

C:\t>cacls 2.txt
C:\t\2.txt Everyone:F

C:\t>del 2.txt

C:\t>uname -a
CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin

C:\t>cp 1.txt 2.txt

C:\t>which cp
/usr/bin/cp

C:\t>cacls 2.txt
C:\t\2.txt NULL SID:(DENY)(special access:)
                    READ_CONTROL

           DESKTOP-BCFUMJ4\jay:(DENY)(special access:)
                               FILE_READ_DATA
                               FILE_READ_EA
                               FILE_EXECUTE

           DESKTOP-BCFUMJ4\jay:(special access:)
                               STANDARD_RIGHTS_ALL
                               DELETE
                               READ_CONTROL
                               WRITE_DAC
                               WRITE_OWNER
                               SYNCHRONIZE
                               STANDARD_RIGHTS_REQUIRED
                               FILE_READ_ATTRIBUTES
                               FILE_WRITE_ATTRIBUTES

           DESKTOP-BCFUMJ4\None:R
           Everyone:R


C:\t>more 1.txt
ECHO is on.

C:\t>more 2.txt
Cannot access file C:\t\2.txt

Same behavior from cygwin64.

C:\t>\cygwin64\bin\uname -a
CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin

Huh?

I would hope Cygwin could/would just copy the ACLs asis.
I am guessing there is some failed attempt to translate them
to an internal form and then back to NT form.

My real scenario was open/write/read, not cp.exe.

 - Jay

Re: Cygwin making files inaccessible?

[Jay K]

I looked at this a while. I tried various recent cygwin1.dlls as there were two ACL changes recently.
I tried building cygwin1.dll with those changes reverted, but failed to build it. 
For one thing it took me a while to find shilka..it is in cocom, but that wasn't the entire problem.

Eventually.. I noticed the behavior was not the same for every file/directory/volume. Sometimes it worked ok.
Though I think the ACLs still get changed quite a bit: "full" expands to "many".
Of course it has worked plenty for me and everyone else.

Eventually I tried chmod -R 777 * and this seems to have worked.

I speculate that some "bad" Cygwin ACLs got created at some point.
 And maybe cacls wasn't deleting them?? That parts seems wierd. Maybe on directories?
Possibly due to those two recent changes, or maybe user error, I don't know.

 - Jay



From: Jay K
Sent: Saturday, February 5, 2022 12:16 PM
To: cygwin@cygwin.com <cygwin@cygwin.com>
Subject: Cygwin making files inaccessible? 
 
Cygwin making files inaccessible?
i.e. when Cygwin copies or writes to them, not random files.

C:\t>dir /s/b/a

C:\t>dir /q .

02/05/2022  04:11 AM    <DIR>          BUILTIN\Administrators .
02/05/2022  04:11 AM    <DIR>          NT SERVICE\TrustedInsta..

C:\t>cacls .
C:\t Everyone:(OI)(CI)F

C:\t>echo > 1.txt

C:\t>cacls 1.txt
C:\t\1.txt Everyone:F

C:\t>copy 1.txt 2.txt
        1 file(s) copied.

C:\t>cacls 2.txt
C:\t\2.txt Everyone:F

C:\t>del 2.txt

C:\t>uname -a
CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin

C:\t>cp 1.txt 2.txt

C:\t>which cp
/usr/bin/cp

C:\t>cacls 2.txt
C:\t\2.txt NULL SID:(DENY)(special access:)
                    READ_CONTROL

           DESKTOP-BCFUMJ4\jay:(DENY)(special access:)
                               FILE_READ_DATA
                               FILE_READ_EA
                               FILE_EXECUTE

           DESKTOP-BCFUMJ4\jay:(special access:)
                               STANDARD_RIGHTS_ALL
                               DELETE
                               READ_CONTROL
                               WRITE_DAC
                               WRITE_OWNER
                               SYNCHRONIZE
                               STANDARD_RIGHTS_REQUIRED
                               FILE_READ_ATTRIBUTES
                               FILE_WRITE_ATTRIBUTES

           DESKTOP-BCFUMJ4\None:R
           Everyone:R


C:\t>more 1.txt
ECHO is on.

C:\t>more 2.txt
Cannot access file C:\t\2.txt

Same behavior from cygwin64.

C:\t>\cygwin64\bin\uname -a
CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin

Huh?

I would hope Cygwin could/would just copy the ACLs asis.
I am guessing there is some failed attempt to translate them
to an internal form and then back to NT form.

My real scenario was open/write/read, not cp.exe.

 - Jay

Re: Cygwin making files inaccessible?

[Andrey Repin]

Greetings, Jay K!

> I looked at this a while. I tried various recent cygwin1.dlls as there were two ACL changes recently.
> I tried building cygwin1.dll with those changes reverted, but failed to build it. 
> For one thing it took me a while to find shilka..it is in cocom, but that wasn't the entire problem.

> Eventually.. I noticed the behavior was not the same for every
> file/directory/volume. Sometimes it worked ok.
> Though I think the ACLs still get changed quite a bit: "full" expands to "many".
> Of course it has worked plenty for me and everyone else.

> Eventually I tried chmod -R 777 * and this seems to have worked.

> I speculate that some "bad" Cygwin ACLs got created at some point.
>  And maybe cacls wasn't deleting them?? That parts seems wierd. Maybe on directories?
> Possibly due to those two recent changes, or maybe user error, I don't know.

This may happen outside Cygwin tree, when initial ACL's are set in some
interesting way.
One possible solution is to tweak /cygdrive mount point to include "noacl"
flag, deferring all ACL modifications to Windows.

(Please bottom post in this list. Thank you.)


> From: Jay K
> Sent: Saturday, February 5, 2022 12:16 PM
> To: cygwin@cygwin.com <cygwin@cygwin.com>
> Subject: Cygwin making files inaccessible? 
>  
> Cygwin making files inaccessible?
> i.e. when Cygwin copies or writes to them, not random files.

> C:\t>dir /s/b/a

> C:\t>dir /q .

> 02/05/2022  04:11 AM    <DIR>          BUILTIN\Administrators .
> 02/05/2022  04:11 AM    <DIR>          NT SERVICE\TrustedInsta..

> C:\t>cacls .
> C:\t Everyone:(OI)(CI)F

> C:\t>echo > 1.txt

> C:\t>cacls 1.txt
> C:\t\1.txt Everyone:F

> C:\t>copy 1.txt 2.txt
>         1 file(s) copied.

> C:\t>cacls 2.txt
> C:\t\2.txt Everyone:F

> C:\t>del 2.txt

> C:\t>uname -a
> CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin

> C:\t>cp 1.txt 2.txt

> C:\t>which cp
> /usr/bin/cp

> C:\t>cacls 2.txt
> C:\t\2.txt NULL SID:(DENY)(special access:)
>                     READ_CONTROL

>            DESKTOP-BCFUMJ4\jay:(DENY)(special access:)
>                                FILE_READ_DATA
>                                FILE_READ_EA
>                                FILE_EXECUTE

>            DESKTOP-BCFUMJ4\jay:(special access:)
>                                STANDARD_RIGHTS_ALL
>                                DELETE
>                                READ_CONTROL
>                                WRITE_DAC
>                                WRITE_OWNER
>                                SYNCHRONIZE
>                                STANDARD_RIGHTS_REQUIRED
>                                FILE_READ_ATTRIBUTES
>                                FILE_WRITE_ATTRIBUTES

>            DESKTOP-BCFUMJ4\None:R
>            Everyone:R


> C:\t>more 1.txt
> ECHO is on.

> C:\t>more 2.txt
> Cannot access file C:\t\2.txt

> Same behavior from cygwin64.

> C:\t>\cygwin64\bin\uname -a
> CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin

> Huh?

> I would hope Cygwin could/would just copy the ACLs asis.
> I am guessing there is some failed attempt to translate them
> to an internal form and then back to NT form.

> My real scenario was open/write/read, not cp.exe.

>  - Jay



-- 
With best regards,
Andrey Repin
Monday, February 7, 2022 9:59:12

Sorry for my terrible english...

Re: Cygwin making files inaccessible?

[Brian Inglis]

On 2022-02-06 22:23, Jay K wrote:
> I looked at this a while. I tried various recent cygwin1.dlls as there were two ACL changes recently.
> Eventually. I noticed the behavior was not the same for every file/directory/volume. Sometimes it worked ok.
> Though I think the ACLs still get changed quite a bit: "full" expands to "many".
> Of course it has worked plenty for me and everyone else.
> Eventually I tried chmod -R 777 * and this seems to have worked.
> I speculate that some "bad" Cygwin ACLs got created at some point.
> And maybe cacls wasn't deleting them?? That parts seems wierd. Maybe on directories?
> Possibly due to those two recent changes, or maybe user error, I don't know.

I found after a Windows level restore from backup I had to retweak a lot 
of Cygwin directory DACLs and directory and file perms;
often setfacl -b does the trick if the file perms "+" ACL flag is set;
when that doesn't work I use scripts that set:

Normal:

perms=a+r,u+w,go-w
dacl=u::rwx,g::r-x,o::r-x,d:u::rwx,d:g::r-x,d:o::r-x

Shared/Sticky/Tmp:

perms=a+rwxt
dacl=u::rwx,g::rwx,o::rwx,d:u::rwx,d:g::rwx,d:o::rwx

Change Windows defaults to Cygwin non-exec defaults:

perms=a+r-x,u+w,go-w
dacl=u::rwx,g::r-x,o::r-x,d:u::rwx,d:g::r-x,d:o::r-x

Add u+x or a+x for executable scripts or commands.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Cygwin making files inaccessible?

[Roland Schwingel]

Hi...

I have seen similar problems on my side, but could not knock them down 
100% reproducable to get a good recipe for debugging it. I got this best 
reproduceable if I generate a tar on linux with eg a windows .exe 
inside. and than untar it on cygwin.  Afterwards ACLs were broken. Not 
every time but frequently. When using windows Explorer I got a message 
like "Permissions are not sorted in the correct way" (in german) when I 
tried to see permissions. And afterwards they have been quite strange 
and files where not accessable / executable.

I have it with 3.x up to 3.3.4.

Roland

"Cygwin" <cygwin-bounces+roland.schwingel=onevision.de@cygwin.com> wrote 
on 07.02.2022 08:01:33:

 > From: "Andrey Repin" <anrdaemon@yandex.ru>
 > To: "Jay K" <jayk123@hotmail.com>, cygwin@cygwin.com
 > Date: 07.02.2022 08:05
 > Subject: Re: Cygwin making files inaccessible?
 > Sent by: "Cygwin" 
<cygwin-bounces+roland.schwingel=onevision.de@cygwin.com>
 >
 > Greetings, Jay K!
 >
 > > I looked at this a while. I tried various recent cygwin1.dlls as
 > there were two ACL changes recently.
 > > I tried building cygwin1.dll with those changes reverted, but
 > failed to build it.
 > > For one thing it took me a while to find shilka..it is in cocom,
 > but that wasn't the entire problem.
 >
 > > Eventually.. I noticed the behavior was not the same for every
 > > file/directory/volume. Sometimes it worked ok.
 > > Though I think the ACLs still get changed quite a bit: "full"
 > expands to "many".
 > > Of course it has worked plenty for me and everyone else.
 >
 > > Eventually I tried chmod -R 777 * and this seems to have worked.
 >
 > > I speculate that some "bad" Cygwin ACLs got created at some point.
 > >  And maybe cacls wasn't deleting them?? That parts seems wierd.
 > Maybe on directories?
 > > Possibly due to those two recent changes, or maybe user error, I 
don't know.
 >
 > This may happen outside Cygwin tree, when initial ACL's are set in some
 > interesting way.
 > One possible solution is to tweak /cygdrive mount point to include 
"noacl"
 > flag, deferring all ACL modifications to Windows.
 >
 > (Please bottom post in this list. Thank you.)
 >
 >
 > > From: Jay K
 > > Sent: Saturday, February 5, 2022 12:16 PM
 > > To: cygwin@cygwin.com <cygwin@cygwin.com>
 > > Subject: Cygwin making files inaccessible?
 > >
 > > Cygwin making files inaccessible?
 > > i.e. when Cygwin copies or writes to them, not random files.
 >
 > > C:\t>dir /s/b/a
 >
 > > C:\t>dir /q .
 >
 > > 02/05/2022  04:11 AM    <DIR>          BUILTIN\Administrators .
 > > 02/05/2022  04:11 AM    <DIR>          NT SERVICE\TrustedInsta..
 >
 > > C:\t>cacls .
 > > C:\t Everyone:(OI)(CI)F
 >
 > > C:\t>echo > 1.txt
 >
 > > C:\t>cacls 1.txt
 > > C:\t\1.txt Everyone:F
 >
 > > C:\t>copy 1.txt 2.txt
 > >         1 file(s) copied.
 >
 > > C:\t>cacls 2.txt
 > > C:\t\2.txt Everyone:F
 >
 > > C:\t>del 2.txt
 >
 > > C:\t>uname -a
 > > CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:
 > 31 i686 Cygwin
 >
 > > C:\t>cp 1.txt 2.txt
 >
 > > C:\t>which cp
 > > /usr/bin/cp
 >
 > > C:\t>cacls 2.txt
 > > C:\t\2.txt NULL SID:(DENY)(special access:)
 > >                     READ_CONTROL
 >
 > >            DESKTOP-BCFUMJ4\jay:(DENY)(special access:)
 > >                                FILE_READ_DATA
 > >                                FILE_READ_EA
 > >                                FILE_EXECUTE
 >
 > >            DESKTOP-BCFUMJ4\jay:(special access:)
 > >                                STANDARD_RIGHTS_ALL
 > >                                DELETE
 > >                                READ_CONTROL
 > >                                WRITE_DAC
 > >                                WRITE_OWNER
 > >                                SYNCHRONIZE
 > >                                STANDARD_RIGHTS_REQUIRED
 > >                                FILE_READ_ATTRIBUTES
 > >                                FILE_WRITE_ATTRIBUTES
 >
 > >            DESKTOP-BCFUMJ4\None:R
 > >            Everyone:R
 >
 >
 > > C:\t>more 1.txt
 > > ECHO is on.
 >
 > > C:\t>more 2.txt
 > > Cannot access file C:\t\2.txt
 >
 > > Same behavior from cygwin64.
 >
 > > C:\t>\cygwin64\bin\uname -a
 > > CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35
 > x86_64 Cygwin
 >
 > > Huh?
 >
 > > I would hope Cygwin could/would just copy the ACLs asis.
 > > I am guessing there is some failed attempt to translate them
 > > to an internal form and then back to NT form.
 >
 > > My real scenario was open/write/read, not cp.exe.
 >
 > >  - Jay
 >
 >
 >
 > --
 > With best regards,
 > Andrey Repin
 > Monday, February 7, 2022 9:59:12
 >
 > 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
 >