A little addon
part of the script (phpfm) doing it ..
-----------------------------------------------
if (!isset($dir_atual)){
$dir_atual = $path_info["dirname"]."/";
if (!$islinux) $dir_atual = ucfirst($dir_atual);
@chmod($dir_atual,0777);
} else $dir_atual = formatpath($dir_atual);
$is_reachable = (stristr($dir_atual,$doc_root)!==false);
-------------------------------------------------
Question is .. Why does the system allow it ??
FC wrote:
Well It is definatly not a HOAX I re-installed a fc3 box to make sure all was clean updated to the latest packages .. Then I recompiled apr-0.9.6-3.src.rpm & apr-util-0.9.6-2.src.rpm (Why ? coz the 0.9.4 is known to have bugs , check apache forums http://lists.marsching.biz/pipermail/suphp/2004-December/000594.html) by simply rebuilding the rpms : rpmbuild -ba ./SPECS/arp.spec rpmbuild -ba ./SPECS/arp-util.spec Then I installed them (no complain on dependencies or anything) Launched that phpfm and boom rights changed on the dir back to 777 So ... you tell me :) that's definatly not a normal behaviour Now where it gets really fishy,on FC3 box1 with a recompiled apache (with a newer apr) either suphp or mod_php break change the dir rights on FC3 box2 with just a new apr installed only suphp breaks the dir rights not mod_phpAny1 can explain this :)I have an explanation .. IF the dir is owned by the same user the phpfm is owned it WILL change the dir rightsexample : mod_php /var/www/html/ owned by root:root /var/www/html/phpfm.php owned by apache.apache nothing changes then /var/www/html/ owned by apache:apache BOOM -> 777 on the dir ... That's a major security flaw . Guess What on FC4 it is does exactly the same with the supplied packages, no special compilation, just out of the box simply try this : copy phpfm to /var/www/html chown apache.apache /var/www/html/phpfm.php chown apache.apache /var/www/html either run it through your httpd or simply by php -q /var/www/html/phpfm.php and look at the nice surprise :)Maybe it is a combination of diff packages installed .. I could reproduce it on 2/3 FC3 box and 1/2 FC4 boxfedora wrote:Some updates I recompiled the FC4 httpd version 2.0.54-10 Same behaviour, really fishy this ..*** glibc detected *** double free or corruption (fasttop): 0x08f33598 ***I suspect apr, gonna recompiel that and retry ...But I am surprised nobody can reproduce that, coz this fc3 box is pretty standard packages installationStay tuned :) Fedora Mailing List wrote:Alexander Dalloz wrote:Am Mo, den 04.07.2005 schrieb Fedora Mailing List um 16:06:The Scenario : get this php filemanager : http://phpfm.sourceforge.net/#downloads simply unzip into your web site directory I have vhosts under a /data dir rights 711 on the vhost dir, all fine drwx--x--x 19 john data 4096 Jun 24 15:35 www.test.com after calling the php file manager http://site.name/index.php the rights on the directory are made world writeable drwxrwxrwx 13 john data 4096 Jul 4 15:39 www.test.com SCARY ---The problem is phpfm then.apache error.log:[Mon Jul 04 15:43:44 2005] [error] [client x.x.x.x] Premature end of script headers: index.php, referer: http://www.test.com/index.php [Mon Jul 04 15:43:44 2005] [error] [client x.x.x.x] SoftException in Application.cpp:227: Directory "/data/www.test.com" is writeable by group, referer: http://www.test.com/index.php [Mon Jul 04 15:43:44 2005] [error] [client x.x.x.x] *** glibc detected *** double free or corruption (fasttop): 0x099c6590 ***, referer: http://www.test.com/index.php [Mon Jul 04 15:43:44 2005] [error] [client x.x.x.x] File does not exist: /data/www.test.com/favicon.ico [Mon Jul 04 15:44:09 2005] [error] [client x.x.x.x] File does not exist: /data/www.test.com/favicon.ico [Mon Jul 04 15:44:19 2005] [error] [client x.x.x.x] Premature end of script headers: index.php, referer: http://www.test.com/index.php [Mon Jul 04 15:44:19 2005] [error] [client x.x.x.x] SoftException in Application.cpp:227: Directory "/data/www.test.com" is writeable by group, referer: http://www.test.com/index.php [Mon Jul 04 15:44:19 2005] [error] [client x.x.x.x] *** glibc detected *** double free or corruption (fasttop): 0x08e16590 ***, referer: http://www.test.com/index.phpSwitching between suphp and mod_php didtn change anything .. the rights on the dir are changed no matter (the error above are with suphp enabled, with mod_php I didnt get any error but the same result)I have doubts that Apache (user apache) is able to change filesystempermissions when it does not own a directory and no extension like suphpis configured or suExec is set.On FC4 the problem didnt occur ------------ System Fedora Core 3 - No Selinux httpd -V Server version: Apache/2.0.54That is no FC3 Apache! $ rpm -q httpd httpd-2.0.52-3.1 $ httpd -v Server version: Apache/2.0.52 Server built: Nov 11 2004 10:31:42Server built: Apr 18 2005 21:03:32 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/etc/httpd" -D SUEXEC_BIN="/usr/sbin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log"I didnt trace and debug the thing yet, pretty in a hurry right now, to find out what may have caused it ... if any1 heared about it .. ?I would say phpfm is broken or misconfigured. I miss the proof that aplain FC3 Apache2 with only mod_php - no suPHP, nor running suExec withPHP cgi scripts - is able to change filesystem permissions for directories / files the apache user does not own. AlexanderYes it has been rebuilt using httpd-2.0.54-3.src.rpm from a fedora mirror and rebuilt with rpmbuild -ba SPECS/httpd.specBut the rest are geniun updated fc3 packages .. so something is actually doing thatI will dig into it, just running out of time today :) Cheers -P
