Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

[xnor]

>Which warning do you mean here?
The "permissions out of order" one. This was not the case before, at 
least not on my installation, so I don't see how this can be called 
normal.


>Come on, be fair.  The new ACL handling started out early 2015, got a
>break when I realized that it doesn't work as is, and then got a new
>test phase starting back in September.  Except for minor bugs it seemed
>to work rather well.  Nobody reported this effect in all the 4 months 
>of
>test period.  You don't actually think I wouldn't have fixed it prior
>to the release if I had known about it, do you?
2.4.0-1 was released ~3 weeks ago. I had actually upgraded a few days 
earlier to a TEST version and noticed that a cygwin downloaded exe 
couldn't be executed but assumed the exe was corrupt and didn't 
investigate...
Then a few days ago the same thing happened again. Now I'm here.

Anyway, clearly most users are just that: users, and not testers that 
will install and test TEST versions.


>They are not supposed to be modifiable in Explorer.  If you want to
>change permissions on a Cygwin ACL, use chmod or setfacl.
Is this a joke?


>
>>  Here is the output from icacls /saveacl for some file:
>>  
>>D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)
>Doh, I'm sorry, but I can't read this format very well.  Can you please
>again send the standard icacls output as well as the output from 
>getfacl
>of the parent dir and the created file?  I'd like to have this problem
>fixed, but I need your help.  As I said, it works fine for me and 
>without
>being able to reproduce I'm somewhat at a loss.
You can import this by putting it in a textfile and using icacls 
testfile /restore acl.txt.
As I've said before, my Windows is German. icacls output will be 
localized. Do you really want that?
What I posted is the only portable way to share ACLs.


>
>>  Here is what's "normal" for Windows if I create a file under a new 
>>folder on
>>  C: in Explorer:
>
>If you don't want POSIX perms, but standard Windows perms, use the 
>"noacl"
>mount option.  See 
>https://cygwin.com/cygwin-ug-net/using.html#mount-table
I guess that is my only option right now.

>
>>  Here is what I would expect:
>>  MyUser is in the group Administrators. Given the inherited 
>>permissions above
>>  a Windows-created file should be shown as "-rwxrwxr--+ MyUser
>>  Administrators"?
>
>Sorry, can't do that, *unless* you make "Administrators" the primary
>group in your user token(*).
Ok, so the group is "None". No big deal.

So what about fixing the permissions like I described?
So the permissions would be "-rwx------+ MyUser None" in Cygwin for a 
Windows-created file with default ACL.

By using the inherited default ACLs there should be at most 3 additional 
ACLs (+1 for NULL SID whatever that is doing):
- deny r/w/x for user ("MyUser")
- allow r/w/x for group ("None")
- allow r/w/x for other ("Everyone")

And leaving the inherited ones untouched, right?
But if you scroll up you will see that in my system Cygwin kills the 
inheritance and I end up with 12 new ACL entries for each file.


--
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: Issues with ACL settings after updating to the latest cygwin.dll

[Andrey Repin]

Greetings, xnor!

>>Which warning do you mean here?
> The "permissions out of order" one. This was not the case before, at 
> least not on my installation, so I don't see how this can be called 
> normal.

It is normal and was normal for at least seventeen years.

>>Come on, be fair.  The new ACL handling started out early 2015, got a
>>break when I realized that it doesn't work as is, and then got a new
>>test phase starting back in September.  Except for minor bugs it seemed
>>to work rather well.  Nobody reported this effect in all the 4 months 
>>of
>>test period.  You don't actually think I wouldn't have fixed it prior
>>to the release if I had known about it, do you?
> 2.4.0-1 was released ~3 weeks ago. I had actually upgraded a few days 
> earlier to a TEST version and noticed that a cygwin downloaded exe 
> couldn't be executed but assumed the exe was corrupt and didn't 
> investigate...
> Then a few days ago the same thing happened again. Now I'm here.

> Anyway, clearly most users are just that: users, and not testers that 
> will install and test TEST versions.

I hope this is not a complaint? You are supposed to know what you are doing,
when installing test versions.

>>They are not supposed to be modifiable in Explorer.  If you want to
>>change permissions on a Cygwin ACL, use chmod or setfacl.
> Is this a joke?

It is a statement of the matter.

>>
>>>  Here is the output from icacls /saveacl for some file:
>>>  
>>>D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)
>>Doh, I'm sorry, but I can't read this format very well.  Can you please
>>again send the standard icacls output as well as the output from 
>>getfacl
>>of the parent dir and the created file?  I'd like to have this problem
>>fixed, but I need your help.  As I said, it works fine for me and 
>>without
>>being able to reproduce I'm somewhat at a loss.
> You can import this by putting it in a textfile and using icacls 
> testfile /restore acl.txt.
> As I've said before, my Windows is German. icacls output will be 
> localized. Do you really want that?

You'd be surprized… But the actual answer is "yes".

> What I posted is the only portable way to share ACLs.

You weren't asked for "portable".

P.S.
Please don't use gmail web interface to post to the list. Either use normal
mail cleint, or gmane.
You're breaking threading.


-- 
With best regards,
Andrey Repin
Wednesday, February 10, 2016 23:31:57

Sorry for my terrible english...

Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

[xnor]

>It is normal and was normal for at least seventeen years.
That's a blatant lie.
It never happened to me before, and I doubled checked this by installing 
the older 2.3. It didn't happen before 2.4.


>You'd be surprized… But the actual answer is "yes".
I actually am surprised since you seem to have undergone a sex change 
and are now Corinna.


>You weren't asked for "portable".
I didn't talk to you. You weren't asked anything.

I find it quite rude that you feel the need to intrude into a discussion 
giving nonsensical know-it-all responses .. even on behalf of other 
people.

I'll ignore further emails from you, thanks for wasting my time.


--
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: Issues with ACL settings after updating to the latest cygwin.dll

[Andrey Repin]

Greetings, xnor!

>>It is normal and was normal for at least seventeen years.
> That's a blatant lie.
> It never happened to me before, and I doubled checked this by installing 
> the older 2.3. It didn't happen before 2.4.

"Never happened to you" does not equal "wasn't the case".
Your presumptuous supposition does not count towards your credit.

>>You'd be surprized… But the actual answer is "yes".
> I actually am surprised since you seem to have undergone a sex change 
> and are now Corinna.

Or perhaps I know a little about inhabitants of this list?
A little something that tells me Corinna would have no issues reading her
mother language?

>>You weren't asked for "portable".
> I didn't talk to you. You weren't asked anything.

> I find it quite rude that you feel the need to intrude into a discussion 
> giving nonsensical know-it-all responses .. even on behalf of other 
> people.

> I'll ignore further emails from you, thanks for wasting my time.

You're welcome.


-- 
With best regards,
Andrey Repin
Thursday, February 11, 2016 02:19:26

Sorry for my terrible english...

Re: Issues with ACL settings after updating to the latest cygwin.dll

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5674 bytes --]

On Feb 10 18:17, xnor wrote:
> 
> >Which warning do you mean here?
> The "permissions out of order" one. This was not the case before, at least
> not on my installation, so I don't see how this can be called normal.

It was already the case before.  It depends on the POSIX permissions
which have to be emulated using a Windows ACL, so you don't see this all
the time.  As a funny sidenote, you'd get the exact same when using the
Interix/SFU POSIX subsystem.  It had the same POSIX vs. Windows semantics
problem to solve.

Things change.  The new Cygwin ACL handling tries to emulate POSIX ACLs
more closely than before.  The role model is what you can download from
http://wt.tuxomania.net/publications/posix.1e/download.html and what's
used on Linux, Solaris, and others.  The Linux man page on ACLs,
http://linux.die.net/man/5/acl, might be helpful, too.

> >Come on, be fair.  The new ACL handling started out early 2015, got a
> >break when I realized that it doesn't work as is, and then got a new
> >test phase starting back in September.  Except for minor bugs it seemed
> >to work rather well.  Nobody reported this effect in all the 4 months of
> >test period.  You don't actually think I wouldn't have fixed it prior
> >to the release if I had known about it, do you?
> 2.4.0-1 was released ~3 weeks ago. I had actually upgraded a few days
> earlier to a TEST version and noticed that a cygwin downloaded exe couldn't
> be executed but assumed the exe was corrupt and didn't investigate...
> Then a few days ago the same thing happened again. Now I'm here.
> 
> Anyway, clearly most users are just that: users, and not testers that will
> install and test TEST versions.

Which is a pity from the dev POV.  The test releases are created so that
people have a chance to test changes before they are officially released.
The less people test test releases, the less bugs are found prior to a
release.  It's also very simple to install a test release via setup and,
if a problem is interfering, to re-install the current release version,
ideally after reporting the problem.

> >They are not supposed to be modifiable in Explorer.  If you want to
> >change permissions on a Cygwin ACL, use chmod or setfacl.
> Is this a joke?

No.

> >> Here is the output from icacls /saveacl for some file:
> >>D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)
> >Doh, I'm sorry, but I can't read this format very well.  Can you please
> >again send the standard icacls output as well as the output from getfacl
> >of the parent dir and the created file?  I'd like to have this problem
> >fixed, but I need your help.  As I said, it works fine for me and without
> >being able to reproduce I'm somewhat at a loss.
> You can import this by putting it in a textfile and using icacls testfile
> /restore acl.txt.

Doesn't work.  First, your machine is using different SIDs of course,
so the SID entries have no meaning on my machine.  Second, even after
changing the SIDs to ones I can use locally, icacls /restore just doesn't
work for me.  It requires that the path to restore is a directory, and
even when giving it a directory, I get an error:

  CMD> icacls C:\cygwin64\home\corinna\subdir\ /restore acl.txt
  C:\cygwin64\home\corinna\subdir\??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????: The system cannot find the file specified.
  Successfully processed 0 files; Failed processing 1 files

> As I've said before, my Windows is German. icacls output will be localized.
> Do you really want that?

My german is not that bad, all things considered.  "None" is "Kein",
"Administrators" is "Administratoren"...

> What I posted is the only portable way to share ACLs.

Given the SID problem, it's not portable.

Again, do you want me to be able to analyze the problem and, *iff* there's
a bug, fix it?  If so, please don't double guess what I'm asking for.

Please provide stock icacls output as well as getfacl output for the
parent dir in which you download the file, and for the file itself.
Don't call the Explorer GUI on the ACL, don't reorder.

> >If you don't want POSIX perms, but standard Windows perms, use the "noacl"
> >mount option.  See https://cygwin.com/cygwin-ug-net/using.html#mount-table
> I guess that is my only option right now.

If you're looking for Windows ACL semantics, it's the way to go.

> So what about fixing the permissions like I described?
> So the permissions would be "-rwx------+ MyUser None" in Cygwin for a
> Windows-created file with default ACL.
> 
> By using the inherited default ACLs there should be at most 3 additional
> ACLs (+1 for NULL SID whatever that is doing):
> - deny r/w/x for user ("MyUser")
> - allow r/w/x for group ("None")
> - allow r/w/x for other ("Everyone")
> 
> And leaving the inherited ones untouched, right?
> But if you scroll up you will see that in my system Cygwin kills the
> inheritance and I end up with 12 new ACL entries for each file.

You're asking for Windows ACL semantics,  As outlined, Cygwin is trying
to follow the POSIX ACL model with "acl" mount mode.  If you want
Windows ACL semantics, use "noacl" mounts.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Issues with ACL settings after updating to the latest cygwin.dll

[Andrey Repin]

Greetings, xnor!

>>The permissions must *not* be reordered.  If Cygwin creates permissions
>>incorrectly it's one thing, but the order to emulate POSIX permissions
>>is non-canonical.  Reordering them will break them.
>>
>>Please provide the exact output from icacls.
> They *have* to be reordered to be modifiable in Windows/Explorer. In 
> other words, if I want to change permission the new ACL behavior ensures 
> that it breaks the Cygwin permissions?

It was always the case.
Permissions are NOT REQUIRED to be ordered in a specific way, but Explorer is
only capable of editing them in the only one way.
Means, Explorer is deficient. Explorer. Not Windows. Windows is perfectly
capable of handling the Cygwin ACL in the intended way.


-- 
With best regards,
Andrey Repin
Wednesday, February 10, 2016 05:05:14

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[2]: Issues with ACL settings after updating to the latest cygwin.dll

[xnor]

>It was always the case.
>Permissions are NOT REQUIRED to be ordered in a specific way, but 
>Explorer is
>only capable of editing them in the only one way.
>Means, Explorer is deficient. Explorer. Not Windows. Windows is 
>perfectly
>capable of handling the Cygwin ACL in the intended way.
No, it really wasn't.

The ACLs were fine until the change in the new Cygwin version. Now there 
are 12 ACL entries, all non inherited / inheritance is broken, for each 
file...

Also, I always ways able to change ACLs through Explorer without 
warnings, which I need to do from time to time.

I'm sorry but all of this can be summed up as bad design.


I've explained what ACLs should be added by Cygwin in a related message. 
By making use of default, inherited ACLs, at most 3 (+1 for whatever 
NULL SID is doing ...) are needed. At least I see no reason why there 
should be such a bloat.

Besides, if cygwin set ACLs properly on the root folder this could be 
reduced to 0 additional non-inherited ACLs for many files.


--
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: Issues with ACL settings after updating to the latest cygwin.dll

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]

On Feb  8 17:48, xnor wrote:
> 
> >I'm not quite sure what you observe there.  The NULL SID ACE only
> >contains extra information about some POSIX bits and the MASK value.
> >It's existence and setting should not influence what you can do with the
> >file.  The permission bits are explicitely set elsewhere in the ACL.
> >
> >Can you reproduce the issue so that I can see what's going on?  I need
> >the icacls output for the file and its parent directory, as well as the
> >output from getfacl for both.
> I have the same problem with Transmission.
> 
> I noticed this first when I tried to execute an exe that was downloaded with
> Transmission compiled in cygwin. When trying to start the exe from Explorer
> an error dialog will appear:
> "Windows cannot access the specified device, path, or file. You may not have
> the appropriate permissions to access the item."

Not sure what Transmission is, but files downloaded with POSIX
tools are usually not executable.  For instance, download Cygwin's
setup-x86.exe with wget.  Then try to execute it.  It won't since
the permissions are set according to your umask and without execute
permissions, e.g., 0644.  This is normal.

> When going to file properties - security I get an information dialog window:
> "The permissions on <program> are incorrectly ordered, which may cause some
> entries to be ineffective."
> 
> Proper permissions (of parent folder) look like this:
> Authenticated Users: modify
> SYSTEM: Full control
> Administrators: Full control
> Users: Read & execute
> 
> 
> The permissions of the cygwin/transmission created files are (manually
> translated from German):
> NULL SID: special
> <My User>: special
> Authenticated Users: Browse folder / Execute file
> SYSTEM: Browse folder / Execute file
> Administrators: Browse folder / Execute file
> Users: Browse folder / Execute file
> Nobody: Read
> Authenticated Users: Read, write, execute
> SYSTEM: Read, write, execute
> Administrators: Read, write, execute
> Users: Read, Execute
> Everyone: Read
> 
> 
> Also when going to advanced permissions it shows the same incorrectly
> ordered warning and asks me to re-order permissions.

The permissions must *not* be reordered.  If Cygwin creates permissions
incorrectly it's one thing, but the order to emulate POSIX permissions
is non-canonical.  Reordering them will break them.

Please provide the exact output from icacls.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

[xnor]

>Not sure what Transmission is, but files downloaded with POSIX
>tools are usually not executable.  For instance, download Cygwin's
>setup-x86.exe with wget.  Then try to execute it.  It won't since
>the permissions are set according to your umask and without execute
>permissions, e.g., 0644.  This is normal.
The behavior has changed with the ACL change in Cygwin and I would not 
consider that "normal". The warning from Windows is not normal.

I realize that the previous implementation was already problematic and 
messed with permissions but I did not notice it since it never denied 
executing executables.


>The permissions must *not* be reordered.  If Cygwin creates permissions
>incorrectly it's one thing, but the order to emulate POSIX permissions
>is non-canonical.  Reordering them will break them.
>
>Please provide the exact output from icacls.
They *have* to be reordered to be modifiable in Windows/Explorer. In 
other words, if I want to change permission the new ACL behavior ensures 
that it breaks the Cygwin permissions?


Here is the output from icacls /saveacl for some file:
D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)

After letting Windows fix the order:
D:PAI(D;;RPWPDTRC;;;S-1-0-0)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)

Here is what's "normal" for Windows if I create a file under a new 
folder on C: in Explorer:
D:AI(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)

Strangely enough this is displayed as "-rwxrwx---+ MyUser None" with `ls 
-l` even though my user is in the group Administrators.


Here is what I would expect:
MyUser is in the group Administrators. Given the inherited permissions 
above a Windows-created file should be shown as "-rwxrwxr--+ MyUser 
Administrators"?

After chmod 664 I would expect this:
- still inherit all the permissions
- add permission MyUser DENY execute
- add permission Administrators DENY execute
- add permission Everyone ALLOW read

Instead Cygwin copies all permissions, drops the inheritance, copies 
them again, adds None, adds NULL SID ...

After a consecutive chmod 770 I would expect the above non-inherited 
permissions to be removed again.



--
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: Issues with ACL settings after updating to the latest cygwin.dll

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

On Jan 29 17:52, K Stahl wrote:
> I've discovered that when I use cvs to pull a module, the security
> settings on the created files and directories are incorrect.  When I
> view the security settings of the files, I noticed an invalid "NULL
> SID" group permission was added.  If I delete this value, I can
> properly execute the file, but if I leave it there, the file I'm
> trying to execute will not run.

I'm not quite sure what you observe there.  The NULL SID ACE only
contains extra information about some POSIX bits and the MASK value.
It's existence and setting should not influence what you can do with the
file.  The permission bits are explicitely set elsewhere in the ACL.

Can you reproduce the issue so that I can see what's going on?  I need
the icacls output for the file and its parent directory, as well as the
output from getfacl for both.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

[xnor]

>I'm not quite sure what you observe there.  The NULL SID ACE only
>contains extra information about some POSIX bits and the MASK value.
>It's existence and setting should not influence what you can do with 
>the
>file.  The permission bits are explicitely set elsewhere in the ACL.
>
>Can you reproduce the issue so that I can see what's going on?  I need
>the icacls output for the file and its parent directory, as well as the
>output from getfacl for both.
I have the same problem with Transmission.

I noticed this first when I tried to execute an exe that was downloaded 
with Transmission compiled in cygwin. When trying to start the exe from 
Explorer an error dialog will appear:
"Windows cannot access the specified device, path, or file. You may not 
have the appropriate permissions to access the item."

When going to file properties - security I get an information dialog 
window:
"The permissions on <program> are incorrectly ordered, which may cause 
some entries to be ineffective."

Proper permissions (of parent folder) look like this:
Authenticated Users: modify
SYSTEM: Full control
Administrators: Full control
Users: Read & execute


The permissions of the cygwin/transmission created files are (manually 
translated from German):
NULL SID: special
<My User>: special
Authenticated Users: Browse folder / Execute file
SYSTEM: Browse folder / Execute file
Administrators: Browse folder / Execute file
Users: Browse folder / Execute file
Nobody: Read
Authenticated Users: Read, write, execute
SYSTEM: Read, write, execute
Administrators: Read, write, execute
Users: Read, Execute
Everyone: Read


Also when going to advanced permissions it shows the same incorrectly 
ordered warning and asks me to re-order permissions.




--
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