* Seems like a bug with mkfifo -m [not found] <1895966314.19173483.1590653374238.JavaMail.zimbra@office.targem.ru> @ 2020-05-28 8:12 ` Дмитрий Есарев 2020-05-28 13:16 ` Ken Brown 0 siblings, 1 reply; 8+ messages in thread From: Дмитрий Есарев @ 2020-05-28 8:12 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Seems like a bug with mkfifo -m 2020-05-28 8:12 ` Seems like a bug with mkfifo -m Дмитрий Есарев @ 2020-05-28 13:16 ` Ken Brown 2020-05-28 14:52 ` Corinna Vinschen 2020-05-28 17:31 ` yoshi kakbudto 0 siblings, 2 replies; 8+ messages in thread From: Ken Brown @ 2020-05-28 13:16 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Seems like a bug with mkfifo -m 2020-05-28 13:16 ` Ken Brown @ 2020-05-28 14:52 ` Corinna Vinschen 2020-05-28 15:28 ` Ken Brown 2020-05-28 17:31 ` yoshi kakbudto 1 sibling, 1 reply; 8+ messages in thread From: Corinna Vinschen @ 2020-05-28 14:52 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Seems like a bug with mkfifo -m 2020-05-28 14:52 ` Corinna Vinschen @ 2020-05-28 15:28 ` Ken Brown 2020-05-28 17:35 ` Ken Brown 0 siblings, 1 reply; 8+ messages in thread From: Ken Brown @ 2020-05-28 15:28 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Seems like a bug with mkfifo -m 2020-05-28 15:28 ` Ken Brown @ 2020-05-28 17:35 ` Ken Brown 0 siblings, 0 replies; 8+ messages in thread From: Ken Brown @ 2020-05-28 17:35 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Seems like a bug with mkfifo -m 2020-05-28 13:16 ` Ken Brown 2020-05-28 14:52 ` Corinna Vinschen @ 2020-05-28 17:31 ` yoshi kakbudto 2020-05-28 17:39 ` Ken Brown 1 sibling, 1 reply; 8+ messages in thread From: yoshi kakbudto @ 2020-05-28 17:31 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Seems like a bug with mkfifo -m 2020-05-28 17:31 ` yoshi kakbudto @ 2020-05-28 17:39 ` Ken Brown 2020-05-28 18:17 ` Corinna Vinschen 0 siblings, 1 reply; 8+ messages in thread From: Ken Brown @ 2020-05-28 17:39 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Seems like a bug with mkfifo -m 2020-05-28 17:39 ` Ken Brown @ 2020-05-28 18:17 ` Corinna Vinschen 0 siblings, 0 replies; 8+ messages in thread From: Corinna Vinschen @ 2020-05-28 18:17 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-05-28 18:17 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1895966314.19173483.1590653374238.JavaMail.zimbra@office.targem.ru> 2020-05-28 8:12 ` Seems like a bug with mkfifo -m Дмитрий Есарев 2020-05-28 13:16 ` Ken Brown 2020-05-28 14:52 ` Corinna Vinschen 2020-05-28 15:28 ` Ken Brown 2020-05-28 17:35 ` Ken Brown 2020-05-28 17:31 ` yoshi kakbudto 2020-05-28 17:39 ` Ken Brown 2020-05-28 18:17 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).