Re: gcc4-core packaging bug
Yaakov (Cygwin/X) writes: > Actually, the RIGHT thing to do is to have Perl (updated to 5.14.4 > and) built without the CC=gcc-4 hack. Oh, absolutely. But until we have that, if anyone runs into troubles that some program which hasn't been rebuilt since the gcc update is unable to find a C compiler, add the .exe suffix to the compatibility link. I've only mentioned it here because I recently got a new machine at work and wondered why I couldn't build some Perl modules anymore until I remembered that I had re-linked the compilers on the old one. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gcc-4.8.2-1: /bin/gcc fails
On 2013-11-02 04:36, Corinna Vinschen wrote: On Nov 1 23:23, David Rothenberger wrote: With gcc-4.8.2-1, the following fails: % touch /tmp/t.c % /bin/gcc -c /tmp/t.c gcc: error: spawn: No such file or directory Curious, are you seeing real-life references to /bin/gcc? Because that wouldn't be portable anyway. I did try this on Fedora (recent version of which use /bin => /usr/bin and /lib => /usr/lib symlinks) and this worked fine. AFAICS, the difference there is that /usr/bin is the "real" directory and /bin is just a symlink, where the reverse is true on Cygwin and a mount is used instead of a symlink. Uh oh. That's bad. Maybe it wasn't such a good idea to switch libexecdir from /usr/lib to /usr/libexec? It breaks applications using relative paths to search other application components when run from /bin. AFAIK GCC is unique in this regard; relocatibility code is uncommon, and most other uses of libexecdir definitely use absolute paths. Either we revert libexecdir to /usr/lib, or we will need to add an automount point /libexec -> /usr/libexec as for /bin and /lib. What if another program references its datadir as ../share/foo? (I'm pretty sure it does happen, although GCC doesn't, FWIW.) Are you going to make an automount point for that as well? (Didn't think so.) Relocatibility simply isn't portable to a /bin == /usr/bin scenarios, although use of a symlink instead of a mount might mitigate that. So, while I'm not convinced that this is a huge issue overall, if "don't do that" isn't good enough, the easiest workaround is to configure GCC with --libexecdir=/usr/lib. Yaakov -- 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: gcc4-core packaging bug
On 2013-11-01 15:44, Achim Gratz wrote: Andrey Repin writes: The package gcc4-core provides a compatibility symlink for programs that expect the old gcc naming scheme (like Perl). The link however is just "gcc4", while Devel::CheckLib for instance looks for "gcc4.exe". Report that to the maintainer of Devel::CheckLib It SHOULD NOT check for .exe suffix under cygwin. Yes it should, since it does not need to know about the .exe magic Cygwin performs. Besides, it gets that information from %Config, which in turn comes from Cygwin's own Perl. Once the compatibility link is named gcc-4.exe, the .exe magic ensures that both checking for an executable named gcc-4 and gcc-4.exe will succeed, so that's the right thing to do and not patching whatever number of Perl modules and/or other build scripts. Actually, the RIGHT thing to do is to have Perl (updated to 5.14.4 and) built without the CC=gcc-4 hack. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: serf-1.3.2-1
The serf packages have been updated to the new upstream release 1.3.2. See http://serf.googlecode.com/svn/tags/1.3.2/CHANGES for more details about the changes in this release. More information about serf can be found at http://code.google.com/p/serf/. DESCRIPTION: The serf library is a C-based HTTP client library built upon the Apache Portable Runtime (APR) library. It multiplexes connections, running the read/write communication asynchronously. Memory copies and transformations are kept to a minimum to provide high performance operation. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org -- 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: p11-kit list-modules fails
On 2013-11-01 22:45, Bassam Tabbara wrote: I’m seeing the following: [snip] On a Windows Server 2012 machine. Now that ca-certificates relies on p11-kit to create the certificate files this broke all tools using SSL including git. cygcheck output attached. Note that until ca-certificates-1.94-1 p11-kit was not used, so it might have been broken for a while. Please try running rebaseall. Yaakov -- 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 about a 64-bit installer that doesn't require UAC?
Greetings, All! > The real solution would be a tool that run in postinstall scripts and can > prompt user for privilege elevation, but noone had time or inclination to > write one. Yet. This got me to think... An alternation of env command with appropriate manifest would be sufficient. -- WBR, Andrey Repin (anrdae...@yandex.ru) 03.11.2013, <02:50> 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 about a 64-bit installer that doesn't require UAC?
Greetings, Bill Welch! > Yes, I could try to change the application manifest myself, but that > seems esoteric and I haven't been able to find any GPL tool. I suggest you use search before posting. This has been discussed already. The real solution would be a tool that run in postinstall scripts and can prompt user for privilege elevation, but noone had time or inclination to write one. Yet. -- WBR, Andrey Repin (anrdae...@yandex.ru) 03.11.2013, <02:26> 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: vi stealing SYSTEM-owned permissions and ownership
Greetings, D. Boland! > First, in my student-setup, Apache is not running under Cygwin. I used the > .msi distribution, available on the Apache website. This installs Apache as a > native Windows Service, and it can be configured using the Windows Services > Control Panel. > As to running as the SYSTEM user, I agree with you. In Linux, Apache is > started > by root, and then immediately switches to the "nobody" user, so it is unable > to touch or even see the outside of its ServerRoot. > In Windows, this mechanism does not work. That is why the "User" and "Group" > directives are left out of the httpd.conf file in the Windows distribution. > I now have Apache running under the username "Daemon" which I created using > the standard Windows "Users" Control Panel. I put this user in my "apache" > group like this: > net localgroup apache Daemon /add > The tricky part was assigning the following permissions to the "Daemon" > user: > * Log on as a service > * Act as part of the operating system > I did this in the "Local Security Settings" Control Panel, which can > be found in the "System Administration" Control Panel. It is also possible to > bring it up by running "secpol.msc" from the Start menu. > Finally, I configured Apache to run as user "Daemon" in the "Services" > control > panel (services.msc). Your main problem is that you are trying to break into native Windows ACL system with Cygwin tools. And not only that, you also trying to wrest native ACLs into POSIX permissions, and expect native applications to work fine afterward. Which can be done theoretically, but in reality is a real big headache to maintain. If you truly want to show your students their Windows systems from the command line, I suggest you learn Windows command line. If not very robust, it is nonetheless rich, and allow for many operations normally performed from GUI, and some operations, that can not be done from GUI, either without much complication or at all. In the case mentioned below, the "net" tool should come in handy. As well as "sc" tool. Or, if you really want to use Cygwin tools to work along with Windows tools, use noacl mount option and let Windows care about control rights and stuff. Bottom line is: Either stick to Cygwin and leave Windows alone, or play by Windows rules. Also, forcing someone to use vi over more sane editors is a torture which no one deserve. -- WBR, Andrey Repin (anrdae...@yandex.ru) 03.11.2013, <02:17> 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: vi stealing SYSTEM-owned permissions and ownership
"Brian S. Wilson" wrote: > > > I'm a Linux teacher at a school for vocational education in the > Netherlands. > > I use Cyqwin to help my students overcome their fear of the command line > by showing them their Windows systems through the eyes of Linux. > ... > > After a chgrp and chmod on the entire Apache folder, the "conf" directory > looks like this: > > > > drwxrwx---+ 1 SYSTEM apache 0 28 okt 20:43 . > > drwxrwx---+ 1 SYSTEM apache 0 2 nov 13:10 .. > > -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf > > -rwxrwx---+ 1 SYSTEM apache 34770 7 okt 23:29 httpd.default.conf > > -rwxrwx---+ 1 SYSTEM apache 13340 3 okt 07:59 magic > > -rwxrwx---+ 1 SYSTEM apache 13340 21 nov 2004 magic.default > > -rwxrwx---+ 1 SYSTEM apache 54599 3 okt 07:59 mime.types > > -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt 2012 mime.types.default > > -rwxrwx---+ 1 SYSTEM apache 9390 5 feb 2013 openssl.cnf > > -rwxrwx---+ 1 SYSTEM apache 11050 3 okt 07:59 ssl.conf > > -rwxrwx---+ 1 SYSTEM apache 11030 7 okt 23:29 ssl.default.conf > > > >My students can now administer Apache without running Cygwin "As > administrator". > > Your statement may not be quite accurate. The Cygwin Apache instance > appears to be running as the "SYSTEM" user since that is the file owner, but > your students can administer the files because they are members of the > "apache" group. I can't really tell which user id is running your Apache > process because I don't know how you are actually starting the Apache > process. Most production Apache instances do not run as the "root" user > since this is a security risk. > > If my guess about the Apache process owner is correct, please make your > students aware that if someone hacks their Cygwin Apache servers, the hacker > may gain the same user access rights as the user id actually running the > Apache process. The Apache process owner would normally be a unique user > account with no login or access privileges to protect the server from > successful attacks (just because your Apache files are owned by "SYSTEM", > Apache could be started under another, less privileged, user id for better > protection; but it is common practice to have the file owner also be the > user id that normally executes the file). It is common to see a "nobody" > user as the owner of Apache in production systems. > > I've spent some time over several years trying to figure out how to get > Apache working as a "nobody" user under Cygwin. I've never succeeded in > getting it to work properly, and my comments to this board have not yielded > an answered. I don't think it is possible to make Apache work this way > under Cygwin, but your students should be made aware of this difference. > > If anyone is aware of how to get Apache working using a restricted "nobody" > user id under Cygwin, please respond (or start a new thread). Your concern is very real, I thought about that also. First, in my student-setup, Apache is not running under Cygwin. I used the .msi distribution, available on the Apache website. This installs Apache as a native Windows Service, and it can be configured using the Windows Services Control Panel. As to running as the SYSTEM user, I agree with you. In Linux, Apache is started by root, and then immediately switches to the "nobody" user, so it is unable to touch or even see the outside of its ServerRoot. In Windows, this mechanism does not work. That is why the "User" and "Group" directives are left out of the httpd.conf file in the Windows distribution. I now have Apache running under the username "Daemon" which I created using the standard Windows "Users" Control Panel. I put this user in my "apache" group like this: net localgroup apache Daemon /add The tricky part was assigning the following permissions to the "Daemon" user: * Log on as a service * Act as part of the operating system I did this in the "Local Security Settings" Control Panel, which can be found in the "System Administration" Control Panel. It is also possible to bring it up by running "secpol.msc" from the Start menu. Finally, I configured Apache to run as user "Daemon" in the "Services" control panel (services.msc). Daniel -- 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 about a 64-bit installer that doesn't require UAC?
Yes, I could try to change the application manifest myself, but that seems esoteric and I haven't been able to find any GPL tool. See http://stackoverflow.com/questions/741726/diagnosing-windows-application-manifests, for example. Same for the solutions noted here http://superuser.com/questions/24631/prevent-elevation-uac-for-an-application-that-doesnt-need-it. From the application manifest of setup-x86_64.exe: uiAccess="false" /> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin64: Rebase problems
On 02/11/2013 11:06, David Stacey wrote: I'm trying to reinstall 64-bit Cygwin, using a snapshot taken on 2013-10-24. The post-install step goes into an infinite loop whilst running 'texlive-collection-basic.sh': perl is attempting to load some modules (IO.dll, MD5.dll, Fcnt.dll, Cwd.dll), which fail with rebase errors. The script waits five seconds before trying (and failing) again; this repeats ad infinitum. Here is an extract from the setup log: 0 [main] perl 3384 child_info_fork::abort: address space needed by 'IO.dll' (0x30) is already occupied Can't fork, trying again in 5 seconds at /usr/bin/updmap line 54. 0 [main] perl 3404 child_info_fork::abort: unable to remap MD5.dll to same address as parent (0x2E) - try running rebaseall Can't fork, trying again in 5 seconds at /usr/bin/updmap line 54. 0 [main] perl 3452 child_info_fork::abort: address space needed by 'IO.dll' (0x30) is already occupied Can't fork, trying again in 5 seconds at /usr/bin/updmap line 54. 0 [main] perl 3456 child_info_fork::abort: address space needed by 'IO.dll' (0x30) is already occupied Can't fork, trying again in 5 seconds at /usr/bin/updmap line 54. 0 [main] perl 3408 child_info_fork::abort: unable to remap Fcntl.dll to same address as parent (0x2F) - try running rebaseall Can't fork, trying again in 5 seconds at /usr/bin/updmap line 54. The error message suggests running rebaseall - however, 'autorebase.bat' was run a few seconds earlier. I launched bash (from 'cmd') and ran 'rebase -si' and the results are attached. There are two things to note. Firstly, a great many entries have a base address of zero(!). Secondly, the last six entries in the file have a rather large base address - I would expect the addresses to start around 0x4 and decrease. If I delete '/etc/rebase.db.x86_64' and run 'rebaseall -p -v' then everything seems to work OK - running 'rebase -si' gives sensible output, and the 'texlive-collection-basic.sh' post-install script runs. Neither 'rebase' nor 'dash' have changed since my last successful install - but 'setup-x86_64.exe' has changed. Clutching firmly to this straw, I tried version 2.819 - and this behaved in exactly the same way to version 2.830. Still, when you have eliminated the impossible... 'rebase' depends on 'grep', which /has/ changed recently. However, if 'grep' was playing up then this list would be awash with complaints from confused users. No - it can't be that. My next step is to work backwards, starting with my snapshot and plodding backwards in time until I find the cause. Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: subversion-1.8.4-1
NEWS: = See CHANGES (URL below) for more information about the differences between 1.8.0 and previous Subversion releases. IMPORTANT: Please read the release notes (URL below) before upgrading from a previous major release. 1.8 includes a new working copy format with a manual upgrade operation. This will render your working copy unusable with previous major releases. Furthermore, there are some issues trying to upgrade corrupt working copies. Please see the release notes http://subversion.apache.org/docs/release-notes/1.8.html for more details about the changes in Subversion. See http://svn.apache.org/repos/asf/subversion/tags/1.8.4/CHANGES for more details about the changes in 1.8.4. This release changes mod_dav_svn to no longer map requests to the local filesystem. Administrators of mod_dav_svn servers should read the section about this in the release notes: http://subversion.apache.org/docs/release-notes/1.8.html#mod_dav_svn-fsmap DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/nightly/en/index.html for the latest official release of the Subversion Book. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-YOU=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org Antonym, n.: The opposite of the word you're trying to think of. -- 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 Make 4.0.1 ??? infinite loop on startup
On Sat, Nov 02, 2013 at 12:42:28PM -0400, Rolf Campbell wrote: >On 2013-11-02 12:36, Rolf Campbell wrote: >> On 2013-10-27 14:51, Christopher Faylor wrote: >>> I downloaded the source code for the above and ran into the problem >>> pretty quickly. make was allocating an ever-increasing amount of memory >>> due to a problem with the processing of eight bit characters with the >>> high-bit set. That caused the character to be interpreted as negative >>> and that caused negative indexing off an array. >>> >>> The upcoming make-4.0-2 release should fix this problem. >> >> Was this a problem with the upstream source? Or just a problem with the >> cygwin build of it? >Nevermind, just looked it up myself. I actually pointed to the upstream bug in the announcement. 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: vi stealing SYSTEM-owned permissions and ownership
Greetings, Brian S. Wilson! >> I'm a Linux teacher at a school for vocational education in the Netherlands. >> I use Cyqwin to help my students overcome their fear of the command line by >> showing them their Windows systems through the eyes of Linux. > ... >> After a chgrp and chmod on the entire Apache folder, the "conf" directory >> looks like this: >> >> drwxrwx---+ 1 SYSTEM apache 0 28 okt 20:43 . >> drwxrwx---+ 1 SYSTEM apache 0 2 nov 13:10 .. >> -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf >> -rwxrwx---+ 1 SYSTEM apache 34770 7 okt 23:29 httpd.default.conf >> -rwxrwx---+ 1 SYSTEM apache 13340 3 okt 07:59 magic >> -rwxrwx---+ 1 SYSTEM apache 13340 21 nov 2004 magic.default >> -rwxrwx---+ 1 SYSTEM apache 54599 3 okt 07:59 mime.types >> -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt 2012 mime.types.default >> -rwxrwx---+ 1 SYSTEM apache 9390 5 feb 2013 openssl.cnf >> -rwxrwx---+ 1 SYSTEM apache 11050 3 okt 07:59 ssl.conf >> -rwxrwx---+ 1 SYSTEM apache 11030 7 okt 23:29 ssl.default.conf >> >>My students can now administer Apache without running Cygwin "As > administrator". > Your statement may not be quite accurate. The Cygwin Apache instance > appears to be running as the "SYSTEM" user since that is the file owner, but > your students can administer the files because they are members of the > "apache" group. I can't really tell which user id is running your Apache > process because I don't know how you are actually starting the Apache > process. Most production Apache instances do not run as the "root" user > since this is a security risk. > If my guess about the Apache process owner is correct, please make your > students aware that if someone hacks their Cygwin Apache servers, the hacker > may gain the same user access rights as the user id actually running the > Apache process. The Apache process owner would normally be a unique user > account with no login or access privileges to protect the server from > successful attacks (just because your Apache files are owned by "SYSTEM", > Apache could be started under another, less privileged, user id for better > protection; but it is common practice to have the file owner also be the > user id that normally executes the file). It is common to see a "nobody" > user as the owner of Apache in production systems. > I've spent some time over several years trying to figure out how to get > Apache working as a "nobody" user under Cygwin. I've never succeeded in > getting it to work properly, and my comments to this board have not yielded > an answered. I don't think it is possible to make Apache work this way > under Cygwin, but your students should be made aware of this difference. > If anyone is aware of how to get Apache working using a restricted "nobody" > user id under Cygwin, please respond (or start a new thread). I can't imagine alot of reasons to not use native Windows Apache server, which is much better adapted for running in Windows security environment. -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.11.2013, <21:44> 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: rename (util-linux 2.21.2)
Greetings, Mariusz WODZICKI! > No, I wasn't using Windows ``ren'' command. Under Windows I was using > Cygwin's ``rename'' for as long as I can remember (my primary > experience is in Unix/Linux territory). "ren" is a short version of a command, which full name is "rename". -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.11.2013, <21: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: GNU Make 4.0.1 ??? infinite loop on startup
On 2013-11-02 12:36, Rolf Campbell wrote: On 2013-10-27 14:51, Christopher Faylor wrote: I downloaded the source code for the above and ran into the problem pretty quickly. make was allocating an ever-increasing amount of memory due to a problem with the processing of eight bit characters with the high-bit set. That caused the character to be interpreted as negative and that caused negative indexing off an array. The upcoming make-4.0-2 release should fix this problem. Was this a problem with the upstream source? Or just a problem with the cygwin build of it? Nevermind, just looked it up myself. -- 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 Make 4.0.1 ??? infinite loop on startup
On 2013-10-27 14:51, Christopher Faylor wrote: I downloaded the source code for the above and ran into the problem pretty quickly. make was allocating an ever-increasing amount of memory due to a problem with the processing of eight bit characters with the high-bit set. That caused the character to be interpreted as negative and that caused negative indexing off an array. The upcoming make-4.0-2 release should fix this problem. Was this a problem with the upstream source? Or just a problem with the cygwin build of it? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: vi stealing SYSTEM-owned permissions and ownership
> I'm a Linux teacher at a school for vocational education in the Netherlands. > I use Cyqwin to help my students overcome their fear of the command line by showing them their Windows systems through the eyes of Linux. ... > After a chgrp and chmod on the entire Apache folder, the "conf" directory looks like this: > > drwxrwx---+ 1 SYSTEM apache 0 28 okt 20:43 . > drwxrwx---+ 1 SYSTEM apache 0 2 nov 13:10 .. > -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf > -rwxrwx---+ 1 SYSTEM apache 34770 7 okt 23:29 httpd.default.conf > -rwxrwx---+ 1 SYSTEM apache 13340 3 okt 07:59 magic > -rwxrwx---+ 1 SYSTEM apache 13340 21 nov 2004 magic.default > -rwxrwx---+ 1 SYSTEM apache 54599 3 okt 07:59 mime.types > -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt 2012 mime.types.default > -rwxrwx---+ 1 SYSTEM apache 9390 5 feb 2013 openssl.cnf > -rwxrwx---+ 1 SYSTEM apache 11050 3 okt 07:59 ssl.conf > -rwxrwx---+ 1 SYSTEM apache 11030 7 okt 23:29 ssl.default.conf > >My students can now administer Apache without running Cygwin "As administrator". Your statement may not be quite accurate. The Cygwin Apache instance appears to be running as the "SYSTEM" user since that is the file owner, but your students can administer the files because they are members of the "apache" group. I can't really tell which user id is running your Apache process because I don't know how you are actually starting the Apache process. Most production Apache instances do not run as the "root" user since this is a security risk. If my guess about the Apache process owner is correct, please make your students aware that if someone hacks their Cygwin Apache servers, the hacker may gain the same user access rights as the user id actually running the Apache process. The Apache process owner would normally be a unique user account with no login or access privileges to protect the server from successful attacks (just because your Apache files are owned by "SYSTEM", Apache could be started under another, less privileged, user id for better protection; but it is common practice to have the file owner also be the user id that normally executes the file). It is common to see a "nobody" user as the owner of Apache in production systems. I've spent some time over several years trying to figure out how to get Apache working as a "nobody" user under Cygwin. I've never succeeded in getting it to work properly, and my comments to this board have not yielded an answered. I don't think it is possible to make Apache work this way under Cygwin, but your students should be made aware of this difference. If anyone is aware of how to get Apache working using a restricted "nobody" user id under Cygwin, please respond (or start a new thread). -- 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
vi stealing SYSTEM-owned permissions and ownership
Hi group, I'm a Linux teacher at a school for vocational education in the Netherlands. I use Cyqwin to help my students overcome their fear of the command line by showing them their Windows systems through the eyes of Linux. I had them install Apache and then configure it in Cygwin using vi. As of Windows 8, the Apache installation sometimes fails, because of permission issues. Installing "As administrator" solves the problem. This is fine with me because in other Linuxes, Apache is installed as root by default. After installation, permissions in the Apache "conf" directory look like this: drwx--+ 1 SYSTEM SYSTEM 0 28 okt 20:43 . drwx--+ 1 SYSTEM SYSTEM 0 2 nov 13:10 .. -rwx--+ 1 SYSTEM SYSTEM 35142 26 okt 18:07 httpd.conf -rwx--+ 1 SYSTEM SYSTEM 34770 7 okt 23:29 httpd.default.conf -rwx--+ 1 SYSTEM SYSTEM 13340 3 okt 07:59 magic -rwx--+ 1 SYSTEM SYSTEM 13340 21 nov 2004 magic.default -rwx--+ 1 SYSTEM SYSTEM 54599 3 okt 07:59 mime.types -rwx--+ 1 SYSTEM SYSTEM 54599 17 mrt 2012 mime.types.default -rwx--+ 1 SYSTEM SYSTEM 9390 5 feb 2013 openssl.cnf -rwx--+ 1 SYSTEM SYSTEM 11050 3 okt 07:59 ssl.conf -rwx--+ 1 SYSTEM SYSTEM 11030 7 okt 23:29 ssl.default.conf To emulate the Unix permissions model, I had my students add a group in Windows, named "apache", making themselves a member and then import it using the mkgroup command. After a chgrp and chmod on the entire Apache folder, the "conf" directory looks like this: drwxrwx---+ 1 SYSTEM apache 0 28 okt 20:43 . drwxrwx---+ 1 SYSTEM apache 0 2 nov 13:10 .. -rwxrwx---+ 1 SYSTEM apache 35142 26 okt 18:07 httpd.conf -rwxrwx---+ 1 SYSTEM apache 34770 7 okt 23:29 httpd.default.conf -rwxrwx---+ 1 SYSTEM apache 13340 3 okt 07:59 magic -rwxrwx---+ 1 SYSTEM apache 13340 21 nov 2004 magic.default -rwxrwx---+ 1 SYSTEM apache 54599 3 okt 07:59 mime.types -rwxrwx---+ 1 SYSTEM apache 54599 17 mrt 2012 mime.types.default -rwxrwx---+ 1 SYSTEM apache 9390 5 feb 2013 openssl.cnf -rwxrwx---+ 1 SYSTEM apache 11050 3 okt 07:59 ssl.conf -rwxrwx---+ 1 SYSTEM apache 11030 7 okt 23:29 ssl.default.conf My students can now administer Apache without running Cygwin "As administrator". Also, this is extremely useful in real-time business situations. It enables my students to grant Apache admin permissions to other users by putting them in the apache group, without giving them full admin access on the entire system. But here's the problem. After editing the httpd.conf file with vi, the permissions on the "httpd.conf" file are changed to: --+ 1 Daniel None 35142 2 nov 13:20 httpd.conf This should not be. I tested this on my RedHat and OpenBSD systems, and there are no changes in ownership or permissions after editing with vi. After fiddling with chown, chgrp, chmod, getfacl, setfacl and icacl for a few hours, I finally installed nano. Nano behaved. It did not alter anything except the contents of the file. But I want my students to learn vi, so having them install nano is not an option. I think the problem is vi. Vi deletes the original file and creates a new one with the changed contents, without resetting the original ownership and permissions. See also this post: http://unix.stackexchange.com/questions/58880/how-does-vim-steal-root-owned-files Can somebody shed some light on this? Meanwhile, I accidentally found sort of a solution: deleting the file without write permissions on the containing folder, restores the permissions set by Administrator. As Administrator: chmod 0700 . touch test.txt chown SYSTEM:apache test.txt chmod 0770 test.txt Results in: -rwxrwx---+ 1 SYSTEM apache 0 2 nov 13:26 test.txt As "normal" user: Edit the file with vi. After, permissions will look like: --+ 1 Daniel None 9 2 nov 13:29 test.txt $ getfacl.exe test.txt # file: test.txt # owner: Daniel # group: None user::--- group::--- group:SYSTEM:rwx group:Administrators:rwx group:Gebruikers:r-x group:apache:rwx mask:rwx other:--- To "solve" this, simply delete the file: rm test.txt The file is not deleted because of 0700 on the containing folder. But the original permissions, set by Admin are restored!! -rwxrwx---+ 1 SYSTEM apache 9 2 nov 13:29 test.txt $ getfacl.exe test.txt # file: test.txt # owner: SYSTEM # group: apache user::rwx group::rwx group:Administrators:rwx group:Gebruikers:r-x mask:rwx other:--- -- 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: gcc-4.8.2-1: /bin/gcc fails
On Nov 1 23:23, David Rothenberger wrote: > With gcc-4.8.2-1, the following fails: > > % touch /tmp/t.c > % /bin/gcc -c /tmp/t.c > gcc: error: spawn: No such file or directory > > This works correctly if gcc is invoked as "gcc" or "/usr/bin/gcc". > It also works correctly with 4.8.1. > > It appears this is due to a change from /usr/lib to /usr/libexec. > /bin/gcc attempts to find cc1 under "/bin/../libexec/...". In 4.8.1, > this was "/bin/../lib/...", which works because /lib is mapped to > /usr/lib by Cygwin. /usr/bin/gcc uses "/usr/bin/../libexec" which > also works fine. > > I can work around the problem as follows: > > % ln -s /libexec /usr/libexec Uh oh. That's bad. Maybe it wasn't such a good idea to switch libexecdir from /usr/lib to /usr/libexec? It breaks applications using relative paths to search other application components when run from /bin. Either we revert libexecdir to /usr/lib, or we will need to add an automount point /libexec -> /usr/libexec as for /bin and /lib. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTEWUijTcGU.pgp Description: PGP signature
Re: Couldn't compute FAST_CWD pointer on Win8.1 x64
On Oct 31 22:17, Alfred Theorin wrote: > I get the following error when I start cygwin (32-bit version 1.7.25) > on Win8.1 x64: > > 0 [main] bash find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. First of all, I tested this already under the 8.1 preview and added code to Cygwin to support the changes in the i686 and x86_64 code prior to the 1.7.25 release. Second, I checked if it still works on 8.1 RTM on i686 as well as on x64 natively and under WOW64, and none printed the above message. Third, I just debugged the Cygwin code step-by-step under WOW64. The OS still uses the same method as in the 8.1 preview so the code is still working as expected, as far as I can see. Are you *sure* you're running Cygwin 1.7.25 and not an older version? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTvb3CgfID6.pgp Description: PGP signature
Re: rename (util-linux 2.21.2)
Mariusz WODZICKI writes: > I frequently use ``rename''. Today I discovered that the most current > version has a changed syntax: Exactly why do you think it changed syntax? Looking at some old and new Linux manpages and the Git repository, it appears that the only thing that changed was the monikers for the parameters plus added documentation for the switches (that had been existing before already: expression <=> from replacement <=> to file<=> file http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=03b3d715ded40c44c074300b704be430aafbc1ae Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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: rename (util-linux 2.21.2)
No, I wasn't using Windows ``ren'' command. Under Windows I was using Cygwin's ``rename'' for as long as I can remember (my primary experience is in Unix/Linux territory). Mariusz Wodzicki -- 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