Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
On Nov 30 01:43, Kacper Michajlow wrote: > 2015-11-29 21:14 GMT+01:00 Corinna Vinschen : > > I just uploaded new developer snapshots to https://cygwin.com/snapshots/ > > and a new test release 2.4.0-0.6 with the aforementioned patch. Please > > give any of them a try. > > I can confirm that the issue is fixed in 2.4.0-0.6. Thanks for great support! Thanks for testing! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2KkVe9tYib.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
2015-11-29 21:14 GMT+01:00 Corinna Vinschen : > On Nov 29 18:10, Corinna Vinschen wrote: >> On Nov 29 15:10, Kacper Michajlow wrote: >> > 2015-11-29 13:59 GMT+01:00 Corinna Vinschen : >> > > Status 0xC078 aka Win32 error 1337 means "invalid SID". And the >> > > SID 1-5-32-1001 is in fact invalid. The S-1-5-32 prefix denotes a >> > > builtin >> > > account, but the RID 1001 is invalid for a builtin group. 1001 is the >> > > RID of your user account, though, but that would be prefixed by the SID >> > > of your machine, which looks like S-1-5-21---. >> > > I don't see how this broken SID came into life, unless your /etc/passwd >> > > and/or /etc/group files are broken (hand edited perhaps?). >> > >> > I guess I only changed shell to zsh in /etc/passwd, but no other >> > changes were made. So I have no idea how they could get corrupted >> > either. >> >> They aren't. There is no 1-5-32-1001 SID in those files and both files >> look entirely insuspicious. Given that Cygwin doesn't create any such >> SID from scratch, I'm totally puzzled where this SID is coming from. >> Your mkdir trace output doesn't show this SID anywhere else either. >> This definitely requires more debugging... > > I think I found it. The problem was the handling of Microsoft Accounts > on machines still using passwd and group files. And the additional > group entry for the user with a gid different from the user's uid was > required to uncover this problem. This is fortunately a border case, > but the fix seemed to be simple so I applied it and added a comment > so as not to forget why we have to do that. > >> > Works. >> >> Ok, that's good to know. Now I just have to find out where this >> weird SID was created :-P > > That fall into place after I realized what was happening. The gid > 1001 didn't exist in /etc/group so Cygwin calls the function to > evaluate a SID from a computed UID/GID, and this in turn generated > the invalid 1-5-32-1001 SID. WHile writing this I realized that > I should harden this part of the code to accept only RIDs < 1000... > >> > I personally am fine with abandoning /etc/passwd and /etc/group. This >> > is good enough solution for me. Though there might be other people >> > with the same issue. >> >> This seems to be a bug in Cygwin, and with the content of your files I >> finally managed to reproduce the issue. I'm planning to debug this next >> week and, hopefully, come up with a patch. It would be nice if you >> could do another test then in your environment :} > > I just uploaded new developer snapshots to https://cygwin.com/snapshots/ > and a new test release 2.4.0-0.6 with the aforementioned patch. Please > give any of them a try. I can confirm that the issue is fixed in 2.4.0-0.6. Thanks for great support! -Kacper -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
On Nov 29 18:10, Corinna Vinschen wrote: > On Nov 29 15:10, Kacper Michajlow wrote: > > 2015-11-29 13:59 GMT+01:00 Corinna Vinschen : > > > Status 0xC078 aka Win32 error 1337 means "invalid SID". And the > > > SID 1-5-32-1001 is in fact invalid. The S-1-5-32 prefix denotes a builtin > > > account, but the RID 1001 is invalid for a builtin group. 1001 is the > > > RID of your user account, though, but that would be prefixed by the SID > > > of your machine, which looks like S-1-5-21---. > > > I don't see how this broken SID came into life, unless your /etc/passwd > > > and/or /etc/group files are broken (hand edited perhaps?). > > > > I guess I only changed shell to zsh in /etc/passwd, but no other > > changes were made. So I have no idea how they could get corrupted > > either. > > They aren't. There is no 1-5-32-1001 SID in those files and both files > look entirely insuspicious. Given that Cygwin doesn't create any such > SID from scratch, I'm totally puzzled where this SID is coming from. > Your mkdir trace output doesn't show this SID anywhere else either. > This definitely requires more debugging... I think I found it. The problem was the handling of Microsoft Accounts on machines still using passwd and group files. And the additional group entry for the user with a gid different from the user's uid was required to uncover this problem. This is fortunately a border case, but the fix seemed to be simple so I applied it and added a comment so as not to forget why we have to do that. > > Works. > > Ok, that's good to know. Now I just have to find out where this > weird SID was created :-P That fall into place after I realized what was happening. The gid 1001 didn't exist in /etc/group so Cygwin calls the function to evaluate a SID from a computed UID/GID, and this in turn generated the invalid 1-5-32-1001 SID. WHile writing this I realized that I should harden this part of the code to accept only RIDs < 1000... > > I personally am fine with abandoning /etc/passwd and /etc/group. This > > is good enough solution for me. Though there might be other people > > with the same issue. > > This seems to be a bug in Cygwin, and with the content of your files I > finally managed to reproduce the issue. I'm planning to debug this next > week and, hopefully, come up with a patch. It would be nice if you > could do another test then in your environment :} I just uploaded new developer snapshots to https://cygwin.com/snapshots/ and a new test release 2.4.0-0.6 with the aforementioned patch. Please give any of them a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFQIJMCLfDU.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
On Nov 29 15:10, Kacper Michajlow wrote: > 2015-11-29 13:59 GMT+01:00 Corinna Vinschen : > > On Nov 29 02:16, Andrey Repin wrote: > >> Greetings, Kacper Michajlow! > >> > >> >> Please also attach the output of `id' and of `getfacl . test test/test'. > >> > >> > getfacl attached. `id` output is already in cygcheck.log > >> > >> > In getfacl output this line `default:group:1001 :r-x` looks > >> > >> Uh-oh. > >> Do you, by any chance, have /etc/passwd file? > >> Or a user comment changing relevant information? > > > > I agree with Andrey here: Uh oh! > > > > The mkdir trace contains a suspicious snippet which is the reason > > the mkdir call doesn't manage to post-process the ACL: > > > > [...] pwdgrp::fetch_account_from_windows: LookupAccountSidW > > (S-1-5-32-1001), Win32 error 1332 > > [...] /[...]/security.cc:337 status 0xC078 -> windows error 1337 > > > > Status 0xC078 aka Win32 error 1337 means "invalid SID". And the > > SID 1-5-32-1001 is in fact invalid. The S-1-5-32 prefix denotes a builtin > > account, but the RID 1001 is invalid for a builtin group. 1001 is the > > RID of your user account, though, but that would be prefixed by the SID > > of your machine, which looks like S-1-5-21---. > > I don't see how this broken SID came into life, unless your /etc/passwd > > and/or /etc/group files are broken (hand edited perhaps?). > > I guess I only changed shell to zsh in /etc/passwd, but no other > changes were made. So I have no idea how they could get corrupted > either. They aren't. There is no 1-5-32-1001 SID in those files and both files look entirely insuspicious. Given that Cygwin doesn't create any such SID from scratch, I'm totally puzzled where this SID is coming from. Your mkdir trace output doesn't show this SID anywhere else either. This definitely requires more debugging... > $ icacls test > test NULL SID:(DENY)(Rc,S) > DOMEK\Kacper:(F) > DOMEK\Kacper:(RX) > Wszyscy:(RX) > NULL SID:(OI)(CI)(IO)(DENY)(Rc,S) > TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) > GRUPA TWORCOW:(OI)(CI)(IO)(RX) > Wszyscy:(OI)(CI)(IO)(RX) > > $ icacls test/test > test/test NULL SID:(DENY)(Rc,S) > DOMEK\Kacper:(F) > DOMEK\Kacper:(RX) > Wszyscy:(RX) > NULL SID:(OI)(CI)(IO)(DENY)(Rc,S) > TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) > GRUPA TWORCOW:(OI)(CI)(IO)(RX) > Wszyscy:(OI)(CI)(IO)(RX) Looks better now. > BTW. icacls doesn't handle UTF-8 characters well. Just saying. Heh, yeah. But given that icacls is a Windows tool, not a Cygwin tool, I'm rather relaxed about this ;) I'm wondering about the lack of UTF-8 support in most Windows CLI tools myself. > > - Try chmod 755 test/test again. > > Works. Ok, that's good to know. Now I just have to find out where this weird SID was created :-P > > - Also, would you mind to attach your /etc/passwd, /etc/group and > > /etc/nsswitch.conf files to your reply? > > /etc/nsswitch.conf has only commented out default values. Two others > are attached. To make this clear, I never edited those files except > zsh change Not even the group entry for group 11001? It doesn't look like an entry which would get created automatically. > so if they are corrupted in any way they must have been > produced like that. Though it probably was over the year ago when I > installed cygwin on this machine. No, the files look ok, basically. > I personally am fine with abandoning /etc/passwd and /etc/group. This > is good enough solution for me. Though there might be other people > with the same issue. This seems to be a bug in Cygwin, and with the content of your files I finally managed to reproduce the issue. I'm planning to debug this next week and, hopefully, come up with a patch. It would be nice if you could do another test then in your environment :} Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDAt34fPxCF.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
2015-11-29 13:59 GMT+01:00 Corinna Vinschen : > On Nov 29 02:16, Andrey Repin wrote: >> Greetings, Kacper Michajlow! >> >> >> Please also attach the output of `id' and of `getfacl . test test/test'. >> >> > getfacl attached. `id` output is already in cygcheck.log >> >> > In getfacl output this line `default:group:1001 :r-x` looks >> >> Uh-oh. >> Do you, by any chance, have /etc/passwd file? >> Or a user comment changing relevant information? > > I agree with Andrey here: Uh oh! > > The mkdir trace contains a suspicious snippet which is the reason > the mkdir call doesn't manage to post-process the ACL: > > [...] pwdgrp::fetch_account_from_windows: LookupAccountSidW > (S-1-5-32-1001), Win32 error 1332 > [...] /[...]/security.cc:337 status 0xC078 -> windows error 1337 > > Status 0xC078 aka Win32 error 1337 means "invalid SID". And the > SID 1-5-32-1001 is in fact invalid. The S-1-5-32 prefix denotes a builtin > account, but the RID 1001 is invalid for a builtin group. 1001 is the > RID of your user account, though, but that would be prefixed by the SID > of your machine, which looks like S-1-5-21---. > I don't see how this broken SID came into life, unless your /etc/passwd > and/or /etc/group files are broken (hand edited perhaps?). I guess I only changed shell to zsh in /etc/passwd, but no other changes were made. So I have no idea how they could get corrupted either. > You're aware that you don't need the /etc/passwd and /etc/group files > anymore, aren't you? https://cygwin.com/cygwin-ug-net/ntsec.html I never really thought about it until it worked. But yeah, this might be good time to abandon those files. > > For testing I'd like you to do the following: > > - Edit /etc/nsswitch,conf and change the "passwd:" and "group:" lines > to omit checking the passwd and group files: > > passwd: db > group: db > > - Exit all Cygwin processes and restart a shell. > > - Call `id' again and attach it to your reply. The uids and gids of > your account and primary group should be different now. > > - Remove the test dir, call `mkdir -p test/test' and call icacls on test > and test/test. $ icacls test test NULL SID:(DENY)(Rc,S) DOMEK\Kacper:(F) DOMEK\Kacper:(RX) Wszyscy:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S) TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) GRUPA TWORCOW:(OI)(CI)(IO)(RX) Wszyscy:(OI)(CI)(IO)(RX) $ icacls test/test test/test NULL SID:(DENY)(Rc,S) DOMEK\Kacper:(F) DOMEK\Kacper:(RX) Wszyscy:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S) TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) GRUPA TWORCOW:(OI)(CI)(IO)(RX) Wszyscy:(OI)(CI)(IO)(RX) BTW. icacls doesn't handle UTF-8 characters well. Just saying. > - Try chmod 755 test/test again. Works. > - Also, would you mind to attach your /etc/passwd, /etc/group and > /etc/nsswitch.conf files to your reply? /etc/nsswitch.conf has only commented out default values. Two others are attached. To make this clear, I never edited those files except zsh change so if they are corrupted in any way they must have been produced like that. Though it probably was over the year ago when I installed cygwin on this machine. I personally am fine with abandoning /etc/passwd and /etc/group. This is good enough solution for me. Though there might be other people with the same issue. -Kacper id.log Description: Binary data group Description: Binary data passwd Description: Binary data -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
On Nov 29 02:16, Andrey Repin wrote: > Greetings, Kacper Michajlow! > > >> Please also attach the output of `id' and of `getfacl . test test/test'. > > > getfacl attached. `id` output is already in cygcheck.log > > > In getfacl output this line `default:group:1001 :r-x` looks > > Uh-oh. > Do you, by any chance, have /etc/passwd file? > Or a user comment changing relevant information? I agree with Andrey here: Uh oh! The mkdir trace contains a suspicious snippet which is the reason the mkdir call doesn't manage to post-process the ACL: [...] pwdgrp::fetch_account_from_windows: LookupAccountSidW (S-1-5-32-1001), Win32 error 1332 [...] /[...]/security.cc:337 status 0xC078 -> windows error 1337 Status 0xC078 aka Win32 error 1337 means "invalid SID". And the SID 1-5-32-1001 is in fact invalid. The S-1-5-32 prefix denotes a builtin account, but the RID 1001 is invalid for a builtin group. 1001 is the RID of your user account, though, but that would be prefixed by the SID of your machine, which looks like S-1-5-21---. I don't see how this broken SID came into life, unless your /etc/passwd and/or /etc/group files are broken (hand edited perhaps?). You're aware that you don't need the /etc/passwd and /etc/group files anymore, aren't you? https://cygwin.com/cygwin-ug-net/ntsec.html For testing I'd like you to do the following: - Edit /etc/nsswitch,conf and change the "passwd:" and "group:" lines to omit checking the passwd and group files: passwd: db group: db - Exit all Cygwin processes and restart a shell. - Call `id' again and attach it to your reply. The uids and gids of your account and primary group should be different now. - Remove the test dir, call `mkdir -p test/test' and call icacls on test and test/test. - Try chmod 755 test/test again. - Also, would you mind to attach your /etc/passwd, /etc/group and /etc/nsswitch.conf files to your reply? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnxJ9168yHR.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
Greetings, Kacper Michajlow! >> Please also attach the output of `id' and of `getfacl . test test/test'. > getfacl attached. `id` output is already in cygcheck.log > In getfacl output this line `default:group:1001 :r-x` looks Uh-oh. Do you, by any chance, have /etc/passwd file? Or a user comment changing relevant information? > suspicious. My user id seems to be in place of group id. Looking at > `test` permissions there should probably be indeed `user` instead of > `group`. But you will know better :) > Hopefully you will be able to diagnose the issue now. -- With best regards, Andrey Repin Sunday, November 29, 2015 02:14: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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
On Nov 27 20:15, Kacper Michajlow wrote: > 2015-11-27 20:02 GMT+01:00 Kacper Michajlow : > > 2015-11-26 14:16 GMT+01:00 Corinna Vinschen : > >> Hi Kacper, > >> > >> On Nov 23 19:09, Kacper Michajlow wrote: > >>> 2015-11-21 17:24 GMT+01:00 Corinna Vinschen : > >>> > Hi Cygwin friends and users, > >>> > > >>> > > >>> > I released a new TEST version of Cygwin, 2.4.0-0.4. > >>> > > >>> > >>> With this version I get permissions denied when trying to chmod a > >>> folder created in a created folder... > >>> > >>> Basically this doesn't work for me: > >>> mkdir test > >>> mkdir test/test > >>> chmod 755 test/test > >> > >> I need to see the ACLs of the parent dir of test, the ACL of test and > >> the ACL of test/test via the icacls command, before calling chmod. > > I'm using Microsoft account. Here is requested information I can't reproduce this. I'm using a local test account which is connected to a Microsoft account. The permissions of the parent folder are identical to yours: > $ pwd > /home/Kacper > $ icacls . > . DOMEK\Kacper:(F) > Wszyscy:(RX) > TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) > GRUPA TWORCOW:(OI)(CI)(IO)(RX) > Wszyscy:(OI)(CI)(IO)(RX) $ icacls . . VMBERT8164\local_000:(F) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) > $ mkdir test > $ icacls test > test NULL SID:(DENY)(Rc,S) > DOMEK\Kacper:(F) > DOMEK\Kacper:(RX) > Wszyscy:(RX) > NULL SID:(OI)(CI)(IO)(DENY)(Rc,S) > TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) > DOMEK\Kacper:(OI)(CI)(IO)(RX) ^^ See below > GRUPA TWORCOW:(OI)(CI)(IO)(RX) > Wszyscy:(OI)(CI)(IO)(RX) $ mkdir test $ icacls test test NULL SID:(DENY)(Rc,S) VMBERT8164\local_000:(F) VMBERT8164\local_000:(RX) Everyone:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Note that in my case the inheritable explicit permissions for the owner account (^) are not generated, which is already puzzeling just by itself. But the test/test icacls output explains why chmod fails: > $ mkdir test/test > $ icacls test/test > test/test NULL SID:(OI)(CI)(DENY)(Rc,S) > DOMEK\Kacper:(F) > TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) > DOMEK\Kacper:(OI)(CI)(RX) > DOMEK\Kacper:(RX) > GRUPA TWORCOW:(OI)(CI)(IO)(RX) > Wszyscy:(OI)(CI)(RX) This is how the ACL looks like after creating the directory, but before Cygwin performs ACL post-processing. The only possible reason for this is that already the mkdir call failed to fix the ACL. But it's not clear why this happens. Your account has "F"ull permissions, so it also has WRITE_DAC permissions. > Tell me if you need any more info. Yes. First of all, please send cygcheck -svr output as requested on http://cygwin.com/problems.html. Next, when you wrote "With this version ...", does that mean this is a regression from 2.4.0-0.2 to 2.4.0-0.4, or did you compare with 2.3.1-1? I'm asking because I'd like to know in which version the regression occured. Is "DOMEK" the name of your local machine or an AD domain? What filesystem is that on? Local or remote share? Real NTFS or some other filesystem? I'm asking because on some remote filesystems even the owner of a file may have no WRITE_DAC permissions, despite having supposedly "full" permissions. Can you please rmdir test/test and then run mkdir under strace: $ strace -o mkdir.trace mkdir test/test and attach the trace file to your reply? Please use ther latest 2.4.0-0.5, just to be sure. Please also attach the output of `id' and of `getfacl . test test/test'. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgps15JNkXcW_.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
2015-11-27 20:02 GMT+01:00 Kacper Michajlow : > 2015-11-26 14:16 GMT+01:00 Corinna Vinschen : >> Hi Kacper, >> >> On Nov 23 19:09, Kacper Michajlow wrote: >>> 2015-11-21 17:24 GMT+01:00 Corinna Vinschen : >>> > Hi Cygwin friends and users, >>> > >>> > >>> > I released a new TEST version of Cygwin, 2.4.0-0.4. >>> > >>> >>> With this version I get permissions denied when trying to chmod a >>> folder created in a created folder... >>> >>> Basically this doesn't work for me: >>> mkdir test >>> mkdir test/test >>> chmod 755 test/test >> >> I need to see the ACLs of the parent dir of test, the ACL of test and >> the ACL of test/test via the icacls command, before calling chmod. I'm using Microsoft account. Here is requested information $ pwd /home/Kacper $ icacls . . DOMEK\Kacper:(F) Wszyscy:(RX) TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) GRUPA TWORCOW:(OI)(CI)(IO)(RX) Wszyscy:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files $ mkdir test $ icacls test test NULL SID:(DENY)(Rc,S) DOMEK\Kacper:(F) DOMEK\Kacper:(RX) Wszyscy:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S) TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) DOMEK\Kacper:(OI)(CI)(IO)(RX) GRUPA TWORCOW:(OI)(CI)(IO)(RX) Wszyscy:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files $ mkdir test/test $ icacls test/test test/test NULL SID:(OI)(CI)(DENY)(Rc,S) DOMEK\Kacper:(F) TWORCA-WLASCICIEL:(OI)(CI)(IO)(F) DOMEK\Kacper:(OI)(CI)(RX) DOMEK\Kacper:(RX) GRUPA TWORCOW:(OI)(CI)(IO)(RX) Wszyscy:(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files $ chmod 755 test/test chmod: nie mozna zmienic uprawnien do „test/test”: Permission denied I'm using Polish version of Windows so in case you have trouble matching groups with English names. "Wszyscy" == "Everyone", "TWORCA-WLASCICIEL" == "CREATOR OWNER", "GRUPA TWORCOW" == "CREATOR GROUP". Tell me if you need any more info. Ps. Sorry for empty mail I've send before. -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
2015-11-26 14:16 GMT+01:00 Corinna Vinschen : > Hi Kacper, > > On Nov 23 19:09, Kacper Michajlow wrote: >> 2015-11-21 17:24 GMT+01:00 Corinna Vinschen : >> > Hi Cygwin friends and users, >> > >> > >> > I released a new TEST version of Cygwin, 2.4.0-0.4. >> > >> >> With this version I get permissions denied when trying to chmod a >> folder created in a created folder... >> >> Basically this doesn't work for me: >> mkdir test >> mkdir test/test >> chmod 755 test/test > > I need to see the ACLs of the parent dir of test, the ACL of test and > the ACL of test/test via the icacls command, before calling chmod. > >> Additional top level directory after creating have drwx---r-x, and >> even after chmod 777, it still have only drwx---rwx. Notice no group >> permissions? I might be missing something here, but doesn't look >> right, does it? > > It is right if you're using one of those annoying Microsoft accounts > instead of a real local account. If so, the primary group SID in your > user token is identical to your user SID. This scenario can't be > easily translated to a POSIX scenario. The group permissions are set > to 0 in this case to allow security sensitive applications checking file > permissions to function without complaining of too open permissions. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
Hi Kacper, On Nov 23 19:09, Kacper Michajlow wrote: > 2015-11-21 17:24 GMT+01:00 Corinna Vinschen : > > Hi Cygwin friends and users, > > > > > > I released a new TEST version of Cygwin, 2.4.0-0.4. > > > > With this version I get permissions denied when trying to chmod a > folder created in a created folder... > > Basically this doesn't work for me: > mkdir test > mkdir test/test > chmod 755 test/test I need to see the ACLs of the parent dir of test, the ACL of test and the ACL of test/test via the icacls command, before calling chmod. > Additional top level directory after creating have drwx---r-x, and > even after chmod 777, it still have only drwx---rwx. Notice no group > permissions? I might be missing something here, but doesn't look > right, does it? It is right if you're using one of those annoying Microsoft accounts instead of a real local account. If so, the primary group SID in your user token is identical to your user SID. This scenario can't be easily translated to a POSIX scenario. The group permissions are set to 0 in this case to allow security sensitive applications checking file permissions to function without complaining of too open permissions. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnipQqqUCYF.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
Greetings, Kacper Michajlow! >> I released a new TEST version of Cygwin, 2.4.0-0.4. >> > With this version I get permissions denied when trying to chmod a > folder created in a created folder... > Basically this doesn't work for me: > mkdir test > mkdir test/test > chmod 755 test/test > Additional top level directory after creating have drwx---r-x, and > even after chmod 777, it still have only drwx---rwx. Notice no group > permissions? I might be missing something here, but doesn't look > right, does it? We need more data points to analyze the issue. Where this directory located? Inside Cygwin root or outside it? What are the full (getfacl/icacls) permissions on the current directory? What are full resulting permissions on the created directories? What kind of the account you are using? Local account or (God forbid!) Microsoft account? -- With best regards, Andrey Repin Tuesday, November 24, 2015 04:02:11 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
2015-11-21 17:24 GMT+01:00 Corinna Vinschen : > Hi Cygwin friends and users, > > > I released a new TEST version of Cygwin, 2.4.0-0.4. > With this version I get permissions denied when trying to chmod a folder created in a created folder... Basically this doesn't work for me: mkdir test mkdir test/test chmod 755 test/test Additional top level directory after creating have drwx---r-x, and even after chmod 777, it still have only drwx---rwx. Notice no group permissions? I might be missing something here, but doesn't look right, does it? -- 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
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.4
Hi Cygwin friends and users, I released a new TEST version of Cygwin, 2.4.0-0.4. (I uploaded a -0.3 release as well, but it was missing a patch) There are three changes compared to 2.4.0-0.2: - Newlib's strtold implementation was completely non-standard and therefore buggy. I replaced it with the latest gdtoa version from David M. Gay, - Windows returned other numerical and monetary decimal point and thousand separator characters than Linux. I fixed that in Cygwin to return the Linux values. - Cygwin exports a new function: rpmatch. == If this code is acceptable, I will create an official 2.4.0 release end of November. == This is the "new POSIX ACL handling reloaded" release. In local testing I successfully integrated AuthZ into the current Cygwin code to generate more correct user permissions by being able to generate effective permissions for arbitrary users. This success convinced me that it might be possible to pick up the POSIX permission rewrite originally targeted for the 2.0.0 release and try to update it using AuthZ and generally revamp it to reflect effective permissions better. My local testing looks good, but this is a major change, so this code really needs a lot more testing in various scenarios. Especially some Windows ACLs created in corporate environments are often a hard nut to crack, and the example from https://cygwin.com/ml/cygwin/2015-04/msg00513.html which was the ultimate downfall of the original implementation is the stuff which needs some good testing. There's, as usual, a downside: AuthZ leans a bit to the slow side. Cygwin caches information already gathered once on a per-process basis, but in locally crafted worst case scenarios (`ls' on lots of file owned by lots of different users and groups) the slowdown may be up to 25%. But that's really just a worst case, in the usual scenarios the slowdown should be mostly unnoticable. To alleviate the problem, the AuthZ code is fortunately only called for non-Cygwin ACLs and Cygwin ACLs created before this release. Within a pure Cygwin environment (e.g., some build directory only used with Cygwin tools) AuthZ should be practically unused. Apart from the aforementioned code changes to "just do it right", there are two additional changes I implemented for this new POSIX ACL revamp release: - I reverted the questionable change I added to 2.0.0-0.7 in terms of chmod group permission handling. The original description of this change was: If you have a non-trivial ACL with secondary accounts and thus a mask value, chmod is supposed to change only the mask, not the permissions of the primary group. However, if the primary group has few permissions to begin with, the result is really surprising. ls -l would, e.g., show read/write perms for the group, but the group might still have only read perms. Personally I find this chmod behaviour really, really bad, so I took the liberty to change it in a way which gives a much less surprising result: If you call chmod on a non-trivial ACL, the group permissions will be used for the primary group and the mask. - setfacl(1) now accepts the combination of the -b and -k options, just as on Linux. As for the description what this implementation strives for, please see http://linux.die.net/man/5/acl What's new: --- - New, unified implementation of POSIX permission and ACL handling. The new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and they allow to inherit the S_ISGID bit. ACL inheritance now really works as desired, in a limited, but theoretically equivalent fashion even for non-Cygwin processes. To accommodate Windows default ACLs, the new code ignores SYSTEM and Administrators group permissions when computing the MASK/CLASS_OBJ permission mask on old ACLs, and it doesn't deny access to SYSTEM and Administrators group based on the value of MASK/CLASS_OBJ when creating the new ACLs. The new code now handles the S_ISGID bit on directories as on Linux: Setting S_ISGID on a directory causes new files and subdirs created within to inherit its group, rather than the primary group of the user who created the file. This only works for files and directories created by Cygwin processes. - New API: rpmatch. What changed: - - setfacl(1) now allows to use the -b and -k option combined to allow reducing an ACL to only reflect standard POSIX permissions. - Fix (numeric and monetary) decimal point and thousands separator in fa_IR and ps_AF locales to be aligned with Linux. Bug Fixes - - Replaced old, buggy strtold implementation with well-tested gdtoa version from David M. Gay. Addresses: https://cygwin.com/ml/cygwin/2015-11/msg002