chmod issue on 3.1.7.

chmod issue on 3.1.7.

[Kaz Kylheku (Cygwin)]

Hi all,

Running this Cygwin on a Windows 10 system:

   0:DESKTOP-K8055OB:~$ uname -a
   CYGWIN_NT-10.0-WOW DESKTOP-K8055OB 3.1.7(0.340/5/3) 2020-08-22 19:03 
i686 Cygwi

When a file is created, and permissions set as follows:

   0:DESKTOP-K8055OB:~$ touch tempfile
   0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
   0:DESKTOP-K8055OB:~$ ls -l tempfile
   -rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile

Then "chmod u=" is not able to clear the owner's permissions to nothing:

   0:DESKTOP-K8055OB:~$ chmod u= tempfile
   0:DESKTOP-K8055OB:~$ ls -l tempfile
   -rwxrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile

As you can see, it has no effect. The expected value is ----rwsrwt.

I tried both with 64 and 32 bit Cygwin: same deal.

This is not a problem with the chmod utility.  I ran into this as a 
failing
test case against a chmod library function in a programming language.

http://www.kylheku.com/cgit/txr/tree/tests/018/chmod.tl

The test cases pass until the "u=", which fails in the same way.
This does not use the chmod utility.

It's an issue with the chmod system call.

This used to work on my older Cygwin installation, which was around 2.5.

Re: chmod issue on 3.1.7.

[Ken Brown]

On 10/10/2020 12:32 PM, Kaz Kylheku (Cygwin) via Cygwin wrote:
> Hi all,
> 
> Running this Cygwin on a Windows 10 system:
> 
>    0:DESKTOP-K8055OB:~$ uname -a
>    CYGWIN_NT-10.0-WOW DESKTOP-K8055OB 3.1.7(0.340/5/3) 2020-08-22 19:03 i686 Cygwi
> 
> When a file is created, and permissions set as follows:
> 
>    0:DESKTOP-K8055OB:~$ touch tempfile
>    0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
>    0:DESKTOP-K8055OB:~$ ls -l tempfile
>    -rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
> 
> Then "chmod u=" is not able to clear the owner's permissions to nothing:
> 
>    0:DESKTOP-K8055OB:~$ chmod u= tempfile
>    0:DESKTOP-K8055OB:~$ ls -l tempfile
>    -rwxrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
> 
> As you can see, it has no effect. The expected value is ----rwsrwt.
> 
> I tried both with 64 and 32 bit Cygwin: same deal.
> 
> This is not a problem with the chmod utility.  I ran into this as a failing
> test case against a chmod library function in a programming language.
> 
> http://www.kylheku.com/cgit/txr/tree/tests/018/chmod.tl
> 
> The test cases pass until the "u=", which fails in the same way.
> This does not use the chmod utility.
> 
> It's an issue with the chmod system call.
> 
> This used to work on my older Cygwin installation, which was around 2.5.

FWIW, I can't reproduce this on my system:

$ uname -a
CYGWIN_NT-10.0-WOW XXX 3.1.7(0.340/5/3) 2020-08-22 19:03 i686 Cygwin

$ touch tempfile

$ ls -l tempfile
-rw-r--r-- 1 kbrown None 0 2020-10-10 15:16 tempfile

$ chmod 03777 tempfile

$ ls -l tempfile
-rwxrwsrwt 1 kbrown None 0 2020-10-10 15:16 tempfile

$ chmod u= tempfile

$ ls -l tempfile
----rwsrwt 1 kbrown None 0 2020-10-10 15:16 tempfile

Ken

Re: chmod issue on 3.1.7.

[Brian Inglis]

On 2020-10-10 13:41, Ken Brown via Cygwin wrote:
> On 10/10/2020 12:32 PM, Kaz Kylheku (Cygwin) via Cygwin wrote:
>> Hi all,
>>
>> Running this Cygwin on a Windows 10 system:
>>
>>    0:DESKTOP-K8055OB:~$ uname -a
>>    CYGWIN_NT-10.0-WOW DESKTOP-K8055OB 3.1.7(0.340/5/3) 2020-08-22 19:03 i686
>> Cygwi
>>
>> When a file is created, and permissions set as follows:
>>
>>    0:DESKTOP-K8055OB:~$ touch tempfile
>>    0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
>>    0:DESKTOP-K8055OB:~$ ls -l tempfile
>>    -rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
>>
>> Then "chmod u=" is not able to clear the owner's permissions to nothing:
>>
>>    0:DESKTOP-K8055OB:~$ chmod u= tempfile
>>    0:DESKTOP-K8055OB:~$ ls -l tempfile
>>    -rwxrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
>>
>> As you can see, it has no effect. The expected value is ----rwsrwt.
>>
>> I tried both with 64 and 32 bit Cygwin: same deal.
>>
>> This is not a problem with the chmod utility.  I ran into this as a failing
>> test case against a chmod library function in a programming language.
>>
>> http://www.kylheku.com/cgit/txr/tree/tests/018/chmod.tl
>>
>> The test cases pass until the "u=", which fails in the same way.
>> This does not use the chmod utility.
>>
>> It's an issue with the chmod system call.
>>
>> This used to work on my older Cygwin installation, which was around 2.5.
> 
> FWIW, I can't reproduce this on my system:
> 
> $ uname -a
> CYGWIN_NT-10.0-WOW XXX 3.1.7(0.340/5/3) 2020-08-22 19:03 i686 Cygwin
> 
> $ touch tempfile
> 
> $ ls -l tempfile
> -rw-r--r-- 1 kbrown None 0 2020-10-10 15:16 tempfile
> 
> $ chmod 03777 tempfile
> 
> $ ls -l tempfile
> -rwxrwsrwt 1 kbrown None 0 2020-10-10 15:16 tempfile
> 
> $ chmod u= tempfile
> 
> $ ls -l tempfile
> ----rwsrwt 1 kbrown None 0 2020-10-10 15:16 tempfile

D/ACLs on the directory could restore/maintain the permissions:
could we please see the output from ls -l, getfacl, and icacls on the directory
and file?

-- 
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: chmod issue on 3.1.7.

[Kaz Kylheku (Cygwin)]

On 2020-10-10 14:51, Brian Inglis wrote:
> D/ACLs on the directory could restore/maintain the permissions:
> could we please see the output from ls -l, getfacl, and icacls on the 
> directory
> and file?

Thanks for your responses, Ken and Brian.

See what you can make of this:

0:DESKTOP-K8055OB:~$ ls -ld . tempfile
drwxr-xr-x+ 1 kaz kaz 0 Oct 11 09:07 .
-rwxrwsrwt  1 kaz kaz 0 Oct 10 09:08 tempfile
0:DESKTOP-K8055OB:~$ getfacl .
# file: .
# owner: kaz
# group: kaz
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

0:DESKTOP-K8055OB:~$ getfacl tempfile
# file: tempfile
# owner: kaz
# group: kaz
# flags: -st
user::rwx
group::rwx
other::rwx

0:DESKTOP-K8055OB:~$ icacls .
. DESKTOP-K8055OB\kaz:(F)
   DESKTOP-K8055OB\kaz:(RX)
   Everyone:(RX)
   CREATOR OWNER:(OI)(CI)(IO)(F)
   CREATOR GROUP:(OI)(CI)(IO)(RX)
   Everyone:(OI)(CI)(IO)(RX)

Successfully processed 1 files; Failed processing 0 files
0:DESKTOP-K8055OB:~$ icacls tempfile
tempfile NULL SID:(DENY)(Rc,S,RD,WD)
          DESKTOP-K8055OB\kaz:(F)
          DESKTOP-K8055OB\kaz:(RX,W)
          Everyone:(RX,W)

Successfully processed 1 files; Failed processing 0 files

Re: chmod issue on 3.1.7.

[Kaz Kylheku (Cygwin)]

On 2020-10-10 09:32, Kaz Kylheku (Cygwin) via Cygwin wrote:
> Hi all,
> 
> Running this Cygwin on a Windows 10 system:
> 
>   0:DESKTOP-K8055OB:~$ uname -a
>   CYGWIN_NT-10.0-WOW DESKTOP-K8055OB 3.1.7(0.340/5/3) 2020-08-22 19:03
> i686 Cygwi
> 
> When a file is created, and permissions set as follows:
> 
>   0:DESKTOP-K8055OB:~$ touch tempfile
>   0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
>   0:DESKTOP-K8055OB:~$ ls -l tempfile
>   -rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
> 
> Then "chmod u=" is not able to clear the owner's permissions to 
> nothing:
> 
>   0:DESKTOP-K8055OB:~$ chmod u= tempfile
>   0:DESKTOP-K8055OB:~$ ls -l tempfile
>   -rwxrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
> 
> As you can see, it has no effect. The expected value is ----rwsrwt.
> 
> I tried both with 64 and 32 bit Cygwin: same deal.
> 
> This is not a problem with the chmod utility.  I ran into this as a 
> failing
> test case against a chmod library function in a programming language.
> 
> http://www.kylheku.com/cgit/txr/tree/tests/018/chmod.tl
> 
> The test cases pass until the "u=", which fails in the same way.
> This does not use the chmod utility.
> 
> It's an issue with the chmod system call.
> 
> This used to work on my older Cygwin installation, which was around 
> 2.5.

Anyone have a clue about this issue?

$ icacls tempfile
tempfile NULL SID:(DENY)(Rc,S,RD,WD)
          BLACKBOX\kaz:(F)
          BLACKBOX\kaz:(RX,W)
          Everyone:(RX,W)

$ getfacl tempfile
# file: tempfile
# owner: kaz
# group: kaz
# flags: -st
user::rwx
group::rwx
other::rwx

$ ls -l tempfile
-rwxrwsrwt 1 kaz kaz 0 Dec 24 13:09 tempfile

$ chmod u= tempfile
$ ls -l tempfile
-rwxrwsrwt 1 kaz kaz 0 Dec 24 13:09 tempfile

Re: chmod issue on 3.1.7.

[Ken Brown]

On 12/24/2020 4:13 PM, Kaz Kylheku (Cygwin) via Cygwin wrote:
> On 2020-10-10 09:32, Kaz Kylheku (Cygwin) via Cygwin wrote:
>> Hi all,
>>
>> Running this Cygwin on a Windows 10 system:
>>
>>   0:DESKTOP-K8055OB:~$ uname -a
>>   CYGWIN_NT-10.0-WOW DESKTOP-K8055OB 3.1.7(0.340/5/3) 2020-08-22 19:03
>> i686 Cygwi
>>
>> When a file is created, and permissions set as follows:
>>
>>   0:DESKTOP-K8055OB:~$ touch tempfile
>>   0:DESKTOP-K8055OB:~$ chmod 03777 tempfile
>>   0:DESKTOP-K8055OB:~$ ls -l tempfile
>>   -rwsrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
>>
>> Then "chmod u=" is not able to clear the owner's permissions to nothing:
>>
>>   0:DESKTOP-K8055OB:~$ chmod u= tempfile
>>   0:DESKTOP-K8055OB:~$ ls -l tempfile
>>   -rwxrwsrwt 1 kaz kaz 0 Oct 10 08:59 tempfile
>>
>> As you can see, it has no effect. The expected value is ----rwsrwt.
>>
>> I tried both with 64 and 32 bit Cygwin: same deal.
>>
>> This is not a problem with the chmod utility.  I ran into this as a failing
>> test case against a chmod library function in a programming language.
>>
>> http://www.kylheku.com/cgit/txr/tree/tests/018/chmod.tl
>>
>> The test cases pass until the "u=", which fails in the same way.
>> This does not use the chmod utility.
>>
>> It's an issue with the chmod system call.
>>
>> This used to work on my older Cygwin installation, which was around 2.5.
> 
> Anyone have a clue about this issue?
> 
> $ icacls tempfile
> tempfile NULL SID:(DENY)(Rc,S,RD,WD)
>           BLACKBOX\kaz:(F)
>           BLACKBOX\kaz:(RX,W)
>           Everyone:(RX,W)
> 
> $ getfacl tempfile
> # file: tempfile
> # owner: kaz
> # group: kaz
> # flags: -st
> user::rwx
> group::rwx
> other::rwx
> 
> $ ls -l tempfile
> -rwxrwsrwt 1 kaz kaz 0 Dec 24 13:09 tempfile
> 
> $ chmod u= tempfile
> $ ls -l tempfile
> -rwxrwsrwt 1 kaz kaz 0 Dec 24 13:09 tempfile

Could the problem be that the owner and group are the same?  You can do that on 
unix, but I'm not sure the Windows security model allows it.  For example, what 
happens when you remove permissions of the owner kaz while retaining the 
permissions of the group kaz?  As far as Windows is concerned, you're talking 
about BLACKBOX\kaz in both cases, I think.

Ken

Re: chmod issue on 3.1.7.

[Kaz Kylheku (Cygwin)]

On 2020-12-24 14:56, Ken Brown via Cygwin wrote:
> Could the problem be that the owner and group are the same?  You can
> do that on unix, but I'm not sure the Windows security model allows
> it.  For example, what happens when you remove permissions of the
> owner kaz while retaining the permissions of the group kaz?  As far as
> Windows is concerned, you're talking about BLACKBOX\kaz in both cases,
> I think.

I have no idea where that came from. All files in the Cygwin 
installation
(/bin, /usr/bin, /lib, ...) are owned by kaz:kaz. Numerically,
197613:197613. The UID and GID are the same number.

I don't see a passwd file any more in current Cygwin, but getpwent 
works:

4$ txr
This is the TXR Lisp interactive listener of TXR 243.
Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
1> (getpwent)
#S(passwd name "kaz" passwd "*" uid 197613 gid 197613 gecos 
"U-BLACKBOX\\kaz,S-1-5-21-3442361740-4082249206-548862920-1005"
           dir "/home/kaz" shell "/bin/bash")
2> (getpwent)
#S(passwd name "SYSTEM" passwd "*" uid 18 gid 18 gecos "U-NT 
AUTHORITY\\SYSTEM,S-1-5-18"
           dir "/home/SYSTEM" shell "/bin/bash")

I have no clue where this configuration came from. Is there some 
prompting
for these names when a new installation is made?

If nobody else has this problem, I must have done something wrong.