We need to back up a bit. I tried something different just for giggles because I thought we might be on the wrong track with setuid. I wrote a little script that this
#!/bin/bash /usr/opt/httpd-2.0.49/bin/httpd -d t -f conf/httpd.conf -DAPACHE2 -DONE_PROCESS -DNO_DETATCH > stdout 2>&1 & tusc -p -f -v -o strace $! after running the script I went to a browser and hit http://cars-l:8529/TestAPI__request_rec The strace looks quite different this way (and the process does not exit). Turns out the setuid thing was the falt of my tusc command being setuid. (Sorry. insert sheepish look here) Trace from this latest test is more what I expected to see: [5889] writev(72, 0x6fff1940, 3) .................................................................... = 40 iov_base[0]: 0x6fff1838 iov_len[0]: 4 iov_base[1]: 0x40cfeebc iov_len[1]: 34 iov_base[2]: 0x7fb78 iov_len[2]: 2 [5889] writev(72, 0x6fff1940, 3) .................................................................... = 40 iov_base[0]: 0x6fff1838 iov_len[0]: 4 iov_base[1]: 0x40cfeebc iov_len[1]: 34 iov_base[2]: 0x7fb78 iov_len[2]: 2 [5889] writev(72, 0x6fff1940, 3) .................................................................... = 11 iov_base[0]: 0x6fff1838 iov_len[0]: 3 iov_base[1]: 0x40cfeebc iov_len[1]: 6 iov_base[2]: 0x7fb78 iov_len[2]: 2 [5889] stat64("/opt/local/wrfopt/build/mod_perl-1.99_14/t/response/TestAPI/request_rec.pm", 0x6ff66648) = 0 st_dev: 64 0x000005 st_ino: 171526 st_mode: S_IFREG|0644 st_nlink: 1 st_rdev: 0 st_size: 2503 st_blksize: 8192 st_blocks: 1 st_uid: 1073741829 st_gid: 27549760 st_atime: Tue Aug 10 16:50:28 2004 st_mtime: Fri Apr 18 02:18:58 2003 st_ctime: Mon Aug 9 20:40:52 2004 [5889] In user-mode ................................................................................. [running] Hangs at this point. The compile with no LFS: [14273] writev(72, 0x6fff1940, 3) .............................................. ..................... = 11 iov_base[0]: 0x6fff1838 iov_len[0]: 3 iov_base[1]: 0x4105eb74 iov_len[1]: 6 iov_base[2]: 0x7fb78 iov_len[2]: 2 [14273] stat("/opt/local/wrfopt/build/mod_perl-1.99_14/t/response/TestAPI/reques t_rec.pm", 0x6ff665f0) = 0 st_dev: 64 0x000005 st_ino: 172780 st_mode: S_IFREG|0644 st_nlink: 1 st_rdev: 0 st_size: 2503 st_blksize: 8192 st_blocks: 8 st_uid: 1062 st_gid: 1062 st_atime: Tue Aug 10 17:11:49 2004 st_mtime: Fri Apr 18 02:18:58 2003 st_ctime: Mon Aug 9 20:40:25 2004 [14273] writev(72, 0x6fff1940, 3) .............................................. ..................... = 11 iov_base[0]: 0x6fff1838 iov_len[0]: 3 iov_base[1]: 0x4105eb74 iov_len[1]: 6 iov_base[2]: 0x7fb78 iov_len[2]: 2 Blows right by the call to stat no problem. Get output in the browser say Ok to all 42 tests. The only notable difference being the call to stat as opposed to stat64. --- Will Fulmer Database Administrator Northampton Community College Bethlehem, PA >>> "William Fulmer" <[EMAIL PROTECTED]> 8/10/2004 9:33:50 AM >>> I have a non root user that I use for all of my software builds (called build strangely enough). All elements (apache, perl, mod_perl) were built as this user. I just tried building as root as the email suggested. It would not run apache as root, but tried to use nobody(which did not work no matter how wide I ripped the permissions). I forced it to run as the user that my webserver nomrally runs as by setting APACHE_TEST_USER and APACHE_TEST_GROUP. Then the test hangs as before. I never got this message: waiting for server to start: .No -M allowed while running setuid. perl_parse: Address family not supported by protocol !!! The server always started successfully. My perl is not configure to emulate setuid/setgid either. Does perl 5.6 handle the setuid differently then 5.8? Also, I'm confuse, does -M bypass the setuid code while stat get's caught? Shouldn't they both hang during make test? My perl.c code looks like this: STATIC void S_forbid_setid(pTHX_ char *s) { if (PL_euid != PL_uid) Perl_croak(aTHX_ "No %s allowed while running setuid", s); if (PL_egid != PL_gid) Perl_croak(aTHX_ "No %s allowed while running setgid", s); } So I changed it to never croak just for some smiles: STATIC void S_forbid_setid(pTHX_ char *s) { if (1 != 1) Perl_croak(aTHX_ "No %s allowed while running setuid", s); if (1 != 1) Perl_croak(aTHX_ "No %s allowed while running setgid", s); } and make test still hangs. --- Will Fulmer Database Administrator Northampton Community College Bethlehem, PA >>> Stas Bekman <[EMAIL PROTECTED]> 8/9/2004 2:05:48 PM >>> William Fulmer wrote: > Apologies. You are correct. I never responded directly to this email. > > my $file = "/tmp"; > my $mtime = (stat $file)[9]; > > and: > > my $file = __FILE__; > my $mtime = (stat $file)[9]; > > both fail (meaning the test hangs) > > -M __FILE__; > > and > > -M "/tmp"; > > both work (which is to say that the test does not hang, but the test > fails because stat returns number of seconds since the epoch and -M > returns the number of days since last modification). Right, but I think both perform stat(). I went back to your strace message, which had: write(2, "N o - M a l l o w e d w h ".., 36) ................................. = 36 with some googling I've found: http://marc.theaimsgroup.com/?l=apache-modperl&m=104941790431878&w=2 which is talking about: "waiting for server to start: .No -M allowed while running setuid. perl_parse: Address family not supported by protocol !!! server has died with status 1 (please examine t/logs/error_log) make: *** [run_tests] Error 143 " Could that be your issue? Do you have setuid involved in your setup? If you build mod_perl as root as Richard mentioned in the above URL, do you get any difference? the error is coming from perl.c: STATIC void S_forbid_setid(pTHX_ char *s) { #ifdef SETUID_SCRIPTS_ARE_SECURE_NOW if (PL_euid != PL_uid) Perl_croak(aTHX_ "No %s allowed while running setuid", s); if (PL_egid != PL_gid) Perl_croak(aTHX_ "No %s allowed while running setgid", s); #endif /* SETUID_SCRIPTS_ARE_SECURE_NOW */ /* PSz 29 Feb 04 * Checks for UID/GID above "wrong": why disallow * perl -e 'print "Hello\n"' * from within setuid things?? Simply drop them: replaced by * fdscript/suidscript and #ifdef IAMSUID checks below. * * This may be too late for command-line switches. Will catch those on * the #! line, after finding the script name and setting up * fdscript/suidscript. Note that suidperl does not get around to * parsing (and checking) the switches on the #! line, but checks that * the two sets are identical. * * With SETUID_SCRIPTS_ARE_SECURE_NOW, could we use fdscript, also or * instead, or would that be "too late"? (We never have suidscript, can * we be sure to have fdscript?) * * Catch things with suidscript (in descendant of suidperl), even with * right UID/GID. Was already checked in suidperl, with #ifdef IAMSUID, * below; but I am paranoid. * * Also see comments about root running a setuid script, elsewhere. */ > Apache, perl and mod_perl where all compiled with HP's ANSI C compiler. > The compiler is now with the latest version and patch level. Also, > will point out that this is now under HP-UX 11i (11.11) was formerly > HP-UX 11.00. Not sure this matters since the symptom's of the problem > remain unchanged. When I first reported the problem I was on the eve of > upgrading the OS on the server I've been trying to get this working on. That's good. -- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
