Re: Basic question about cygport
On Mon, 4 Aug 2014, Steven Penny wrote: ...snip... This is highly presumptuous. I have asked 10 questions and given 68 answers on ... This list has had a long history of having a somewhat different attitude - culture, if you will - than you might find elsewhere on the net; some might call it ascerbic. However, the deeper point is that if you want help here, fitting in with the culture you find here is the way to go. The REAL issue isn't how good or bad whatever else is, it's that people are busy and have the view, "help me help you", and "I only help people who have shown they are trying", however that's expressed, and that's reasonable enough. In this case, a reasonable translation of the comment you elicited would be: "I'm too busy to go click somewhere else; you want to solicit my help for free, make it easy for me." The insult of others was unfortunate. I for one wish people would lighten up; if you don't want to help, don't, but telling other people off about it is not useful; you could have helped the person by doing those other things (like looking at stackoverflow) using less energy than you spent being abrasive. Thankfully, the "rough attitude" is not held by everyone, though it sometimes has been seen in people who carry platinum watches - and that might encourage its continuation... BTW, if I knew how to contribute more than just explaining the culture, I would... Good luck to everyone, Richard -- 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: Why /usr/bin/*.dll must be executable?
On Mon, 23 Apr 2012, Larry Hall (Cygwin) wrote: > > On 4/23/2012 3:01 PM, Warren Young wrote: > > Options 2-5 in the list at the page linked above don't really apply here. > > Cygwin purposely keeps itself nice and segregated from the rest of the > > system, so installing DLLs under c:\Windows isn't an option, and CWD is > > simply useless for our purpose here. > > While the windows and system directories aren't a great place to be putting > DLLs that don't belong to the O/S in some way (and indeed Windows tries to > discourage it actively in recent versions by keeping it off limits to > users without sufficient privileges), why do you think Cygwin apps > wouldn't see a DLL it needed if it were in one of these locations? > > I'm in full agreement that the 16-bit system directory and "current" > directory aren't useful or appropriate options in the context of > locations for Cygwin DLLs. > > Hmmm... I was following this thread hoping to learn something about a problem I was trying to solve wherein I launch a Cygwin-GNU-compiled program and it failed with "error while loading shared libraries: ?: cannot open shared object file: No such file or directory". (I think the question mark stands where there would ordinarily be the name of some DLL, but I only received the question mark.) ...It seemed reasonable to think the problem may be related to where the .dll files go, PATH, or some other clue given on the web page cited earlier in this thread regarding the search order for shared libraries, (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx#search_order_for_desktop_applications) but I eventually traced it to something that seems bizarre to me: the use of --login on a call to bash. Pre-Windows 7, this code was known to work fine without the login switch and it drove me banannas until tried --login. I'm wondering; what on earth would --login have to do with where the dlls are found? Thanks, Richard -- 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
Installation / download issues
...During an exchange on a completely unrelated topic: On Sat, 14 Apr 2012, Christopher Faylor wrote: > >> > >> On 4/10/2012 6:15 PM, Richard Troy wrote: > >> > >> > >> > >Did that, though once again I ran into the ole cygwin update / > >installation disaster that is based on the fact that something > >somewhere doesn't download and the installation doesn't complete properly > >and you have to manually figure out what didn't download, explicitly > >download that, and then, several tries later, you get a working > >installation. Why the cygwin population puts up with this and doesn't fix > >the installation script is beyond my pay grade... Heck, just giving us a > >single zip to get "everything" would be _so_ less problematic! -shrug- > > > > If something doesn't download properly the setup.exe is not supposed to > continue. And, the next time you rerun setup.exe the file should be > downloaded correctly. Setup.exe uses md5sums to try to ensure that what > it downloads is correct. I have observed on not less than three completely separate occasions, separated by several years each, that what you write above is incorrect; that is, it has continued on in spite of some unknown error, with some fundamental library or component not present which prevented a properly complete installation as per what was desired. Sometimes the problem pertains to the whole installation and you notice it right away, during the ending phase of the installation process and on other occasions you only notice when some package isn't working correctly. > > Maybe you found a bug in setup.exe but there is no way to know that > since you felt compelled to waste bandwidth venting rather than calmly > describing your problem. If you'd care to file a proper bug report > then it's possible that someone will look into it. BOTH of the last times I reported this all I got were blank stares, so please reserve your own indignation; I don't deserve it. One person had the kindness to point out what sub-component the missing item came from. I then tried to download the package that contained it a few times further and got no joy, so I moved on to a different repository (mirror), it installed OK, and I moved on. (...How am I supposed to do better when the folks that are supposed to care just shine on the problem completely - more than once?) On subsequent occasions I have merely known that when an installation hoses up (which appears to be every single time I try and download - which was why I was seven releases behind and only upgrade when there's a damned good reason to) I should try a different repository and usually I've had success on the next try, or just keep going repeatedly until it actually works. Never has there been a competent error message that points to the real cause, only that some script(s) couldn't do something-or-other. Sometimes these involve a single script - like the host setup for sshd, and sometimes it involves all scripts, like what happened to me Tuesday night when some ncurses library was missing. My guess is that it has nothing to do with MD5 checksums but rather that a whole package didn't download somehow and the installation process misses it completely. Heck, it even thought it had installed the package in question. I want to point out that I've seen other people - non-regulars on this list - with echos of the problem(s) I'm telling you about now. I recall about a month ago some fellow being told something like (paraphraised), "oh, your system is missing xyz, go install that" and the person responding, "ok, sure, but I thought I'd installed everything..." I deleted that dialogue out of my inbox but recall it specifically because of my own experience. As you want a bug report, I think I saved the logs, so maybe that's still possible, though I was under the impression that they got overwritten on subsequent tries; I _think_ I may have saved the logs from the first attempt on this latest cycle last Tuesday night. I'll try and dig into it tomorrow AM over coffee and if it's still available, I'll log a bug. As I'm not a Cygwin committer, is submitting here, on-list, sufficient, or where do you want me to enter it officially? "Problem reports" url cited below? > Remeber: > > Indignation != clue Not Always, smart guy. ... I'm very grateful for all that the community does, but sometimes there is some valid criticism. You might temper YOUR indignation at me; I'm a supporter and ally - as best I can be anyway. And I've read a lot of your posts from the archives or live on the list and I know you're earnest and mean well - please know that I am, too. Tell me how to help and I will if I possibly can. Regards, Rich
Re: Some context is being stripped and I don't know how to create it to avoid "error while loading shared libraries: ?: cannot open shared object file: No such file or directory" problem
On Tue, 10 Apr 2012, Larry Hall (Cygwin) wrote: > > On 4/10/2012 6:15 PM, Richard Troy wrote: > > > > The orphaned installations represent places where cygwin1.dlls are or were. > You want to make sure you clean them up. No reason to leave around orphans > to trip and fall on. Done. > Also, since you're running 7 versions behind, updating > is recommended but, as you say, not obviously your problem. Did that, though once again I ran into the ole cygwin update / installation disaster that is based on the fact that something somewhere doesn't download and the installation doesn't complete properly and you have to manually figure out what didn't download, explicitly download that, and then, several tries later, you get a working installation. Why the cygwin population puts up with this and doesn't fix the installation script is beyond my pay grade... Heck, just giving us a single zip to get "everything" would be _so_ less problematic! -shrug- > Still, no > reason not to be thorough in your testing. I would say, though, that it > makes sense to test that the environment you expect to see is what you're > getting when you invoke bash. How about if you invoke "env" from "cmd /c" > instead of your program and send the output to a file you can inspect? > Done that and more. New post on this this AM. > If any or all of the above doesn't enlighten, I'd recommend cygcheck output > accompany any follow-up here. OK. I posted more information a little while ago, but somewhow I overlooked sending cygcheck output again. -frown- Regards - and thanks for your reply, Richard -- 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
Some context is being stripped and I don't know how to create it to avoid "error while loading shared libraries: ?: cannot open shared object file: No such file or directory" problem
Hello All, some oh, ten years ago or so I ran into this problem and thought I had it licked wherein I'm launching Cygwin's bash utility (and from it another program compiled under Cygwin) from Java. However, while the same code works on every other version of Windows I can remember trying, it seems to have returned for Windows 7. Either that, or I've forgotten some small configuration fix! I've searched the archives and found nothing pertinent so I entered a question about this on Stackoverflow - could save some writing here to just reference that: http://stackoverflow.com/questions/10092730/launching-cygwin-built-executable-from-java-on-windows-7-fails-with-error-while In short, a Gnu C program compiled under Cygwin wakes up, checks security and configuration information, then calls Java. Later, under certain conditions, the Java program wants to instantiate a program similar to itself, so it calls the OS-level tools to launch the same C program from Java, and the new instance of the C program then calls the same or modestly different Java program. The error occurs when the first (oldest) Java program attempts to launch the (second) C program. The call is something like this: cmd.exe /C C:/cygwin/bin/bash -c '/cygdrive/c/opt/ST/v3.3/bin/ST.exe' The reason for calling cmd.exe (on some versions 'command.exe') is due to inconsistencies in behavior if one just calls bash or other executable programs as this is a general purpose interface. (This was developed more than a decade ago and needs to run everywhere - if there's a better way, I'm open to it, but this has worked well for a long time.) It's worth mentioning that there is a test program that confirms the Java call to the OS is working correctly by launching some basic level Cygwin program. It reports success at calling programs to be run under bash. (It could be the test is insufficient / flawed!) Both the Windows PATH and every place I can find to set the "linux" PATH have C:\cygwin\bin or equivalent. I recall that a LONG time ago, I'd copy the cygwin1.dll to various places to cure this type of problem, but I don't think I've done that in a long time (or don't recall doing it!) - doing so now (making a copy in C:/Windows/system32/ for example) didn't help. I'm sure it is no surprise to anyone that everything works fine when it's NOT being launched from Java... But it seems odd to me that I have an old version of XP running with this same setup and the calls from Java work fine! I doubt very much this has anything to do with the Cygwin version, but I'll provide whatever data anyone asks for. However, some things cygcheck reports that caught my eye are to be found below. One notable thing is apparent "orphaned Cygwin installations" - but I don't recall ever making true installations in the locations claimed! (Maybe cygwin1.dll makes these from wherever it's used?) Thank you for any and all help. Regards, Richard __ Excerpts from cygcheck: Windows 7 Professional N Ver 6.1 Build 7600 Running under WOW64 on AMD64 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin System: Key: 715c149bf086df04 Path: C:\opt\ScienceTools\v3.3 (ORPHANED) System: Key: a8fb4064ab2b92ac Path: C:\windows (ORPHANED) Cygwin DLL version info: DLL version: 1.7.6 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 230 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 Warning: There are multiple cygwin1.dlls on your path (YES, I did that trying to cure this problem!) -- Richard -- 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: GNU Guile 1.8.7 - readline is not provided
On Thu, 29 Dec 2011, [UTF-8] Róbert Kohányi wrote: > Subject: GNU Guile 1.8.7 - readline is not provided > > Using a fresh installation of Cygwin with GNU Guile (during the > install process I've only selected this latter package explicitly) > I've tried to use Guile's readline support[1] unsuccessfully. > > As the documentation told me to, I've created a configuration file > (.guile) in my home directory and started Guile, but it raised an > error (guile.out) and I don't understand why. > > I've searched the mailing lists and found a previous release > announcement[2] where the package maintainer said that the readline > support is "OK" (although it was a previous release of Guile -- 1.5.x) > and listed the required libraries for it to work. During the install > all of these libraries were installed by setup.exe transitively > (cygcheck.out). > > Is this a bug in the release or readline support is omitted from > Guile's Cygwin version on purpose? > > If the latter holds it would be nice to know: "why?". Can't Guile be > build with this feature enabled? > > Regards, > Robert Hi Robert, I had a similar problem recently. I don't know if what you are experiencing is the same or not, but it probably is: Incomplete download and a (to my mind) broken dependency engine. Readline is fundamental, but when it was missing from my download - how, I have NO idea - none of the concluding scripts that are supposed to run after an installation completes actually ran. The solution was easy enough; Do the download part again, and explicitly include readline. Note that this mechanism of reloading also easily verified that that was in fact the problem because it didn't show up in the list of packages to possibly upgrade, delete, or whathaveyou. Merely pointing to a different repository solved the problem. I don't understand how the dependency engine lets this happen, but it does. Good luck, Richard -- Richard Troy, Chief Scientist Science Tools Corporation rt...@sciencetools.com, http://ScienceTools.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
Broken dependencies? Bad Mirrors causing hidden problems? Was Re: New Installation fails: cygreadline7.dll not found.
On Wed, 14 Dec 2011, Larry Hall (Cygwin) wrote: > > On 12/14/2011 10:51 PM, Richard Troy wrote: > > > > Hi Folks, > > > > I'm a long-time Cygwin user and recently got a new Windows 7 box that > > needed to be taught bash and other neat tricks, so naturally I downloaded > > the latest version - 1.7.9-1, I believe - and then did the installation > > from the local repository. I told it to install "absolutely everything". > > > > When it got to the end, the post installation activities failed in > > spectacular fashion. My guess is none of the Cygwin post-installation > > functions were actually performed. The first one to fail was > > /etc/postinstall/000-cygwin-post-install.sh, which complained that > > cygreadline7.dll was missing. This was followed by a large number of > > errors substantially identical to that (differing only in what program was > > complaining), and then there were 202 errors where various packages > > complained about some package component returning "exit code -1073741515". > > > > Sure enough, there is no cygreadline7.dll on the box. Hmmm... > > > > ...I figured this must be a common problem, but didn't find it in the FAQ, > > and when I did a search of the e-list, it returned zero matches for > > "cygreadline7.dll" and "missing". A web search yielded no results, either. > > > > I have cygreadline7.dll available on other boxes, in /bin, but the new > > system doesn't have it, and the only file starting with "cygr" in /bin is > > cygrunsrv, yet there are other .dll files in the /bin directory. > > > > Can I / should I merely copy over the cygreadline7.dll from an older > > installation of cygwin? Other comments / ideas? ...I apologize in advance > > if I missed something obvious. > > I recommend running 'setup.exe' again and selecting 'libreadline7' from the > list of packages. That should help. Hmmm... I tried that and setup didn't show such a package! So, I tried a different mirror and found it elsewhere. It's downloading now. However, this brings up a VERY key point, I think: How was it possible for me to do an installation like this and NOT get readline? And not know about it at the time? I mean, shouldn't the dependencies mechanisms caught this? If I download an incomplete set of materials from some mirror somewhere, how do I catch this other than just trying to fix whatever problems crop up? This has me thinking that over the years I may have had this happen before to me and my coleagues as, for example, quite notably sshd wouldn't work and I never had the time to troubleshoot it... For that matter, can I download an ISO image from somewhere and thus guarantee I get the whole thing? Buy a DVD? Thanks, Richard -- Richard Troy, Chief Scientist Science Tools Corporation rt...@sciencetools.com, http://ScienceTools.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
New Installation fails: cygreadline7.dll not found.
Hi Folks, I'm a long-time Cygwin user and recently got a new Windows 7 box that needed to be taught bash and other neat tricks, so naturally I downloaded the latest version - 1.7.9-1, I believe - and then did the installation from the local repository. I told it to install "absolutely everything". When it got to the end, the post installation activities failed in spectacular fashion. My guess is none of the Cygwin post-installation functions were actually performed. The first one to fail was /etc/postinstall/000-cygwin-post-install.sh, which complained that cygreadline7.dll was missing. This was followed by a large number of errors substantially identical to that (differing only in what program was complaining), and then there were 202 errors where various packages complained about some package component returning "exit code -1073741515". Sure enough, there is no cygreadline7.dll on the box. Hmmm... ...I figured this must be a common problem, but didn't find it in the FAQ, and when I did a search of the e-list, it returned zero matches for "cygreadline7.dll" and "missing". A web search yielded no results, either. I have cygreadline7.dll available on other boxes, in /bin, but the new system doesn't have it, and the only file starting with "cygr" in /bin is cygrunsrv, yet there are other .dll files in the /bin directory. Can I / should I merely copy over the cygreadline7.dll from an older installation of cygwin? Other comments / ideas? ...I apologize in advance if I missed something obvious. Thanks, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-717-6942 rt...@sciencetools.com, http://ScienceTools.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
Re: Cygwin & openssh(d) & login without password
(I don't know _why_ I'm sitting at the keys on this glorious Saturday morning, nor do I know why I'm replying to such a thread... Oh wait, "I was a newbie once, too, and I remember what that was like." Yeah, that's it! True, that was "back in the day," but I still remember...) On Fri, 8 Oct 2004, lex ein wrote: > > On Tue, 5 Oct 2004 10:47:57 +0200, Corinna Vinschen > <[EMAIL PROTECTED]> wrote: > > On Oct 5 16:00, David Campbell wrote: > >> I've read lots of web pages about how to set it up, and I believe I've > >> followed them, eg http://bumblebee.lcs.mit.edu/ssh2/ (for openssh to > >> openssh): > > > > WHY DON'T YOU READ THE OFFICIAL DOCUMENTATION INSTEAD? [caps mine] > > OpenSSH comes with a lot of man pages. Then there's > > /usr/share/doc/Cygwin/openssh.README. > > Then you could have used ssh-host-config and ssh-user-config for the > > basic configuration. > > BECAUSE in the case of openssh(and others), the "official documentation" > is of little use to a new user: information is not gathered, stored, or > presented in a orderly, logical, or sensible hierarchical manner, is not > meaningfully cross-referenced, and is not reasonably searchable. There's > just no usable thread to pull to unravel the mystery, either. Well Lex, you are ABSOLUTELY RIGHT. First of all, though, you need to realize that WJM. Yes, and not just the Cygwinners - and Cygwhiners - but the whole Unix/Linux community! As I see it, the single biggest problem for Unix/Linux acceptance by a wider community is lack of an intuitive help strategy. The obvious reason _why_ is because it's an evolution of _student_labor_ - students who, by the way, may have been (were!) outstandingly bright but who had not yet been out in the "real world." There _were_ great solutions to emulate, such as Digital Equipment Corporation's VMS with it's stupendous 'help' utility, but _students_ had nevery been out in the real world to encounter such gems and therefore didn't have the experience of a competent system to emulate for their Unix development work. ...Don't know what to do, nor even where to start? Type help and the system presents you with a summary list of all the possible commands or groups of commands (so the list isn't forever and a day long). Want more help? Type help , and this format can continue an arbitrary number of levels and you can... Bt! Oh! That's the alarm clock going off telling me it's time to wake up to where we are now - it's not 1986 any more. Ssh configuration problems? RIGHT. It's VERY poorly described. VERY few times have I found a good write up on it, though the cygwin setup package for it is _superb._ I tend to only have to deal with it once in a very long while - like years sometimes - and so a refresher is needed now and then, especially when trying to get any of the varriants of SSH to talk to one another. ... Did you know, for example, that there are THREE major varriants of SSH? They're called OpenSSH, Commercial SSH and non-Commercial SSH - but these are _just_ names as there are commercial and non-commercial versions of ALL THREE! The two non-OpenSSH versions talk well together but OpenSSH is the odd-man-out. Oh, and responses on this list like this one: > > Huh? I have read /usr/share/doc/Cygwin/openssh.README, then I ran > > sshd-config and ssh-config and it works for me. I edited manually > > the /etc/sshd_config file to disable password login and to enable > > X forwarding. are just downright rude and unhelpful. However, see note above wherein I pointed out that WJM. ...Anyway, yes, the terminology used in describing ssh is _very_ challenging for the newbie, and can even be annoyingly obfuscated for the experienced user! Unless you're willing to take this on yourself, however, you've _got_ to deal with it because nobody's paying anybody to do a better job and, speaking for myself only, I'm overworked and can't volunteer to fix this for the community. All that said, you've made your point. ...Here's a write up I did find helpful out there: http://www.netsys.com/cgi-bin/display_article.cgi?1254 And, in case it helps, below are some notes on setting up SSH in mixed Open/non-Open ssh environments, and, in particular, including Cygwin. Finally, I direct your attention to the bottom of the section below regarding file transferr... HTH, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ __ The following is excerpted from notes between our engineers and our documentation writers. Enjoy, RT -snip- These notes are intended to help shorten the process of learning how to set up ssh in a mixed (Ope
Re: Spurious "You have multiple copies of cygwin1.dll on your system."
On Thu, 7 Oct 2004, Igor Pechtchanski wrote: -snip- > Basically, it's not enough to share the network directory -- you also have > to have the "/", "/usr/bin", and "/usr/lib" mounts pointing to it for the > network copy of Cygwin to work properly. So, your mount changing idea may > not be so off the mark after all, but in the other direction (i.e., switch > "/" back to the network drive)... Unfortunately, anything written to > those directories will then also go back to the network drive, which isn't > what you want. Sort of a Catch-22 here... -snip- ...Without speaking to any of the other issues of this thread, I can provide commentary about the above comments; In short, it's not very difficult to configure a shared installation with as much local deviation as you wish. We do it here with a great many software packages that were "never intended" to be managed this way. Here's the go: Start with an intact, proven working installation directory tree that's on a served network drive (by whatever means). Then, on each "installation client" provide a complete directory tree that matches the structure of the networked tree in every particular, at least in so far as local modifications are desired. Then, each directory on the client nodes are populated with links back to the network counterpart. When particular sections of the tree don't need any local variant, a link can be provided at the directory level to present entire branches of the directory tree from the networked installation. Of course, this has nothing to do with Cygwin, and, now that I think of it, I'm not sure I've ever done this with a Cygwin-served (Windows-served) directory tree, but I can't think of any reason why this wouldn't work just fine in an all-Windows environment. Hope this helps, Richard P.S. Igor, regarding execv(), I had indeed 'malloc'ed just enough memory for nargv and the extra null was in fact in non-malloced memory! Arg! What surprised me was that the write to that memory space was permitted and it failed sometime later when that memory location was needed/used for something else! (wtf? -frown- ) Tnx, RT P.P.S. My Windows XP Pro _doesn't_ have ping or dig/nslookup?! -frown- Tnx again, RT -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: seg-vios from gcc program at execv() on Windows XP
On Thu, 30 Sep 2004, Igor Pechtchanski wrote: > > > Note that the code is _rock_solid_ on Linux/Unix/Mac OSX, and on all > > earlier versions of Windows we've ever tried it on. We've _never_ seen it > > seg-vio before. > > Please provide a complete (hopefully simple) testcase, along with the > compilation flags, etc. In particular, it'd be interesting to see how > nargv is allocated, etc. I suspect you're not placing a NULL at the end > of the argument list, and Cygwin and Linux allocate nargv differently (so > that on Linux, nargv just happens to have zeroed memory after it). Almost; right issue, wrong problem. It turned out not that there wasn't a terminating NULL but that there was an extra one, one past where it should have been! This kind of problem is, apparently, _very_ easy to overlook and I guess we just got away with it in the past. -shrug- I want to thank you for taking the time to reply, Igor. I was awfully stressed out about it. Even though it wasn't really a Cygwin problem, you were supportive and I appreciagte it. > > (BTW ping and dig utilities would be nice!) > > FWIW, XP (and 2k) come with "`cygpath -S`/ping.exe" and > "`cygpath -S`/nslookup.exe". ?? ...Doesn't do _anything_ on my computer! -smile- (Maybe I'd better to a hunt for them as they aren't in my path today.) Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
seg-vios from gcc program at execv() on Windows XP
Hello Cygwiners, I'm a long-time user of Cygwin - love it, depend on it... and rarely have a problem, but I really need some help with this one particular problem. I've already tapped into my other technical resources on this and haven't gotten anywhere at all. It isn't clear this is a Cygwin problem, but then, it isn't clear that it isn't, either. ...I really need some insight here... A couple of weeks ago some skum-bag stole my laptop and my new one came with Windows XP Professional. ...I now understand what XP stands for: XP means eXtremely Painful. Anyway, I use the laptop for sales calls (I'm the technical person) and it just _has_ to work. I've been having trouble getting my company's software working on the system and my boss said, "well, this is a good chance for you to make sure our stuff works on XP, so, have fun!" - or words to that effect... But I am _not_ having fun. -frown- The problem is that we've got a GCC based program that ends up calling Java via execv(). It _always_ seg-vios when the GCC program itself is called from another program (non-interactive) and it sometimes seg-vios when run from an interactive Cygwin Bash prompt. Significant testing has shown that the interactive failure seems to be associated with environment variables. For example, the code uses an environment variable to determine if it should output "verbose" statements to std-out (via printf), and if this is set, the execv() always fails. However, it also fails sometimes depending on other variables that should have _nothing_ to do with the program. Here's an excerpt of the code in the vicinity of the exec: strcpy(program,JavaHomeenv); strcat(program,"/bin/java"); // make sure that argv0 is fully qualified so that java doesn't // default to a local binary nargv[0]=program; //nargv[0]= "java"; nargv[1]= "-classpath"; nargv[2]= classpathenv; nargv[3]= std; nargv[4]= ck; nargv[5]= rus; nargv[6]= host; nargv[7]= stc; nargv[8]= stt; nargv[9]= dk; nargv[10]= cl; i = execv(program, nargv); Note that the code is _rock_solid_ on Linux/Unix/Mac OSX, and on all earlier versions of Windows we've ever tried it on. We've _never_ seen it seg-vio before. Also note that I recompiled the executable on the target system. I'm wondering if there's something about the new installation of Cygwin on XP that's changed something about how the binary runs... In case it helps: cygcheck -s says we're running 1.5.10, and gcc is 3.3.1-3. It was a fresh, absolutely complete installation - even the stuff I never need. (BTW ping and dig utilities would be nice!) Help! Thanks everyone, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Implementing a workaround for the suid bit
This one is for the archives... On Unix/Linux, there's a feature that provides security for applications which require access to privileged data by unprivileged users called the suid bit. This bit is set on a per-executable basis and is stored in the file system. It directs the "exec" system call to run the executable as the owner of the file, not as the user who called the program. (Note that this is distinctly different than programs that call the setuid system call, though surely any given executable could do either or both.) When porting such applications to Windows, there's a problem because Windows has a considerably different mechanism. Cygwin honors the suid bit in the file system but the feature that implements 'exec' does not. Until that is resolved, ported programs that need to provide reasonable security from Windows users who are not fully privileged have to use another mechanism. The following describes one such method using "SSH." If sshd is installed, the application can be called using the ssh client. To set it up, create a new user account for this application that will be "disabled" but will be used exclusively for the purpose of this workaround. Importantly, this account must have a directory that's protected somewhere and is not shared by another account since ssh configuration files should be kept separate. Grant it whatever group privileges make sense for your security strategy. Be sure this account is created either before Cygwin is installed, or be sure to run mkpasswd/mkgroup, as directed elsewhere in Cygwin literature. This ensures the account is known to Cygwin. Install the Cygwin sshd, too, which you can do at the same time you install Cygwin if you wish. Create null pass-phraise keys for the application account that let any user with the right key login without a password. Distribute this key to all authorized users of the program and set it up in their environs according to ssh's directions. Create a helper program that will launch your application. The helper program is pointed to in Cygwin's /etc/passwd for the application account instead of the shell (usually /user/bin/bash). When called from ssh, it will receive two arguments, one is just '-c' and the other is the complete command line. Your helper program will have to reformat the arguments as required by your application and then do an exec call to execute the desired, unmodified application. You are now ready to setup lanuching the application. There are many ways, such as creating an alias something like this: $ alias ='ssh @localhost -c ' Whatever is typed after the alias will be appended to the line and become arguments to your application. There remains an important issue: Unlike a genuine suid-bit launched program, in this scenario the environment is lacking in information about the genuine authenticity of the launching user - what system are they on and what is their username are important among these. Providing a scheme for resolution of this problem is a bit beyond the scope of this whitepaper, but the interested reader can probably invent something clever, perhaps with the use of more sophisticated helper programs on both ends. Here are a few additional thoughts regarding the missing information. One idea is to use "identd". Unfortunately, identd is not currently an available package for Cygwin. You could just pass information along from the original user as a flag ( -U @ for example) but knowing that it's genuine is a bit of a trick. In such cases, I recommend encrypting the username and hostname and then have the helper explicitly check that the connection is in fact local and set the username in the environment before calling the application. Also, if the application account has SYSTEM privilege, it may then change users, and this may be a desireable trait to consider in your helpers. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation rtroy at ScienceTools dot com, 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sshd as a substitute for the suid bit on executables...
On Tue, 23 Mar 2004, Corinna Vinschen wrote: > On Mar 23 08:22, Richard Troy wrote: > > One additional challenge that has just occurred to me in my particular > > scenario is that in ordinary useage on Unix, my program that runs under > > the suid bit eventually launches a Java program that creates display > > windows and attaches to the keyboard/mouse in the usual way and the user > > never knows it's running as the file owner and not them. Before I go > > Google is your friend. Search for "Allow service to interact with desktop". Corinna, your solution looks to be the only thing that can be done today without writing code - or, at least, nothing significant: I've tested the solution and it works fine, though you do have to tollerate this stupid, empty sshd popup window. If you close the window, sshd exits, though you can reset the window properties to make it tiny and it will remember them if you ask it to - on W2kPro, at least. You have to create a spare "dummy account" you won't ever log into and have a "transferr" program available (or modify your target) in order to catch the command line sent to it by sshd/bash (it'll get -c ) For those that may search the archives behind me and want a full articulation, in a few minutes I'll make a post that outlines the whole thing, top to bottom. Thanks Corinna! (And Igor!) Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: suid bit on executables?
Hi Igor, Interesting dialogue, but you seem to be mising one CRITICAL point, which I apparently didn't make clear: It is absolutely unacceptible to have the user of the software in question know any password other than the one for their own account or otherwise have access to privileges they're not supposed to have (through ssh keys, for example). The objective of the exercise is to find a way to enforce "proper" security. Therefore, installing as a service with a password is entirely acceptible because it's done by a system administrator type person who _has_ the appropriate privilege... That said, the _LAST_ thing I'd want is to have a privileged console program come up and provide _any_ access whatsoever! ... Anyway, your suggestion about /dev/conin and /dev/conout may well be on the right track. Here might be a reasonable solution: $ cygrunsrv --install --path --args " /dev/conout 2>/dev/conout" --env --username --password [other cygrunsrv args] ...While typing all these emails, I've been trying to do just this! However, I've had to reboot a couple of times, and am otherwise slowed down a little. -frown- The key here is, from the command line, how does a user fire off a connection/dialogue with the installed program/service? My bet is, though, that this isn't possible, since you go on to state: > conin/conout will let the process access the console that cygrunsrv pops > up, rather than the stdout/stderr file descriptors, which are redirected > to files in /var/log... ...and I very surely don't want any popup console! > Technically, you should have been able to look at > <http://cygwin.com/cygwin-ug-net/using-specialnames.html> instead... Thanks for the pointer... > The > Cygwin User's Guide makes for wonderful and exciting bed-time reading. ;-) (At one point, about 3 years ago, I actually read all available Cygwin documentation "cover to cover. -Yawn!- ) > However, the above document is strangely silent on the topic of > conin/conout... As things stand now, looking at the Cygwin source is > probably your best bet. ...Hopefully that won't be necessary! I take it that conin and conout are "console in" and "console out", respectively, though I don't yet see how a user at a bash prompt, for example, hooks up with the installed program. If that can be done, I'd MUCH rather this solution than to use ssh... > Yes, except you'd probably need to redirect the stdout to /dev/conout as > well. As above, maybe? > Yes, cygrunsrv allows services running explicitly as some user, with two > caveats: they can't be interactive, and you'd need to enter a password for > that user. The above method will let you switch the context with no > password, thus emulating the "suid" functionality. I got errors when I tried to use the --interactive flag as found in your example, and -h didn't show it, either! -smile- Oh well... > All the password checking, etc, is superficial. The point is that there > exists functionality that lets any user, no matter how unprivileged, to > switch the context to that of any other user, as long as the appropriate > permissions are verified (e.g., the user knows the root password). Well, I don't think the password checking is superficial at all! I'm just trying to let the "unprivileged user" have access to functionality (provided by a special program) without having access to the actual raw data (as used by that special program). ...The system administrator sets up that special data and special program... The "unprivileged user" must remain that way! > I didn't say that having this functionality is a security hole, I just > said that in Windows, a user context switch is not possible from all user > accounts unless special privileges are assigned to all user accounts, > which *would* open a security hole. I sure hope you're wrong as that's what this whole exercise is all about! We want a user context switch to a new user without having to give extra privileges to anybody! I suspect that we're in violent agreement, it's just that you've perhaps misunderstood what I was after. -shrug- And again, thanks for the dialogue... Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: suid bit on executables?
Igor, one of us is confused! ...NOT referring to Cygwin, but Unix in general: 'su' requires the caller to either already be root, or have the password of the account they want to "become". In contrast, there's no checking of passwords at all when a program is launched that has the suid bit set: It simply starts in the context of the files owner. The user may well be unaware, even, that a different user id is involved - not at all the case with su, where it's explicit. BTW, tnx for the pointer to ntsec, but that's old hat for me: I have for many years been aware of this issue, though I'm far from a guru. As for those "security holes" - that's what we're trying to work through in this dialogue: I have a legitimate need, we can see the "right" answer is to have cygwin1.dll perform execs that honor suid - perhaps with the aid of cygserver, and that at the moment we are discussing a workaround for the interrim! -smile- ...And _THANK_YOU_VERY_MUCH_ for your participation in this dialogue! Anyway, back to my question you neatly avoided! -smile- If the program were installed with cygrunsrv and the user flag specified the right user, can conin and conout be used to get the "command line" access to the running program? I gathered that's what your example using conin and conout were really all about, not su.exe - we _know_ that's "broken!" Maybe take a second look at my post on my interpretation of your suggestion and see if I've gotten it right? Regards, and thanks again, Richard > > No, what I need is _very_ different. The requirement is for a program that > > runs as a different user without that user having any special privileges > > themselves and without the ability to log in, or run other programs as > > that other user. On Unix (and Unix clones), there's a concept of the "suid > > bit" which is set in the file system and associated with executable > > programs (and on many implementations, executable shell scripts too). When > > any user, including root, executes a program with the suid bit set, the > > program runs just like any other program except that it runs in the user > > context of the file's owner, NOT as the user who called the program. In > > contrast, su requires that the caller have the password of the account in > > question... > > > > That said, a "working su" program _should_ be able to be used as the > > foundation of an implementation of an exec call where the suid bit is set. > > Corinna hinted that W2003 makes things harder and I haven't any idea why, > > but it figures that Windows would try very hard to ensure that nothing > > else is compatible with Windows. -frown- > > > > Regards, > > Richard > > Richard, > > The functionality of "su" and the "suid bit" is the same. Aside from > privilege checking, both require the ability to have any user set its > effective user id to that of another user. This is currently not possible > in Windows without opening a whole set of security holes. By default, the > only account able to switch user contexts is SYSTEM. Reading > <http://cygwin.com/cygwin-ug-net/ntsec.html> should provide some insights. > Win2003 makes it harder because the appropriate privileges aren't assigned > to SYSTEM by default, as they were in the previous versions of Windows. > HTH, > Igor > -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: suid bit on executables?
> Richard, > > FYI, Cygwin implements /dev/conin and /dev/conout, so, perhaps, the > approach suggested in <http://cygwin.com/ml/cygwin/2004-03/msg00259.html> > would be helpful (or something along those lines). Hi Igor, I tried man and apropos, and found nothing for conin or conout, but if I understand what you're suggesting, you're saying I should try something like the following: The original command to use as a template (I take it this worked?): cygrunsrv --install fetchmail --path /usr/bin/su.exe --args "-p -c '/usr/bin/fetchmail --daemon 300 --nodetach /dev/conout' domain\\user" --env HOME=/home/user --termsig TERM --shutdown --type manual --interactive My interpretation of the above: cygrunsrv --install --path /usr/bin/su.exe --args "-p -c ' /dev/conout' \\" --env --termsig TERM --shutdown --type manual --interactive Hmmm... Yes, this _seems_to_me_ to be exactly what I was hinting at when Corinna suggested ssh instead. ... The above would be both better and easier because there's no need for keys and no encryption overhead. Do I understand that conin and conout redirect std-in and std-out to/from the installed service to the caller of the service? Also, you said: > OTOH, once cygserver is in place, we'll have a working "su" (which is > exactly what you want, right?). But in the above cygrunsrv you call su! Yes, I know the executable is there - in at least this example, does it work? Also, since there's an ability to specify the user, maybe use the user flag, specify it explicitly and ignore the su.exe? Thanks for all your keystrokes! Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: suid bit on executables?
On Tue, 23 Mar 2004, Igor Pechtchanski wrote: > FYI, Cygwin implements /dev/conin and /dev/conout, so, perhaps, the > approach suggested in <http://cygwin.com/ml/cygwin/2004-03/msg00259.html> > would be helpful (or something along those lines). Thanks, Igor, I'll look into that in a minute... > OTOH, once cygserver is in place, we'll have a working "su" (which is > exactly what you want, right?). > Igor No, what I need is _very_ different. The requirement is for a program that runs as a different user without that user having any special privileges themselves and without the ability to log in, or run other programs as that other user. On Unix (and Unix clones), there's a concept of the "suid bit" which is set in the file system and associated with executable programs (and on many implementations, executable shell scripts too). When any user, including root, executes a program with the suid bit set, the program runs just like any other program except that it runs in the user context of the file's owner, NOT as the user who called the program. In contrast, su requires that the caller have the password of the account in question... That said, a "working su" program _should_ be able to be used as the foundation of an implementation of an exec call where the suid bit is set. Corinna hinted that W2003 makes things harder and I haven't any idea why, but it figures that Windows would try very hard to ensure that nothing else is compatible with Windows. -frown- Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
sshd as a substitute for the suid bit on executables...
> From: Corinna Vinschen <[EMAIL PROTECTED]> > Subject: Re: suid bit on executables? > > > On Mar 23 07:04, Richard Troy wrote: > > I know > > there's the SSHD code that could serve as an example, but it seems to > > me that it's overkill for what I want [...] > > Nope. There's nothing simpler than utilizing an existing and working > piece of code instead of creating another application with it's entirely > new, own set of bugs. IMO, using sshd is the way to go. > > Corinna So, Corinna, you see it as simple... Before I start punching a tar-baby and get all stuck in things, few more keystrokes might be helpful... One additional challenge that has just occurred to me in my particular scenario is that in ordinary useage on Unix, my program that runs under the suid bit eventually launches a Java program that creates display windows and attaches to the keyboard/mouse in the usual way and the user never knows it's running as the file owner and not them. Before I go create a great solution that doesn't solve my real problem, I realize that I am unfamilliar with the security demands, if any, Windows imposes in such circumstances; please advise with your thoughts on this subject in the scenario under discussion here if you can. Next, I can see how an account that has a particular privilege that provides all of the necessary access can have its shell re-directed to be a particular program other than a usual shell (just update /etc/passwd, right?) and can have a null passphraise providing a key-access (passwordless access) to the desired account by other users, captured so that they can't run anything else in the account. This is then followed up with an alias that looks like the usual command but that instead performs something like: alias foo="ssh @ " # cmd line args trail and get passed along in the usual way Such a solution would require _no_ additional coding, but a bit of configuration instead - a perfectly workable solution if, in fact, the resulting executing program can indeed open windows in the normal way on the console display. (Non-Cygwin Q: Can, in fact, the shell be replaced with an ordinary program and have the args passed like this? Or is there another blessed method for "capturing" an account so it only runs one program?) Corinna, is this what you had in mind? (Anyone else with a good idea?) As always, thank you very, very much - this is a big deal to me. Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Forwarded message -- Date: Tue, 23 Mar 2004 16:04:08 +0100 From: Corinna Vinschen <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: suid bit on executables? On Mar 23 07:04, Richard Troy wrote: > I know > there's the SSHD code that could serve as an example, but it seems to me > that it's overkill for what I want [...] Nope. There's nothing simpler than utilizing an existing and working piece of code instead of creating another application with it's entirely new, own set of bugs. IMO, using sshd is the way to go. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: suid bit on executables?
On Tue, 23 Mar 2004, Corinna Vinschen wrote: > On Mar 22 19:49, Richard Troy wrote: > > A little over a year ago, I poked my nose under the tent to inquire about > > this once more and in the interrim there had been a new cygserver and a > > new ssh daemon, and I was very happy with the advance, but still things > > were short of the SUID bit being honored... > > > > Now, I read in the archives about something, apparently upcoming, called > > cygdaemon... I read hints that cygdaemon helps address this problem. > > There's no such thing as a cygdaemon, only cygserver. If the SUID stuff > gets implemented, it will be based on cygserver. But there's no code > for doing this so far. Security changes in 2K3 are making an implementation > even more complex. > > Corinna Thank you, Corinna. ...might you please propose a work-around for the following scenario? If I wanted just one particular program to run as this other user, there's that nifty tool in Cygwin that lets you define a service that _can_ run as another user. This would work for me if I had a way for a Cygwin program, launched from a command-line interface, from Bash, say, to attach to it and let it do the dirty work. It would need a way to pass command-line arguments, and redirect or share std-in, std-out, and std-error. ...I know there's the SSHD code that could serve as an example, but it seems to me that it's overkill for what I want since there's no need for it to credential itself as anyone. ...The simpler, the better, so long as it's sufficient! Thank you for your suggestions/ideas, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
suid bit on executables?
Hello All, I'm looking for an update on this problem, please... As background: Nearly three years ago now I got involved with Cygwin for a time and was quite keen on security issues related to Cygwin's launching of programs which should run as someone other than the user who requested the program be run. On Unix systems (including Linux), there's a nifty feature called the suid bit which one can set in the file system on executable programs (always binaries and often scripts) in which the program in question will run as the file owner, not the user - Cygwin supports the setting of this bit but does not (did not?) honor it. This is distinctly different than a program explicitly calling 'setuid' as using this feature lets _any_ program run as the file owner, not just special ones that were coded to change user contexts. At the time, this was a real work-in-progress and there was a new thing called the cygserver which was just at the bleeding edge. I really wanted to get involved and solve this but my management said no - and there's no free-time in my life anymore so that was that. A little over a year ago, I poked my nose under the tent to inquire about this once more and in the interrim there had been a new cygserver and a new ssh daemon, and I was very happy with the advance, but still things were short of the SUID bit being honored... Now, I read in the archives about something, apparently upcoming, called cygdaemon... I read hints that cygdaemon helps address this problem. Without digging into source code or anything, my guess would be that it's a bit like cygserver but it's specifically intended for this on-the-fly capability yet overcome Window's demand that there be a process with SYSTEM privileges to do this. I would love an update... Is this what cygdaemon is all about? Any chance there's some beta code? (I note with little surprise that there's still nothing in the documentaiton about cygserver, so of course I don't expect anything on cygdaemon, either!) If anyone can please comment, I'm all ears. I was just painfully reminded today how really deeply needed this functionality is! Thanks, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin GDB crashes on single step
On Mon, 14 Jul 2003, Christopher Faylor wrote: > From: Christopher Faylor <[EMAIL PROTECTED]> ...snip... > Just type "insight" to get insight. > > cgf Ah, what that it were all so easy in life. -shrug- Thanks for the perspective. RT -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
More Re: flaky disk share access
...Hmmm... I was intrigued by the other person's report a few minutes ago that they'd had problems with net.exe output but that according to them it was working. So, I did a little testing... On my W2000 system, the Cygwin Bash shell started from the default icon can run net.exe and gets output that the ssh session doesn't get, but it does NOT work properly. ONLY from the 'dos command prompt' window does net.exe work correctly. So, there appear to be THREE different levels of behavior: Dos prompt - everything works, Cygwin Bash - gets help output and current state output but commands to change things don't work, and an ssh session - is like Cygwin Bash but can't get help output. Harumph. Comments still welcome. Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ On Fri, 11 Jul 2003, Richard Troy wrote: > Date: Fri, 11 Jul 2003 09:06:26 -0700 (PDT) > From: Richard Troy <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: flaky disk share access > > > Hi Igor, All, > > thanks for the prompt reply. Unfortunately, 'net use' does _not_ work. > -frown- > > ...I brought up three windows on the box, a Cygwin Bash session, an SSH > session (F-Secure client), and a "dos command prompt". The Bash session > and the dos prompt window work identically, but the ssh session doesn't > work at all. Since this is the first I've used the 'net' command, I'm not > entirely sure what to expect from it, but it was frustrating that I > couldn't even get it to spit out help on the ssh session, though help > worked fine on the Bash and dos prompt windows. > > >From the ssh session, 'net use' returns: > > $ net use > New connections will be remembered. > > > Status Local RemoteNetwork > > --- > Unavailable K:\\fs1\Commons Microsoft Windows Network > Unavailable S:\\fs1\softwareMicrosoft Windows Network > Unavailable U:\\fs1\users Microsoft Windows Network > The command completed successfully. > > ...Whereas in both of the other sessions, the Status is listed as "OK". > > When I try other commands, there seems to be some kind of terminal > interaction problem. For example, in the following example, I only entered > the command at the system prompt, and it returned me to the system prompt > without pausing for my interaction: > > $ net use k: rtroy > k: has a remembered connection to \\fs1\Commons. Do you > want to overwrite the remembered connection? (Y/N) [Y]: > No valid response was provided. > > $ > In other cases, it just runs silently, but has no apparent effect, for > example, the following just return to the system prompt: > > $ net use /user:rtroy > > $ net use * /user:rtroy > > ...Since I've never successfully used 'net use', I'm still struggling a > little with the syntax, but that asside, 'net' isn't having a normal user > interation dialogue with me, I don't think. > > Any further comments greatly appreciated. > > Richard > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Issue with net.exe and no output when ssh'ing into NT system
HEY, _THAT_ sure sounds like the problem I just described! ...I seem to have come into the middle of this conversation... Can someone please bring me up to speed: Todd, are you saying that you understand where this problem originates and think a fix might be coming soon? In 1.5? -smile- Thanks again, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ On Fri, 11 Jul 2003, Todd Bowden wrote: > Date: Fri, 11 Jul 2003 10:45:53 -0500 > From: Todd Bowden <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: RE: Issue with net.exe and no output when ssh'ing into NT system > > Larry, > > Thanks for the reply. It seems that this is a defect in the current > release and will hopefully be fixed in the near future. > > Todd C. Bowden > HP Certified > AtosOrigin > 5000 S. Bowen > Arlington, TX 76017 > Office: 817-264-8211 > E-mail: [EMAIL PROTECTED] > > > -Original Message- > From: Larry Hall [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 10, 2003 4:10 PM > To: Todd Bowden > Cc: [EMAIL PROTECTED] > Subject: Re: Issue with net.exe and no output when ssh'ing into NT > system > > > Todd Bowden wrote: > > > To all below you will find my cygcheck.out file. > > > > Im running cygwin 1.3.22. > > > > The issue Im having is after ssh'ing into a Win 2000 system and try to > > > execute net.exe I get no output. If Im logged on locally and bring up > > > a bash shell I get the output that I expect. > > > > I have tested a few scenerios: > > > > 1. Logged on locally using the bash shell, net.exe runs and produces > > output as expected. 2. SSH into same system net.exe returns no > > output, however the command does execute correctly. No other commands > > > have the same behavior. 3. Using an older version of the cygwin1.dll > > fixed the output problem of net.exe, but produced other problems. > > > > Does anyone else have this problem? > > Do you google? > > <http://www.google.com/search?as_q=&num=10&hl=en&ie=UTF-8&oe=UTF-8&btnG= > Google+Search&as_epq=net.exe&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_q > dr=all&as_occt=any&as_dt=i&as_sitesearch=cygwin.com&safe=images> > > This is one discussion on this subject. > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: flaky disk share access
Hi Igor, All, thanks for the prompt reply. Unfortunately, 'net use' does _not_ work. -frown- ...I brought up three windows on the box, a Cygwin Bash session, an SSH session (F-Secure client), and a "dos command prompt". The Bash session and the dos prompt window work identically, but the ssh session doesn't work at all. Since this is the first I've used the 'net' command, I'm not entirely sure what to expect from it, but it was frustrating that I couldn't even get it to spit out help on the ssh session, though help worked fine on the Bash and dos prompt windows. >From the ssh session, 'net use' returns: $ net use New connections will be remembered. Status Local RemoteNetwork --- Unavailable K:\\fs1\Commons Microsoft Windows Network Unavailable S:\\fs1\softwareMicrosoft Windows Network Unavailable U:\\fs1\users Microsoft Windows Network The command completed successfully. ...Whereas in both of the other sessions, the Status is listed as "OK". When I try other commands, there seems to be some kind of terminal interaction problem. For example, in the following example, I only entered the command at the system prompt, and it returned me to the system prompt without pausing for my interaction: $ net use k: rtroy k: has a remembered connection to \\fs1\Commons. Do you want to overwrite the remembered connection? (Y/N) [Y]: No valid response was provided. $ In other cases, it just runs silently, but has no apparent effect, for example, the following just return to the system prompt: $ net use /user:rtroy $ net use * /user:rtroy ...Since I've never successfully used 'net use', I'm still struggling a little with the syntax, but that asside, 'net' isn't having a normal user interation dialogue with me, I don't think. Any further comments greatly appreciated. Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ On Thu, 10 Jul 2003, Igor Pechtchanski wrote: > Date: Thu, 10 Jul 2003 14:02:47 -0400 (EDT) > From: Igor Pechtchanski <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: Richard Troy <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: flaky disk share access > > On Thu, 10 Jul 2003, Richard Troy wrote: > > > Hi All, > > > > When I ssh in to my cygwin/W2000 system, I don't reliably have access to > > the disk shares, even if I log in as the same user who's "logged in on the > > console." The shares in question are served by Samba and are reconnected > > at "console" login every time with password authentication. They are also > > system mounted within cygwin and always are available from the default > > cygwin bash shell. This works as solid as a rock on my Windows NT systems > > but on Windows 2000 it sometimes it works, and most of the time not. It > > seems as though it's related to how long it takes me to log in after the > > system has rebooted, but that could be a red-herring. I can't get it to > > work often enough to really figure out why/how it sometimes works and > > sometimes doesn't. Anybody got any ideas? > > > > In a related question, is it possible to have an SSH user authenticate > > themselves for their own private shares? If so, please point me in the > > right direction! ...This would be damned handy, privilege wise, for > > example, what about logging into a box that hasn't got anybody logged in > > at the console? > > > > Thanks much, > > Richard > > > > P.S. "cygcheck version 1.32", "Compiled on Mar 18, 2003" ... RT > > Richard, > > The "net use" command should work. You might need to give it the > "/user:" switch, and provide a password as well. > Igor > P.S. That was the output of "cygcheck -svr" as an attachment, not > "cygcheck --version". ;-) > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
flaky disk share access
Hi All, When I ssh in to my cygwin/W2000 system, I don't reliably have access to the disk shares, even if I log in as the same user who's "logged in on the console." The shares in question are served by Samba and are reconnected at "console" login every time with password authentication. They are also system mounted within cygwin and always are available from the default cygwin bash shell. This works as solid as a rock on my Windows NT systems but on Windows 2000 it sometimes it works, and most of the time not. It seems as though it's related to how long it takes me to log in after the system has rebooted, but that could be a red-herring. I can't get it to work often enough to really figure out why/how it sometimes works and sometimes doesn't. Anybody got any ideas? In a related question, is it possible to have an SSH user authenticate themselves for their own private shares? If so, please point me in the right direction! ...This would be damned handy, privilege wise, for example, what about logging into a box that hasn't got anybody logged in at the console? Thanks much, Richard P.S. "cygcheck version 1.32", "Compiled on Mar 18, 2003" ... RT -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC bug with strftime
Thanks, Corinna, ...Good thing I've already written a work-around! -smile- Gee, you never know what you might learn by posting on the wrong list! -wink- RT -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ On Tue, 14 Jan 2003, Corinna Vinschen wrote: > Date: Tue, 14 Jan 2003 10:05:46 +0100 > From: Corinna Vinschen <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: Cygwin <[EMAIL PROTECTED]> > Subject: Re: GCC bug with strftime > > On Mon, Jan 13, 2003 at 07:00:07PM -0800, Richard Troy wrote: > > > > The problem is that this call fails to return an hour: > > > > > > > > strftime(IT,key,"%m/%d/%y %l:%M %p", brokentime); > > I'm sorry to say that but... > > > The answer is yes, I have checked. The code works in my various RedHat > > environments and has been for a long time. Also capital I is not what I > > ...just because it works under RH Linux it doesn't mean it's correct code. > The %l specifier character is not covered by SUSv3: > > http://www.opengroup.org/onlinepubs/007904975/functions/strftime.html > > which means, your usage of %l is non-portable. > > Corinna > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bugs in Rsync?
Michael, I honestly have no idea about your particular problems but I can tell you that rsync has some limitations on what you can expect from it on all platforms on which I've tried it so far. It's worth mentioning that I _always_ use the restart option... In short, if the total space you wish to point it at exceeds some 'n'G, then you can expect it to get into a cycle of restarting with only modest progress on each pass, effectively stalling forever. Oh sure, days later it may eventually finish, but I've found that it's best to not give it such large workloads. I think it has to do with the size of the difference between the source and destination trees and doesn't pertain to the memory on the box, but that's a guess. The best strategy (for me) has been to manually move (scp or whatever) if there are many gigabytes of difference between the two trees, and only scp when there's 2GB or less (as a guesstimate) of difference between the trees. And... I effect this with a short script, which is what I recommend you do. I have a short shell script that walks the top level trees in particular file systems. I log the sessions and when the script isn't done in the morning or when the log shows more hours than usual, I look at where in the tree the problem is and I add a hook to walk into that level of the file system and do each item within separately. ...It's really easy to code and it works great - AND it could help you explicitly walk over problems like the one you report. Hope this helps, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ On Mon, 13 Jan 2003, Michael Hipp wrote: > Date: Mon, 13 Jan 2003 23:15:10 -0600 > From: Michael Hipp <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Bugs in Rsync? > > I'm trying to use Rsync to back up this system to a remote across the > network. I'm butting my head against 2 probs: > > - When rsync is given a source of /, it absolutely refuses to descend into > /cygdrive. It's as if the -x (one fs only) is set. > > - When rsync is given a source of /cygdrive/c/ it will attempt to read > pagefile.sys (the NT swap file) and always reports an IO error and this > causes it to change its behavior (doesn't quite die). It does this > regardless of all-powerful exclusions that would cause it to skip over > pagefile.sys. Even touching that file enough to realize to exclude it > evidently causes it problems. > > Are these really problems or am I just missing something? Thanks. > > Michael > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC bug with strftime
> > of cygwin and tried again, but it's still there. So, I'd like to report > > it. I sent mail to the gcc-bugs list but nobody there seems to care, so I > > thought I'd mention it here. > > > > The problem is that this call fails to return an hour: > > > > strftime(IT,key,"%m/%d/%y %l:%M %p", brokentime); > > hmmm... > > Are you sure that you are not passing a 'el' instead of a capital 'eye' > > it is real hard to differentiate in some typefaces > > note: python just calls the underlying 'C' strftime() implementation > > HTH > > Norman Thanks for the thought, Norman. The answer is yes, I have checked. The code works in my various RedHat environments and has been for a long time. Also capital I is not what I need; As your example illustrated, it returns a zero padded two digit hour, but what I want/need is a non-padded hour, two or one digit, depending. The reason I really care is because there are two programs that have to talk to one another, one written in C and the other in Java. It nearly doesn't matter which is which is which, they just have to agree on the format. All was fine until I compiled the code on my cygwin installation. -shrug- Richard -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC bug with strftime
> >I recently discovered a bug in strftime(). I downloaded a very recent copy > >of cygwin and tried again, but it's still there. So, I'd like to report > >it. I sent mail to the gcc-bugs list but nobody there seems to care, > > Why *would* anyone in gcc care about a library problem? I believe that > they actually mentioned that the below was a GNU extension. But, > regardless, the problem has nothing to do with gcc. Doah! Yeah, glibc - what _was_ I thinking?! -smile- > >The problem is that this call fails to return an hour: > > > > strftime(IT,key,"%m/%d/%y %l:%M %p", brokentime); > > > >The l% is supposed to represent a _space_ padded hour, as documented here: > >http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_17.html#SEC302 > > cygwin != glibc. However, since cygwin uses newlib, and the people in > the newlib project are a cooperative bunch, maybe if you submitted a > patch, they'd consider adding it. The mailing list is newlib at sources > dot redhat dot com. Thanks Christopher... Richard > > cgf > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
current state of credential hopping?
Hi All, One of the long-time known problems (limitations) with cygwin has been the lack of the ability to switch user identities, such as is done with the suid bit, and su utility. I know that as of last April, there was some talk of using the cygserver as a partial answer (with shared memory as a possible attack/leak point). I'm wondering about what's happened or is happening on this point and I've got a few practical questions and observations that relate. The primary question is simple, but does not appear to be reflected in the archive: Is anybody working on cygserver to get this technology implemented? I also observe that the sshd seems to be doing something a bit like this - how is it doing so? If we have an sshd doing something like this, why not have an su program? In fact, I have been taking advantage of the client side of ssh to ask a program be run for you on the "remote" system. Yeah, performance sucks, but then, at least it works! It does make for a crude 'su' program! A somewhat related observation is that when I use ssh to create a session on the system, it seems to work just fine HOWEVER, it does not have good access to disk shares. How might I go about providing my ssh clients who are a different user than is logged in into windows (or when noone is logged in!) access to disk shares? These other users, if logged into windows directly, have privileges for their own disk share access. The question then is, how can I mount volumes just for them? Do they need their own drive letters, or will they be private? ...I've read up on mount, but don't think this solves the problem: Simply accessing mounts which another user has the credentials for isn't quite right. The credentials should be based upon the rights of the user who's using them... That is to say, how/where do I tell it what username and password to use for the shares accessed? Or, will windows apply the correct credentials on my behalf? (I guess I could figure that out on my own with a lot of testing, but it'd be nice to get a straight answer if someone knows, please.) Thanks, and happy CYGWINning! Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
GCC bug with strftime
Hi All, It's been about eight months since I last posted to this list - hope everyone is doing well... I recently discovered a bug in strftime(). I downloaded a very recent copy of cygwin and tried again, but it's still there. So, I'd like to report it. I sent mail to the gcc-bugs list but nobody there seems to care, so I thought I'd mention it here. The problem is that this call fails to return an hour: strftime(IT,key,"%m/%d/%y %l:%M %p", brokentime); The l% is supposed to represent a _space_ padded hour, as documented here: http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_17.html#SEC302 I wrote a test program to illustrate the problem - call it a "bug script:" $ ./strftime This program illustrates a bug with strftime as it fails to return the hour. We are trying to use these flags: '%m/%d/%y %l:%M %p' strftime returned: 01/09/03 :26 PM The proper result: 01/09/03 3:26 PM $ My workaround (in the bug script) gets the hour as two digits and then tosses a leading zero... What a pain. -shrug- I don't know how to check what version of the library I have, but I have the following gcc compilers installed (as reported by cygcheck -s): gcc 3.2-3 gcc-mingw 20020817-4 gcc22.95.3-10 Please direct me on how I can get this information to someone who knows what to do with it! Thanks much, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: The Cygwin Server Daemon
> > The normal install with setup.exe didn't provide cygserver. > > Correct. This was stated in the development list: the source for > cygserver was only merged in post 1.3.10 being released, so no release > of cygwin has occurred with the cygserver built. I missed that in the archive, though I thought I read _every_ post which contained 'cygserver'. -shrug- > > When you say it > > does very little, I'm still left with the question, "Well, > > what _does_ it > > do?" > > I already answered this. -smile- Perhaps I should have said, "I wish I understood what it does!" > Use cygrunsrv if you want this to happen. > > > + If it's run by a normal user, how does this impart any > > ability to change > > user contexts? (When I asked about assigning privileges, I > > got the short > > answer, "What?") > > Ah, that sort of privilege. Well as it isn't slated to perform user > context changes, that hasn't come up. It certainly could if it ran as a > user with the appropriate access, and the appropriate additional code > was added. Ah, I see. I was perhaps confused because Corinna said in one of the oldest posts on cygserver that "I now know how" to make user context changes. ...There was an implication there, or so I thought! Silly Richard. > > + Regarding my own hopeful use someday: What is a reasonable > > approach to > > adding the honoring of the setuid (and guid) bit(s) in > > image execution? > > Review the _execve code. Create a cygserver message class for use in > that code, and use cygserver to create processes when the set[u|g]id bit > is set. Once the process is created cygserver should return the handle > that CreateProcess returns, and then the _execve code continues as > normal. Ah, a clue. Thank you... ...Since you noticed correctly that I was thinking "a little deep" (most of my OS internals experience is in machine language, assembler, and "Bliss-32"), I could use some clarification here. Here's what I envision at this point: _execve() code notices the suid/guid bits are set, checks that the file owner is not the caller and that the callers group list does not include the files group id, and dispatches a message to cygserver. That message includes the path to the image - and does not include the owner.group as a secondary guard to security at the cost of having to fetch this information a second time. At this point, I presume from your clue that cygserver calls CreateProcess(), passing arguments which tell it to create that process in the context (with the credentials) of the indicated user and group, along with the image name, of course. ...CreateProcess() then returns a "handle" to that process, and returns it to the caller. Or, does cygserver itself switch contexts? (hope not - sounds painful) ...Of course, the caller then returns the handle just as _execve() does. Your thoughts on this are most appreciated. ...If I understand this right, it doesn't sound all that hard! I think I saw code here somewhere that fetches the credentials, and I already have glibc code that pulls user and group info from the system based on the effective user ID of the current process... > cygrunsrv doco - you should just reference the cygrunsrv man page IMO - > rather than recapitulating it in the cygserver doco. Somehow I was confused that they were aspects of the same thing. Oops! > > Server Children: > > > > Regarding the question: Doesn't the implementation imply that > > the server > > must spawn every process? Or at least be the caller of the > > win32 to start > > the process and setup the process<->server communication channel? The > > answer is yes. > > No. The answer is no. Any cygwin process can attach to the server. It > uses standard NT calls to identify the uid and gid of the process. Ah! Well, this was what I got from an honest reading of the archive. Glad you caught that as I was _quite_ curious - which is why I included it in the writeup! > Good work on the collation to date, keep it coming :}. Thanks, Rob, it was a whole lot more work than I would have thought! (And the mail archive being down part of Sunday didn't help! -shrug-) Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: The Cygwin Server Daemon - VERY LONG
Hi All, when I asked: > + Regarding my own hopeful use someday: What is a reasonable approach to > adding the honoring of the setuid (and guid) bit(s) in image execution? > > I take it that cygwin1.dll needs to be changed, but cygwin1.dll seems to > be built of little bits of source code scattered about. I imagine that > in there somewhere is code that forks off a process to run a new image > that the user wants run. And I imagine that somewhere in there, where > the file access occurrs to bring in the executable image, there's a > place where new code should be inserted to test the suid bits and, if > the bit is set, a call to change security context into the file owner > should occurr. Comments _please._ In particular, does anyone know the > module name I should be mucking with? What about the call to change > context to the file owner? These pointers will help save me a lot of > time and are greatly appreciated. I have noticed the source src/winsup/cygwin/exec.cc - seems like it might be the right place. However, it has the following comment: /* This is called _execve and not execve because the real execve is defined in libc/posix/execve.c. It calls us. */ Not sure just where that was, I was surprised at this result! $ find . -iname execve.c ./newlib/libc/posix/execve.c ./newlib/libc/sys/mmixware/execve.c ./newlib/libc/sys/sysmec/execve.c ./newlib/libc/sys/sysnecv850/execve.c And, libc/posix/execve.c said: /* This and the other exec*.c files in this directory require the target to provide the _execve syscall. */ $ ls newlib/libc/posix/exec* execl.c execle.c execlp.c execv.c execve.c execvp.c ...Hmmm... I've mostly been a consumer of Unix/posix exec calls... It seems reasonable that there'd be a translation layer between the posix exec call formats and the Windows OS calls. I take it that the posix routines call the appropriate routine in src/winsup/cygwin/exec.cc, which is responsible for the appropriate behavior under cygwin? Commentary? Anybody know where there's a reasonably concise write up of this strategy? Thanks in advance, Richard -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: The Cygwin Server Daemon
Hi All, I've finally had a chance to play some. So, there's nothing like trying something! In answer to some of my own questions: > + Why doesn't the cygserver run, itself, as a server under NT much as sshd > does? You can do that. > + Regarding starting the server with cygrunsrv: > > - If the server is started with cygrunsrv, are we supposed to "install" > cygserver itself? Yes, exactly. > - What is the intent of the ability to install, remove, start and stop > services? Are these "services" supposed to be the "objects" we read > about in the archives? No, they're not the objects referred to. Rather, cygrunsrv lets you define your own NT(+) services. That you might setup cygserver to run as a service is a separate question. ...OK... So this gets me further along. I guess I was confused by cygrunsrv being involved with cygserver. -shrug- RT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
The Cygwin Server Daemon - VERY LONG
Hello again, Last week when I inquired about the cygserver architecture, present state of development, etc, I was told that cygserver is documented primarily in the cygwin-developers email list archive. I am now working on a document that will hopefully serve as better documentation of cygserver, starting as a compilation of materials found in the cygwin-developers archive, those found in the normal cygwin email archive, and augmented with my own questions and observations. I would appreciate any and all feedback on this document and on this topic in general. In doing this compliation and write up a lot of questions yet remain for me. There are just a whole lot of loose ends. It's my casual observation that the emails in the archive weren't as helpful and clear to me as they might have been because the original email audience knows each other and come from similar backgrounds so they don't need as many words to communicate an idea. Frankly, the code moved from losely sketched concept to running code without much discussion of the architecture. I, on the other hand, need a little more detail to really get it. One of the loose ends: > > didn't find any working copies of it either. > > What do you mean by this? It works for me, and the other folk who tested > it before it got committed. Currently it does very little though. The normal install with setup.exe didn't provide cygserver. Only a build of the source provided a copy. I was surprised by that. When you say it does very little, I'm still left with the question, "Well, what _does_ it do?" And, the new cygwin1.dll was _huge_ in comparison to the previous one. Is that because of debugging info? Other important open questions include: + Why doesn't the cygserver run, itself, as a server under NT much as sshd does? + If it's run by a normal user, how does this impart any ability to change user contexts? (When I asked about assigning privileges, I got the short answer, "What?") + Regarding starting the server with cygrunsrv: - If the server is started with cygrunsrv, are we supposed to "install" cygserver itself? - What is the intent of the ability to install, remove, start and stop services? Are these "services" supposed to be the "objects" we read about in the archives? + Regarding my own hopeful use someday: What is a reasonable approach to adding the honoring of the setuid (and guid) bit(s) in image execution? I take it that cygwin1.dll needs to be changed, but cygwin1.dll seems to be built of little bits of source code scattered about. I imagine that in there somewhere is code that forks off a process to run a new image that the user wants run. And I imagine that somewhere in there, where the file access occurrs to bring in the executable image, there's a place where new code should be inserted to test the suid bits and, if the bit is set, a call to change security context into the file owner should occurr. Comments _please._ In particular, does anyone know the module name I should be mucking with? What about the call to change context to the file owner? These pointers will help save me a lot of time and are greatly appreciated. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ ___ ___ Cygwin Server The following topics are covered in this text: Cygwin Server Concept + needs and features Accessing the Cygserver Daemon + Communications strategy Running the cygserver Multi-threading Server Children Code Size Stability Present Status Far future Other notes ___ Cygwin Server Concept: All operating systems which provide a multi-user security environment require a mechanism by which a non-privileged user can perform privileged tasks in a controlled and secure way. There are two generalized mechanisms in widespread use. The most common mechanism presumes a network-based model in which a privileged program is contacted by an unprivileged client program to effect the desired behavior. On Unix and Unix based operating systems such as Linux, the "inetd" daemon is a good example of this technique. However, Unix augments this technique with the "setuid bit", (a technique patented by Dennis Ritchie in the late '70s, IIRC) which provides a cue to the operating system to start an executable image in the user context of the owner identified in the file system for the executable
The Server Daemon
Hi All, So, I'm trying to get started with implementing the honoring of the suid bit by cygwin. I've downloaded the source and performed a build (which failed - the tail of make.log is below). So, I jumped into the source directory and looked at what was there. I started with the cygserver* files, as, if I'm not mistaken, that's where I'd need to be working... I went on to read the ROADMAP and most how-*.txt files, exec.cc, and other important looking files. As a recap, what I need from cygwin is the honoring of the suid bit, so that execution of an image with this bit set is executed in the context of the user identified in the file system as owner. I'd also be happy with any other alternative which lets my application code run in a security context other than that of the user without having to give that user any special privileges. There were a number of things in there that I _didn't_ see, most notably some documentation on the intended architecture of the daemon/server. I didn't find any working copies of it either. ...In reading the code, it's clear to me that I need some help understanding the architecture. What is this code intended to do? Is it intended to move the cygwin shared memory into a protected environment to close the existing security hole? Or, just what were the motives for creating it? What's its development status? I noticed comments about not being thread-safe in parts - what's up with that? There's talk of running two instances simultaneously someday - how does that fit into development plans? How is it installed and loaded? How do I give it privileges? And, as an asside, comments about things like this would be great to have in the source code itself! Yes, I could write the individuals mentioned in the source, but Corinna dictated that we should keep our dialogues here. In deference to her, I'm posting here... Your input greatly appreciated. Richard ___ Tail of make.log ___ c++ -L/d/d1/RT/cygwin/obj/i686-pc-cygwin/winsup -L/d/d1/RT/cygwin/obj/i686-pc-cy gwin/winsup/cygwin -L/d/d1/RT/cygwin/obj/i686-pc-cygwin/winsup/w32api/lib -isyst em /d/d1/RT/cygwin/src/winsup/include -isystem /d/d1/RT/cygwin/src/winsup/cygwin /include -isystem /d/d1/RT/cygwin/src/winsup/w32api/include -isystem /d/d1/RT/cygwin/src/newlib/libc/sys/cygwin -isystem /d/d1/RT/cygwin/src/newlib/libc/sys/cyg win32 -B/d/d1/RT/cygwin/obj/i686-pc-cygwin/newlib/ -isystem /d/d1/RT/cygwin/obj/ i686-pc-cygwin/newlib/targ-include -isystem /d/d1/RT/cygwin/src/newlib/libc/include -MMD -g -O2 -mno-cygwin -I. -I/d/d1/RT/cygwin/src/winsup/cinstall -I/d/d1/RT/cygwin/src/winsup/mingw/include -I/d/d1/RT/cygwin/src/winsup/bz2lib -mwindows -c -o mklink2.o ../../../../src/winsup/cinstall/mklink2.cc ../../../../src/winsup/cinstall/mklink2.cc: In function `void make_link_2(const char *, const char *, const char *, const char *)': ../../../../src/winsup/cinstall/mklink2.cc:24: cannot convert `CLSID_ShellLink' from type `const GUID' to type `const CLSID *' ../../../../src/winsup/cinstall/mklink2.cc:25: cannot convert `IID_IPersistFile' from type `_GUID' to type `const IID *' make[2]: *** [mklink2.o] Error 1 make[2]: Leaving directory `/d/d1/RT/cygwin/obj/i686-pc-cygwin/winsup/cinstall' make[1]: *** [cinstall] Error 1 make[1]: Leaving directory `/d/d1/RT/cygwin/obj/i686-pc-cygwin/winsup' make: *** [all-target-winsup] Error 2 Any ideas what went wrong? -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin mentors? Was: bash and the suid bit
On Fri, 19 Apr 2002, Heribert Dahms wrote: > Hi Richard, > > if it's that important for your company's project > (that you work like me 50% of each 25h day 8-) > why don't you pay Red Hat per hour or day, > so Corinna or Chris work for you in their prime time? Hi Heribert, Yes, that's a reasonable suggestion. I haven't read much of Chris' posts, but Corinna has written a lot of posts with 'suid' in them and I've read a lot of those. Clearly, she's a sharp cookie, and it would be a privilege to have her working on code for me. However, I think she and her present management would object to the terms of the employment contract! If she got the same deal as I have, she'd have to work 16+ hour work days, every day (no weekends, holidays, vacation, sick time), barely any pay, and would be expected to write bug-free code! -smile- Another consideration is feasibility: How close is the code already? And, if it's not very close, are there good alternatives for what I want to do? Please see my next post... Thanks for your suggestion, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ On Fri, 19 Apr 2002, Heribert Dahms wrote: > -Original Message- > From: Richard Troy [mailto:[EMAIL PROTECTED]] > Sent: Donnerstag, 18. April 2002 17:45 > To: Corinna Vinschen > Subject: Re: cygwin mentors? Was: bash and the suid bit > > > [Heribert] [snip] > You may operate under the assumption that it's left-over minutes in the > day that are being applied, and you're probably right for most everyone > else. However, that's not what I'm proposing. If I attempt this, it will > be "during my work day", which, at the present time, comprises about 5AM > to midnight every day, including weekends and most holidays - aren't > startup companies fun? -wink- ...I need this other code to run on a > Windows Box (NT/2k and later), and it's a high priority. > [Heribert] [snip] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin mentors? Was: bash and the suid bit
> > > It requires a person with > > > a lot of time, actually... > > > > And, I have been wondering how I might > > contribute too, being as over- worked and as busy as I am. > > Contribution is something you're doing voluntarily and just > as far as you're able to. We all have daytime jobs which > take more or less time. If there's energy left a few minutes > a day... go ahead and contribute. Not this time, Corinna. A Contribution is a contribution, regardless of the circumstances of its creation, I submit. I am, personally, interested in helping, however, if it weren't for the confluence of needs, I would not even be able to entertain the concept of helping at this time. You may operate under the assumption that it's left-over minutes in the day that are being applied, and you're probably right for most everyone else. However, that's not what I'm proposing. If I attempt this, it will be "during my work day", which, at the present time, comprises about 5AM to midnight every day, including weekends and most holidays - aren't startup companies fun? -wink- ...I need this other code to run on a Windows Box (NT/2k and later), and it's a high priority. If the best way to get it there is to help implement suid in cygwin, then I can justify it and both cygwin and my work benefit. Since I think my problem would be solved if only cygwin honored the suid bit, then it may make sense. Otherwise, I'm off to create a wholly different solution that will probably not make use of cygwin at all, and in that case, cygwin won't benefit. That said, presuming I give it a go, while this is a very high priority, it doesn't mean I can spend 100% of my time on it until it's done, though I may spend 8 hours a day on it, perhaps. ...Anyway, this is why I'm asking for a mentor: Help keep me focused on this problem and not get lost on dead-ends. Remember I indicated I have no experience programming in this environment, and it's clear enough I'm not yet fully informed of the systems internals issues that NT+ pose. Yet some of you are. If you can point me in the right direction, this could work. Or, you could let me flail around, spend countless hours reading email archives only to not find direction, spend countless more reading up on MS topics that don't really have anything to do with what I'm trying to do - but I don't know any better - and the project suffers and with it my work. And we both loose - cygwin looses a potentially very helpful contribution and I loose potentially very important hours. Resolving this connundrum is exactly what mentorship is all about: Focus the newcomer on the important things. If you are - someone is - up for it, so am I. Keep in mind, I'm offering that huge chunk of that time you said was required in exchange for only a little time from an experienced member of the community. I don't understand why you wouldn't encourage such a "trade." However, I'm experienced enough to know that you're right when you say solving the SUID problem will take "a lot of time." Without someone to draw upon for guidance, I'm not sure I'm ready for the risk of this tar-baby (time sink). Yes, it's possible to use this e-list for that purpose, but experience says that's not nearly as effective as someone making the decision, "OK, I'll point. Here's where you need to go..." Respectfully yours, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygwin mentors? Was: bash and the suid bit
> First of all, it's not bash but the OS (here Cygwin) which would > have to care for the suid bit. -smile- > Second, the suid bit is available with ntsec on NTFS file systems > but for now it's *only* available as a flag. It has no effect! Yes! I have learned this! And I am sad because of it. > The implementation of suid under Win32 requires a running daemon > with special permissions (running under SYSTEM account, that is) > which can start a process under a different user account on behalf > of the calling process. The daemon already exists but the suid > functionality isn't implemented yet. It requires a person with > a lot of time, actually... Yes, I was afraid of that. -frown- Perhaps this seems a silly place to say so, but I'm very impressed with the work I've seen in CYGWIN, and in the open community and GNU in general. In researching this SUID problem, I spent six or eight hours yesterday reading all the related posts from the archive, and I noticed how there's a lot of really good work - the internals discussions have been well written and there are a few of you, like you, Corinna, who are outstanding contributors... And, I have been wondering how I might contribute too, being as over- worked and as busy as I am. However, I _really_ need this - or some solution - working in this environment, so it seems we have a case of converging needs. I think It makes more sense for me to help out with suid than it does for me to write a one-off. ... After thinking it over for a bit... I'm willing to give it a go if someone can mentor me along. My apprenticeship resume: I started hacking in '77 at the tender age of 14, so by now I've got a lot of experience. I once wrote a complete real-time, multi-tasking operating system by myself which is in use today controlling pipelines and oil refineries, and I used to be one of the top VAX/VMS internals people at DEC, so this internals experience must be of some use here, especially since NT/W2k is based on VMS. If someone were to work with me, point me at the juicy stuff so I don't have to hunt so much, I can probably commit to this project. Otherwise, I'm concerned it'll take me too long to ramp up. Anyone want to be a mentor? Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: will bash honor the suid bit or not?
Thank you for your reply, Larry. You're right when you say that the requirement to give these permissions would defeat the whole purpose. In short, the purpose of the application itself is security-related. The information contained in the config. files is sensitive. The user needs to have the benefit of the data - through action of the program - but should not have access to the data itself. Giving out extensive privileges is exactly contray to this purpose. And you were right to guess that I already set ntsec in CYGWIN - it was my first move. That, and to put the definition in the systems env. vars, so other users who log in without Administrator privilege can't change it. I am apparently ignorant of how to handle a case like this on NT/2000, nor do I even know where to look. This problem must be solved for many uses already. I would think that a great many services have this same problem. It's an exceptionally common need to have a non-privileged user run a program and get privileged results. ...I'm a skilled, experienced programmer, but am _completely_ ignorant of the NT/2000 world - I don't even know where to look for answers! Worse, I'm very short on time. Yesterday, for example, I put in 19 hours of work. ...Working tired sure doesn't help. -sigh- >From where I sit, it sure looks like this problem should be solved for the BASH shell. Perhaps it should become a service? I dunno! It'd be great to hear from more of you: Anyone else care to confirm Larry's suggestion that giving privileges to users is the solution in this case? Thanks for your input, Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ On Wed, 17 Apr 2002, Larry Hall (RFK Partners, Inc) wrote: > Date: Wed, 17 Apr 2002 22:34:29 -0400 > From: "Larry Hall (RFK Partners, Inc)" <[EMAIL PROTECTED]> > To: Richard Troy <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: will bash honor the suid bit or not? > > At 09:56 PM 4/17/2002, Richard Troy wrote: > > >Hi All, > > > >I've got an application I'm trying to port from Unix to cygwin on Windows > >NT/2000 using NTFS. > > > >The application consists of an executable and a few configuration files. > >To work correctly, the executable and configuration files need to be owned > >by any ole user which is _not_ the user who wishes to run the application. > >Root/Administrator privileges are _not_ required, or desireable. The > >config files and executable are then secured from the user being able to > >change them, or view the configuration files. The suid bit of the > >executable is set in the file system. When the user runs the program, > >bash, or whatever shell, should then note the suid bit and run the program > >in the user context of the file owner, not the user who executes the > >program. The application thereby has access to the config files that the > >user does not ordinarily have. > > > >The program does not call, and does not need to call setuid(), nor any > >other flavor of such a call. > > > >The program works just fine on every Unix and Linux system upon which it > >has so far been tried. Now for Windows NT/2000! In setting it up and > >testing, I found that it runs properly for the user who owns the > >executable and configuration files. However, if another user tries to run > >it, it fails. > > > >In reading up, there's talk of the cygwin dll having a setuid() function, > >so I don't understand why the cygwin bash shell doesn't honor the setuid > >bit. I also observe that the file system _appears_ to honor the concept of > >the setuid bit. That is to say, you can $ chmod u+s , and > >$ls -l also shows the bit being set (or cleared as the case may > >be). ...SO... If the cygwin bash doesn't honor the bit, why bother having > >it available? (I didn't see this on the "to do" list.) > > > >It occurrs to me that there's a section in the User's Guide, which I > >didn't quite understand, that talks about "special permissions." In > >particular, it states: > > > >"NT uses so called `access tokens' to identify a user and it's > >permissions. To switch the user context the application has to request > >such an `access token'. This is typically done by calling the NT API > >function LogonUser. The access token is returned and either used in > >ImpersonateLoggedOnUser to change user context of the current process > >or in CreateProcessAsUser to change user context of a spawned child > >process. An important restriction is that the appli
will bash honor the suid bit or not?
Hi All, I've got an application I'm trying to port from Unix to cygwin on Windows NT/2000 using NTFS. The application consists of an executable and a few configuration files. To work correctly, the executable and configuration files need to be owned by any ole user which is _not_ the user who wishes to run the application. Root/Administrator privileges are _not_ required, or desireable. The config files and executable are then secured from the user being able to change them, or view the configuration files. The suid bit of the executable is set in the file system. When the user runs the program, bash, or whatever shell, should then note the suid bit and run the program in the user context of the file owner, not the user who executes the program. The application thereby has access to the config files that the user does not ordinarily have. The program does not call, and does not need to call setuid(), nor any other flavor of such a call. The program works just fine on every Unix and Linux system upon which it has so far been tried. Now for Windows NT/2000! In setting it up and testing, I found that it runs properly for the user who owns the executable and configuration files. However, if another user tries to run it, it fails. In reading up, there's talk of the cygwin dll having a setuid() function, so I don't understand why the cygwin bash shell doesn't honor the setuid bit. I also observe that the file system _appears_ to honor the concept of the setuid bit. That is to say, you can $ chmod u+s , and $ls -l also shows the bit being set (or cleared as the case may be). ...SO... If the cygwin bash doesn't honor the bit, why bother having it available? (I didn't see this on the "to do" list.) It occurrs to me that there's a section in the User's Guide, which I didn't quite understand, that talks about "special permissions." In particular, it states: "NT uses so called `access tokens' to identify a user and it's permissions. To switch the user context the application has to request such an `access token'. This is typically done by calling the NT API function LogonUser. The access token is returned and either used in ImpersonateLoggedOnUser to change user context of the current process or in CreateProcessAsUser to change user context of a spawned child process. An important restriction is that the application using LogonUser must have special permissions" How to set these special permissions is not discussed, and it merely begins describing how to write a setuid call - or, rather, replace it? ...Either way, it's my (barely educated) view that BASH should recognize that the suid bit is set for the about-to-be-executed image and should place the call to CreateProcessAsUser on our behalf... This would avoid -any- coding changes whatsoever. It would be _very_ useful, too! So... Do I merely have to set special permissions on the application program somehow? If so, pray-tell how? Or, is there no solution today? If there's no solution, since I _have_ to solve this, should I take it upon myself to contribute a tiny piece of code that implements this that could later be rolled into the cygwin-bash? (Please note that I don't really feel competent to write such code! I have _never_ written _any_ "Windows" application code!) Inquiring minds - and creative and demanding hackers - need to know! ...Thanks in advance for your time! Richard -- Richard Troy, Chief Scientist Science Tools Corporation [EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
