Seems like a bug with mkfifo -m

Seems like a bug with mkfifo -m

[Дмитрий Есарев]

Hi, all

When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe with no user and group permissions.

in the latest cygwin the above command creates device with 0644 permissions. And i cant drop it to 0600:

cygcheck.exe -V
cygcheck (cygwin) 3.1.4

$ umask 0077
$ touch somefile; ls -l somefile
-rw------- 1 admin absent 0 may 26 18:15 somefile

$ mkfifo -m 0600 somefifo; ls -l somefifo
prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo

$ chmod 600 somefifo; ls -l somefifo
prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo



In old-good cygwin 2.x the command works as expected:

$ cygcheck.exe -V
cygcheck (cygwin) 2.9.0

$ umask
0022

$ mkfifo -m 0600 somefifo; ls -l somefifo
prw------- 1 builduser Domain Users 0 May 26 18:21 somefifo



I've also questioned the topic at https://superuser.com/questions/1555204/cygwin-3-x-mkfifo-m0600-creates-named-pipe-with-0644-permissions


best regards,
 Yoshi kakbudto

Re: Seems like a bug with mkfifo -m

[Ken Brown]

On 5/28/2020 4:12 AM, Дмитрий Есарев via Cygwin wrote:
> Hi, all
> 
> When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe with no user and group permissions.
> 
> in the latest cygwin the above command creates device with 0644 permissions. And i cant drop it to 0600:
> 
> cygcheck.exe -V
> cygcheck (cygwin) 3.1.4
> 
> $ umask 0077
> $ touch somefile; ls -l somefile
> -rw------- 1 admin absent 0 may 26 18:15 somefile
> 
> $ mkfifo -m 0600 somefifo; ls -l somefifo
> prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo
> 
> $ chmod 600 somefifo; ls -l somefifo
> prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo
> 
> 
> 
> In old-good cygwin 2.x the command works as expected:
> 
> $ cygcheck.exe -V
> cygcheck (cygwin) 2.9.0
> 
> $ umask
> 0022
> 
> $ mkfifo -m 0600 somefifo; ls -l somefifo
> prw------- 1 builduser Domain Users 0 May 26 18:21 somefifo

Thanks for the report.  The problem isn't with mkfifo, it's with the permission 
information reported by ls.  I did a bisection of the Cygwin development repo 
and found that the regression was introduced by the following commit:

commit f36262d56ac78f04de147746ce4a85c6155e4a23
Author: Corinna Vinschen <corinna@vinschen.de>
Date:   Wed Jan 29 15:14:05 2020 +0100

     Cygwin: stat: fix st_mode of fifos

I'll take a look if Corinna doesn't get to it first.

Ken

Re: Seems like a bug with mkfifo -m

[Corinna Vinschen]

On May 28 09:16, Ken Brown via Cygwin wrote:
> On 5/28/2020 4:12 AM, Дмитрий Есарев via Cygwin wrote:
> > Hi, all
> > 
> > When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe with no user and group permissions.
> > 
> > in the latest cygwin the above command creates device with 0644 permissions. And i cant drop it to 0600:
> > 
> > cygcheck.exe -V
> > cygcheck (cygwin) 3.1.4
> > 
> > $ umask 0077
> > $ touch somefile; ls -l somefile
> > -rw------- 1 admin absent 0 may 26 18:15 somefile
> > 
> > $ mkfifo -m 0600 somefifo; ls -l somefifo
> > prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo
> > 
> > $ chmod 600 somefifo; ls -l somefifo
> > prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo
> > 
> > 
> > 
> > In old-good cygwin 2.x the command works as expected:
> > 
> > $ cygcheck.exe -V
> > cygcheck (cygwin) 2.9.0
> > 
> > $ umask
> > 0022
> > 
> > $ mkfifo -m 0600 somefifo; ls -l somefifo
> > prw------- 1 builduser Domain Users 0 May 26 18:21 somefifo
> 
> Thanks for the report.  The problem isn't with mkfifo, it's with the
> permission information reported by ls.  I did a bisection of the Cygwin
> development repo and found that the regression was introduced by the
> following commit:
> 
> commit f36262d56ac78f04de147746ce4a85c6155e4a23
> Author: Corinna Vinschen <corinna@vinschen.de>
> Date:   Wed Jan 29 15:14:05 2020 +0100
> 
>     Cygwin: stat: fix st_mode of fifos
> 
> I'll take a look if Corinna doesn't get to it first.

Not sure what I was thinking at the time.  I recall having observed
something funny, but the patch was apparently wrong.  Just revert
it at your discretion, Ken.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: Seems like a bug with mkfifo -m

[Ken Brown]

On 5/28/2020 10:52 AM, Corinna Vinschen wrote:
> On May 28 09:16, Ken Brown via Cygwin wrote:
>> On 5/28/2020 4:12 AM, Дмитрий Есарев via Cygwin wrote:
>>> Hi, all
>>>
>>> When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe with no user and group permissions.
>>>
>>> in the latest cygwin the above command creates device with 0644 permissions. And i cant drop it to 0600:
>>>
>>> cygcheck.exe -V
>>> cygcheck (cygwin) 3.1.4
>>>
>>> $ umask 0077
>>> $ touch somefile; ls -l somefile
>>> -rw------- 1 admin absent 0 may 26 18:15 somefile
>>>
>>> $ mkfifo -m 0600 somefifo; ls -l somefifo
>>> prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo
>>>
>>> $ chmod 600 somefifo; ls -l somefifo
>>> prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo
>>>
>>>
>>>
>>> In old-good cygwin 2.x the command works as expected:
>>>
>>> $ cygcheck.exe -V
>>> cygcheck (cygwin) 2.9.0
>>>
>>> $ umask
>>> 0022
>>>
>>> $ mkfifo -m 0600 somefifo; ls -l somefifo
>>> prw------- 1 builduser Domain Users 0 May 26 18:21 somefifo
>>
>> Thanks for the report.  The problem isn't with mkfifo, it's with the
>> permission information reported by ls.  I did a bisection of the Cygwin
>> development repo and found that the regression was introduced by the
>> following commit:
>>
>> commit f36262d56ac78f04de147746ce4a85c6155e4a23
>> Author: Corinna Vinschen <corinna@vinschen.de>
>> Date:   Wed Jan 29 15:14:05 2020 +0100
>>
>>      Cygwin: stat: fix st_mode of fifos
>>
>> I'll take a look if Corinna doesn't get to it first.
> 
> Not sure what I was thinking at the time.  I recall having observed
> something funny, but the patch was apparently wrong.  Just revert
> it at your discretion, Ken.

I remember we had an IRC discussion about it, but I can't remember what the 
issue was.  I'll look a little more closely before reverting.

Ken

Re: Seems like a bug with mkfifo -m

[yoshi kakbudto]

you say  'ls' is a problem source. Then i have to be more specific with the
problem to not miss any other possible problems around it.

My use case is this: I have an ssh rsa keys dynamically loaded in
environment variables.
Those variables then expaned and piped to the named pipe and then the pipe
instantly read by ssh-add. 
I know there could be other ways to ssh-add from environment, but its just
our specifics.
So the actual commands looks like this:

$ mkfifo -m 0600 somefifo

# The KEY contains ssh rsa private key data
$ echo $KEY > somefifo | ssh-add somefifo

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'somefifo' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.







--
Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html

Re: Seems like a bug with mkfifo -m

[Ken Brown]

On 5/28/2020 11:28 AM, Ken Brown via Cygwin wrote:
> On 5/28/2020 10:52 AM, Corinna Vinschen wrote:
>> On May 28 09:16, Ken Brown via Cygwin wrote:
>>> On 5/28/2020 4:12 AM, Дмитрий Есарев via Cygwin wrote:
>>>> Hi, all
>>>>
>>>> When i ran cygwin 2.x, i used mkfifo -m 0600 file to create a named pipe 
>>>> with no user and group permissions.
>>>>
>>>> in the latest cygwin the above command creates device with 0644 permissions. 
>>>> And i cant drop it to 0600:
>>>>
>>>> cygcheck.exe -V
>>>> cygcheck (cygwin) 3.1.4
>>>>
>>>> $ umask 0077
>>>> $ touch somefile; ls -l somefile
>>>> -rw------- 1 admin absent 0 may 26 18:15 somefile
>>>>
>>>> $ mkfifo -m 0600 somefifo; ls -l somefifo
>>>> prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo
>>>>
>>>> $ chmod 600 somefifo; ls -l somefifo
>>>> prw-r--r-- 1 admin absent 0 may 26 18:16 somefifo
>>>>
>>>>
>>>>
>>>> In old-good cygwin 2.x the command works as expected:
>>>>
>>>> $ cygcheck.exe -V
>>>> cygcheck (cygwin) 2.9.0
>>>>
>>>> $ umask
>>>> 0022
>>>>
>>>> $ mkfifo -m 0600 somefifo; ls -l somefifo
>>>> prw------- 1 builduser Domain Users 0 May 26 18:21 somefifo
>>>
>>> Thanks for the report.  The problem isn't with mkfifo, it's with the
>>> permission information reported by ls.  I did a bisection of the Cygwin
>>> development repo and found that the regression was introduced by the
>>> following commit:
>>>
>>> commit f36262d56ac78f04de147746ce4a85c6155e4a23
>>> Author: Corinna Vinschen <corinna@vinschen.de>
>>> Date:   Wed Jan 29 15:14:05 2020 +0100
>>>
>>>      Cygwin: stat: fix st_mode of fifos
>>>
>>> I'll take a look if Corinna doesn't get to it first.
>>
>> Not sure what I was thinking at the time.  I recall having observed
>> something funny, but the patch was apparently wrong.  Just revert
>> it at your discretion, Ken.
> 
> I remember we had an IRC discussion about it, but I can't remember what the 
> issue was.  I'll look a little more closely before reverting.

OK, it turned out that part of that patch needed to be reverted.  It's done now.

Ken

Re: Seems like a bug with mkfifo -m

[Ken Brown]

On 5/28/2020 1:31 PM, yoshi kakbudto wrote:
> you say  'ls' is a problem source. Then i have to be more specific with the
> problem to not miss any other possible problems around it.
> 
> My use case is this: I have an ssh rsa keys dynamically loaded in
> environment variables.
> Those variables then expaned and piped to the named pipe and then the pipe
> instantly read by ssh-add.
> I know there could be other ways to ssh-add from environment, but its just
> our specifics.
> So the actual commands looks like this:
> 
> $ mkfifo -m 0600 somefifo
> 
> # The KEY contains ssh rsa private key data
> $ echo $KEY > somefifo | ssh-add somefifo
> 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions 0644 for 'somefifo' are too open.
> It is required that your private key files are NOT accessible by others.
> This private key will be ignored.

Sorry, I shouldn't have said the problem was with ls.  The problem was actually 
with stat, and it's fixed now.  You should be able to test it the next time 
Corinna creates a snapshot.

Ken

Re: Seems like a bug with mkfifo -m

[Corinna Vinschen]

On May 28 13:39, Ken Brown via Cygwin wrote:
> On 5/28/2020 1:31 PM, yoshi kakbudto wrote:
> > you say  'ls' is a problem source. Then i have to be more specific with the
> > problem to not miss any other possible problems around it.
> > 
> > My use case is this: I have an ssh rsa keys dynamically loaded in
> > environment variables.
> > Those variables then expaned and piped to the named pipe and then the pipe
> > instantly read by ssh-add.
> > I know there could be other ways to ssh-add from environment, but its just
> > our specifics.
> > So the actual commands looks like this:
> > 
> > $ mkfifo -m 0600 somefifo
> > 
> > # The KEY contains ssh rsa private key data
> > $ echo $KEY > somefifo | ssh-add somefifo
> > 
> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> > @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
> > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> > Permissions 0644 for 'somefifo' are too open.
> > It is required that your private key files are NOT accessible by others.
> > This private key will be ignored.
> 
> Sorry, I shouldn't have said the problem was with ls.  The problem was
> actually with stat, and it's fixed now.  You should be able to test it the
> next time Corinna creates a snapshot.

Done.  Try the latest snapshot from https://cygwin.com/snapshots/


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer