Re: [ANNOUNCEMENT] Updated: cygutils-1.4.10-2
Hello, On Fri, Apr 13, 2012 at 12:01:59AM -0400, Charles Wilson wrote: >> CHANGES (from cygutils-1.4.10-1) >> >> * fix bug where readshortcut --raw was always "on" >> * corrected longstanding issue with lpr printer name normalization >> * readshortcut now handles embedded "windows" environment variables >> (%foo%) correctly. Thank you. Regards, Denis Excoffier. -- 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
VIRUS: XWin.exe 1.12.0-4 "Bloodhound.Sonar.9"
Just performed a routine update to cygwin, which resulted in the updated XWin.exe being quarantined due to a virus threat. Details: setup.exe version: 2.769 source: http://cygwin.xl-mirror.nl xorg-servers-common version:1.12.0-4 Symantec Endpoint Protection reported XWin.exe contained "Bloodhound.Sonar.9" file size: 2828127 hash: 157814B5160244D44E469CA9829124DABA14426F3D60E6A22B52E953625CA0B2 category: application heuristic scan type: SONAR SONAR Risk level: High SONAR: High Reverting back to 1.12.0-3 from same source does *not* show this issue. Could be a false positive? But AV policy prevents me from running it. Regards, Simon. == Simon A Watts CPhys CITP Northrop Grumman Mission Systems Europe Ltd Senior Software Engineer Leander House 4600 Parkway Solent Business Park Fareham PO15 7AZ United Kingdom Tel: +44 (0) 845 67 102 67 Fax: +44 (0) 845 67 102 68 swa...@ngms.eu.com www.ngms.eu.com Registered in England No. 2741988 == Northrop Grumman Mission Systems Europe is a subsidiary of the Mission Systems sector of Northrop Grumman Corporation. This email is for the intended addressees only. If you have received it in error then you should not use, retain, disseminate or otherwise deal with it. Please notify the sender by return email. The views of the author may not necessarily constitute the views of Northrop Grumman Mission Systems Europe Ltd. Nothing in this email shall bind Northrop Grumman Mission Systems Europe Ltd in any contract or obligation. == -- 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: VIRUS: XWin.exe 1.12.0-4 "Bloodhound.Sonar.9"
On 2012-04-23 03:28, Watts, Simon (UK) wrote: Just performed a routine update to cygwin, which resulted in the updated > XWin.exe being quarantined due to a virus threat. http://cygwin.com/faq/faq-nochunks.html#faq.setup.virus Yaakov Cygwin/X -- 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
how to deny delete
I've noticed that on windows 7, even if we protect a folder by selecting "delete - Deny" in permissions, cygwin doesn't care and it allows to continue with rm. I think this is not good. I can think of other ways like creating a lock file in my scripts but that wont be a clean way. Isn't there any way that i can set some level of protection in NTFS without too much of fuss. I need to write to files and folder underneath but only want to deny delete permission on that top folder. regards -- View this message in context: http://old.nabble.com/how-to-deny-delete-tp33732027p33732027.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
[snip] > lgiambro@lorien ~ > $ cat len.sh > #!/bin/sh > echo it works And man sh states " --norc Do not read and execute the personal initialization file ~/.bashrc if the shell is interactive. This option is on by default if the shell is invoked as sh." Which eliminates bashrc as a possible culprit. I have also tried the same as you did (len.sh on a samba share) and saw the same problem. Then I saw that the len.sh got a (cygwin *and* linux) mode of -rwxrw-r-- *without* doing any chmod. Then I saw that *every* file I create on the samba share, gets the same mode! First things first, is there a workaround? Yes, chmod 777 len.sh *done on linux* works. And it actually works too when done on cygwin. However, recreating len.sh on cygwin, then a chmod 700 len.sh again on cygwin, does not work, again "./len.sh: Permission denied". But the mode seen on the linux side is -rwx--. I have also tried deleting then recreating the file in cygwin, then closing all cygwin processes and unmapping and remapping the samba drive. No cigar. Then I tried cacls in various situations. It turns out that with mode 777, cacls reveals "Everyone:F", but with mode 700 we get: len.sh F (special access:) Everyone:(special access:) And getfacl says: # file: len.sh # owner: # group: user::rwx group::--- mask:rwx other:--- Now I would say cygwin behaves as expected in my case: owner has execute permission, but who is the owner? Unfortunately this can only be *part* of the explanation, since for the OP it is # file: len.sh # owner: lgiambro # group: releng user::rwx group::--- mask:rwx other:--- (see thread head for the cacls). His samba setup is obviously better than mine. But now I cant be sure my workaround (mode 777) will work in his case. Hope these can help. -- 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: VIRUS: XWin.exe 1.12.0-4 "Bloodhound.Sonar.9"
Greetings, Watts, Simon (UK)! > Just performed a routine update to cygwin, which resulted in the updated > XWin.exe being quarantined due to a virus threat. > Details: > setup.exe version: 2.769 > source: http://cygwin.xl-mirror.nl > xorg-servers-common version:1.12.0-4 > Symantec Endpoint Protection reported XWin.exe contained "Bloodhound.Sonar.9" > file size: 2828127 > hash: > 157814B5160244D44E469CA9829124DABA14426F3D60E6A22B52E953625CA0B2 > category: application heuristic > scan type: SONAR > SONAR Risk level: High > SONAR: High > Reverting back to 1.12.0-3 from same source does *not* show this issue. > Could be a false positive? But AV policy prevents me from running it. >From the report, it seems like it's AV heuristic backfired. https://www.virustotal.com/file/157814b5160244d44e469ca9829124daba14426f3d60e6a22b52e953625ca0b2/analysis/ -- WBR, Andrey Repin (anrdae...@freemail.ru) 23.04.2012, <14:39> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.13-1: can't execute shell scripts on samba share
On Mon, Apr 23, 2012 at 7:02 AM, Michel Bardiaux wrote: > [snip] > >> lgiambro@lorien ~ >> $ cat len.sh >> #!/bin/sh >> echo it works > > And man sh states " --norc Do not read and execute the personal > initialization file ~/.bashrc if the > shell is interactive. This option is on by default if the > shell is invoked > as sh." > Which eliminates bashrc as a possible culprit. bash as sh will use ~/.profile in interactive and -login mode. My guess is the remote disk handler is causing Cygwin to not see the file as executable. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
Building for nocygwin
A number of open-source projects (a.o. libav) indicate the use of -mnocygwin to build, on cygwin, libraries or executables that do not need the cygwin dll Section 6.10 of the FAQ also says so, but also states "This section has not yet been updated for the latest net release.". And indeed, gcc 4.5.3 just kicks you out with "The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.". Using gcc-3, or setting it using /etc/alternatives, works but of course it is better to use the more recent compiler. Could someone publish the appropriate recipe? TiA, (s) Michel Bardiaux -- 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: Building for nocygwin
On Mon, Apr 23, 2012 at 7:35 AM, Michel Bardiaux wrote: > A number of open-source projects (a.o. libav) indicate the use of > -mnocygwin to build, on cygwin, libraries or executables that do not > need the cygwin dll Section 6.10 of the FAQ also says so, but also > states "This section has not yet been updated for the latest net > release.". And indeed, gcc 4.5.3 just kicks you out with "The > -mno-cygwin flag has been removed; use a mingw-targeted > cross-compiler.". > > Using gcc-3, or setting it using /etc/alternatives, works but of course > it is better to use the more recent compiler. Could someone publish the > appropriate recipe? Sure, --host=i686-pc-mingw32 or some other appropriate host string during configure. You'll need to make sure you have the appropriate files for cross compiling. The -mno-cygwin has been gone for some months moving into years. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: how to deny delete
Greetings, pen! > I've noticed that on windows 7, even if we protect a folder by selecting > "delete - Deny" in permissions, cygwin doesn't care and it allows to > continue with rm. Stop working under administrative account, then. -- WBR, Andrey Repin (anrdae...@freemail.ru) 23.04.2012, <15:41> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to deny delete
On Apr 23 02:23, pen wrote: > > I've noticed that on windows 7, even if we protect a folder by selecting > "delete - Deny" in permissions, cygwin doesn't care and it allows to > continue with rm. I think this is not good. I can think of other ways like > creating a lock file in my scripts but that wont be a clean way. Isn't there > any way that i can set some level of protection in NTFS without too much of > fuss. I need to write to files and folder underneath but only want to deny > delete permission on that top folder. If the user is neither the owner of the dir, nor an admin, and if the permissions are set to 0700, the user won't be able to delete the folder. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.13-1: can't execute shell scripts on samba share
On Apr 23 13:02, Michel Bardiaux wrote: > [snip] > > > lgiambro@lorien ~ > > $ cat len.sh > > #!/bin/sh > > echo it works > > And man sh states " --norc Do not read and execute the personal > initialization file ~/.bashrc if the > shell is interactive. This option is on by default if the > shell is invoked > as sh." > Which eliminates bashrc as a possible culprit. > > I have also tried the same as you did (len.sh on a samba share) and saw > the same problem. Then I saw that the len.sh got a (cygwin *and* linux) > mode of -rwxrw-r-- *without* doing any chmod. Then I saw that *every* > file I create on the samba share, gets the same mode! > > First things first, is there a workaround? Yes, chmod 777 len.sh *done > on linux* works. And it actually works too when done on cygwin. > > However, recreating len.sh on cygwin, then a chmod 700 len.sh again on > cygwin, does not work, again "./len.sh: Permission denied". But the mode > seen on the linux side is -rwx--. > > I have also tried deleting then recreating the file in cygwin, then > closing all cygwin processes and unmapping and remapping the samba > drive. No cigar. > > Then I tried cacls in various situations. It turns out that with mode > 777, cacls reveals "Everyone:F", but with mode 700 we get: > > len.sh F > (special access:) > Everyone:(special access:) > > And getfacl says: > > # file: len.sh > # owner: > # group: You could mount the samba share with "noacl", see http://cygwin.com/cygwin-ug-net/using.html#mount-table Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
[snip] > You could mount the samba share with "noacl", > see http://cygwin.com/cygwin-ug-net/using.html#mount-table > Corinna Thanks for the suggestion. I have added this to /etc/fstab: Y: /cygdrive/y smbfs binary,noacl,auto 0 0 Closed all cygwin windows, reopened one (mintty), mount says: C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) Y: on /cygdrive/y type smbfs (binary,noacl) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) created (again...) len.sh on the samba drive, and again: $ getfacl len.sh # file: len.sh # owner: # group: user::rwx group::rw- mask:rwx other:r-- Curiouser and curiouser: the file begins with #!, hence with noacl it should be executable by anyone, right? But I still have permission denied, unless I chmod 777. BTW: I am now playing around with execute mode and samba drives to help solve the OP's problem, maybe find a bug. I actually use cygwin with ssh, scp, svn, etc. so that I do *not* have to cope with the idiosyncrasies of multiple security layers: windows + samba + linux. So, adding a 4th one is akin to masochism! Greetings, (s) M. Bardiaux
Re: cygwin 1.7.13-1: can't execute shell scripts on samba share
On Apr 23 13:53, Corinna Vinschen wrote: > On Apr 23 13:02, Michel Bardiaux wrote: > > [snip] > > > > > lgiambro@lorien ~ > > > $ cat len.sh > > > #!/bin/sh > > > echo it works > > > > And man sh states " --norc Do not read and execute the personal > > initialization file ~/.bashrc if the > > shell is interactive. This option is on by default if the > > shell is invoked > > as sh." > > Which eliminates bashrc as a possible culprit. > > > > I have also tried the same as you did (len.sh on a samba share) and saw > > the same problem. Then I saw that the len.sh got a (cygwin *and* linux) > > mode of -rwxrw-r-- *without* doing any chmod. Then I saw that *every* > > file I create on the samba share, gets the same mode! > > > > First things first, is there a workaround? Yes, chmod 777 len.sh *done > > on linux* works. And it actually works too when done on cygwin. > > > > However, recreating len.sh on cygwin, then a chmod 700 len.sh again on > > cygwin, does not work, again "./len.sh: Permission denied". But the mode > > seen on the linux side is -rwx--. > > > > I have also tried deleting then recreating the file in cygwin, then > > closing all cygwin processes and unmapping and remapping the samba > > drive. No cigar. > > > > Then I tried cacls in various situations. It turns out that with mode > > 777, cacls reveals "Everyone:F", but with mode 700 we get: > > > > len.sh F > > (special access:) > > Everyone:(special access:) > > > > And getfacl says: > > > > # file: len.sh > > # owner: > > # group: Just to clarify: The unknown owner and group accounts in the getfacl output above are almost certainly the fake SIDs created by Samba to generate an unambiguous Unix UID/GID to Windows SID mapping. This occurs if you don't use winbind on the Samba side to generate a real UID/GID to SID mapping. The fake SIDs created by Samba are of the form S-1-22-1-UID S-1-22-2-GID You can add them to your /etc/passwd and /etc/group files by using the `mkpasswd/mkgroup -U option, see http://cygwin.com/cygwin-ug-net/using-utils.html#mkpasswd and http://cygwin.com/cygwin-ug-net/using-utils.html#mkgroup For instance: $ mkpasswd -o 2 -U root,corinna -L my_samba_server Unix User\root:unused:2:9:,S-1-22-1-0:: Unix User\corinna:unused:20500:9:,S-1-22-1-500:: $ mkgroup -o 2 -U root,vinschen -L calimero Unix Group\root:S-1-22-2-0:2: Unix Group\vinschen:S-1-22-2-11125:31125: This gives a useful output in ls, getfacl or stat. > You could mount the samba share with "noacl", see > http://cygwin.com/cygwin-ug-net/using.html#mount-table Corinna -- 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 1.7.13-1: can't execute shell scripts on samba share
On Apr 23 14:26, Michel Bardiaux wrote: > [snip] > > > You could mount the samba share with "noacl", > > see http://cygwin.com/cygwin-ug-net/using.html#mount-table > > Corinna > > Thanks for the suggestion. I have added this to /etc/fstab: > > Y: /cygdrive/y smbfs binary,noacl,auto 0 0 That won't work. Don't try to overload the cygdrive prefix for single drives, that's not supported. Use something like Y: /my_y_drive whatever binary,noacl 0 0 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
[snip] >> Y: /cygdrive/y smbfs binary,noacl,auto 0 0 > That won't work. Don't try to overload the cygdrive prefix for single > drives, that's not supported. Ooops. How do I restore the normal default? It no longer appears in 'mount'. > Use something like > Y: /my_y_drive whatever binary,noacl 0 0 Yep, that worked.
FW: cygwin 1.7.13-1: can't execute shell scripts on samba share
Sorry, forgot to change the recipient. -Original Message- > [snip] > >> lgiambro@lorien ~ >> $ cat len.sh >> #!/bin/sh >> echo it works > > And man sh states " --norc Do not read and execute the personal > initialization file ~/.bashrc if the > shell is interactive. This option is on by default if > the shell is invoked > as sh." > Which eliminates bashrc as a possible culprit. > bash as sh will use ~/.profile in interactive and -login mode. Yes, I forgot about .profile. The OP should check his .profile does nothing that could cause it to fail when the current directory is a samba share. > My guess is the remote disk handler is causing Cygwin to not see the file as > executable. Then why would getfacl, and ls, say it *is* executable? (In the OP case; in my case you are absolutely right).
RE: Building for nocygwin
[snip] > Sure, --host=i686-pc-mingw32 or some other appropriate host string during > configure. > You'll need to make sure you have the appropriate files for cross compiling. > The -mno-cygwin has been gone for some months moving into years. That much I could guess. I am pretty sure I could muddle through until I can configure and build, say, libav. I was hoping for a general solution. (s) M. Bardiaux
Re: Building for nocygwin
On Mon, Apr 23, 2012 at 9:09 AM, Michel Bardiaux wrote: > [snip] > >> Sure, --host=i686-pc-mingw32 or some other appropriate host string during >> configure. >> You'll need to make sure you have the appropriate files for cross compiling. >> The -mno-cygwin has been gone for some months moving into years. > > That much I could guess. I am pretty sure I could muddle through until I can > configure and build, say, libav. I was hoping for a general solution. That is the "general solution". The error message was appropriate and gave a clue. Beyond that you'll need to communicate a patch to the maintainers of the package that is still using -mno-cygwin. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Building for nocygwin
[snip] > That is the "general solution". The error message was appropriate and gave a > clue. Beyond that > you'll need to communicate a patch to the maintainers of the package that is > still using -mno-cygwin. Let me rephrase. gcc-3 -mno-cygwin -o foo.exe foo.c under cygwin, works to create a windows executable that does not reference the cygwin dlls. (provided of course that foo.c does not call any APIs that can only be provided by cygwin, like fork). That *was* a general solution. What is the equivalent using gcc-4 under cygwin?
Re: Building for nocygwin
Hi, On Mon, Apr 23, 2012 at 3:56 PM, Michel Bardiaux wrote: > [snip] > >> That is the "general solution". The error message was appropriate and gave >> a clue. Beyond that >> you'll need to communicate a patch to the maintainers of the package that is >> still using -mno-cygwin. > > Let me rephrase. > > gcc-3 -mno-cygwin -o foo.exe foo.c > > under cygwin, works to create a windows executable that does not reference > the cygwin dlls. (provided of course that foo.c does not call any APIs that > can only be provided by cygwin, like fork). That *was* a general solution. > > What is the equivalent using gcc-4 under cygwin? > i686-pc-mingw32-gcc -o foo.exe foo.c Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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: Building for nocygwin
On Apr 23 15:56, Michel Bardiaux wrote: > [snip] > > > That is the "general solution". The error message was appropriate and gave > > a clue. Beyond that > > you'll need to communicate a patch to the maintainers of the package that > > is still using -mno-cygwin. > > Let me rephrase. > > gcc-3 -mno-cygwin -o foo.exe foo.c > > under cygwin, works to create a windows executable that does not reference > the cygwin dlls. (provided of course that foo.c does not call any APIs that > can only be provided by cygwin, like fork). That *was* a general solution. As Earnie wrote, now you should use the appropriate mingw32 or mingw64 cross compiler, both of which are available as part of the Cygwin distro. This *is* the general solution. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building for nocygwin
On 23/04/2012 9:56 AM, Michel Bardiaux wrote: [snip] That is the "general solution". The error message was appropriate and gave a clue. Beyond that you'll need to communicate a patch to the maintainers of the package that is still using -mno-cygwin. Let me rephrase. gcc-3 -mno-cygwin -o foo.exe foo.c under cygwin, works to create a windows executable that does not reference the cygwin dlls. (provided of course that foo.c does not call any APIs that can only be provided by cygwin, like fork). That *was* a general solution. What is the equivalent using gcc-4 under cygwin? The -mno-cygwin option was a dirty, half-broken hack that was replaced by a proper cross-compiler starting with gcc-4. If you want to compile an app under cygwin that doesn't depend on cygwin at runtime, you should install and use the mingw-targeted cross compiler that exists precisely for that purpose (it's available in setup.exe). If you don't know what a cross-compiler is, or how to specify one to ./configure, then Google it (it's not a cygwin-specific thing). If your project of choice doesn't support cross compiling, file a bug with the maintainers or, in the unlikely case that the project doesn't use POSIX features, set CC to the mingw compiler. Regards, Ryan -- 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: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
Perhaps I did not make it clear enough, but these issues still exist as far as I can tell. I have clean Windows 7 and Windows XP virtual machines, and a clean install of Cygwin that was updated at the time I sent my original message. Both issues I described still exist. This is why I wrote the message. If the issues weren't existing on an up-to-date Cygwin installation, I would not write to this mailing list and waste anyone's time - I am usually not that dumb! Just this morning, I turned on my Cygwin installation in the Windows 7 VM. This time, cygreadline7.dll decided to relocate to 0x7003 - different from the original location I mentioned in my original e-mail. This DLL is not locating itself in a stable location. And there are still system DLLs located very close to the Cygwin DLLs. If having Windows randomly rebase cygreadline7.dll in a child process via ASLR is not a problem, I'd simply be interested to know why. I thought *any* Cygwin DLL relocating itself would cause fork to fail. If having Cygwin DLLs conflict with system DLLs in the address space is not a potential problem, I'd also be interested to know why. Because I am observing both of these on an *up-to-date Cygwin installation* - not just the Cygwin 1.7.9 setup. According to the users guide at http://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process - section "Problems with process creation" - having Cygwin DLLs conflict with system DLLs is a problem, and having cygreadline7.dll randomly based via ASLR is a problem - so is my logic faulty in this case or not? As far as I can tell, I'm up-to-date... Setup says I have libreadline7 6.1.2-2 installed - the latest according to http://cygwin.com/packages/libreadline7/. My file size and date matches what is shown at that URL. Yet: c:\cygwin\bin>dumpbin /headers cygreadline7.dll | more 8040 DLL characteristics Dynamic base Terminal Server Aware Notice the "Dynamic base" flag set. -Original Message- Sent: Friday, April 20, 2012 20:50 Subject: Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs On Fri, Apr 20, 2012 at 05:44:38PM -, James Johnston wrote: >[snip] >... Today this issue came >to a head on one installation of Cygwin 1.7.9,... >[snip] >Thoughts, anyone? Yep. Update your Cygwin installation. You're four revisions out of date. It should come not too great a surprise that we've had extensive discussions about this issue and have made some changes in recent releases. -- 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 -- 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: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On Apr 23 14:23, James Johnston wrote: > Perhaps I did not make it clear enough, but these issues still exist as far > as I can tell. I have clean Windows 7 and Windows XP virtual machines, and > a clean install of Cygwin that was updated at the time I sent my original > message. Both issues I described still exist. This is why I wrote the > message. If the issues weren't existing on an up-to-date Cygwin > installation, I would not write to this mailing list and waste anyone's time > - I am usually not that dumb! > > Just this morning, I turned on my Cygwin installation in the Windows 7 VM. > This time, cygreadline7.dll decided to relocate to 0x7003 - different > from the original location I mentioned in my original e-mail. This DLL is > not locating itself in a stable location. And there are still system DLLs > located very close to the Cygwin DLLs. > > If having Windows randomly rebase cygreadline7.dll in a child process via > ASLR is not a problem, I'd simply be interested to know why. I thought > *any* Cygwin DLL relocating itself would cause fork to fail. Yes, it is a problem in the first place if DLLs have the dynamicbase flag set, because, obviously, it undermines what rebaseall is doing. It's not a problem if the new address it gets rebased to doesn't collide with any other used DLL since ASLR on Windows only shuffles ASLR-enabled DLL addresses when a DLL is loaded by an application for the first time. Afterwards, it will use the new address for that DLL until reboot. So, yes, we should make sure that the ASLR flag is not used for Cygwin DLLs. Eric, could you create a new package which avoids setting the dynamicbase flag for cygreadline and cyghistory? In one of my installations there's also cygperl5_10.dll having the dynamicbase flag set. Reini, could you please have a look and make sure it's not set? In my installations there's no other DLL with this flag set. As for the address space, we should stick to using the addresses below 0x7000, top-down. The reason is that we also need room for the application heap. On 32 bit systems the heap will be placed at 0x2000 and in case it's too small it will be extended up to the start address of the Cygwin DLL (minus 3 * 64K). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Building for nocygwin
> As Earnie wrote, now you should use the appropriate mingw32 or mingw64 cross > compiler, > both of which are available as part of the Cygwin distro. > This *is* the general solution. I *get* that. My problem was, the web is so cluttered with pages mentioning the no-cygwin thing (including the cygwin FAQ!) that finding a good howto is nearly impossible. Lots of pages about running the mingw toolchain on mingw/msys, but at some point in the past I had installed cygwin *and* msys, and managing the path, the profile scripts, etc was a real pain, so never again. With the benefit of Csaba's hint, the basic recipe is now: 1. Install mingw-gcc-core (which pulls other necessary packages) 2. i686-pc-mingw32-gcc -o jef.exe jef.c With that under my belt, I can start thinking about adding spices, herbs, truffles, and soy sauce :-) Is there a deep reason not to amend the FAQ?
Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On 04/23/2012 08:51 AM, Corinna Vinschen wrote: >> If having Windows randomly rebase cygreadline7.dll in a child process via >> ASLR is not a problem, I'd simply be interested to know why. I thought >> *any* Cygwin DLL relocating itself would cause fork to fail. > > Yes, it is a problem in the first place if DLLs have the dynamicbase > flag set, because, obviously, it undermines what rebaseall is doing. > It's not a problem if the new address it gets rebased to doesn't collide > with any other used DLL since ASLR on Windows only shuffles ASLR-enabled > DLL addresses when a DLL is loaded by an application for the first time. > Afterwards, it will use the new address for that DLL until reboot. > So, yes, we should make sure that the ASLR flag is not used for Cygwin > DLLs. > > Eric, could you create a new package which avoids setting the > dynamicbase flag for cygreadline and cyghistory? At the time I created the current cygreadline package, cygwin didn't have quite as good support for running rebaseall; since things have improved on that front, I will see about getting a new release of the readline package this week that disables the ASLR hack I had added way back when. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On Apr 23 08:54, Eric Blake wrote: > On 04/23/2012 08:51 AM, Corinna Vinschen wrote: > >> If having Windows randomly rebase cygreadline7.dll in a child process via > >> ASLR is not a problem, I'd simply be interested to know why. I thought > >> *any* Cygwin DLL relocating itself would cause fork to fail. > > > > Yes, it is a problem in the first place if DLLs have the dynamicbase > > flag set, because, obviously, it undermines what rebaseall is doing. > > It's not a problem if the new address it gets rebased to doesn't collide > > with any other used DLL since ASLR on Windows only shuffles ASLR-enabled > > DLL addresses when a DLL is loaded by an application for the first time. > > Afterwards, it will use the new address for that DLL until reboot. > > So, yes, we should make sure that the ASLR flag is not used for Cygwin > > DLLs. > > > > Eric, could you create a new package which avoids setting the > > dynamicbase flag for cygreadline and cyghistory? > > At the time I created the current cygreadline package, cygwin didn't > have quite as good support for running rebaseall; since things have > improved on that front, I will see about getting a new release of the > readline package this week that disables the ASLR hack I had added way > back when. Thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building for nocygwin
On Mon, Apr 23, 2012 at 04:52:54PM +0200, Michel Bardiaux wrote: >> As Earnie wrote, now you should use the appropriate mingw32 or mingw64 cross >> compiler, >> both of which are available as part of the Cygwin distro. >> This *is* the general solution. > >I *get* that. My problem was, the web is so cluttered with pages mentioning >the no-cygwin thing (including the cygwin FAQ!) that finding a good howto is >nearly impossible. Lots of pages about running the mingw toolchain on >mingw/msys, but at some point in the past I had installed cygwin *and* msys, >and managing the path, the profile scripts, etc was a real pain, so never >again. > >With the benefit of Csaba's hint, the basic recipe is now: > >1. Install mingw-gcc-core (which pulls other necessary packages) >2. i686-pc-mingw32-gcc -o jef.exe jef.c > >With that under my belt, I can start thinking about adding spices, herbs, >truffles, and soy sauce :-) > >Is there a deep reason not to amend the FAQ? No, there is no reason not to change the FAQ. Could someone provide some appropriate words? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: >On Apr 23 14:23, James Johnston wrote: >> Perhaps I did not make it clear enough, but these issues still exist as far >> as I can tell. I have clean Windows 7 and Windows XP virtual machines, and >> a clean install of Cygwin that was updated at the time I sent my original >> message. Both issues I described still exist. This is why I wrote the >> message. If the issues weren't existing on an up-to-date Cygwin >> installation, I would not write to this mailing list and waste anyone's time >> - I am usually not that dumb! >> >> Just this morning, I turned on my Cygwin installation in the Windows 7 VM. >> This time, cygreadline7.dll decided to relocate to 0x7003 - different >> from the original location I mentioned in my original e-mail. This DLL is >> not locating itself in a stable location. And there are still system DLLs >> located very close to the Cygwin DLLs. >> >> If having Windows randomly rebase cygreadline7.dll in a child process via >> ASLR is not a problem, I'd simply be interested to know why. I thought >> *any* Cygwin DLL relocating itself would cause fork to fail. > >Yes, it is a problem in the first place if DLLs have the dynamicbase >flag set, because, obviously, it undermines what rebaseall is doing. >It's not a problem if the new address it gets rebased to doesn't collide >with any other used DLL since ASLR on Windows only shuffles ASLR-enabled >DLL addresses when a DLL is loaded by an application for the first time. >Afterwards, it will use the new address for that DLL until reboot. >So, yes, we should make sure that the ASLR flag is not used for Cygwin >DLLs. Is this something that rebase could turn off when it touches a DLL? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On Apr 23 11:44, Christopher Faylor wrote: > On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: > >On Apr 23 14:23, James Johnston wrote: > >> Perhaps I did not make it clear enough, but these issues still exist as far > >> as I can tell. I have clean Windows 7 and Windows XP virtual machines, and > >> a clean install of Cygwin that was updated at the time I sent my original > >> message. Both issues I described still exist. This is why I wrote the > >> message. If the issues weren't existing on an up-to-date Cygwin > >> installation, I would not write to this mailing list and waste anyone's > >> time > >> - I am usually not that dumb! > >> > >> Just this morning, I turned on my Cygwin installation in the Windows 7 VM. > >> This time, cygreadline7.dll decided to relocate to 0x7003 - different > >> from the original location I mentioned in my original e-mail. This DLL is > >> not locating itself in a stable location. And there are still system DLLs > >> located very close to the Cygwin DLLs. > >> > >> If having Windows randomly rebase cygreadline7.dll in a child process via > >> ASLR is not a problem, I'd simply be interested to know why. I thought > >> *any* Cygwin DLL relocating itself would cause fork to fail. > > > >Yes, it is a problem in the first place if DLLs have the dynamicbase > >flag set, because, obviously, it undermines what rebaseall is doing. > >It's not a problem if the new address it gets rebased to doesn't collide > >with any other used DLL since ASLR on Windows only shuffles ASLR-enabled > >DLL addresses when a DLL is loaded by an application for the first time. > >Afterwards, it will use the new address for that DLL until reboot. > >So, yes, we should make sure that the ASLR flag is not used for Cygwin > >DLLs. > > Is this something that rebase could turn off when it touches a DLL? In theory that's the job of peflags, not of rebase. And somebody could want the ASLR flag to be set on certain DLLs. But probably we can safely assume that the Cygwin distro DLLs should not have set the dynamicbase flag and the rebaseall script could call rebase with an extra flag which automatically removes the dynamicbase flag from all rebased DLLs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On 4/23/2012 11:58 AM, Corinna Vinschen wrote: On Apr 23 11:44, Christopher Faylor wrote: On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: On Apr 23 14:23, James Johnston wrote: Perhaps I did not make it clear enough, but these issues still exist as far as I can tell. I have clean Windows 7 and Windows XP virtual machines, and a clean install of Cygwin that was updated at the time I sent my original message. Both issues I described still exist. This is why I wrote the message. If the issues weren't existing on an up-to-date Cygwin installation, I would not write to this mailing list and waste anyone's time - I am usually not that dumb! Just this morning, I turned on my Cygwin installation in the Windows 7 VM. This time, cygreadline7.dll decided to relocate to 0x7003 - different from the original location I mentioned in my original e-mail. This DLL is not locating itself in a stable location. And there are still system DLLs located very close to the Cygwin DLLs. If having Windows randomly rebase cygreadline7.dll in a child process via ASLR is not a problem, I'd simply be interested to know why. I thought *any* Cygwin DLL relocating itself would cause fork to fail. Yes, it is a problem in the first place if DLLs have the dynamicbase flag set, because, obviously, it undermines what rebaseall is doing. It's not a problem if the new address it gets rebased to doesn't collide with any other used DLL since ASLR on Windows only shuffles ASLR-enabled DLL addresses when a DLL is loaded by an application for the first time. Afterwards, it will use the new address for that DLL until reboot. So, yes, we should make sure that the ASLR flag is not used for Cygwin DLLs. Is this something that rebase could turn off when it touches a DLL? In theory that's the job of peflags, not of rebase. And somebody could want the ASLR flag to be set on certain DLLs. But probably we can safely assume that the Cygwin distro DLLs should not have set the dynamicbase flag and the rebaseall script could call rebase with an extra flag which automatically removes the dynamicbase flag from all rebased DLLs. Maybe it would also be a good idea to modify peflagsall so that by default it removes the dynamicbase flag rather than setting it. Ken -- 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: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
> -Original Message-
> Sent: Monday, April 23, 2012 14:51
> Subject: Re: Two probable basing issues causing fork failures: (1)
> cygreadline7.dll has ASLR enabled, (2) default base address conflicts with
> ASLR-relocated/system DLLs
>
> Yes, it is a problem in the first place if DLLs have the dynamicbase flag set,
> because, obviously, it undermines what rebaseall is doing.
> It's not a problem if the new address it gets rebased to doesn't collide with
> any other used DLL since ASLR on Windows only shuffles ASLR-enabled DLL
> addresses when a DLL is loaded by an application for the first time.
> Afterwards, it will use the new address for that DLL until reboot.
> So, yes, we should make sure that the ASLR flag is not used for Cygwin DLLs.
Well, that's what I figured... Thanks for investigating!
I also thought that an ASLR-relocated DLL would keep the same random base
address until reboot. But on the Cygwin 1.7.9 system I mentioned in the
original e-mail, I would have sworn that ASLR was not consistently basing
cygreadline7.dll in the same place even in the same user session, even when
multiple instances of Cygwin were running. I wish I took screenshots or took
better documentation or something though. It wasn't just a random error - it
was failing every single time - I couldn't launch any process at all from bash.
There is certainly no guarantee that ASLR DLLs will never be relocated after
first load and until reboot. A quick demonstration:
// compile with DYNAMICBASE:NO and NXCOMPAT:NO
#include
#include
#include
int main() {
HMODULE hm = LoadLibrary(_T("RandomASLRDLL.dll"));
std::cout << std::hex << reinterpret_cast(hm) << std::endl;
char c[50];
std::cin.getline(c, 50);
return 0;
}
Every execution seemed to alternate between two different base addresses.
However, running multiple instances at a time seemed to cause them to share the
same base address. Maybe with more work I could get the loader to violate that
assumption as well...
Or maybe I'm remembering things wrong from what I saw. (very possible!) I'll
be keeping an eye out.
> As for the address space, we should stick to using the addresses below
> 0x7000, top-down. The reason is that we also need room for the
> application heap. On 32 bit systems the heap will be placed at 0x2000
> and in case it's too small it will be extended up to the start address of the
> Cygwin DLL (minus 3 * 64K).
This explains why the base address for Cygwin1.dll was at 0x6100 while
rebaseall has DefaultBaseAddress=0x7000 it's top-down... makes sense -
somehow I missed that detail.
But on systems with ASLR, I noticed multiple ASLR system DLLs in this address
range. Even on clean Windows XP SP3 installations there was a system DLL in
the 0x6000 - 0x7000 range. Isn't it just by luck that the DLLs didn't
conflict and cause one to be relocated? (Or does Cygwin rebasing have some
more smarts I am overlooking, like working around system DLLs that are already
loaded? Although, that wouldn't help with ASLR DLLs... it still sounds risky.
And Windows Update will potentially change the DLLs, too.)
Certainly heap space is a compromise - I thought of that - but I would guess
most Cygwin users don't need it. At least, this one doesn’t!
For users who don't need to maximize heap space at the possible expense of
fork() reliability, is it safe to say that a lower top-end rebase address would
be a lot safer? For example, running this after installing Cygwin for the
first time:
rebaseall -b 0x6000
(or maybe even 0x5000 if you really don't need the heap space?)
Or are there other factors I am overlooking?
James
--
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: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On Apr 23 12:20, Ken Brown wrote: > On 4/23/2012 11:58 AM, Corinna Vinschen wrote: > >In theory that's the job of peflags, not of rebase. And somebody could > >want the ASLR flag to be set on certain DLLs. But probably we can safely > >assume that the Cygwin distro DLLs should not have set the dynamicbase > >flag and the rebaseall script could call rebase with an extra flag which > >automatically removes the dynamicbase flag from all rebased DLLs. > > Maybe it would also be a good idea to modify peflagsall so that by > default it removes the dynamicbase flag rather than setting it. Sounds like a good idea to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On Apr 23 16:31, James Johnston wrote: > > As for the address space, we should stick to using the addresses below > > 0x7000, top-down. The reason is that we also need room for the > > application heap. On 32 bit systems the heap will be placed at 0x2000 > > and in case it's too small it will be extended up to the start > > address of the Cygwin DLL (minus 3 * 64K). > [...] > But on systems with ASLR, I noticed multiple ASLR system DLLs in this > address range. Even on clean Windows XP SP3 installations there was a > system DLL in the 0x6000 - 0x7000 range. Isn't it just by > luck that the DLLs didn't conflict and cause one to be relocated? (Or > does Cygwin rebasing have some more smarts I am overlooking, like > working around system DLLs that are already loaded? Although, that > wouldn't help with ASLR DLLs... it still sounds risky. And Windows > Update will potentially change the DLLs, too.) We have to compromise. There is no 100% guarantee that it works. > Certainly heap space is a compromise - I thought of that - but I would > guess most Cygwin users don't need it. At least, this one doesn’t! You don't know if you need it or not. It's something the application requests automatically under the hood (sbrk call). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs
On Mon, Apr 23, 2012 at 05:58:23PM +0200, Corinna Vinschen wrote: >On Apr 23 11:44, Christopher Faylor wrote: >> On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: >> >On Apr 23 14:23, James Johnston wrote: >> >> Perhaps I did not make it clear enough, but these issues still exist as >> >> far >> >> as I can tell. I have clean Windows 7 and Windows XP virtual machines, >> >> and >> >> a clean install of Cygwin that was updated at the time I sent my original >> >> message. Both issues I described still exist. This is why I wrote the >> >> message. If the issues weren't existing on an up-to-date Cygwin >> >> installation, I would not write to this mailing list and waste anyone's >> >> time >> >> - I am usually not that dumb! >> >> >> >> Just this morning, I turned on my Cygwin installation in the Windows 7 VM. >> >> This time, cygreadline7.dll decided to relocate to 0x7003 - different >> >> from the original location I mentioned in my original e-mail. This DLL is >> >> not locating itself in a stable location. And there are still system DLLs >> >> located very close to the Cygwin DLLs. >> >> >> >> If having Windows randomly rebase cygreadline7.dll in a child process via >> >> ASLR is not a problem, I'd simply be interested to know why. I thought >> >> *any* Cygwin DLL relocating itself would cause fork to fail. >> > >> >Yes, it is a problem in the first place if DLLs have the dynamicbase >> >flag set, because, obviously, it undermines what rebaseall is doing. >> >It's not a problem if the new address it gets rebased to doesn't collide >> >with any other used DLL since ASLR on Windows only shuffles ASLR-enabled >> >DLL addresses when a DLL is loaded by an application for the first time. >> >Afterwards, it will use the new address for that DLL until reboot. >> >So, yes, we should make sure that the ASLR flag is not used for Cygwin >> >DLLs. >> >> Is this something that rebase could turn off when it touches a DLL? > >In theory that's the job of peflags, not of rebase. Sure, peflags should be able to unset/set it but it doesn't seem to ever make sense for a dll that rebase has touched so... >But probably we can safely assume that the Cygwin distro DLLs should >not have set the dynamicbase flag and the rebaseall script could call >rebase with an extra flag which automatically removes the dynamicbase >flag from all rebased DLLs. I don't see a real need for an extra rebase flag, unless it is turn off the "remove dynamicbase behavior" but it's no big deal. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 4/20/2012 7:07 AM, Václav Zeman wrote: This is a Windows thing. Another aspect of the Windows Thing which I have not seen discussed yet is the DLL load path: http://goo.gl/VA8yC Since Windows looks for DLLs first in the *.exe directory, this is the most reliable place to put them. 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. The only thing stopping us from using the final option in the article (i.e. putting cyg*.dll somewhere else in the PATH) is that it would put the DLLs off in the most fragile location allowed under the rules and it wouldn't solve the OP's problem anyway. The DLLs would still appear in file name completion lists, since that also searches the PATH. -- 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 4/20/2012 1:06 PM, Jon TURNEY wrote: 'export EXECIGNORE=*.dll' is a cygwin extension to bash to tell it you don't want to see those pesky dlls. Is there a good reason this isn't in the stock /etc/bash.bashrc? -- 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, Apr 23, 2012 at 01:02:39PM -0600, Warren Young wrote: > On 4/20/2012 1:06 PM, Jon TURNEY wrote: > > > >'export EXECIGNORE=*.dll' is a cygwin extension to bash to tell it you don't > >want to see those pesky dlls. > > Is there a good reason this isn't in the stock /etc/bash.bashrc? Not that I can think of. Added for the next release of base-files. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: Why /usr/bin/*.dll must be executable?
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. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why /usr/bin/*.dll must be executable?
On 4/23/2012 2:15 PM, 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 not saying it wouldn't work, I'm just saying that installing Cygwin DLLs under %SYSTEMROOT% would cross the grain of the Cygwin installation philosophy. It would complicate uninstallation, perhaps to the point that someone decides we now need an automatic uninstaller. As it is, manual uninstallation is easy and rare enough that the biggest problem we see with it is people not finding the FAQ item. -- 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
Re: Why /usr/bin/*.dll must be executable?
On 4/23/2012 6:12 PM, Richard Troy wrote: what on earth would --login have to do with where the dlls are found? Without that, you don't run the profile files[*], so you get the Windows PATH[**] which is clearly insufficient in your situation. Somewhere in one of these files is a line of code that adds the directory containing the problem DLL to your PATH. [*] /etc/profile, ~/.bash_profile, ~/.profile, ~/.bash_login... [**] System control panel > Advanced > Environment Variables -- 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
Problems with nfs
Hello! I have a problem with Cygwin NFS server. I boot up my host PC and then boot up ARM Linux embedded system, which then connects to my host over NFS. An attempt to mount NFS resource produces "RPC error: connection refused" until i restart portmap service on my host. What can be wrong? I examined logs, and found no problems. I also examined 'netstat -a' output on the PC, and found nothing interesting (portmap is working and is listening). Windows firewall is set up correctly (i added exceptions for NFS and RPC ports). I do nothing else except simple portmap restart. Also, why does nfs access appear to be so horribly slow? Loading a directory with ~150 files takes about two minutes in mc. I understand fork() issue, but what are problems with just reading files descriptors? -- Kind regards Pavel Fedin Expert engineer, Samsung Moscow research center -- 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
