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: Symlink targets dereferenced when winsymlinks:native
On 26. 11. 2015 12:53, Corinna Vinschen wrote: > On Nov 24 20:51, David Macek wrote: >> My test command is `touch 1 && ln -s 1 2`, then I clean up by `rm 1 2`. Now >> the results: >> >> in /bin/: relative >> in /: absolute >> in ~/ (/cygdrive/c/Users/username/): relative >> in /cygdrive/w/: absolute >> >> Note that W: is a permasubst (created using `DOSDevices` in registry), which >> would explain the different behaviour (but not excuse it :), but I don't see >> why / is also special. Even if only one from the link pair (target or >> source) is in a relative-symlink-unsupporting path, I get an absolute path. >> >> Can you confirm? > > Yes, thanks for this part of the analysis. There was a typo in the > code checking the relative paths. The check for a drive colon in the > pathname used a wrong offset into the path string, which ultimately > always created an absolut path to the target if the path of the > target was in a drive's root dir or one level below that. > > I fixed that in the repo and created a new developer snapshot for > testing: https://cygwin.com/snapshots/ Please give it a try. I get relative symlinks in all of my test cases now. Thanks. -- David Macek smime.p7s Description: S/MIME Cryptographic 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: Symlink targets dereferenced when winsymlinks:native
On Nov 29 15:00, David Macek wrote: > On 26. 11. 2015 12:53, Corinna Vinschen wrote: > > On Nov 24 20:51, David Macek wrote: > >> My test command is `touch 1 && ln -s 1 2`, then I clean up by `rm 1 2`. > >> Now the results: > >> > >> in /bin/: relative > >> in /: absolute > >> in ~/ (/cygdrive/c/Users/username/): relative > >> in /cygdrive/w/: absolute > >> > >> Note that W: is a permasubst (created using `DOSDevices` in registry), > >> which would explain the different behaviour (but not excuse it :), but I > >> don't see why / is also special. Even if only one from the link pair > >> (target or source) is in a relative-symlink-unsupporting path, I get an > >> absolute path. > >> > >> Can you confirm? > > > > Yes, thanks for this part of the analysis. There was a typo in the > > code checking the relative paths. The check for a drive colon in the > > pathname used a wrong offset into the path string, which ultimately > > always created an absolut path to the target if the path of the > > target was in a drive's root dir or one level below that. > > > > I fixed that in the repo and created a new developer snapshot for > > testing: https://cygwin.com/snapshots/ Please give it a try. > > I get relative symlinks in all of my test cases now. Thanks. Cool, thanks for testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpc8DOv0sNpl.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: Ability to specify /cygdrive mount value in setup
On 11/26/2015 1:04 PM, Achim Gratz wrote: > Corinna Vinschen writes: >> The right thing to do is to change the base-files package to utilize >> /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive >> prefix currently in use. If these symlinks under /etc used the >> /proc/cygdrive symlink, they would work all the time, independenly of >> the actual cygdrive prefix. > > I was thinking of using a native symlink, but going through the procfs > seems cleaner. > >> Achim, any chance to tweak base-file accordingly? > > Noted, but it might take a while. > That should work. Thanks for listening and working through the problem. -- cyg Simple -- 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: Ability to specify /cygdrive mount value in setup
On 11/26/2015 1:04 PM, Achim Gratz wrote: > Corinna Vinschen writes: >> Achim, any chance to tweak base-file accordingly? > > Noted, but it might take a while. > That should work. Thanks for listening and working through the problem. -- cyg Simple -- 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
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.6
Hi Cygwin friends and users, I released a new TEST version of Cygwin, 2.4.0-0.6. There's a single bugfix compared to 2.4.0-0.5: - Fix generating invalid SIDs in a border case related to using Microsoft Accounts. Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00362.html == If this code is acceptable, I will create an official 2.4.0 release end of this week. == 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 standard Windows ACLs, the POSIX permissions of the owner and all other users in the ACL are computed using the Windows AuthZ API. This may slow down the computation of POSIX permissions noticably in some circumstances, but is generally more correct. The new code also 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/msg00205.html - Fix handling of relat
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
