[PHP-DEV] Re: Any idea why we have two html_puts()'s?
The zend-equivalent is painfully slow. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: kai
I need access to phpdoc CVS repository for help with translating PHP manual into Russian. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
Hmm, then it could be fixed, but we shouldn't introduce a new implementation. Assuming you refer to the large number of output calls, they can be saved using output buffering - implementing localized buffering in every place is not a good way to go by. I'm not sure output buffering was already there when php_html_puts() was introduced, though :) Zeev At 15:42 12/05/2002, Sascha Schumann wrote: The zend-equivalent is painfully slow. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
On May 11, 2002 06:56 pm, Chand wrote: The solution we've chosen is to have a cgi php binary instead of a module for security stuff. The main reason to do so was to have the user-created file have the user's uid. We had to suid the php binary and setuid() the process to the script's uid, of course. This seemed like a good security trouble-keeper (I know some people will say that setuid scripts and security in the same sentence usually ain't a good mix'n'match but .. :) ) since this let the filesystem take care of file permissions which seemed to me the most secure way, Ain't it ? Maybe the Open_basedir solution is a better one although i like the idea of files really owned by the user and not only virtually. The drawback on the cgi php binary is performance. We have lotsa trouble with php cgi binary not dying after the max_execution_time and stayin' alive on the machines. So we have to terminate them frequently. This has been reported I think a while back and said to be solved but looks like we have an environment that's unique in terms of number of requests per second and load averages, and that not a lot of people can use to test. So people might have the dead binaries sleeping around bug solved, but we don't. As far as security is concerned this is probably the best approach, IMHO. Because by running PHP as this user you can use various OS kernel tools such as LIDS or GrSecurity to set limits of what each user can do and how many resources they can consume. Ilia, the scripts you talk about that eat up process, cpu, file pointers etc are very interesting, we've already gone against most of them except for the file handlers Attack. Never had that but I think i'm gonna talk about this with our NOC team cause it could be a very big issue now that's it's in the open :) There are other ways to cause problems with PHP, we could probably go on for days documenting each way someone could use PHP to cause a problem on a server. Here is yet another example: ?php sleep(time()); ? of ?php while(1) usleep(time()); ? Now the script will sleep indefinately ignoring the set_time_limit parameter. This webserver thread is now in sleep mode for virtually forever, by repeatedly accessing such a script and attacker can prevent the webserver from serving actual web pages since all threads will be asleep. But this is the nature of any programming/scripting language it allows you do can do things with it :P The ultimate bottom line is that if you do not trust your users to use the tools they are given appropriately then you shouldn't put those tools in their hands. Seriously, i've been surprised as to how low was the number of people trying to hack our system thru PHP. I was really afraid it would far worse, but this might not be the case everywhere, and we still have to be vigilant about all that security stuff. I too think that safe_mode is not a good thing and that open_basedir seems better and more secure. I'm willing to help on a PHP-ISP-Howto document even though but since i've never done such a thing, i'm not sure i can really do something good, Plus we might not have taken the best way of doing things around here. If anybody has comments and or solutions, I'm interested. Later Chand -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mime help!
ok i have that a script that is supposed to decode base64, the thing that it's decoding is a email, html encoded. For some od reason it just puts the message into funny characters. Does anyone know where I could get a tutorial maybe on this subject if nobody wanted to help me. All help is appreciated -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
On Sun, 12 May 2002, Zeev Suraski wrote: Hmm, then it could be fixed, but we shouldn't introduce a new implementation. Assuming you refer to the large number of output calls, they can be saved using output buffering - implementing localized buffering in every place is I've just noticed that you have kicked out the premier implementation of the same functionality in favor of the dog slow old one. Note that relying on output buffering alone is inferior, because (a) it is not always enabled and (b) it does not address the inherent flaws in the zend implementation. I suggest reverting that commit and doing whatever is necessary to improve the zend implementation. This could be achieved by defining a function pointer zend_html_puts with the same parameters as php_html_puts and let applications set that function pointer. The default could continue to point to the current zend_html_puts code. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
At 17:43 12/05/2002, Sascha Schumann wrote: I've just noticed that you have kicked out the premier implementation of the same functionality in favor of the dog slow old one. I almost missed those idyllic descriptions :) Note that relying on output buffering alone is inferior, because (a) it is not always enabled It can be enabled for this purpose alone, if you think it's that much of an issue (I don't, but I don't mind doing that either). and (b) it does not address the inherent flaws in the zend implementation. What inherent flaws? So far, the only difference between them that I could spot was that php_html_puts() was buggy, and did not convert series of spaces into nbsp;'s. Otherwise, the only difference was the use of buffering. I may have missed something, though. I suggest reverting that commit and doing whatever is necessary to improve the zend implementation. This could be achieved by defining a function pointer zend_html_puts with the same parameters as php_html_puts and let applications set that function pointer. The default could continue to point to the current zend_html_puts code. I don't see why it's necessary. If you think buffering phpinfo() is really necessary, then we can enable buffering for it. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
What inherent flaws? So far, the only difference between them that I could spot was that php_html_puts() was buggy, and did not convert series of spaces into nbsp;'s. Otherwise, the only difference was the use of buffering. I may have missed something, though. That is not buggy, although it was not part of the original php_html_puts. IIRC, Jani put it in place to prevent excessivily wide tables in phpinfo(). I would not mind adding an option for that though, if the original behaviour is required for some purpose. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
At 17:58 12/05/2002, Sascha Schumann wrote: What inherent flaws? So far, the only difference between them that I could spot was that php_html_puts() was buggy, and did not convert series of spaces into nbsp;'s. Otherwise, the only difference was the use of buffering. I may have missed something, though. That is not buggy, although it was not part of the original php_html_puts. IIRC, Jani put it in place to prevent excessivily wide tables in phpinfo(). I would not mind adding an option for that though, if the original behaviour is required for some purpose. What I'm pointing out is that there are no 'inherent flaws' in the 'dog slow' implementation that we already had for a couple of years. If you want to add buffering, we can add buffering. There's no point in adding a specialized buffered implementation. The spaces issue is well implemented in the zend implementation (I also fixed it in the php_html_puts() implementation, before I removed it; At some point, it was too much of a deja-vu, which is why I don't like duplicate implementations :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
What I'm pointing out is that there are no 'inherent flaws' in the 'dog slow' implementation that we already had for a couple of years. If you want to add buffering, we can add buffering. There's no point in adding a specialized buffered implementation. Well, php_html_puts has several advantages: - it is buffering as you already noted without having to rely on the huge output-buffering infrastructure. I have not benchmarked it, but I do assume that it is noticably slower than php_html_puts. - it is faster due to passing TSRMLS around, instead of having to fetch it for *every* single examined byte. This is especially significant in threaded environments such as Apache 2 or ISAPI. - it is there and working fully. :-) - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
At 18:24 12/05/2002, Sascha Schumann wrote: - it is buffering as you already noted without having to rely on the huge output-buffering infrastructure. I have not benchmarked it, but I do assume that it is noticably slower than php_html_puts. - it is faster due to passing TSRMLS around, instead of having to fetch it for *every* single examined byte. This is especially significant in threaded environments such as Apache 2 or ISAPI. I'm trying to understand why you care so much about its performance..? There are cases where duplicating code for performance reasons makes sense, but I don't see how this function falls into that category. Either way, enabling output buffering for it should definitely do the trick, even if it's a couple of percent slower than the specialized implementation. Are you using it in some module? Because the only code to currently make use of it is phpinfo(), and it isn't noticeably slow even in the current byte-by-byte method... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
I'd *really* like to avoid having two copies of the same code, though. Please remove the duplicated implementation... Zeev At 18:24 12/05/2002, Sascha Schumann wrote: What I'm pointing out is that there are no 'inherent flaws' in the 'dog slow' implementation that we already had for a couple of years. If you want to add buffering, we can add buffering. There's no point in adding a specialized buffered implementation. Well, php_html_puts has several advantages: - it is buffering as you already noted without having to rely on the huge output-buffering infrastructure. I have not benchmarked it, but I do assume that it is noticably slower than php_html_puts. - it is faster due to passing TSRMLS around, instead of having to fetch it for *every* single examined byte. This is especially significant in threaded environments such as Apache 2 or ISAPI. - it is there and working fully. :-) - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
I favor php_html_puts also due to maintability reasons.
Please consider this part of code from zend_html_puts:
!(((ptr+1)=end) || (*(ptr+1)==' ')) /* next is not a space */
!((ptr==s) || (*(ptr-1)==' '))) /* last is not a space */ {
And contrast it with the inherent beauty of php_html_puts.
I'd *really* like to avoid having two copies of the same code,
though. Please remove the duplicated implementation...
Ok, I'll implement the solution I posted earlier and make
zend_html_puts a function pointer.
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
At 18:34 12/05/2002, Sascha Schumann wrote:
I favor php_html_puts also due to maintability reasons.
Please consider this part of code from zend_html_puts:
!(((ptr+1)=end) || (*(ptr+1)==' ')) /* next is not a space */
!((ptr==s) || (*(ptr-1)==' '))) /* last is not a space */ {
And contrast it with the inherent beauty of php_html_puts.
Ok, so I'll use your method. By the way, there was nothing inherent in the
two places you used 'inherent', on this topic :)
I'd *really* like to avoid having two copies of the same code,
though. Please remove the duplicated implementation...
Ok, I'll implement the solution I posted earlier and make
zend_html_puts a function pointer.
Again, I fail to understand the logic behind it. I'll change the space
handling code to your method (which is indeed nicer); Why on earth would
we need to have a stupid HTML printout function as a function pointer?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
Ok, so I'll use your method. By the way, there was nothing inherent in the two places you used 'inherent', on this topic :) php_html_puts is simple, consistent and easy to follow. These are its essential characteristics, and thus they are inherent. But I digress. Again, I fail to understand the logic behind it. I'll change the space handling code to your method (which is indeed nicer); Why on earth would we need to have a stupid HTML printout function as a function pointer? If you would also address the two performance aspects I mentioned earlier, I would divert from my current stance that php_html_puts should be used further. Oh, wait and there is a third issue I did not think of earlier. Because zend_html_puts does not convert the whole string and calls ZEND_PUTC/_PUTS for each token, not only does that cause a TSRMLS_FETCH for every token, it also adds a jump over an indirect function pointer each time (zend_write). Thousands of such calls can easily add up and introduce a significant and in this case unnecessary overhead. php_html_puts can avoid this, because it knows about PHPWRITE and calls it only once per string, instead of a few dozen times. The last point cannot be easily addressed other than by supporting a redefinition of zend_html_puts by the application. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
At 19:00 12/05/2002, Sascha Schumann wrote: Again, I fail to understand the logic behind it. I'll change the space handling code to your method (which is indeed nicer); Why on earth would we need to have a stupid HTML printout function as a function pointer? If you would also address the two performance aspects I mentioned earlier, I would divert from my current stance that php_html_puts should be used further. No, I believe that if we decide that performance is important enough, we make php_html_puts() be a wrapper around zend_html_puts() that uses output buffering. The performance difference between an output buffering implementation and a specialized buffered implementation will most probably be negligible. You still haven't said why we should even strive to make html_puts() as efficient as possible. Again, the only place it's being used today is phpinfo(), and in all these years, I've yet to hear about a single person that complained about its performance :) Oh, wait and there is a third issue I did not think of earlier. You could find a zillion such places, and it doesn't mean anything. We have an infrastructure for a reason, and it makes sense to work around it only when you have an performance sensitive function, which html_puts() clearly is not. The function pointer dereferences, as well as TSRM fetches, are completely negligible in comparison to the IO performance. A small test I conducted, calling phpinfo(): No buffering: 12 req/s Specialized OB: 36.3 req/s PHP OB (C level, for each separate string): 35.9 req/s PHP OB (userland, for the entire phpinfo()):50 req/s I still don't think that we should care too much about the performance of this function, but if decide that we do, then turning it into a function pointer is not exactly the right thing to do :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: Re: [PHP-DEV] Re: Any idea why we have two html_puts()'s?
I messed up on the test, I left output buffering enabled for tests 2 and 3. So you can see that using output buffering on top of the global output buffering (whether specialized or not) slows you down by about 30%. However, to be fair, the numbers w/o global output buffering enabled: Specialied OB: 26 req/s PHP OB (C level, for each separate string): 23 req/s No buffering: 12 req/s Specialized OB: 36.3 req/s PHP OB (C level, for each separate string): 35.9 req/s PHP OB (userland, for the entire phpinfo()):50 req/s By far, the quickest solution is to use output buffering for the entire page. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring config.m4
Sascha Schumann wrote: WITH is solely for the purpose of pointing to paths and other external entities. Note that the comment has always mentioned --disable-mbstring which clearly refers to enable and not with. Shouldn't '--without-mysql' be renamed to '--disable-mysql' then? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfault in current HEAD
Can't tell how to reproduce this, it occurs when working with Harald's form validation system, which is built on top of PEAR::XML_Transformer: NTDLL! 778cb892() NTDLL! 778cb733() shutdown_memory_manager(int 0, int 0, void * * * 0x00b328d8) line 468 + 60 bytes php_request_shutdown(void * 0x) line 818 + 34 bytes main(int 1, char * * 0x00b324c8) line 1072 + 8 bytes mainCRTStartup() line 338 + 17 bytes -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring config.m4
Hi, On Sun, 12 May 2002 19:33:13 +0200 Sebastian Bergmann [EMAIL PROTECTED] wrote: Shouldn't '--without-mysql' be renamed to '--disable-mysql' then? you want to have --with-mysql=/path/to and --disable-mysql as the two options ? -1 Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault in current HEAD
This trace isn't meaningful... At 20:36 12/05/2002, Sebastian Bergmann wrote: Can't tell how to reproduce this, it occurs when working with Harald's form validation system, which is built on top of PEAR::XML_Transformer: NTDLL! 778cb892() NTDLL! 778cb733() shutdown_memory_manager(int 0, int 0, void * * * 0x00b328d8) line 468 + 60 bytes php_request_shutdown(void * 0x) line 818 + 34 bytes main(int 1, char * * 0x00b324c8) line 1072 + 8 bytes mainCRTStartup() line 338 + 17 bytes -- Sebastian Bergmann http://sebastian-bergmann.de/http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mbstring config.m4
Jan Lehnardt wrote: you want to have --with-mysql=/path/to and --disable-mysql as the two options ? Never mind, I forgot about --with-mysql=/path/to. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault in current HEAD
Zeev Suraski wrote: This trace isn't meaningful... I know. How would I produce a more useful one? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault in current HEAD
At 21:33 12/05/2002, Sebastian Bergmann wrote: Zeev Suraski wrote: This trace isn't meaningful... I know. How would I produce a more useful one? It's probably not possible - the best thing to do is to try to cut down the script to the smallest one that still demonstrates the crash. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Getting posted variable
Hello, I would like to know how I can reach the posted variables , the one included in the HTTP_POST_VARS array, outside the php page. In fact I would like to do something like : MyPhpPbject -getPostedVar(); The getPostedVars would be located in an included file. instead of MyVar-var1 = HTTP_POST_VARS[field1] and so on. Thank you -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Getting posted variable
Vous etes dans la mauvaise liste, inscrivez-vous sur http://fr2.php.net/mailing-lists.php - General user list a+ pa -Original Message- From: Stephane Tirard [mailto:[EMAIL PROTECTED]] Sent: lundi 13 mai 2002 00:22 To: [EMAIL PROTECTED] Subject: [PHP-DEV] Getting posted variable Hello, I would like to know how I can reach the posted variables , the one included in the HTTP_POST_VARS array, outside the php page. In fact I would like to do something like : MyPhpPbject -getPostedVar(); The getPostedVars would be located in an included file. instead of MyVar-var1 = HTTP_POST_VARS[field1] and so on. Thank you -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] IMAP module efficiency improvements
On Fri, May 10, 2002 at 02:49:12PM -0400, Rob Siemborski wrote: Last summer I sent in some patches to speed up the IMAP module's dealing with large mailboxes. At the time I noted that there were similar problems with other parts of the module, but I didn't have time to fix them then. Since I still see the problems in 4.2.0 (and I've suddenly had a need to improve performance with large #'s of mailboxes), I went ahead and finished the patch for folder lists. The changes to php_imap.c and php_imap.h are attached. Basically the same things that I did to the message list last year. If someone could briefly look these over and commit them that would be very helpful. Your changes look good, so I just committed them. They probably won't be included in the 4.2.1 release, however. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #17168: error_log can be used to bypass safe_mode
Not quite sure how to fix this one. It's not like we can simply check
before we open the error_log file in general, because that might be set
by the server admin, it is only if the user tries to redefine where this
error logfile should be that we want to apply the safe-mode restriction.
Even if we try to do everything in the VCWD stuff in 4.3 we will have to
keep some sort of state that tells us who provided the error
logfile pathname
-Rasmus
On 12 May 2002 [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.18
PHP version: 4.2.0
PHP Bug Type: Scripting Engine problem
Bug description: error_log can be used to bypass safe_mode
By doing ini_set('error_log', 'any_path); The user can append data to any
file writeable by the webserver.
--
Edit bug report at http://bugs.php.net/?id=17168edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17168r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17168r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17168r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17168r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17168r=support
Expected behavior: http://bugs.php.net/fix.php?id=17168r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17168r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17168r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17168r=globals
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #17168: error_log can be used to bypass safe_mode
We can check it at the ini handler level.
We can either forbid modifying error_log from userspace (denying
PHP_INI_USER), deny it only in safe mode, or even apply the safe mode
restriction at that level.
At 00:25 13/05/2002, Rasmus Lerdorf wrote:
Not quite sure how to fix this one. It's not like we can simply check
before we open the error_log file in general, because that might be set
by the server admin, it is only if the user tries to redefine where this
error logfile should be that we want to apply the safe-mode restriction.
Even if we try to do everything in the VCWD stuff in 4.3 we will have to
keep some sort of state that tells us who provided the error
logfile pathname
-Rasmus
On 12 May 2002 [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.18
PHP version: 4.2.0
PHP Bug Type: Scripting Engine problem
Bug description: error_log can be used to bypass safe_mode
By doing ini_set('error_log', 'any_path); The user can append data to any
file writeable by the webserver.
--
Edit bug report at http://bugs.php.net/?id=17168edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17168r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17168r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17168r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17168r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17168r=support
Expected behavior: http://bugs.php.net/fix.php?id=17168r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17168r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17168r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17168r=globals
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #17168: error_log can be used to bypass safe_mode
Right, but it would seem like we need a bit of a general purpose check on
ini_set() from userspace. There are probably other directives that we may
not want to allow or at least want to check from safe_mode. But yes,
that's the code I was looking at. I think we should apply the safe-mode
restriction on the argument in the ini handler.
-R
On Mon, 13 May 2002, Zeev Suraski wrote:
We can check it at the ini handler level.
We can either forbid modifying error_log from userspace (denying
PHP_INI_USER), deny it only in safe mode, or even apply the safe mode
restriction at that level.
At 00:25 13/05/2002, Rasmus Lerdorf wrote:
Not quite sure how to fix this one. It's not like we can simply check
before we open the error_log file in general, because that might be set
by the server admin, it is only if the user tries to redefine where this
error logfile should be that we want to apply the safe-mode restriction.
Even if we try to do everything in the VCWD stuff in 4.3 we will have to
keep some sort of state that tells us who provided the error
logfile pathname
-Rasmus
On 12 May 2002 [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.18
PHP version: 4.2.0
PHP Bug Type: Scripting Engine problem
Bug description: error_log can be used to bypass safe_mode
By doing ini_set('error_log', 'any_path); The user can append data to any
file writeable by the webserver.
--
Edit bug report at http://bugs.php.net/?id=17168edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17168r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17168r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17168r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17168r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17168r=support
Expected behavior: http://bugs.php.net/fix.php?id=17168r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17168r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17168r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17168r=globals
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
But for really large shared hosts, I don't think that is feasible. How are you going set up 100,000 prisons on a server? I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
Well, as long as there is exec(2), there is a way. How many users do Lycos Europe provide sandboxed PHP for? - Stig On Sun, 2002-05-12 at 23:37, Rasmus Lerdorf wrote: But for really large shared hosts, I don't think that is feasible. How are you going set up 100,000 prisons on a server? I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
Ok, but dropping to CGI is kind of crappy. Especially on a really busy server. On 12 May 2002, Stig S. Bakken wrote: Well, as long as there is exec(2), there is a way. How many users do Lycos Europe provide sandboxed PHP for? - Stig On Sun, 2002-05-12 at 23:37, Rasmus Lerdorf wrote: But for really large shared hosts, I don't think that is feasible. How are you going set up 100,000 prisons on a server? I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
Instead of just giving up on the problem, perhaps we should go into full attack mode. I see a couple of choices (and there are probably others): 1. Review and push open_basedir as the PHP-based jail mechanism 2. Pitch in and get Apache 2's perchild mpm up to snuff. There are all sorts of other issues associated with this option though, like needing to make sure all the stuff we link against is threadsafe. 3. Push FastCGI as the solution based on Shane's latest work on that front 4. Come up with step-by-step idiot-proof instructions for setting up Squid or other reverse proxies and running multiple instances of Apache listening on multiple ports and having requests directed appropriately by something like SquidGuard. I don't mean we should do just one of these, we should perhaps push forward on all fronts and come up with a document that describes the plusses and minuses of each as it applies to large shared hosting scenarios. -Rasmus On 12 May 2002, Stig S. Bakken wrote: I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug #17168: error_log can be used to bypass safe_mode
Maybe creating an php.ini option like disable_ini where the admin can list
the ini options that can be or cannot be set by users. Of course certain
options like child_terminate should be disabled by default.
Btw the child_terminate which allows the user to kill the current apache
child is setup in such a way that anyone can enable it. IMHO that is a very
bad idea, a user should not have the decision over their ability to terminate
apache children, this option should be for the admin alone.
Ilia
On May 12, 2002 05:36 pm, Rasmus Lerdorf wrote:
Right, but it would seem like we need a bit of a general purpose check on
ini_set() from userspace. There are probably other directives that we may
not want to allow or at least want to check from safe_mode. But yes,
that's the code I was looking at. I think we should apply the safe-mode
restriction on the argument in the ini handler.
-R
On Mon, 13 May 2002, Zeev Suraski wrote:
We can check it at the ini handler level.
We can either forbid modifying error_log from userspace (denying
PHP_INI_USER), deny it only in safe mode, or even apply the safe mode
restriction at that level.
At 00:25 13/05/2002, Rasmus Lerdorf wrote:
Not quite sure how to fix this one. It's not like we can simply check
before we open the error_log file in general, because that might be set
by the server admin, it is only if the user tries to redefine where this
error logfile should be that we want to apply the safe-mode restriction.
Even if we try to do everything in the VCWD stuff in 4.3 we will have to
keep some sort of state that tells us who provided the error
logfile pathname
-Rasmus
On 12 May 2002 [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.18
PHP version: 4.2.0
PHP Bug Type: Scripting Engine problem
Bug description: error_log can be used to bypass safe_mode
By doing ini_set('error_log', 'any_path); The user can append data to
any file writeable by the webserver.
--
Edit bug report at http://bugs.php.net/?id=17168edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17168r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=17168r=alreadyfixed Need backtrace:
http://bugs.php.net/fix.php?id=17168r=needtrace Try newer
version: http://bugs.php.net/fix.php?id=17168r=oldversion Not
developer issue: http://bugs.php.net/fix.php?id=17168r=support
Expected behavior: http://bugs.php.net/fix.php?id=17168r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=17168r=notenoughinfo Submitted twice:
http://bugs.php.net/fix.php?id=17168r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17168r=globals
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
It may not be the fastest solution, but certainly a secure one. It is up to each admin to decide whether they want speed or security, I am sure the security minded ISPs probably would prefer a small performance loss over security integrity of their customer's data. Ilia On May 12, 2002 05:42 pm, Rasmus Lerdorf wrote: Ok, but dropping to CGI is kind of crappy. Especially on a really busy server. On 12 May 2002, Stig S. Bakken wrote: Well, as long as there is exec(2), there is a way. How many users do Lycos Europe provide sandboxed PHP for? - Stig On Sun, 2002-05-12 at 23:37, Rasmus Lerdorf wrote: But for really large shared hosts, I don't think that is feasible. How are you going set up 100,000 prisons on a server? I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Session question/bug?
I was looking at the functionality of session_unset. Currently if register globals is on it will get rid of all variables and it also clears out PS(http_session_vars).. should it also get rid of PS(vars)? I have a script that changes the session id a few times thruought the live of the script. The problem is that it keeps the variables in PS(vars) so when i call session_encode(), (which reads PS(vars)) I get some old session vars.. ex.. ? session_id(1234); session_start(); $_SESSION['test']++; var_dump(session_encode()); session_write_close(); session_unset(); session_id(12345); session_start(); var_dump(session_encode()); // this will have data for test ? After looking thru the session functions i don't see any of them that clear out PS(vars). - Brad __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
On Sun, May 12, 2002 at 02:52:24PM -0700, Rasmus Lerdorf wrote: ... 2. Pitch in and get Apache 2's perchild mpm up to snuff. There are all sorts of other issues associated with this option though, like needing to make sure all the stuff we link against is threadsafe. Actually this isn't as bad as it sounds. I've been doing some of the work necessary to make perchild portable lately. And as for making it threadsafe/reentrant, I think those kinds of problems are going to show up with the worker MPM as well (which seems to be working fairly well with PHP at the moment). -aaron -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
FastCGI can provide the security needed in shared environments, without loosing all the performance. I don't beleive it is fast as direct server plugins, but there are other benefits...such as running PHP single threaded to avoid thread issues. It would be nice to see it become a standard compile option. One thing that does need to happen is a multithreaded fastcgi option for PHP. I've had that in the back of my head but haven't gotten around to it yet. Shane Rasmus Lerdorf wrote: Instead of just giving up on the problem, perhaps we should go into full attack mode. I see a couple of choices (and there are probably others): 1. Review and push open_basedir as the PHP-based jail mechanism 2. Pitch in and get Apache 2's perchild mpm up to snuff. There are all sorts of other issues associated with this option though, like needing to make sure all the stuff we link against is threadsafe. 3. Push FastCGI as the solution based on Shane's latest work on that front 4. Come up with step-by-step idiot-proof instructions for setting up Squid or other reverse proxies and running multiple instances of Apache listening on multiple ports and having requests directed appropriately by something like SquidGuard. I don't mean we should do just one of these, we should perhaps push forward on all fronts and come up with a document that describes the plusses and minuses of each as it applies to large shared hosting scenarios. -Rasmus On 12 May 2002, Stig S. Bakken wrote: I'm +1 on removing safe mode in PHP 5, and encourage the use of system-level sandboxes/prisons instead. - Stig On Sat, 2002-05-11 at 17:39, Ilia A. wrote: In the process of writing an installer in PHP for one of my projects I've come in contact with a number of servers running PHP with safe_mode enabled. As you can probably imagine the installer at first broke completely because of safe_mode restrictions. Despite the restriction I was able to write php code that was able to bypass safe_mode restriction in every single case, which should tell you just how safe that option is. There are numerous ways to bypass it, rely on file system utils if they are in the path, make the script copy itself and then write stuff as webserver, install a small script into cgi-bin directory that will do the same thing etc... The number of ways to bypass this feature are too numerous to list here. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. It is my belief that safe_mode gives people who use false sense of security by supposedly securing their webserver from their own users, which is pointless since a dedicated user can cause plenty of damage by using while(1) include $PHP_SELF; etc... In addition safe_mode makes the developer life extremely difficult since it blocks the most common operations that ARE ALLOWED by the webserver's file permissions, why does PHP take on the role that is not done in any other programming language? It is nearly impossible to write a PHP file system code that would work with safe_mode it is much easier to just release C/Perl/Python etc.. code that will do the very same thing and run via a command line or the user's cgi-bin directory. For example, if a user uploads test.php with their FTP and test.php creates a file, it will no longer be able to read that file under safe_mode since the uid of the script and the file it created differ. IMHO safe_mode should be removed from the php core, because it lulls web server admins into false sense of security thus not taking the time to setup proper file system permissions in addition to severely crippling the PHP's file system functionality. If the safe_mode like functionality remains it should simply block all file system and shell execution code since with it most of that code becomes useless anyway. Regards, Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
2. Pitch in and get Apache 2's perchild mpm up to snuff. There are all sorts of other issues associated with this option though, like needing to make sure all the stuff we link against is threadsafe. Actually this isn't as bad as it sounds. I've been doing some of the work necessary to make perchild portable lately. And as for making it threadsafe/reentrant, I think those kinds of problems are going to show up with the worker MPM as well (which seems to be working fairly well with PHP at the moment). True, but the perchild mpm is really rough. I was trying it yesterday and it looks like it needs some serious work. We also have to realize that the target market here is the big-ass ISP and they are traditionally slow to upgrade so it will be a good long while before they are going to go anywhere near Apache2+perchild. We still need to work towards getting this stable and useful, but it is not the solution for 6-months from now in my opinion. More like 18-months out. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH - improvements for imap_headerinfo() (fwd)
On Mon, May 13, 2002 at 12:35:12AM +0300, Jani Taskinen wrote: Reviewed and committed. - Jon Can you check this patch too? :) --Jani -- Forwarded message -- Date: 24 Apr 2002 15:02:45 -0400 From: Adam Kauffman [EMAIL PROTECTED] To: Jani Taskinen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] PATCH - improvements for imap_headerinfo() These changes don't (although I realize you shouldn't just take my word for it) break the functionality of imap_headerinfo(). It just is a streamlined way of doing it. The function as it stands does a mail_fetchheader_full(), takes the result of that, and turns it into an envelope object. Afterwards, it has to free that object. The c-client provides a way to get just the envelope with mail_fetchenvelope(). It is beneficial to use this for a few reasons: 1. As you can see it makes the code much simpler 2. It is faster. For each message you don't have to fetch full headers and turn them into an envelope object. You can simply just get the envelope object. 3. Simpler for the IMAP server. Instead of making it do a BODY.PEEK, it just has to fetch the envelope (which some IMAP servers cache). Adam On Wed, 2002-04-24 at 14:33, Jani Taskinen wrote: What was this patch supposed to do again? At first glance it looks like it's modifying the imap_headerinfo() function quite dramatically and propably breaks it too.. Have you compared the output of this function without this patch and with it and does it return the same kind of object? (and send patches as attachements..) --Jani -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
while(1) fopen(rand(), w); After a few seconds depending on system speed system will run out of file pointers. I am sure you can see how that would be BAD. You are _extremely_ incorrect. The previously mentioned code would open 1 file descriptor repeatedly until the script hit max execution time. This occurs because the garbage collector closes the unused file descriptor with every iteration. You could gain the desired effect of abusing file descriptors by using the following code while (1) $vars[]=fopen(rand(), w); However, quite frankly, this is a lame attack, because all it will do is consume file descriptors for only the CHILD process the script is running in. The script will then hit the fd limit of the child process (most systems around 255 is the default) This will not hurt the process, because all needed file descriptors were opened before the script was executed. The beauty of this is that the kernel will the reject all future calls beyond the limit, which halts i/o usage, and causes the process to consume more user time, which cause the process to hit max execution limit. The argument you make to remove safe mode because it is not perfect is unfounded. By the same argument you could say we shouldn't use locks on our doors, because hey they can be picked. -Jason Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
However, quite frankly, this is a lame attack, because all it will do is consume file descriptors for only the CHILD process the script is running in. The script will then hit the fd limit of the child process (most systems around 255 is the default) This will not hurt the process, because all needed file descriptors were opened before the script was executed. The beauty of this is that the kernel will the reject all future calls beyond the limit, which halts i/o usage, and causes the process to consume more user time, which cause the process to hit max execution limit. While the file description attack may be lame as you call it and won't cause excessive harm. There are many other ways that 2-3 lines a webserver can be brought down to its knees. If you want I can post code for A LOT more potent attacks that will disable the webserver. I simply choose not to because I believe that disclosing such information will do more harm then good. Even the lame file descriptor attack can be made very dangerous by adding of 1 line of code. The argument you make to remove safe mode because it is not perfect is unfounded. By the same argument you could say we shouldn't use locks on our doors, because hey they can be picked. Safe mode is not only imperfect it does not even work properly. In the last day and a half I've showed 5 bugs that allow it be bypassed, simply take a look at the latest safe_mode bugs. Some of those were fixed other were not as yet. To continue with your lock analogy, you do not protect your house with a broken lock, because beyond cosmetic value it does absolutely nothing. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
On Sun, 2002-05-12 at 22:46, Ilia A. wrote: However, quite frankly, this is a lame attack, because all it will do is consume file descriptors for only the CHILD process the script is running in. The script will then hit the fd limit of the child process (most systems around 255 is the default) This will not hurt the process, because all needed file descriptors were opened before the script was executed. The beauty of this is that the kernel will the reject all future calls beyond the limit, which halts i/o usage, and causes the process to consume more user time, which cause the process to hit max execution limit. While the file description attack may be lame as you call it and won't cause excessive harm. There are many other ways that 2-3 lines a webserver can be brought down to its knees. If you want I can post code for A LOT more potent attacks that will disable the webserver. I simply choose not to because I believe that disclosing such information will do more harm then good. Even the lame file descriptor attack can be made very dangerous by adding of 1 line of code. Really, what is that line? I would take a bet that it probably has nothing to do with safe mode, and would work regardless of it being in the language.. I will also take a bet that there is another security measure in php that can be used against it. The argument you make to remove safe mode because it is not perfect is unfounded. By the same argument you could say we shouldn't use locks on our doors, because hey they can be picked. Safe mode is not only imperfect it does not even work properly. In the last day and a half I've showed 5 bugs that allow it be bypassed, simply take a look at the latest safe_mode bugs. Five, I only saw one. Regardless they can and should be fixed. Some of those were fixed other were not as yet. To continue with your lock analogy, you do not protect your house with a broken lock, because beyond cosmetic value it does absolutely nothing. If the lock is broken, you fix it, you don't get rid of the lock altogether Ilia -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
Really, what is that line? sleep(1000); If you insist on being creative you can use file locking or sockets to get the process in to un-interuptible sleep. I would take a bet that it probably has nothing to do with safe mode, and would work regardless of it being in the language.. I am not saying this particular problem is due to safe_mode, which only theoreticaly prevents people from viewing/modifying files they do not own. I say theoretically because in reality a bugs in safe_mode can be used to bypass this limitation or simply write code in another programming language to do it. However, safe mode implies safety, which in reality it DOES NOT offer, of course if the defenition of the word safe has changed, please let me know. I will also take a bet that there is another security measure in php that can be used against it. Don't bet on it, you'll loose. The argument you make to remove safe mode because it is not perfect is unfounded. By the same argument you could say we shouldn't use locks on our doors, because hey they can be picked. Safe mode is not only imperfect it does not even work properly. In the last day and a half I've showed 5 bugs that allow it be bypassed, simply take a look at the latest safe_mode bugs. Five, I only saw one. Regardless they can and should be fixed. Check again: Bug report #17168-69 Bug report #17155-57 Some of those were fixed other were not as yet. To continue with your lock analogy, you do not protect your house with a broken lock, because beyond cosmetic value it does absolutely nothing. If the lock is broken, you fix it, you don't get rid of the lock altogether If you've fixed the same lock a dosen times and it still breaks it is probably smarter to get rid off it and get a new one. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
On Sun, 2002-05-12 at 23:38, Ilia A. wrote: Really, what is that line? sleep(1000); If you insist on being creative you can use file locking or sockets to get the process in to un-interuptible sleep. I would take a bet that it probably has nothing to do with safe mode, and would work regardless of it being in the language.. I am not saying this particular problem is due to safe_mode, which only theoreticaly prevents people from viewing/modifying files they do not own. I say theoretically because in reality a bugs in safe_mode can be used to bypass this limitation or simply write code in another programming language to do it. However, safe mode implies safety, which in reality it DOES NOT offer, of course if the defenition of the word safe has changed, please let me know. Ok now you are changing your argument. If you say it is inappropriately named, I will agree. However, the functionality of extra uid checks is a good measure The thing we have to hope for is that the admin is smart enough to realize their is no such thing as perfect security I will also take bet that there is another security measure in php that can be used against it. Don't bet on it, you'll loose. disable_functions = sleep The argument you make to remove safe mode because it is not perfect is unfounded. By the same argument you could say we shouldn't use locks on our doors, because hey they can be picked. Safe mode is not only imperfect it does not even work properly. In the last day and a half I've showed 5 bugs that allow it be bypassed, simply take a look at the latest safe_mode bugs. Five, I only saw one. Regardless they can and should be fixed. Check again: Bug report #17168-69 Bug report #17155-57 All of those regarding safe mode are fixed now. Some of those were fixed other were not as yet. To continue with your lock analogy, you do not protect your house with a broken lock, because beyond cosmetic value it does absolutely nothing. If the lock is broken, you fix it, you don't get rid of the lock altogether If you've fixed the same lock a dosen times and it still breaks it is probably smarter to get rid off it and get a new one. Ilia It depends on why the lock is broken, you have been suggesting this whole time that safe mode is a DESIGN flaw. However, your reasoning is only BUILD flaws. I have yet to hear a single reason as to why the concept of extra uid, checks of files is a bad thing. The fact of the matter, is that it is YOU who is ultimately responsible for your systems security. When you allow thousands of users to share the same system, and all execute arbitrary code on that system, there is always the possibility of problems. You can not rely on PHP itself solving all of your webhosting systems security problems. By the same argument that you make to get rid of safe mode, we could tell you to not use a shared environment, and use dedicated servers. There are problems here and you can be a bit more constructive, and send patches, offer new security techniques, report bugs. Exaggerating and cursing safe mode does nothing but waste time. -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Fix bundle compilation on Darwin for Apache 2.0
This patch adds support for Darwin bundles for the apache2filter
module. I brought up extending apxs to allow building self-contained
libraries on the dev@httpd lists to no answer. Since Darwin is a
special case that requires self-contained libraries (unless using
a flat namespace), I don't think it's necessary to add code to apxs
to always build self-contained libraries - we just need to handle
Darwin specially.
This patch does two things that should only be Darwin specific:
- Call apr-config and apu-config to determine the link information
for the requisite libraries so that they can be self-contained.
- Modifies the libphp4.bundle target to allow linking with libtool.
Since ap{ru}-config *may* print out information requiring libtool
to link (i.e. libexpat.la as a dependency), this makes more sense
to me.
While I was at WWDC last week, I talked to the linker developer
and we tossed around some ideas for handling this bundling problem.
I don't forsee any solution coming in the Jaguar timeframe, but
perhaps something later on. If you are interested in more details,
drop me a line as I don't think the entire PHP community cares
about Darwin. =)
Please let me know if you have any questions or comments. I have
tested this on my platform and it works. -- justin
Index: Makefile.global
===
RCS file: /repository/php4/Makefile.global,v
retrieving revision 1.11
diff -u -r1.11 Makefile.global
--- Makefile.global 28 Apr 2002 03:27:43 - 1.11
+++ Makefile.global 12 May 2002 23:01:21 -
-15,7 +15,7
$(LIBTOOL) --mode=link $(CC) $(COMMON_FLAGS) $(CFLAGS) $(EXTRA_CFLAGS) -rpath
$(phptempdir) $(EXTRA_LDFLAGS) $(LDFLAGS) $(PHP_RPATHS) $(PHP_GLOBAL_OBJS)
$(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $
libs/libphp4.bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
- $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS)
$(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) $(EXTRA_LIBS)
$(ZEND_EXTRA_LIBS) -o $ cp $ libs/libphp4.so
+ $(LIBTOOL) --mode=link $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN)
+$(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
+$(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $ cp $ libs/libphp4.so
php: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
$(LIBTOOL) --mode=link $(CC) -export-dynamic $(COMMON_FLAGS) $(CFLAGS_CLEAN)
$(EXTRA_CFLAGS) $(EXTRA_LDFLAGS) $(LDFLAGS) $(PHP_RPATHS) $(PHP_GLOBAL_OBJS)
$(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $
Index: sapi/apache2filter/config.m4
===
RCS file: /repository/php4/sapi/apache2filter/config.m4,v
retrieving revision 1.15
diff -u -r1.15 config.m4
--- sapi/apache2filter/config.m45 May 2002 09:52:39 - 1.15
+++ sapi/apache2filter/config.m412 May 2002 23:01:33 -
-57,7 +57,18
INSTALL_IT=$APXS -i -a -n php4 $SAPI_LIBTOOL
;;
*darwin*)
-MH_BUNDLE_FLAGS=-bundle -bundle_loader $APXS_HTTPD
+dnl When using bundles on Darwin, we must resolve all symbols. However,
+dnl the linker does not recursively look at the bundle loader and
+dnl pull in its dependencies. Therefore, we must pull in the APR
+dnl and APR-util libraries.
+APXS_BINDIR=`$APXS -q BINDIR`
+if test -f $APXS_BINDIR/apr-config; then
+MH_BUNDLE_FLAGS=`$APXS_BINDIR/apr-config --ldflags --link-ld --libs`
+fi
+if test -f $APXS_BINDIR/apu-config; then
+MH_BUNDLE_FLAGS=`$APXS_BINDIR/apu-config --ldflags --link-ld --libs`
+$MH_BUNDLE_FLAGS
+fi
+MH_BUNDLE_FLAGS=-bundle -bundle_loader $APXS_HTTPD $MH_BUNDLE_FLAGS
PHP_SUBST(MH_BUNDLE_FLAGS)
PHP_SELECT_SAPI(apache2filter, bundle, sapi_apache2.c apache_config.c
php_functions.c)
SAPI_SHARED=libs/libphp4.so
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Prefer glibtool over libtool (resend)
(This is a resend of an earlier patch.) It switches to preferring glibtool over libtool so that we can correctly run buildconf on Darwin. Since Darwin comes with a libtool but not the GNU libtool, we should try glibtool first. Since libtool exists, we don't look for glibtool and then when we try to verify $libtool is a GNU libtool, we fail because $libtool isn't a GNU libtool. Please let me know if you have any questions or comments. -- justin Index: build/buildcheck.sh === RCS file: /repository/php4/build/buildcheck.sh,v retrieving revision 1.16 diff -u -r1.16 buildcheck.sh --- build/buildcheck.sh 4 Mar 2002 08:28:57 - 1.16 +++ build/buildcheck.sh 5 May 2002 08:10:10 - -60,8 +60,8 fi # libtool 1.4 or newer -libtool=`which libtool` -if test ! -f $libtool; then libtool=`which glibtool`; fi +libtool=`which glibtool` +if test ! -f $libtool; then libtool=`which libtool`; fi lt_pversion=`$libtool --version 2/dev/null|sed -n -e 's/^[^0-9]*//' -e 1's/[- ].*//p'` if test $lt_pversion = ; then echo buildconf: libtool not found. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
disable_functions = sleep Ah but you forgot usleep, and flock() and socket_set_limit etc... Soon enough you'll disable every function. And when you do, I'll still be able to deadlock a PHP process by making it excute a query on a locked SQL table, thus end up waiting forever for the lock to be released. So, you'll need to disable all database functions from your PHP. The argument you make to remove safe mode because it is not perfect is unfounded. By the same argument you could say we shouldn't use locks on our doors, because hey they can be picked. Safe mode is not only imperfect it does not even work properly. In the last day and a half I've showed 5 bugs that allow it be bypassed, simply take a look at the latest safe_mode bugs. Five, I only saw one. Regardless they can and should be fixed. Check again: Bug report #17168-69 Bug report #17155-57 All of those regarding safe mode are fixed now. Really, you don't say... bug reports #17168-69 are still open at the time of this message being written. And when they are closed, don't worry I'll have a few more posted tommorow for your enjoyment... It depends on why the lock is broken, you have been suggesting this whole time that safe mode is a DESIGN flaw. However, your reasoning is only BUILD flaws. I have yet to hear a single reason as to why the concept of extra uid, checks of files is a bad thing. It is not PHPs job as a scripting/programming language to do security. security should/must be done at the OS and web server level. Checking uid is STUPID, the simplest example, is that if you upload a php script and it creates a file you can no longer read or write to that file even though you have file permissions to do so. File system permissions exist for a reason, use them. If you have sensetive data, like credit card information and you are not using a dedicated server to store that data then do be surprised to find your data in someone elses hands. In a shared enviroment especially where programming/scripting languages are avaliable it is merely a matter of time before someone takes advantage of some security hole/oversight and grabs the hold of your data. There are problems here and you can be a bit more constructive, and send patches, offer new security techniques, report bugs. Exaggerating and cursing safe mode does nothing but waste time. I am clearly demonstrating the problem and if you actually payed attention instead of trying to pretend this problem did not exist, reporting bugs about it. I'd gladly offer a patch that will get rid off safe_mode for the core php tree if developers are willing to add it to the CVS :) Safe mode wasteful and pointless this is no exageratio,n it makes development in the safe enviroment pointlessly difficult and offers no real safety. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Prefer glibtool over libtool (resend)
(This is a resend of an earlier patch.) It switches to preferring glibtool over libtool so that we can correctly run buildconf on Darwin. Since Darwin comes with a libtool but not the GNU libtool, we should try glibtool first. Since libtool exists, we don't look for glibtool and then when we try to verify $libtool is a GNU libtool, we fail because $libtool isn't a GNU libtool. Thanks Justin! The thing is, we don't actually use glibtool on the platform at all. Not with the Apache SAPIs anyway. I'll take a look and see how difficult it would be to get rid of it completely in these checks and elsewhere. Until I do, however, your patch is in. --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
On Mon, 2002-05-13 at 00:41, Ilia A. wrote: disable_functions = sleep Ah but you forgot usleep, and flock() and socket_set_limit etc... Soon enough you'll disable every function. Not likely, and I wouldn't disable every single function. You complained about the ability, I provided you with the way that YOU can disable it. You have to ask yourself why your user would need to be able to call sleep And when you do, I'll still be able to deadlock a PHP process by making it excute a query on a locked SQL table, thus end up waiting forever for the lock to be eleased. So, you'll need to disable all database functions from your PHP. Now you are really starting to stretch it. I am sure the ratio of customers that have db backends are much smaller than general webhosting customers In all of these scenarios, the webserver itself would just spawn another process, and the os would page the other one because it is not in use, and then eventually the webserver would log the problem. If you factor that in with a shared environment with multiple webservers and a load balance, your risk is pretty low. Even if someone did do something like that to kill all of your webservers, you would easily be able to find out who did it, and fix the abuser. The argument you make to remove safe mode because it is not perfect is unfounded. By the same argument you could say we shouldn't use locks on our doors, because hey they can be picked. Safe mode is not only imperfect it does not even work properly. In the last day and a half I've showed 5 bugs that allow it be bypassed, simply take a look at the latest safe_mode bugs. Five, I only saw one. Regardless they can and should be fixed. Check again: Bug report #17168-69 Bug report #17155-57 All of those regarding safe mode are fixed now. Really, you don't say... bug reports #17168-69 are still open at the time of this message being written. And when they are closed, don't worry I'll have a few more posted tommorow for your enjoyment... It depends on why the lock is broken, you have been suggesting this whole time that safe mode is a DESIGN flaw. However, your reasoning is only BUILD flaws. I have yet to hear a single reason as to why the concept of extra uid, checks of files is a bad thing. It is not PHPs job as a scripting/programming language to do security. security should/must be done at the OS and web server level. Checking uid is STUPID, the simplest example, is that if you upload a php script and it creates a file you can no longer read or write to that file even though you have file permissions to do so. File system permissions exist for a reason, use them. how are you planning on protecting your passwd file then? If you have sensetive data, like credit card information and you are not using a dedicated server to store that data then do be surprised to find your data in someone elses hands. In a shared enviroment especially where programming/scripting languages are avaliable it is merely a matter of time before someone takes advantage of some security hole/oversight and grabs the hold of your data. So then you are agreeing : ) There are problems here and you can be a bit more constructive, and send patches, offer new security techniques, report bugs. Exaggerating and cursing safe mode does nothing but waste time. I am clearly demonstrating the problem and if you actually payed attention instead of trying to pretend this problem did not exist, I am not, I am merely disagreeing that safe mode should be removed. I mean god man, if you hate safe mode so much turn it off. There are options you know, but just because you don't like it does not mean that everyone should not be able to use it. reporting bugs about it. I'd gladly offer a patch that will get rid off safe_mode for the core php tree if developers are willing to add it to the CVS :) Or you could try something more useful, like fixing a bug in safe mode, adding a new security feature, etc. etc. However, I suppose it is too difficult to come up with a constructive solution. Safe mode wasteful and pointless this is no exageratio,n it makes development in the safe enviroment pointlessly difficult and offers no real safety. Ilia Hmm, but you just said that a shared webhosting enviroment, by nature, has no real safety. Pointlesly difficult. then safe mode must be doing something -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix bundle compilation on Darwin for Apache2.0
This patch does two things that should only be Darwin specific:
- Call apr-config and apu-config to determine the link information
for the requisite libraries so that they can be self-contained.
- Modifies the libphp4.bundle target to allow linking with libtool.
Since ap{ru}-config *may* print out information requiring libtool
to link (i.e. libexpat.la as a dependency), this makes more sense
to me.
I have been quite happy to have finally got rid of libtool on our links,
however! I'd much prefer committing the rest of your patch and waiting for
the first bug report about libtool-specific dependencies.
The problem is that while linking with libtool might work with the
Apple-supplied glibtool, it doesn't with a fresh GNU 1.4.x one. This means
that running buildconf (with your other patch) would become mandatory on
Darwin, even for end users. Me not like.
Again, I throw the ball in your court -- it seems entirely possible to me to
get the *real* dependencies figured out when building ap{ru}-config.
--Marko
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
