Re: 1.7.25, Windows 7: dumper doesn't generate core file
On Wed, Mar 12, 2014 at 03:03:52PM +1100, Sam lia...@constrainttec.com wrote: > >Thanks Corinna I appreciate the response. > >>>Question 2: IS THE CODE MODIFICATION AN ACCEPTABLE SOLUTION TO THE PROBLEM? > > > Maybe, but first it would be helpful if somebody could explain why > > sections should be able to overlap at all. That's puzzling me. > > > > As for patches, did you seehttp://cygwin.com/contrib.html > > For small, obvious patches, we don't need the copyright assignment. > > Rule of thumb is < 10 lines. > > > I'm happy to submit minor patches on both points covered in the >original post. > However as you noted I'll wait for someone to first explain if/why >sections overlap. I doubt we'll get an answer here. Possibly someone in the binutils mailing list would know but I think it's probably safe to assume that sections don't overlap. cgf -- 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
If you are having problems sending email here
On Tue, Mar 11, 2014 at 09:53:52PM -0400, Christopher Faylor wrote: >Just to be clear: The intent of my email was to actually save people >from going to the pointless exercise of trying to contact Corinna or >Larry directly since it won't work. To reiterate, here's the mailing list FAQ: https://sourceware.org/lists.html#FAQ The instructions there are designed to help work through most problems. The most common problem by far is people sending html-formatted email. I often see people who should know better sending html-formatted messages multiple times, apparently in the hopes that one message will sneak by. Second to this is people including raw email addresses in the subjects or bodies of their messages. Third is people sending email to various Cygwin personalities at cygwin.com expecting to have a private chat (i.e., what prompted the first message in this thread). The html restriction is a sourceware.org policy so please don't attempt to argue about it here. This is also not the place to gripe about "antiquated" mailing list software. If you want to make a case for changing something related to site policy (like html mail or "antiquated" software), send email to overseers at this site. If you have email problems that can't be solved by reading the FAQ (this is a rare occurence) then send email to cygwin-owner/postmaster. Oh, and this should go without saying but before claiming that your email isn't going through: 1) Check the archives (see http://cygwin.com/lists.html) to make sure that it really didn't go through. 2) Check your spam filters to make sure that you haven't received a helpful bounce message telling you what's wrong. postmaster (aka me) will want to see the bounce message if it's not html-related. And, *please* don't reply to this message complaining that you did everything and nothing worked. If you are having problems send a short note to postmaster (aka me) and I will work out what is going on. I'll even do it if you are bitter, angry, and lecturey. I won't like you much but I'll still help. If you send email claiming that the system is saying that you are sending html-formatted email and you know you're not I'll just point you at the FAQ and make sure you know that our mail system is probably better than you at noticing when email is formatted in html. cgf -- 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: 1.7.25, Windows 7: dumper doesn't generate core file
Thanks Corinna I appreciate the response. Question 2: IS THE CODE MODIFICATION AN ACCEPTABLE SOLUTION TO THE PROBLEM? > Maybe, but first it would be helpful if somebody could explain why > sections should be able to overlap at all. That's puzzling me. > > As for patches, did you seehttp://cygwin.com/contrib.html > For small, obvious patches, we don't need the copyright assignment. > Rule of thumb is < 10 lines. I'm happy to submit minor patches on both points covered in the original post. However as you noted I'll wait for someone to first explain if/why sections overlap. Thanks, Sam On 11/03/14 22:02, Corinna Vinschen wrote: Hi Sam, On Mar 11 10:35, Sam Liapis wrote: >As a disclaimer I'm new to Cygwin and memory mapping that's alluded to in this post. > >My brief was to investigate and resolve an issue with dumper not producing a core. > >With that I'll proceed with outlining the journey including my findings so far. > >I'll begin with the error message given by dumper when run in verbose mode: >(Note: I modified debug output to provide base address of excluded memory) >[,..] >Code analysis reveals a few shortcomings leading up to this failure. Firstly the process of >identifying sections to exclude, includes sorting and checking that regions do not overlap. >Upon closer inspection the function in question at ...winsup/utils/parse_pe.cc appears to >have a couple of problems. > > a) "if (q == p + 1)" at line 60 always resolves true bypassing subsequent loop code. > > b) The 'size' parameter at line 63 is a global instead of p->size. The test expression >should be if (p->base + p->size > q->base) in order to test for overlapping regions. This looks very wrong indeed. >[...] >Even if sort_and_check () worked correctly it wouldn't prevent dumper failure it just raises an alert. > >Secondly when dumper builds a list of memory regions to dump into a core file it has no logic to cater >for overlapping sections to exclude. Here in lies my first question regarding this issue: > > >Question 1: SHOULD MEMORY REGIONS IDENTIFIED FOR EXCLUSION EVER OVERLAP? I can't really answer this question safely, but AFAIK, the answer is no. The sections and memory layout in a pe/coff file are so that the sections have unique VMAs, including debug sections. An overlap of sections should never occur, otherwise the Windows loader would have refused to load the executable into memory anyway. Unless I'm missing something... >Question 2: IS THE CODE MODIFICATION AN ACCEPTABLE SOLUTION TO THE PROBLEM? Maybe, but first it would be helpful if somebody could explain why sections should be able to overlap at all. That's puzzeling me. As for patches, did you seehttp://cygwin.com/contrib.html For small, obvious patches, we don't need the copyright assignment. Rule of thumb is < 10 lines. Thanks, 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: Please stop sending email to ...
Just to be clear: The intent of my email was to actually save people from going to the pointless exercise of trying to contact Corinna or Larry directly since it won't work. On Tue, Mar 11, 2014 at 04:42:36PM -0700, Someone Who Took Personal Offense About General Advice wrote: >Christopher Faylor-8 wrote >> I know that this is a pointless exercise but I'll say it anyway: people >> who think that they can have a private chat with Corinna or Larry by >> sending email to what seem to be their private email addresses will just >> show up in the spam trap, possibly even causing spamassassin to think >> that they are a spammer. >> >> We mention in multiple places that cygwin-related issues should go to >> this list. So, please don't bother trying to send private email unless >> you've been specifically asked to do so. You'll also be doing me a >> favor because I won't have to spend time cleaning out the spam traps. > >Well, here goes nothing. > >I am happy to admit that I'm one of those persons. The problem is >exactly that what you claim we "should do" versus what is actually >possible to do. If any of the list maintainers had actually bothered >to try to register to these email lists, you would probably have found >out that your spam filters are set so high, that it is impossible for >normal people to even register to these lists! FYI, The Cygwin list has 1212 subscribers with 89 new joiners since January 1. I'm the "list maintainer" and I'm obviously registered. The same software that handles Cygwin also handles gcc.gnu.org and sourceware.org. There are many other mailing lists under those domains, and some of them have even more subscribers. I told you why your mail was blocked, indicated that I took steps to correct the action, and told you were to send email if you had further problems. You have not availed yourself of that channel since I told you about it (you did try to send email there prior to that point though). If you really do want to get to the bottom of your email issues then please start a dialog with cygwin-owner or postmaster. You'll still be talking to me but you won't be using this list for your non-cygwin concerns. You'd mentioned that you hadn't received notification that you'd been subscribed so I checked on that. You subscribed to cygwin-allow. Our mailing list software doesn't send confirmation notice when signing up for *-allow. It does when you actually subscribe. So, since you aren't subscribed to the actual cygwin list (under this email address at least) you wouldn't have seen a subscription ACK. But, anyway, subscribing to cygwin-allow or cygwin itself would only slightly relax the spam checking. It wouldn't have helped with the spam block that you were seeing. That required manual intervention on my part. As I said, I fixed that. >So to conclude, it is really your own fault that people are desperate >to try to contact anyone on this list, to help them out. You're assuming facts not in evidence. There was a specific email that prompted one of my periodic reminders not to try to send private email but it was not in *any* way a plaintive request for help. But, regardless, if you think about it, sending email to some...@cygwin.com because you are frustrated about being spam blocked when sending to somethinge...@cygwin.com doesn't make a whole lot of sense. What does make sense is following the link at the bottom of http://cygwin.com/lists.html which leads you to: https://sourceware.org/lists.html#faqs If you follow that list then you get to: https://sourceware.org/lists.html#spam which *does* tell you where to send email if you feel you are being inappropriately blocked. >Good Luck and Best Wishes, > >Gene Rederer >(CEO, developer and Cygwin user since ~10 years) Same to you. Chris Faylor Kernel Programmer, Cygwin Contributor for 17 years, Cygwin Maintainer for 16 years, and Schmuck who spends a lot of time doing complicated stuff for people for free -- 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: Please stop sending email to corinna-cygwin and lh-cygwin
Christopher Faylor-8 wrote > I know that this is a pointless exercise but I'll say it anyway: people > who think that they can have a private chat with Corinna or Larry by > sending email to what seem to be their private email addresses will just > show up in the spam trap, possibly even causing spamassassin to think > that they are a spammer. > > We mention in multiple places that cygwin-related issues should go to > this list. So, please don't bother trying to send private email unless > you've been specifically asked to do so. You'll also be doing me a > favor because I won't have to spend time cleaning out the spam traps. Well, here goes nothing. I am happy to admit that I'm one of those persons. The problem is exactly that what you claim we "should do" versus what is actually possible to do. If any of the list maintainers had actually bothered to try to register to these email lists, you would probably have found out that your spam filters are set so high, that it is impossible for normal people to even register to these lists! So then what are you supposed to do? In addition you do not mention anywhere what to do and who to contact, when you have problems registering to this list. Trust me, I have tried in this last week to get properly registered using at least 3 different email addresses (one gmail and two professional ones under the domain names of the companies I work for.) Every time the response is that the confirmation emails are blocked due to anti-spam score of over 500. I should also mention that I am a member of several other email lists with these accounts, and nver had any problem with these before. So I thought perhaps my email domains are located on a shared and spammy subdomain. But that investigation was also negative. So to conclude, it is really your own fault that people are desperate to try to contact anyone on this list, to help them out. I can't begin to imagine how many bug reports you are loosing because of people not being able to contact you or report their findings. I have now given up, as anything that shows here has the warning that it has not been approved by the list. Finally, I find it very hard to understand why the Cygwin developers keep on insisting on using this outdated (and obviously failing) 1990's email lists for their main communication channel. Good Luck and Best Wishes, Gene Rederer (CEO, developer and Cygwin user since ~10 years) -- View this message in context: http://cygwin.1069669.n5.nabble.com/Please-stop-sending-email-to-corinna-cygwin-and-lh-cygwin-tp107039p107040.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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
Please stop sending email to corinna-cygwin and lh-cygwin
I know that this is a pointless exercise but I'll say it anyway: people who think that they can have a private chat with Corinna or Larry by sending email to what seem to be their private email addresses will just show up in the spam trap, possibly even causing spamassassin to think that they are a spammer. We mention in multiple places that cygwin-related issues should go to this list. So, please don't bother trying to send private email unless you've been specifically asked to do so. You'll also be doing me a favor because I won't have to spend time cleaning out the spam traps. Thank you. cgf -- 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: Cygwin64 ignoring /etc/passwd shell field?
Corinna Vinschen writes: > Thanks for finding this one! Unfortunately David has left us, > apparently. Isn't it that a bit too short a time to come to this conclusion? > Is anybody willing to take over maintainership of the base-files > package? Seeing that I have additional patches that David didn't apply to the test version, I could do that. But let's confirm first that he's not just having a vacation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: Cygwin64 ignoring /etc/passwd shell field?
Corinna Vinschen wrote: On Mar 6 14:40, Ken Brown wrote: On 3/3/2014 10:05 AM, Corinna Vinschen wrote: On Mar 3 08:55, Charles Wilson wrote: On 2/26/2014 5:07 AM, Corinna Vinschen wrote: Weird, I was pretty sure we already have an /etc/shells file installed by default. Apparently not. So, shan't we add one? /bin/sh /bin/bash /bin/dash /bin/mksh /bin/zsh /usr/bin/sh /usr/bin/bash /usr/bin/dash /usr/bin/mksh /usr/bin/zsh The base-files package would be a good place to be. David? Currently inetutils-server provides /etc/defaults/etc/shells. If that file is required by base functionality now, then I've no problem removing it and modifying inetutils' postinstall/preremove scripts. But we'll need to synchronize the uploads of inetutils-server-$next and base-files-$next. Speaking of base-files, version 4.1-2 has been in test now for over two years...works fine here and fixes a problem with $TEMP and other "standard" variable names: 4.1-1 set both $TEMP and $temp, but these are not distinguished by native processes, leading to confusion if a native process reset $TEMP (but not $temp). I had a problem when running it in an early stage of 64 bit development, but I don't remember at all what the problem was. Do you run it on 64 bit as well? I think this is what you're trying to remember: http://cygwin.com/ml/cygwin/2013-07/msg00114.html Thanks for finding this one! Unfortunately David has left us, apparently. Is anybody willing to take over maintainership of the base-files package? Thanks, Corinna It seems no one is interested. I don't know anything about package maintenance for Cygwin, but this particular package doesn't look that hard. I'd be willing to give it a shot. Is the information on this page (http://cygwin.com/setup.html) up-to-date? -- Chris J. Breisch -- 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: Need general snapshot testers/console buffer jumble
On 10/03/2014 11:11, Corinna Vinschen wrote: On Mar 10 07:46, Marco Atzeri wrote: On 10/03/2014 04:21, Christopher Faylor wrote: On Sun, Mar 09, 2014 at 09:25:02PM -0500, Steven Penny wrote: On Sun, Mar 9, 2014 at 2:14 PM, Christopher Faylor wrote: Interesting problem. Windows always surprises. This should be fixed in the upcoming snapshot. cgf $ uname -svr CYGWIN_NT-6.1-WOW64 1.7.29s(0.272/5/3) 20140310 03:20:19 xwin still segfaults as for http://cygwin.com/ml/cygwin/2014-03/msg00107.html I just tried the latest 32 bit snapshot: CYGWIN_NT-6.3-WOW64 1.7.29s(0.272/5/3) 20140310 03:20:19 and I can't reproduce this crash running startxwin. I removed my /etc/nsswitch.conf file to use the default settings throughout for the passwd/group stuff for testing, but it also works fine with passwd: db group: db db_enum: all What are you settings? I also ran the same under a 64 bit Cygwin built from CVS. No crash either. Corinna Hi Corinna, I think it is due to the unusual history of my cygwin installation, that is triggering a corner case. The system is installed on a USB disk and it migrated from one computer to another, so some of old ACLs are not recognized from one new system. On AD aware snapshots: $ uname -svr CYGWIN_NT-6.1-WOW64 1.7.29s(0.272/5/3) 20140310 03:20:19 $ ls -l nco-4.*.gz ls: cannot access nco-4.3.9.tar.gz: Bad address -rw-r--r-- 1 marco root 5846624 Jan 29 2013 nco-4.2.5.tar.gz -rw-r--r-- 1 Administrators None 4479960 Jan 30 00:07 nco-4.4.1.tar.gz while on 1.7.29 branch snapshot $ uname -svr CYGWIN_NT-6.1-WOW64 1.7.29s(0.272/5/3) 20140309 23:12:54 $ ls -l nco-4.*.gz -rw-r--r-- 1 marco Administrators 5846624 Jan 29 2013 nco-4.2.5.tar.gz -rw-r--r-- 1 marco 4418931 Dec 6 22:14 nco-4.3.9.tar.gz -rw-r--r-- 1 Administrators None 4479960 Jan 30 00:07 nco-4.4.1.tar.gz I am using the same /etc/passwd and /etc/group and there is no /etc/nsswitch.conf file. Using a old version of SetACL by Helge Klein Homepage:http://setacl.sourceforge.net Version: 2.0.3.0 I catched the ACL for two of the files: "\\?\E:\cygwin\pub\devel\nco\nco-4.3.9.tar.gz",1,"O:S-1-5-21-531030479-1339336681-3415091201-1009G:S-1-5-21-1870173206-1308263284-2375963468-513D:P(A;;0x1f019f;;;S-1-5-21-531030479-1339336681-3415091201-1009)(A;;FR;;;S-1-5-21-1870173206-1308263284-2375963468-513)(A;;FR;;;WD)" SetACL finished successfully. "\\?\E:\cygwin\pub\devel\nco\nco-4.2.5.tar.gz",1,"O:S-1-5-21-531030479-1339336681-3415091201-1009G:BAD:P(A;;0x1f019f;;;S-1-5-21-531030479-1339336681-3415091201-1009)(A;;FR;;;BA)(A;;FR;;;WD)" and looking on new system /etc/group: None:S-1-5-21-531030479-1339336681-3415091201-513:513: old system /etc/group: None:S-1-5-21-1870173206-1308263284-2375963468-513:513: the "bad address" error is coming from the the file with the old ACL for "None" group. I suspect the Xwin crash was due to some files under /tmp or /var that had similar files, as making extensive use of chgrp.exe -R Administrators * I have not anymore the segfault. Regards 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: cannot open mintty as adminstrator
Well, that problem happened all day yesterday. Today there is no such problem. I have not done anything on the system since then, but that is the situation today. -- 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
Compiled executables requiring admin rights - different results between MinGW host type
Hi, I'm looking at a very simple 32-line c file, source is available here https://github.com/JuliaLang/julia/blob/master/contrib/stringpatch.c I'm seeing unpredictable results w.r.t. the compiled executable requiring admin rights to run, depending which host compiler is used. Under 32 bit Cygwin: gcc -o stringpatch-cyg stringpatch.c # requires admin rights i686-pc-mingw32-gcc -o stringpatch-pc-32 stringpatch.c # requires admin rights i686-w64-mingw32-gcc -o stringpatch-w64-32 stringpatch.c # requires admin rights x86_64-w64-mingw32-gcc -o stringpatch-w64-64 stringpatch.c # does not require admin rights Under 64 bit Cygwin: gcc -o stringpatch-cyg stringpatch.c # does not require admin rights i686-pc-mingw32-gcc -o stringpatch-pc-32 stringpatch.c # requires admin rights i686-w64-mingw32-gcc -o stringpatch-w64-32 stringpatch.c # requires admin rights x86_64-w64-mingw32-gcc -o stringpatch-w64-64 stringpatch.c # does not require admin rights What is the explanation for this discrepancy? Is this expected behavior? Is there an easy way to prevent any of the compiled executables from requiring admin rights? All the compilers are version 4.8.2, with the exception of i686-pc-mingw32-gcc which is version 4.7.3 in both 32 and 64 bit. Cygcheck contents for both installations are posted here https://gist.github.com/9492379. If providing any additional info would be useful, please let me know. Thanks, Tony -- 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: File permissions when using ACLs
Charles Plager writes: > * Anybody else experience files that lose all permissions? Any > suggestions on resetting the file (short of reformatting the drive)? Ahem. Yes, that has happened once to me. I don't know how the IT guys fixed it exactly, but they eventually deleted that file without formatting the disk or rebooting the server. The process starts with (recursively) taking ownership of said file or directory and then re-enabling the right to delete, IIRC. I've been using "noacl" mount option for that particular server ever since (also because it is slow enough as is and gets slower still when using ACL). > * Any other hints/insights that might be useful here? Not really, except that concurrent access to other files in the same directory seemed to be involved. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Testers needed: New passwd/group handling in Cygwin
Achim Gratz NexGo.DE> writes: > Exactly. But as revealed above, what was really missing is the > Administrators group. Somehow, when "files" is in effect, that mapping > doesn't seem to exist unless it is explicitly listed in the file. It does > get auto-created when I use _only_ the "db". I hope that somehow makes sense... I guess it does: the mapping that gets created from AD is sometimes 1049120 instead of 544. That depends on the settings in nsswitch.conf and whether an /etc/group file exists at all or contains an entry for Administrators. I guess that once this behaviour is stable (and maps to 544 in every case) the problem that Perl is having also goes away. Regards, Achim. -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > > With the original passwd and group file in place and nsswitch.conf set to > > either "files" or "files db" the test fails. With just "files" getfacl > > doesn't show the group ACL at all, > > How does it look with any non-AD integrated Cygwin? ... doesn't show the group ACL until I add them to the group file. That part is consistent with the AD enabled snapshot. Actually... if I create a group file with those two groups added, the access again doesn't get granted. Which finally reveals that I also need to have the administrators group present in that file (which mkpasswd had been doing) -- then it works. I can even leave out the two ACL groups again and it still works. > Hmm. So you're saying that the groups in question are not in > /etc/groups, but it works with the non-AD Cygwin but not with the > AD-Cygwin? Exactly. But as revealed above, what was really missing is the Administrators group. Somehow, when "files" is in effect, that mapping doesn't seem to exist unless it is explicitly listed in the file. It does get auto-created when I use _only_ the "db". I hope that somehow makes sense... > > So, Perl somehow uses the gid/uid mapping and relies on those to be working, No, it seems to balk on not being able to map the Administrator group (which is my egid). Regards, Achim. -- 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: Testers needed: New passwd/group handling in Cygwin
On Mar 11 15:07, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > You don't have to move them away. Just set nsswitch.conf. > > Did that and using the snapshot DLL from 2014-03-05 on top of a full > snapshot install from 2014-03-10. The ACL is this: > > # file: x86 > # owner: gratz > # group: Domain Users > user::--- > group::--- > group:admin-cygwinupload:rwx > group:user-cygwinupload:rwx > mask:rwx > other:--- > default:user::--- > default:group::--- > default:group:admin-cygwinupload:rwx > default:group:user-cygwinupload:rwx > default:mask:rwx > default:other:--- > > With the original passwd and group file in place and nsswitch.conf set to > either "files" or "files db" the test fails. With just "files" getfacl > doesn't show the group ACL at all, How does it look with any non-AD integrated Cygwin? > while with "files db" I see the ACL for > both the admin and the user group (both are not in the group file). Setting > to just "db" the ACL is shown as before and the test from Perl now succeeds! Ok. > In fact any combination that includes "files" fails. Hmm. So you're saying that the groups in question are not in /etc/groups, but it works with the non-AD Cygwin but not with the AD-Cygwin? A group which is not in /etc/groups is, in theory, just not in the ACL with the old Cygwin. What's not in Cygwin anymore is the mapping of a non-existing account to the uid/gid -1, what would have been printed as "" in ls output. This automatism would have collided with the DB stuff, but maybe I have to re-introduce it if only "files" is used. This could explain what happens in the "files"-only case... ...but that doesn't explain what happens with "files db". The uid/gid values may differ from the DB values, but only if the account actually exists in the file. And then the values in the files would have precedent over the db values. I'm really wondering what perl is checking there. > So, after some head > scratching I changed the uid and gid in the passwd and group files to match > the new mapping scheme and lo and behold the test is now working. The > getfacl command starts to show the group ACL when I add them to the group > file (with the correct gid mapping), but the test still fails with "files" > only. With the correct group entries and "files db", the test also works. Erm... > So, Perl somehow uses the gid/uid mapping and relies on those to be working, Whatever it's doing there. That doesn't make sense, unless it calls getgrent maybe?!? > while bash uses a code path that doesn't and probably just uses the uid/gid > directly. Much easier. bash just calls access(2). > I guess I could make the "files" only case work by adding some > more groups (no time for checking what that might be at the moment), again > changing the mapping (will mkpasswd do this at some point?). Do you still > need traces or does get you a test case that works in your environment? Yes, please. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPRjzbaDz2Z.pgp Description: PGP signature
Re: New snapshots are from the 1.7.29 branch. That means...
Christopher Faylor cygwin.com> writes: > You're responding to a heads up which was intended to *inform* you of > this fact. > > The snapshot does not have Corinna's new code. How is that unclear? The original message was posted when a 2014-03-10 snapshot (with AD integration) already existed and was replaced with one that doesn't. The website shows only that snapshot as being from the release branch. The 2013-03-09 snapshot was never explicitly mentioned in the original posting and is not shown on the webpage as being from the release branch (which it apparently is). More clear now? Regards, Achim. -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > You don't have to move them away. Just set nsswitch.conf. Did that and using the snapshot DLL from 2014-03-05 on top of a full snapshot install from 2014-03-10. The ACL is this: # file: x86 # owner: gratz # group: Domain Users user::--- group::--- group:admin-cygwinupload:rwx group:user-cygwinupload:rwx mask:rwx other:--- default:user::--- default:group::--- default:group:admin-cygwinupload:rwx default:group:user-cygwinupload:rwx default:mask:rwx default:other:--- With the original passwd and group file in place and nsswitch.conf set to either "files" or "files db" the test fails. With just "files" getfacl doesn't show the group ACL at all, while with "files db" I see the ACL for both the admin and the user group (both are not in the group file). Setting to just "db" the ACL is shown as before and the test from Perl now succeeds! In fact any combination that includes "files" fails. So, after some head scratching I changed the uid and gid in the passwd and group files to match the new mapping scheme and lo and behold the test is now working. The getfacl command starts to show the group ACL when I add them to the group file (with the correct gid mapping), but the test still fails with "files" only. With the correct group entries and "files db", the test also works. So, Perl somehow uses the gid/uid mapping and relies on those to be working, while bash uses a code path that doesn't and probably just uses the uid/gid directly. I guess I could make the "files" only case work by adding some more groups (no time for checking what that might be at the moment), again changing the mapping (will mkpasswd do this at some point?). Do you still need traces or does get you a test case that works in your environment? Regards, Achim. -- 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: ssh login reports "Could not chdir to home directory /home/root: Bad address"
If you could repeat the information below for a machine with the latest Cygwin and OpenSSH, along with your '/etc/passwd' and 'cygcheck -srv' output, that may be helpful. On 3/11/2014 9:36 AM, Ernesto Puig Rodriguez wrote: Hi Larry, After analyzing the debug information you recommended, I was still not able to find the reason of the error message during the ssh login. Below the output of the commands after the login. $ ssh root@winsrv2008 root@winsrv2008's password: ** Last login: Fri Mar 7 16:16:51 2014 from hostname dot com Could not chdir to home directory /home/root: Bad address entering /etc/profile root@winsrv2008 ~ $ pwd /home/root root@winsrv2008 ~ $ ls -l total 88 -rw-r--r-- 1 root Administrators 88080 Feb 27 18:00 cygcheck.out drwxr-xr-x+ 1 root Administrators 0 Jan 22 15:47 perl5 root@winsrv2008 ~ $ ls -dl .* drwxr-xr-x+ 1 root Administrators0 Feb 28 15:52 . drwxrwxrwt+ 1 root None 0 Feb 28 15:40 .. -rw--- 1 root Administrators 7953 Mar 7 16:26 .bash_history -rwxr-xr-x 1 root Administrators 1494 Feb 28 15:52 .bash_profile -rwxr-xr-x 1 root Administrators 6054 Jan 15 11:14 .bashrc -rw--- 1 root Administrators 87 Jan 21 09:32 .cvspass -rwxr-xr-x 1 root Administrators 1919 Jan 15 11:14 .inputrc -rw--- 1 root Administrators 49 Feb 18 09:54 .lesshst -rwxr-xr-x 1 root Administrators 1236 Jan 15 11:14 .profile drwx--+ 1 root Administrators0 Mar 3 08:56 .ssh root@winsrv2008 ~ $ id uid=500(root) gid=513(None) groups=513(None),544(Administrators),545(Users) root@winsrv2008 ~ $ getfacl -d /home/root # file: /home/root # owner: root # group: Administrators default:user::rwx default:group::r-x default:other:r-x root@winsrv2008 ~ $ cacls "c:\cygwin\home\root" c:\cygwin\home\root WINSRV2008\Administrator:F BUILTIN\Administrators:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R The output of ssh -v -v -v ... (See attached file: ssh-v-v-v.out) The debug info of sshd in /var/log/messages ... (See attached file: sshd_dbg) The only customized change in /etc/sshd_config is the debug flag one: LogLevel DEBUG3 Thanks, Ernesto. - On 2/27/2014 2:07 PM, Ernesto Puig Rodriguez wrote: When I log in into my Windows Server 2008 R2 using ssh, I get the following error: $ ssh root@winsrv2008 root@winsrv2008's password: Could not chdir to home directory /home/root: Bad address This is independent on whether I log in with the root user who is mapped to the Administrator in the /etc/passwd or not using another user of the group Administrators. The sshd daemon is able to log me in and everything seems fine, but this error is telling me something is wrong in my machine which I was not able to find till now. I have also re-installed cygwin and upgraded ssh with the level OpenSSH_6.5p1-1 without success. What does 'pwd' say after you login? Does '/home/root' exist? If so, what are the permissions it shows (for each of ls -l, getfacl, cacls)? Looking at the output of ssh -v -v -v may help. Setting up a sshd service to run debug and looking at that output will probably be more help. -- Larry -- 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 -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: About "defunct" processes
On Tue, Mar 11, 2014 at 12:26:45PM +, Kurt Franke wrote: >Angelo Graziosi alice.it> writes: > > >> $ ps >>PIDPPIDPGID WINPID TTY UIDSTIME COMMAND >> 2648 12648 2648 ? 1001 12:01:38 /usr/bin/mintty >> 372426483724 2012 pty01001 12:01:38 /usr/bin/bash >> 317637243176 3832 pty01001 12:02:14 /usr/bin/ps >> 190426482648 1760 ? 1001 12:01:41 >> /usr/bin/mintty >> >> Why that "defunct" process? I don't remember having seen that before on >> my old Cygwin32 installation. > >Hi, > >it looks like the cygwin process handling becomes more unix like :-) Right. It's a new feature that I implemented sometime around 1998 or so. cgf -- 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: New snapshots are from the 1.7.29 branch. That means...
On Tue, Mar 11, 2014 at 02:01:00PM +, Achim Gratz wrote: >Christopher Faylor cygwin.com> writes: >> The snapshots page is incorrectly listing every snapshot as coming from >> the branch. Sigh. I'll fix this. > >The 2013-03-09 snapshot also doesn't appear to have the AD integration code. You're responding to a heads up which was intended to *inform* you of this fact. The snapshot does not have Corinna's new code. How is that unclear? cgf -- 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: New snapshots are from the 1.7.29 branch. That means...
Christopher Faylor cygwin.com> writes: > The snapshots page is incorrectly listing every snapshot as coming from > the branch. Sigh. I'll fix this. The 2013-03-09 snapshot also doesn't appear to have the AD integration code. Regards, Achim. -- 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: Current mirror size
Jon TURNEY sent the following at Tuesday, March 11, 2014 9:18 AM
>On 10/03/2014 20:09, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> Jon TURNEY sent the following at Monday, March 10, 2014 12:17 PM
>>> On 10/03/2014 09:36, Alexander Kurilo wrote:
could anyone say how much space does Cygwin mirror currently take?
I'll be really grateful if someone can run du -hs * (or something similar)
in
the root of existing Cygwin mirror and post the output (or hint how can I
see
it myself given an existing mirror).
>>>
>>> $ du -hs * 4.0K md5.sum 48K unsupported 22G x86 15G x86_64
>>
>> curl -s ftp://mirror.cs.vt.edu/pub/cygwin/cygwin/x86/setup.ini | \
>> gawk '/^install: / || /^source: / { T = T + $3 ; N++ }; END { print N, T }'
>> 9601 54669681355
>>
>> 32 bit is 55G in 9.6k files.
>>
>> curl -s ftp://mirror.cs.vt.edu/pub/cygwin/cygwin/x86_64/setup.ini | \
>> gawk '/^install: / || /^source: / { T = T + $3 ; N++ }; END { print N, T }'
>> 7179 44743121652
>>
>> 64 bit is 45G in 7.2k files.
>
>Good idea! But these size numbers are not right, as this method counts
>the size of a source package for every binary package which is built
>from it.
curl -s ftp://mirror.cs.vt.edu/pub/cygwin/cygwin/x86/setup.ini | \
gawk '/^install: / { T = T + $3 ; N++ }; END { print N, T }'
4881 10124045929
32 bit: 10G in 4.9k files
curl -s ftp://mirror.cs.vt.edu/pub/cygwin/cygwin/x86_64/setup.ini | \
gawk '/^install: / { T = T + $3 ; N++ }; END { print N, T }'
3593 7238904766
64 bit: 7.2G in 3.6k files
I'd thought that a complete mirror includes source, but I agree that
one doesn't need that if the mirror is for private use.
Not being a developer and so not paying attention to source packages,
I hadn't realized that source was so much more bulky than binary.
- Barry
Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: ssh login reports "Could not chdir to home directory /home/root: Bad address"
Hi Larry, After analyzing the debug information you recommended, I was still not able to find the reason of the error message during the ssh login. Below the output of the commands after the login. $ ssh root@winsrv2008 root@winsrv2008's password: ** Last login: Fri Mar 7 16:16:51 2014 from hostname dot com Could not chdir to home directory /home/root: Bad address entering /etc/profile root@winsrv2008 ~ $ pwd /home/root root@winsrv2008 ~ $ ls -l total 88 -rw-r--r-- 1 root Administrators 88080 Feb 27 18:00 cygcheck.out drwxr-xr-x+ 1 root Administrators 0 Jan 22 15:47 perl5 root@winsrv2008 ~ $ ls -dl .* drwxr-xr-x+ 1 root Administrators0 Feb 28 15:52 . drwxrwxrwt+ 1 root None 0 Feb 28 15:40 .. -rw--- 1 root Administrators 7953 Mar 7 16:26 .bash_history -rwxr-xr-x 1 root Administrators 1494 Feb 28 15:52 .bash_profile -rwxr-xr-x 1 root Administrators 6054 Jan 15 11:14 .bashrc -rw--- 1 root Administrators 87 Jan 21 09:32 .cvspass -rwxr-xr-x 1 root Administrators 1919 Jan 15 11:14 .inputrc -rw--- 1 root Administrators 49 Feb 18 09:54 .lesshst -rwxr-xr-x 1 root Administrators 1236 Jan 15 11:14 .profile drwx--+ 1 root Administrators0 Mar 3 08:56 .ssh root@winsrv2008 ~ $ id uid=500(root) gid=513(None) groups=513(None),544(Administrators),545(Users) root@winsrv2008 ~ $ getfacl -d /home/root # file: /home/root # owner: root # group: Administrators default:user::rwx default:group::r-x default:other:r-x root@winsrv2008 ~ $ cacls "c:\cygwin\home\root" c:\cygwin\home\root WINSRV2008\Administrator:F BUILTIN\Administrators:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R The output of ssh -v -v -v ... (See attached file: ssh-v-v-v.out) The debug info of sshd in /var/log/messages ... (See attached file: sshd_dbg) The only customized change in /etc/sshd_config is the debug flag one: LogLevel DEBUG3 Thanks, Ernesto. - On 2/27/2014 2:07 PM, Ernesto Puig Rodriguez wrote: When I log in into my Windows Server 2008 R2 using ssh, I get the following error: $ ssh root@winsrv2008 root@winsrv2008's password: Could not chdir to home directory /home/root: Bad address This is independent on whether I log in with the root user who is mapped to the Administrator in the /etc/passwd or not using another user of the group Administrators. The sshd daemon is able to log me in and everything seems fine, but this error is telling me something is wrong in my machine which I was not able to find till now. I have also re-installed cygwin and upgraded ssh with the level OpenSSH_6.5p1-1 without success. What does 'pwd' say after you login? Does '/home/root' exist? If so, what are the permissions it shows (for each of ls -l, getfacl, cacls)? Looking at the output of ssh -v -v -v may help. Setting up a sshd service to run debug and looking at that output will probably be more help. -- Larry ssh-v-v-v.out Description: Binary data sshd_dbg 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: Current mirror size
On 10/03/2014 20:09, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Jon TURNEY sent the following at Monday, March 10, 2014 12:17 PM
>> On 10/03/2014 09:36, Alexander Kurilo wrote:
>>> could anyone say how much space does Cygwin mirror currently take?
>>> I'll be really grateful if someone can run du -hs * (or something similar)
>>> in
>>> the root of existing Cygwin mirror and post the output (or hint how can I
>>> see
>>> it myself given an existing mirror).
>>
>> $ du -hs * 4.0K md5.sum 48K unsupported 22G x86 15G x86_64
>
> curl -s ftp://mirror.cs.vt.edu/pub/cygwin/cygwin/x86/setup.ini | \
> gawk '/^install: / || /^source: / { T = T + $3 ; N++ }; END { print N, T }'
> 9601 54669681355
>
> 32 bit is 55G in 9.6k files.
>
> curl -s ftp://mirror.cs.vt.edu/pub/cygwin/cygwin/x86_64/setup.ini | \
> gawk '/^install: / || /^source: / { T = T + $3 ; N++ }; END { print N, T }'
> 7179 44743121652
>
> 64 bit is 45G in 7.2k files.
Good idea! But these size numbers are not right, as this method counts the
size of a source package for every binary package which is built from 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
Re: Testers needed: New passwd/group handling in Cygwin
On Mar 11 12:07, Achim Gratz wrote: > Corinna Vinschen cygwin.com> writes: > > > st_atim=531DE525.1B5BB150 (release) > > > st_atim=531DF887.5D9B9F8 (snapshot) > > > > Access time. On Windows it even changes when requesting certain > > kinds of metadata :-P > > It's been consistent over many days of testing and the only difference > between release and snapshot, so I thought I'd mention it. Can't explain that. There are no changes at all in this piece of code. > > But the question is, does perl actually use that list? The strace > > snippets don't show anything here. If it doesn't use the access(2) > > call, it would have to load the full ACL of the file and match that > > against your token group list. This requires calls to getgroups (which > > would create the litany of group SIDs from fetch_account_from_windows) > > and acl. It's pretty unlikely that perl would do this manually. > > Not that I can see, it simply seems to call stat64, which it did before. I > don't think it drops any groups, either. And again, just mounting cygdrive > with "noacl" gets rid of the problem entirely. There's a test in perl somewhere, which fails. "noacl" only fakes permissions anyway, so it doesn't matter. > > You're still using a group file? > > I think yes, I hadn't moved it away (but no passwd file). You don't have to move them away. Just set nsswitch.conf. > > Anyway, I need the full straces. It's pretty hard to say anything, let > > alone isolate at least the most probable cause without them. Can you > > please run the simple examples under the 2014-03-09 snapshot and send > > URLs to the snapshots? > > I've just updated to the latest snapshot w/o AD integration for testing, > will revert to the other one for more testing. Not sure if I can fit that > in today, will send the links via PM when I have the traces uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpc4jzLlq3Wk.pgp Description: PGP signature
Re: File permissions when using ACLs
On Mar 11 08:40, Charles Plager wrote: > Hi Andrey, > > I understand that Cygwin is emulating POSIX permissions (and, yes, we > already turn this off using the /etc/fstab). What I don't understand > is why it uses "special" permissions and not the standard "read/write" > options that are available. > > One possibility I just though of: Cygwin uses special permissions in > the case where the file is not executable (but readable or > readable/writable)? I guess I can see that. That, and the FILE_DELETE_CHILD flag. But you're just looking into the simplified output on the security tab. The "advanced" view is a bit more helpful, though not exactly. > I'd still love to hear from anybody who's experienced the vanishing > permissions... Never seen that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpI_1pUUYVyk.pgp Description: PGP signature
Re: File permissions when using ACLs
Hi Andrey, I understand that Cygwin is emulating POSIX permissions (and, yes, we already turn this off using the /etc/fstab). What I don't understand is why it uses "special" permissions and not the standard "read/write" options that are available. One possibility I just though of: Cygwin uses special permissions in the case where the file is not executable (but readable or readable/writable)? I guess I can see that. I'd still love to hear from anybody who's experienced the vanishing permissions... Thanks! Charles On Tue, Mar 11, 2014 at 8:30 AM, Andrey Repin wrote: > Greetings, Charles Plager! > >> Short version: When writing to network drives (and probably local >> ones) as Cygwin is setup by default, we see the permissions being set >> using the ACLs where "creator owner" is given "full control" and >> "creator" group are given "read/execute", but by setting "special >> permissions" instead of just having "full control" or "read/execute" >> set. > >> Why does it not just set "full control" or "read/execute"? > > Cygwin by default mimicking POSIX permission set. > If this behavior is undesirable, You can work around it by letting operating > system control the ACL. > Modify cygdrive entry in /etc/fstab to include noacl option. > Then any files accessed outside direct/implied mounts will have permissions > controlled by OS. > >> Long, slightly different version: When the above permissions get set, >> we sometimes see (sometimes = 1 file in a million or less) a file that >> ends up with no permissions. Owner loses permissions, admin loses >> permissions and so far, IT has only been able to make the file go away >> by reformatting the drive. > >> When we tell Cygwin not to use ACLs (adding the following in >> /etc/fstab), this does not seem to happen (in 100 million or so files >> created). > >> none /cygdrive/ cygdrive binary,posix=0,user,noacl 0 0 > > >> This only seems to happen for files created by Cygwin with the ACL >> permissions (although, to be fair, without Cygwin, I don't know that >> anybody is generating as many files). I'm assuming it isn't Cygwin, >> per say, but rather something that interacts with how Cygwin setup the >> permissions (and given the rarity of the problem it is difficult to >> diagnose more thoroughly. > >> So, to sum up: > >> * Why use special permissions and not default settings when using ACLs? > >> * Anybody else experience files that lose all permissions? Any >> suggestions on resetting the file (short of reformatting the drive)? > >> * Any other hints/insights that might be useful here? > >> Thanks, >> Charles > >> p.s. We see this behavior for Cygwin 1.7.9 and beyond. In 1.7.5, it >> doesn't appear as if the ACLs are used and it acts as if "noacl" is >> set. > > > -- > WBR, > Andrey Repin (anrdae...@yandex.ru) 11.03.2014, <16:08> > > 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: File permissions when using ACLs
Greetings, Charles Plager! > Short version: When writing to network drives (and probably local > ones) as Cygwin is setup by default, we see the permissions being set > using the ACLs where "creator owner" is given "full control" and > "creator" group are given "read/execute", but by setting "special > permissions" instead of just having "full control" or "read/execute" > set. > Why does it not just set "full control" or "read/execute"? Cygwin by default mimicking POSIX permission set. If this behavior is undesirable, You can work around it by letting operating system control the ACL. Modify cygdrive entry in /etc/fstab to include noacl option. Then any files accessed outside direct/implied mounts will have permissions controlled by OS. > Long, slightly different version: When the above permissions get set, > we sometimes see (sometimes = 1 file in a million or less) a file that > ends up with no permissions. Owner loses permissions, admin loses > permissions and so far, IT has only been able to make the file go away > by reformatting the drive. > When we tell Cygwin not to use ACLs (adding the following in > /etc/fstab), this does not seem to happen (in 100 million or so files > created). > none /cygdrive/ cygdrive binary,posix=0,user,noacl 0 0 > This only seems to happen for files created by Cygwin with the ACL > permissions (although, to be fair, without Cygwin, I don't know that > anybody is generating as many files). I'm assuming it isn't Cygwin, > per say, but rather something that interacts with how Cygwin setup the > permissions (and given the rarity of the problem it is difficult to > diagnose more thoroughly. > So, to sum up: > * Why use special permissions and not default settings when using ACLs? > * Anybody else experience files that lose all permissions? Any > suggestions on resetting the file (short of reformatting the drive)? > * Any other hints/insights that might be useful here? > Thanks, > Charles > p.s. We see this behavior for Cygwin 1.7.9 and beyond. In 1.7.5, it > doesn't appear as if the ACLs are used and it acts as if "noacl" is > set. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.03.2014, <16:08> 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: About "defunct" processes
Angelo Graziosi alice.it> writes: > $ ps >PIDPPIDPGID WINPID TTY UIDSTIME COMMAND > 2648 12648 2648 ? 1001 12:01:38 /usr/bin/mintty > 372426483724 2012 pty01001 12:01:38 /usr/bin/bash > 317637243176 3832 pty01001 12:02:14 /usr/bin/ps > 190426482648 1760 ? 1001 12:01:41 > /usr/bin/mintty > > Why that "defunct" process? I don't remember having seen that before on > my old Cygwin32 installation. Hi, it looks like the cygwin process handling becomes more unix like :-) in unix exach process has an entry in the process list unless its parent has do a wait call on it to get the information abouit process termination. if the parent process teminates the init process will become the new parent and will do this wait if not already done -- 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: Testers needed: New passwd/group handling in Cygwin
Corinna Vinschen cygwin.com> writes: > > st_atim=531DE525.1B5BB150 (release) > > st_atim=531DF887.5D9B9F8 (snapshot) > > Access time. On Windows it even changes when requesting certain > kinds of metadata :-P It's been consistent over many days of testing and the only difference between release and snapshot, so I thought I'd mention it. > But the question is, does perl actually use that list? The strace > snippets don't show anything here. If it doesn't use the access(2) > call, it would have to load the full ACL of the file and match that > against your token group list. This requires calls to getgroups (which > would create the litany of group SIDs from fetch_account_from_windows) > and acl. It's pretty unlikely that perl would do this manually. Not that I can see, it simply seems to call stat64, which it did before. I don't think it drops any groups, either. And again, just mounting cygdrive with "noacl" gets rid of the problem entirely. > You're still using a group file? I think yes, I hadn't moved it away (but no passwd file). > Anyway, I need the full straces. It's pretty hard to say anything, let > alone isolate at least the most probable cause without them. Can you > please run the simple examples under the 2014-03-09 snapshot and send > URLs to the snapshots? I've just updated to the latest snapshot w/o AD integration for testing, will revert to the other one for more testing. Not sure if I can fit that in today, will send the links via PM when I have the traces uploaded. Regards, Achim. -- 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
File permissions when using ACLs
Hi, Short version: When writing to network drives (and probably local ones) as Cygwin is setup by default, we see the permissions being set using the ACLs where "creator owner" is given "full control" and "creator" group are given "read/execute", but by setting "special permissions" instead of just having "full control" or "read/execute" set. Why does it not just set "full control" or "read/execute"? Long, slightly different version: When the above permissions get set, we sometimes see (sometimes = 1 file in a million or less) a file that ends up with no permissions. Owner loses permissions, admin loses permissions and so far, IT has only been able to make the file go away by reformatting the drive. When we tell Cygwin not to use ACLs (adding the following in /etc/fstab), this does not seem to happen (in 100 million or so files created). none /cygdrive/ cygdrive binary,posix=0,user,noacl 0 0 This only seems to happen for files created by Cygwin with the ACL permissions (although, to be fair, without Cygwin, I don't know that anybody is generating as many files). I'm assuming it isn't Cygwin, per say, but rather something that interacts with how Cygwin setup the permissions (and given the rarity of the problem it is difficult to diagnose more thoroughly. So, to sum up: * Why use special permissions and not default settings when using ACLs? * Anybody else experience files that lose all permissions? Any suggestions on resetting the file (short of reformatting the drive)? * Any other hints/insights that might be useful here? Thanks, Charles p.s. We see this behavior for Cygwin 1.7.9 and beyond. In 1.7.5, it doesn't appear as if the ACLs are used and it acts as if "noacl" is set. -- 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: 1.7.25, Windows 7: dumper doesn't generate core file
Hi Sam, On Mar 11 10:35, Sam lia...@constrainttec.com wrote: > As a disclaimer I'm new to Cygwin and memory mapping that's alluded > to in this post. > > My brief was to investigate and resolve an issue with dumper not > producing a core. > > With that I'll proceed with outlining the journey including my > findings so far. > > I'll begin with the error message given by dumper when run in verbose mode: > (Note: I modified debug output to provide base address of excluded memory) > [,..] > Code analysis reveals a few shortcomings leading up to this failure. > Firstly the process of > identifying sections to exclude, includes sorting and checking that > regions do not overlap. > Upon closer inspection the function in question at > ...winsup/utils/parse_pe.cc appears to > have a couple of problems. > > a) "if (q == p + 1)" at line 60 always resolves true bypassing > subsequent loop code. > > b) The 'size' parameter at line 63 is a global instead of > p->size. The test expression > should be if (p->base + p->size > q->base) in order to test > for overlapping regions. This looks very wrong indeed. > [...] > Even if sort_and_check () worked correctly it wouldn't prevent > dumper failure it just raises an alert. > > Secondly when dumper builds a list of memory regions to dump into a > core file it has no logic to cater > for overlapping sections to exclude. Here in lies my first question > regarding this issue: > > > Question 1: SHOULD MEMORY REGIONS IDENTIFIED FOR EXCLUSION EVER OVERLAP? I can't really answer this question safely, but AFAIK, the answer is no. The sections and memory layout in a pe/coff file are so that the sections have unique VMAs, including debug sections. An overlap of sections should never occur, otherwise the Windows loader would have refused to load the executable into memory anyway. Unless I'm missing something... > Question 2: IS THE CODE MODIFICATION AN ACCEPTABLE SOLUTION TO THE PROBLEM? Maybe, but first it would be helpful if somebody could explain why sections should be able to overlap at all. That's puzzeling me. As for patches, did you see http://cygwin.com/contrib.html For small, obvious patches, we don't need the copyright assignment. Rule of thumb is < 10 lines. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpL5XR27F2eu.pgp Description: PGP signature
Re: Testers needed: New passwd/group handling in Cygwin
On Mar 11 07:44, Achim Gratz wrote: > Achim Gratz nexgo.de> writes: > > IIRC, the next call is the write that prints "no" or "yes"... there may > > have been something like "stat_helper" inbetween only on Cygwin64, but > > I'll have to check again tomorrow. > > It's a call to stat_worker with the UNC file path and the stat_worker > handle, both times returning zero. zero == success > There is only one interesting difference > between the release and the snapshot DLL, they are reporting the atime to be > different: > > st_atim=531DE525.1B5BB150 (release) > st_atim=531DF887.5D9B9F8 (snapshot) Access time. On Windows it even changes when requesting certain kinds of metadata :-P > Whatever differences there are probably inside stat_worker, but I don't > really know. stat_worker is just a wrapper. Nothing happens in there which could explain any differences. > I've just found out that cygcheck cuts off the group listing after exactly > 16kiB. That's because cygcheck uses a fixed buffer of 16K to collect the output of the `id' call. > Maybe there are some other places where it's now possible to overrun > some buffer (pwdgrp::fetch_account_from_windows has got all of them > according top the trace) or maybe some other limit for the number of groups? Not in Cygwin. The limit is set by the application in the call to getgroups: http://linux.die.net/man/2/getgroups What we have is a NGROUPS_MAX define in limits.h and the equivalent NGROUPS in sys/param.h. It's defined as 1024, but it's not used or enforced anywhere in Cygwin. > The group that grants access is number 293 in the list as returned by id... But the question is, does perl actually use that list? The strace snippets don't show anything here. If it doesn't use the access(2) call, it would have to load the full ACL of the file and match that against your token group list. This requires calls to getgroups (which would create the litany of group SIDs from fetch_account_from_windows) and acl. It's pretty unlikely that perl would do this manually. > I've also found that two trusted domains aren't returning an entry for > cyg_ldap::fetch_posix_offset_for_domain from the DC I'm assigned to, so that > probably explains the long startup times I've been seeing with earlier > snapshots. Maybe of interest: > > 987 1803457 [main] perl 6856 alloc_sd: uid 1124017, gid 10513, attribute > 0x2190 You're still using a group file? Anyway, I need the full straces. It's pretty hard to say anything, let alone isolate at least the most probable cause without them. Can you please run the simple examples under the 2014-03-09 snapshot and send URLs to the snapshots? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnDE2C2aKvK.pgp Description: PGP signature
Re: Testers needed: New passwd/group handling in Cygwin
Achim Gratz nexgo.de> writes: > IIRC, the next call is the write that prints "no" or "yes"... there may > have been something like "stat_helper" inbetween only on Cygwin64, but > I'll have to check again tomorrow. It's a call to stat_worker with the UNC file path and the stat_worker handle, both times returning zero. There is only one interesting difference between the release and the snapshot DLL, they are reporting the atime to be different: st_atim=531DE525.1B5BB150 (release) st_atim=531DF887.5D9B9F8 (snapshot) Whatever differences there are probably inside stat_worker, but I don't really know. I've just found out that cygcheck cuts off the group listing after exactly 16kiB. Maybe there are some other places where it's now possible to overrun some buffer (pwdgrp::fetch_account_from_windows has got all of them according top the trace) or maybe some other limit for the number of groups? The group that grants access is number 293 in the list as returned by id... I've also found that two trusted domains aren't returning an entry for cyg_ldap::fetch_posix_offset_for_domain from the DC I'm assigned to, so that probably explains the long startup times I've been seeing with earlier snapshots. Maybe of interest: 987 1803457 [main] perl 6856 alloc_sd: uid 1124017, gid 10513, attribute 0x2190 860 1804317 [main] perl 6856 cygsid::debug_print: alloc_sd: owner SID = S-1-5-21-2052111302-842925246-682003330-75441 (+) 877 1805194 [main] perl 6856 cygsid::debug_print: alloc_sd: group SID = S-1-5-21-2052111302-842925246-682003330-513 (+) 827 1806021 [main] perl 6856 alloc_sd: ACL-Size: 124 934 1806955 [main] perl 6856 alloc_sd: Created SD-Size: 200 Regards, Achim. -- 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
