Re: Permission Problems
> From: Dave Caswell > To: cygwin > Cc: > Date: 2016/4/25, Mon 09:29 > Subject: Permission Problems > >T his is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html > > To recap, making three nested directories on a non-C drive produces a > third level which is unusable. > > davec@MERCURYWIN ~/python > $ rm -rf g1 > davec@MERCURYWIN ~/python > $ mkdir g1 g1/g2 g1/g2/g3 > davec@MERCURYWIN ~/python > $ ls -la g1 g1/g2 g1/g2/g3 > g1: > total 12 > drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./ > drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../ > drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/ > g1/g2: > total 0 > drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./ > drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../ > d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/ > ls: cannot open directory 'g1/g2/g3': Permission denied > > The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1, > and goes away when I downgrade back to 2.5.0-1 > > More info: I tested on a couple of external drives and things worked > properly there. Can I have screwed up the permissions on my D drive > so that cygwin gets confused but Windows still works? > > thanks > Perhaps workaround is to use the beloe $ cygstart --action=runas (cygwin command) In your case, $ cygstart --action=runas ls -la g1 g1/g2 g1/g2/g3 Tatsuro -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Proposed patch for web site: update most links to HTTPS
On Mon, Apr 25, 2016 at 08:49:18AM +0300, Andrey Repin wrote: > Greetings, Brian Clifton! > > -Original Message- > > From: Andrey Repin > >> Greetings, Brian Clifton! > > > >>> Hi folks, > > > >>> I have a proposed change for the web site. This patch (see below) will > >>> update most of the urls to HTTPS. In many cases there was a redirect; > >>> for those I captured the new canonical address. > > > >> Please no. > > > > Can you please elaborate on why? I'm confused on why you prefer that Cygwin > > links users to non-secure versions of pages? (which in many cases will be > > redirected anyways). > > I prefer it not forcing either, and only force secure connection, when > absolutely > necessary. I.e. when downloading the setup binary. > > > Links which ONLY work on http *have not* been changed and there are no other > > changes in this patch. > > Secure connections been painfully slow and just annoying, when all you need is > a quick glance at the documentation. > All internal links must be relative to the domain and not force either > protocol or the domain name. Secure connections historically had a high overhead, sure, but that's very rarely the case nowadays. Certainly my experince of loading the Cygwin web page is that there's no perceptible difference between the http and https versions. Adam Langley (a senior engineer at Google) wrote an article back in 2010 about how TLS is now computationally cheap[0]; it's only gotten cheaper since. [0]: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html See also https://istlsfastyet.com/, which has a lot of discussion about the impacts of TLS, but the short answer is "yes". At the very least, the Cygwin website should be using protocol- independent links, meaning users accessing the website using https aren't switched to http when they click on a link (i.e. link to "//cygwin.com/path/to/page" rather than "https://cygwin.com/..."; or "http://cygwin.com/...";). But I agree with Brian: the Cygwin website should use https everywhere unless there's some good, specific reason why it's a bad idea. And "TLS is slow" hasn't been a good reason for years. Adam -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Proposed patch for web site: update most links to HTTPS
Greetings, Adam Dinwoodie! > Secure connections historically had a high overhead, sure, but that's > very rarely the case nowadays. Certainly my experince of loading the > Cygwin web page is that there's no perceptible difference between the > http and https versions. Adam Langley (a senior engineer at Google) > wrote an article back in 2010 about how TLS is now computationally > cheap[0]; it's only gotten cheaper since. Typical marketing bullshit. > [0]: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html > See also https://istlsfastyet.com/, which has a lot of discussion about > the impacts of TLS, but the short answer is "yes". If YOUR experience was positive, mine was always negative, especially with cygwin.com, down to being forced to switch to plain HTTP to even load any page. > At the very least, the Cygwin website should be using protocol- > independent links, meaning users accessing the website using https > aren't switched to http when they click on a link That was my point, exactly. > (i.e. link to > "//cygwin.com/path/to/page" rather than "https://cygwin.com/..."; or > "http://cygwin.com/...";). Just /path/to/page is enough. Even necessary considering cygwin.com is multi-domain site. > But I agree with Brian: the Cygwin website should use https everywhere > unless there's some good, specific reason why it's a bad idea. And "TLS is > slow" hasn't been a good reason for years. See above. -- With best regards, Andrey Repin Monday, April 25, 2016 16:01:59 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: can't open cygwin from shortcut
The nonworking "Cygwin64 Terminal" shortcut is indeed a bug in CYGWIN_NT-10.0 version 2.4.1(0.293/5/3). Adding .exe to the pathname for mintty fixes it. Thanks to Brian Inglis for telling me how to do that. Doug McIlroy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
gcc x86 - problem on library search order
Visible on 32bit and not present on 64bit
$ cat uuid.c
#include
int main ()
{
uuid_t out;
uuid_generate_random(out);
return 0;
}
$ gcc uuid.c -luuid
/tmp/ccLlmFMf.o:uuid.c:(.text+0x16): undefined reference to
`uuid_generate_random'
collect2: error: ld returned 1 exit status
$ gcc uuid.c -luuid -L /usr/lib
The problem seems "/usr/lib/w32api" searched
before "/usr/lib"
$ cygcheck -l w32api-runtime |grep libuuid.
/usr/lib/w32api/libuuid.a
$ cygcheck -l libuuid-devel |grep libuuid.dll
/usr/lib/libuuid.dll.a
$ cygcheck -c gcc-core
Cygwin Package Information
Package VersionStatus
gcc-core 5.3.0-4OK
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Proposed patch for web site: update most links to HTTPS
-Original Message- From: Adam Dinwoodie > ... > But I agree with Brian: the Cygwin website > should use https everywhere unless there's some good, specific reason > why it's a bad idea... 1. Did Brian say that? I couldn't find it in the thread. 2. I would be interested to hear the rationale for such a statement. Cygwin is open source. What's the point of encrypting? --Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Proposed patch for web site: update most links to HTTPS
> On Apr 25, 2016, at 2:33 PM, Nellis, Kenneth wrote: > > -Original Message- > From: Adam Dinwoodie >> ... >> But I agree with Brian: the Cygwin website >> should use https everywhere unless there's some good, specific reason >> why it's a bad idea... > > 1. Did Brian say that? I couldn't find it in the thread. > 2. I would be interested to hear the rationale for such a statement. > Cygwin is open source. What's the point of encrypting? I’m not sure what being open source has to do with it. It should be encrypted for privacy. Frankly, from what we’ve seen in the last couple of years, plain http: should disappear. It should all be https. (And Adam is exactly correct on the performance; it is a non-issue today and has been for years.) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Proposed patch for web site: update most links to HTTPS
>From: cygwin-ow...@cygwin.com on behalf of Vince >Rice >Sent: Monday, April 25, 2016 12:58 PM >To: cygwin@cygwin.com >Subject: Re: Proposed patch for web site: update most links to HTTPS > >> On Apr 25, 2016, at 2:33 PM, Nellis, Kenneth >> wrote: >> >> -Original Message- >> From: Adam Dinwoodie >>> ... >>> But I agree with Brian: the Cygwin website >>> should use https everywhere unless there's some good, specific reason >>> why it's a bad idea... >> >> 1. Did Brian say that? I couldn't find it in the thread. >> 2. I would be interested to hear the rationale for such a statement. >> Cygwin is open source. What's the point of encrypting? > >I’m not sure what being open source has to do with it. >It should be encrypted for privacy. Frankly, from what we’ve seen in the last >couple of years, plain http: should disappear. It should all be https. (And >Adam is exactly correct on the performance; it is a non-issue today and has >been for years.) Hi folks, Sorry for the top reply in my previous posts, I'm new to email lists :) Forcing HTTPS was the goal I had in mind, for exactly the reason Vince mentions (for security and privacy). Using relative URLs is OK if a rewrite rule is put in place, forcing HTTPS (which is the case). But many of the links updated are external and do not do that. There are many articles about why you should always use HTTPS. The article I referenced with the patch is: https://textslashplain.com/2016/03/17/seek-and-destroy-non-secure-references-using-the-moartls-analyzer/ Another from Google can be found here: https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https?hl=en Besides security, another important consideration is that search engines prefer HTTPS links (and rank them higher, even if only by a small amount). In addition to this patch, Apache could be configured better (Cygwin.com scores a B): https://www.ssllabs.com/ssltest/analyze.html?d=cygwin.com Thanks Brian -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: httpd/sshd will not start due to "failed to create proxy mutex" error
I fixed it! I don't know if the fix is any good, but the server starts and serves pages. The key was this Mutex directive: https://httpd.apache.org/docs/current/mod/core.html#mutex I wound up adding this to my httpd.conf: > Mutex posixsem proxy I don't know if "posixsem" is the right choice, but it seems to work. All of the choices have warnings that make them all sound horrible: dizzyness, depression, erectile dysfunction...but we're going to try this. I'm just developing on my local system, anyway. Cheers, Matt -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Permission Problems
On Mon, Apr 25, 2016 at 4:30 AM, Tatsuro MATSUOKA wrote: >> From: Dave Caswell >> To: cygwin >> Cc: >> Date: 2016/4/25, Mon 09:29 >> Subject: Permission Problems >> >>T his is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html >> >> To recap, making three nested directories on a non-C drive produces a >> third level which is unusable. >> >> davec@MERCURYWIN ~/python >> $ rm -rf g1 >> davec@MERCURYWIN ~/python >> $ mkdir g1 g1/g2 g1/g2/g3 >> davec@MERCURYWIN ~/python >> $ ls -la g1 g1/g2 g1/g2/g3 >> g1: >> total 12 >> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./ >> drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../ >> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/ >> g1/g2: >> total 0 >> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./ >> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../ >> d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/ >> ls: cannot open directory 'g1/g2/g3': Permission denied >> >> The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1, >> and goes away when I downgrade back to 2.5.0-1 >> >> More info: I tested on a couple of external drives and things worked >> properly there. Can I have screwed up the permissions on my D drive >> so that cygwin gets confused but Windows still works? >> >> thanks >> > Perhaps workaround is to use the beloe > $ cygstart --action=runas (cygwin command) > > In your case, > $ cygstart --action=runas ls -la g1 g1/g2 g1/g2/g3 > Tatsuro The problem is the creation of a directory (or file) with a mangled ACL.. at least windows isn't capable of dealing with the directory either. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Permission Problems
On Mon, Apr 25, 2016 at 12:09 AM, Marco Atzeri wrote: > On 25/04/2016 02:29, Dave Caswell wrote: >> >> This is a followup to: https://cygwin.com/ml/cygwin/2016-03/msg00345.html >> >> To recap, making three nested directories on a non-C drive produces a >> third level which is unusable. >> >> davec@MERCURYWIN ~/python >> $ rm -rf g1 >> davec@MERCURYWIN ~/python >> $ mkdir g1 g1/g2 g1/g2/g3 >> davec@MERCURYWIN ~/python >> $ ls -la g1 g1/g2 g1/g2/g3 >> g1: >> total 12 >> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ./ >> drwxrwx---+ 1 davec Users 0 Mar 16 20:23 ../ >> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 g2/ >> g1/g2: >> total 0 >> drwsrwsr-t+ 1 davec None 0 Mar 16 20:23 ./ >> drwxrwxr-x+ 1 davec None 0 Mar 16 20:23 ../ >> d--Srws--T+ 1 davec None 0 Mar 16 20:23 g3/ >> ls: cannot open directory 'g1/g2/g3': Permission denied >> >> The problem went away with Cygwin 2.5.0-0.7 but is back with 2.5.1-1, >> and goes away when I downgrade back to 2.5.0-1 >> >> More info: I tested on a couple of external drives and things worked >> properly there. Can I have screwed up the permissions on my D drive >> so that cygwin gets confused but Windows still works? >> >> thanks > > > It works fine for me. > "E:" is an external NTFS USB disk > > $ mount > E:/cygwin64/bin on /usr/bin type ntfs (binary,auto) > E:/cygwin64/lib on /usr/lib type ntfs (binary,auto) > E:/cygwin64 on / type ntfs (binary,auto) > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) > E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto) > > $ cd /cygdrive/e/temp > > $ mkdir g1 g1/g2 g1/g2/g3 > > $ ls -la g1 g1/g2 g1/g2/g3 > g1: > total 4.0K > drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 . > drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .. > drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 g2 > > g1/g2: > total 0 > drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 . > drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .. > drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 g3 > > g1/g2/g3: > total 0 > drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 . > drwxr-xr-x+ 1 marco Administrators 0 Apr 25 07:59 .. > > $ icacls . > . GE-MATZERI-EU\0356EU:(F) > BUILTIN\Administrators:(RX) > Everyone:(RX) > NT AUTHORITY\SYSTEM:(OI)(CI)(F) > CREATOR OWNER:(OI)(CI)(IO)(F) > CREATOR GROUP:(OI)(CI)(IO)(RX) > Everyone:(OI)(CI)(IO)(RX) > > $ icacls g1/g2/g3 > g1/g2/g3 NULL SID:(DENY)(Rc,S,REA,X,DC) > GE-MATZERI-EU\0356EU:(F) > BUILTIN\Administrators:(RX) > NT AUTHORITY\SYSTEM:(RX,W,DC) > Everyone:(RX) > NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC) > CREATOR OWNER:(OI)(CI)(IO)(F) > CREATOR GROUP:(OI)(CI)(IO)(RX) > NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC) > Everyone:(OI)(CI)(IO)(RX) > > I suggest to use icacls and eventually "setfacl -b" > for permission cleaning if needed. What wound up doing was backing up all the files from my documents disk to a scratch disk, reformatting the documents disk, and restoring the backup, and finally running icacls /reset on the whole drive. This seems to have my system working ok now. But there is still something different about 2.5.0-1 that prevented it from writing a confused ACL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
