Re: [PHP-DEV] Re: Bug #16739 Updated: `print' variable function call
On Sat, 11 May 2002, Yasuo Ohgaki wrote: [...] IMHO, we need someone who documents language design Actually, we need someone to finish this: http://cvs.php.net/cvs.php/php-lang regards, Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- 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 /sapi/cgi cgi_main.c /sapi/cliphp_cli.c
On Sat, 11 May 2002, Edin Kadribasic wrote: $ php -vv PHP 4.3.0-dev (cli), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies PHP_VERSION_API 20020510 ZEND_EXTENSION_API_NO 20020510 ZEND_MODULE_API_NO 20020510 On second thought, do we really need this. Can you imagine scenario where I think it is useful, as the number of shared modules will increase when PECL comes into play. [...] Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] HEAD broken on *NIX
/php4/main/php_ini.c:236: MAX_PATH undeclared -- 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] [PATCH] apache2filter -- enable compilation
Hi, since from, 20020506 (2.0.37-dev) Removed r-boundary in request_rec. Index: php_functions.c === RCS file: /repository/php4/sapi/apache2filter/php_functions.c,v retrieving revision 1.22 diff -u -r1.22 php_functions.c --- php_functions.c 9 Apr 2002 17:25:13 - 1.22 +++ php_functions.c 11 May 2002 08:09:42 - @@ -90,7 +90,6 @@ ADD_STRING(method); ADD_LONG(mtime); ADD_LONG(clength); - ADD_STRING(boundary); ADD_STRING(range); ADD_LONG(chunked); ADD_STRING(content_type); MT. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] xslt sablot backend
Hello,
Two problems with sablot support in PHP 4.1.2 (and propably later releases).
1) This patch makes xslt/sablot to work with libsablot = 0.90 and also
makes it incompatible with earlier sablotron releases. This fix might be in
HEAD already (at least it seems so), but please include this with next
minor release since anything 0.90 is too damn old if we are talking about
sablotron.
2) Added a lot of if(retval) checks to avoid segfaults when user specified
callback doesn't exist. Right now after module issues warning it segfaults
when trying to zval_ptr_dtor(retval) because that retval isn't actually
allocated when specified function doesn't exist.
This patch is against 4.1.2 source.
Thanks,
Lenar
--- sablot.c.old Sat May 11 12:10:49 2002
+++ sablot.c Sat May 11 12:58:18 2002
-52,15 +52,15
static int scheme_close(void *, SablotHandle, int);
/* Sax handler functions */
-static SAX_RETURN sax_startdoc(void *);
-static SAX_RETURN sax_startelement(void *, const char *, const char **);
-static SAX_RETURN sax_endelement(void *, const char *);
-static SAX_RETURN sax_startnamespace(void *, const char *, const char *);
-static SAX_RETURN sax_endnamespace(void *, const char *);
-static SAX_RETURN sax_comment(void *, const char *);
-static SAX_RETURN sax_pi(void *, const char *, const char *);
-static SAX_RETURN sax_characters(void *, const char *, int);
-static SAX_RETURN sax_enddoc(void *);
+static SAX_RETURN sax_startdoc(void *, SablotHandle);
+static SAX_RETURN sax_startelement(void *, SablotHandle, const char *, const char **);
+static SAX_RETURN sax_endelement(void *, SablotHandle, const char *);
+static SAX_RETURN sax_startnamespace(void *, SablotHandle, const char *, const char *);
+static SAX_RETURN sax_endnamespace(void *, SablotHandle, const char *);
+static SAX_RETURN sax_comment(void *, SablotHandle, const char *);
+static SAX_RETURN sax_pi(void *, SablotHandle, const char *, const char *);
+static SAX_RETURN sax_characters(void *, SablotHandle, const char *, int);
+static SAX_RETURN sax_enddoc(void *, SablotHandle);
/* Error handlers */
static MH_ERROR error_makecode(void *, SablotHandle, int, unsigned short, unsigned short);
-723,12 +723,14
xslt_call_function(scheme get all, XSLT_SCHEME(handle).get_all,
3, argv, retval);
- /* Save the return value in the buffer (copying it) */
- *buffer = estrndup(Z_STRVAL_P(retval), Z_STRLEN_P(retval));
- *byte_count = Z_STRLEN_P(retval);
+ if(retval) {
+ /* Save the return value in the buffer (copying it) */
+ *buffer = estrndup(Z_STRVAL_P(retval), Z_STRLEN_P(retval));
+ *byte_count = Z_STRLEN_P(retval);
- /* Free return value */
- zval_ptr_dtor(retval);
+ /* Free return value */
+ zval_ptr_dtor(retval);
+ }
return 0;
}
-801,11 +803,13
xslt_call_function(scheme open, XSLT_SCHEME(handle).open,
3, argv, retval);
- /* Return value is a resource pointer to an open file */
- *fd = Z_LVAL_P(retval);
+ if(retval) {
+ /* Return value is a resource pointer to an open file */
+ *fd = Z_LVAL_P(retval);
- /* Free it all up */
- zval_ptr_dtor(retval);
+ /* Free it all up */
+ zval_ptr_dtor(retval);
+ }
/* return success */
return 0;
-845,11 +849,13
xslt_call_function(scheme get, XSLT_SCHEME(handle).get,
3, argv, retval);
- /* Returns the number of bytes read */
- *byte_count = Z_LVAL_P(retval);
+ if(retval) {
+ /* Returns the number of bytes read */
+ *byte_count = Z_LVAL_P(retval);
- /* Free things up */
- zval_ptr_dtor(retval);
+ /* Free things up */
+ zval_ptr_dtor(retval);
+ }
/* return success */
return 0;
-889,11 +895,13
xslt_call_function(scheme put, XSLT_SCHEME(handle).put,
3, argv, retval);
- /* The return value is the number of bytes written */
- *byte_count = Z_LVAL_P(retval);
+ if(retval) {
+ /* The return value is the number of bytes written */
+ *byte_count = Z_LVAL_P(retval);
- /* Free everything up */
- zval_ptr_dtor(retval);
+ /* Free everything up */
+ zval_ptr_dtor(retval);
+ }
/* Return success */
return 0;
-931,7 +939,8
2, argv, retval);
/* Free everything up */
- zval_ptr_dtor(retval);
+ if(retval)
+ zval_ptr_dtor(retval);
/* Return success */
return 0;
-940,7 +949,7
/* {{{ sax_startdoc()
Called when the document starts to be processed */
-static SAX_RETURN sax_startdoc(void *ctx)
+static SAX_RETURN sax_startdoc(void *ctx, SablotHandle proc)
{
zval *argv[1];/* Arguments to the sax start doc function */
zval *retval; /* Return value from sax start doc function */
-964,13 +973,15
1, argv, retval);
/* Cleanup */
- zval_ptr_dtor(retval);
+ if(retval)
+ zval_ptr_dtor(retval);
}
/* }}} */
/* {{{ sax_startelement()
Called when an element is begun to be processed */
static SAX_RETURN sax_startelement(void *ctx,
+
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cgi cgi_main.c /sapi/cliphp_cli.c
On Sat, 11 May 2002, Markus Fischer wrote: Someone came up that it may be a use for PECL modules (or any C extension) which relies on a certain API number. Maybe Stig can see a use for it? Blame Derick who came up with the idea (I think ? :-) *hides*. I'm still not buying it. If future modules are dependent upon a specific version of PHP to work, that version will more than likely be the PHP version. I don't see how the API number is going to effect any development. Multiple version of any of those mentioned API numbers are not possible per release (it's only a #define, nothing more). My point exactly. Which standard ? :) Anyway, It's quite common to have multiple occurences of the same option additionally enhance the option, e.g. rpm: $ rpm --help|grep verbose -v- be a little more verbose -vv - be incredibly verbose (for debugging) A de facto standard stating -v is for version information. And please PLEASE don't use RPM as a model for software development. So far that is the first time I've ever seen the -vv option. Look against things like gcc, sendmail, and a multitude of other cross-platform tools. -v is what people have to expect for version statistics. Btw, jimw has activated the new anti-spam feature also for [EMAIL PROTECTED] adressed (just in case ... ) Why build a house on the river delta, knowing the river floods, when I can build on the high grounds and be safer? AKA I'd rather not stop spam at the receiving level, but rather at the sending level. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- 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 /sapi/cgi cgi_main.c /sapi/cli php_cli.c
On Sat, May 11, 2002 at 06:43:54AM -0400, Dan Kalowsky wrote : On Sat, 11 May 2002, Markus Fischer wrote: Someone came up that it may be a use for PECL modules (or any C extension) which relies on a certain API number. Maybe Stig can see a use for it? Blame Derick who came up with the idea (I think ? :-) *hides*. I'm still not buying it. If future modules are dependent upon a specific version of PHP to work, that version will more than likely be the PHP version. I don't see how the API number is going to effect any development. So far we have 3 votes for it, 1 against it (not counting mine). Maybe the others can give some useful examples too (as this was not suggested by me but I don't think it harms us and I find the -vv switch quite nice, but we could use -V too). Which standard ? :) Anyway, It's quite common to have multiple occurences of the same option additionally enhance the option, e.g. rpm: $ rpm --help|grep verbose -v- be a little more verbose -vv - be incredibly verbose (for debugging) A de facto standard stating -v is for version information. And please PLEASE don't use RPM as a model for software development. It is NOT a model for me. It was just the quickest thing I could find. I've seen numerous apps using switches this way in the past years, though I would not sit here if I could remember everything I've seen in my life :) - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc I'm not stupid, you know? :) - Jani Taskinen -- 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 /sapi/cgi cgi_main.c /sapi/cli php_cli.c
A de facto standard stating -v is for version information. And please PLEASE don't use RPM as a model for software development. It is NOT a model for me. It was just the quickest thing I could find. I've seen numerous apps using switches this way in the past years, though I would not sit here if I could remember everything I've seen in my life :) Many apps use multiple swithces for similar purpose. Typical use is to enhance the original switch. The logining level on OpenBSD's ftpd is specified by repeating -l switch many times. I've seen examples of -l -l -l (or -lll) or more. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Any idea why we have two html_puts()'s?
We currently have two html_puts()'s - the old zend_html_puts(), and a relatively new php_html_puts(). Was there any good reason for adding php_html_puts()? It duplicates the same logic of both zend_html_putc() and zend_html_puts(). Zeev -- 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 /sapi/cgi cgi_main.c /sapi/cli php_cli.c
php-config is for displaying information like this without the need for further parsing. Why not just add --zend-module-api --php-module-api and --zend-ext-api flags to php-config outputting the number and nothing else? - Stig On Sat, 2002-05-11 at 04:00, Markus Fischer wrote: Hi, On Sat, May 11, 2002 at 10:45:12AM +0900, Yasuo Ohgaki wrote : Markus Fischer wrote: Hi, I've modified the out now to look something like $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies Derick suggested also to add some other internal version numbers like module about for both PHP and Zend. We just need to come up with a decent description of the various numbers: ZEND_EXTENSION_API_NO ZEND_MODULE_API_NO PHP_VERSION_API How about use the macro names? For example, programmers may try to find . -name *.[ch] | xargs grep -n PHP_VERSION_API to see how API version macros are used. Ok, that would mean getting the PHP version number is something like php -v |grep PHP |grep -v PHP_ | ... sounds ok to me. So a complete output can look like: $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies PHP_VERSION_API 20020510 ZEND_EXTENSION_API_NO 20020510 ZEND_MODULE_API_NO 20020510 ? Hmm, now looking again, this looks ugly :) Would it make sense to have $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies and $ php -vv PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies PHP_VERSION_API 20020510 ZEND_EXTENSION_API_NO 20020510 ZEND_MODULE_API_NO 20020510 Or is this just unnecessary bloat and let's fire all versions we have to standard output with -v ? - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc I'm not stupid, you know? :) - Jani Taskinen -- 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 /sapi/cgi cgi_main.c /sapi/cli php_cli.c
Hi, that's even better! :) - Markus On Sat, May 11, 2002 at 03:42:00PM +0200, Stig S. Bakken wrote : php-config is for displaying information like this without the need for further parsing. Why not just add --zend-module-api --php-module-api and --zend-ext-api flags to php-config outputting the number and nothing else? - Stig On Sat, 2002-05-11 at 04:00, Markus Fischer wrote: Hi, On Sat, May 11, 2002 at 10:45:12AM +0900, Yasuo Ohgaki wrote : Markus Fischer wrote: Hi, I've modified the out now to look something like $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies Derick suggested also to add some other internal version numbers like module about for both PHP and Zend. We just need to come up with a decent description of the various numbers: ZEND_EXTENSION_API_NO ZEND_MODULE_API_NO PHP_VERSION_API How about use the macro names? For example, programmers may try to find . -name *.[ch] | xargs grep -n PHP_VERSION_API to see how API version macros are used. Ok, that would mean getting the PHP version number is something like php -v |grep PHP |grep -v PHP_ | ... sounds ok to me. So a complete output can look like: $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies PHP_VERSION_API 20020510 ZEND_EXTENSION_API_NO 20020510 ZEND_MODULE_API_NO 20020510 ? Hmm, now looking again, this looks ugly :) Would it make sense to have $ php -v PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies and $ php -vv PHP 4.3.0-dev (cli) Zend Engine v1.2.1, Copyright (c) 1998-2002 Zend Technologies PHP_VERSION_API 20020510 ZEND_EXTENSION_API_NO 20020510 ZEND_MODULE_API_NO 20020510 Or is this just unnecessary bloat and let's fire all versions we have to standard output with -v ? - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc I'm not stupid, you know? :) - Jani Taskinen -- 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 -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc I'm not stupid, you know? :) - Jani Taskinen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Safe Mode
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
Re: [PHP-DEV] Safe Mode
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. It already does this. You can only execute things in the safe_mode_exec_dir. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
There are numerous ways to bypass it, rely on file system utils if they are in the path, Won't work. make the script copy itself and then write stuff as webserver, You always write stuff as web server install a small script into cgi-bin directory that will do the same thing That's not really a PHP issue. Many ISP's turn off cgi-bin access so in those cases that won't work. The number of ways to bypass this feature are too numerous to list here. Let's have some real specifics please. I should also point out that safe_mode implementation has numerous bugs in every PHP version including the very latest CVS. Again, specifics please. 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... The process limits should take care of that. 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? Because PHP is in many cases the only scripting language an ISP is willing to give people access to on a shared server. 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. Sure, so do that. PHP is a web scripting language. 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. Correct. That's why we have open_basedir. Safe-mode is a crappy feature that shouldn't need to be in PHP. This is something that should be done at the web server level as with the perchild mpm in Apache 2.0. Unfortunately Apache 2.0, and especially the perchild mpm is nowhere near robust enough to run a large shared hosting environment at this point. So until a better solution comes along, we are stuck with safe-mode or open_basedir. Personally I think more ISP's should be using open_basedir restrictions instead of safe-mode, but we give them the choice. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] On vacation
I'm on vacation until June 16th and will not read any mail until I return. Your mail concerning Assigned PHP 4 bugs reminder will be read when I'm back. PS See http://www.venaas.no/whereami/ for my current location. Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] add PATH_INFO and PATH_TRANSLATED to apache 2 sapi
Diff'ed against the stable 4.2.0 source package.
Adds the same behavior as the CGI and ISAPI modules with regard to PATH_INFO
and PATH_TRANSLATED variables to the Apache 2 filter interface. If the user
does not specifically set the AcceptPathInfo configuration variable to
off, the patch passes the accepted state to the core module who makes them
available to the PHP output filter.
As the default PHP content handler is no longer among us, it would probably
be a good idea to put all this in the fixup phase. Still for now I think it
gets the job done.
D
--- sapi/apache2filter/sapi_apache2.c.orig Thu Apr 18 18:34:49 2002
+++ sapi/apache2filter/sapi_apache2.c Sat May 11 03:27:07 2002
-477,6 +477,13
strcmp(r-content_type, application/x-httpd-php) == 0) {
php_add_filter(r, r-output_filters);
php_add_filter(r, r-input_filters);
+
+ /* Accept PATH_INFO and PATH_TRANSLATED if not specifically
+* set by the user. (mimic the CGI module behavior) */
+
+ if ((r-used_path_info == AP_REQ_DEFAULT_PATH_INFO)
+r-path_info *r-path_info)
+r-used_path_info = AP_REQ_ACCEPT_PATH_INFO;
}
}
--
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 11:35 am, you wrote: There are numerous ways to bypass it, rely on file system utils if they are in the path, Won't work. make the script copy itself and then write stuff as webserver, You always write stuff as web server What is the point of limiting the script's write access if it can just bypass that by making a copy of itself? This merely adds an annoyance step for the programmer. install a small script into cgi-bin directory that will do the same thing That's not really a PHP issue. Many ISP's turn off cgi-bin access so in those cases that won't work. Cerainly some ISPs do that, but most do offer cgi-bin directories in addition to PHP, because many of their customers rely on perl/c etc.. scripts that can be run via cgi-bin. The number of ways to bypass this feature are too numerous to list here. Let's have some real specifics please. Sure here is just 1 example: Current directory is /home/user/dir1/dir2/ mkdir(/home/user/dir1/dir2/dir3) fails (Safe Mode Error) mkdir(dir3) works fine This has been replicated with PHP 4.2.0 on 2 servers I've tried this on. 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... The process limits should take care of that. There are numerous and untold ways to cause PHP to eat up the cpu or to crash the child, more then a few ways were posted on this list. That was just the simplest example I could show. 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? Because PHP is in many cases the only scripting language an ISP is willing to give people access to on a shared server. I agree that most common use of PHP is a web scripting language, but IMHO it is the job of the webserver/filesystem to limit what user can do, not of the scripting or programming language. 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. Correct. That's why we have open_basedir. Ideally every ISP would use it and each virtual host would have such a directory. In reality I've set to see a SINGLE ISP that has used that option. In fact I didn't know about it myself until you told me about on IRC. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
What is the point of limiting the script's write access if it can just bypass that by making a copy of itself? This merely adds an annoyance step for the programmer. If user joe makes a copy of his script so it now is owned by nobody, it still doesn't let him read user bob's scripts. That's not really a PHP issue. Many ISP's turn off cgi-bin access so in those cases that won't work. Cerainly some ISPs do that, but most do offer cgi-bin directories in addition to PHP, because many of their customers rely on perl/c etc.. scripts that can be run via cgi-bin. And in that case you can also write cgi-bin programs in PHP then. What's your point? Sure here is just 1 example: Current directory is /home/user/dir1/dir2/ mkdir(/home/user/dir1/dir2/dir3) fails (Safe Mode Error) mkdir(dir3) works fine This has been replicated with PHP 4.2.0 on 2 servers I've tried this on. Did you file a bug report? I can't replicate this on my server. Do you have symlinks, nfs or something else involved? There are numerous and untold ways to cause PHP to eat up the cpu or to crash the child, more then a few ways were posted on this list. That was just the simplest example I could show. Yes, but safe_mode guards against one user getting at another's user's data. So again, I fail to see your point here. Because PHP is in many cases the only scripting language an ISP is willing to give people access to on a shared server. I agree that most common use of PHP is a web scripting language, but IMHO it is the job of the webserver/filesystem to limit what user can do, not of the scripting or programming language. Correct, but we have a situation where multiple users all run under the same UNIX user id. In this case you cannot solve things strictly with UNIX-level permissions. The real solution is of course to not run everything as the same user id, but that is not something PHP has any control over. We simply try to do the best we can with the hand we are dealt. Correct. That's why we have open_basedir. Ideally every ISP would use it and each virtual host would have such a directory. In reality I've set to see a SINGLE ISP that has used that option. In fact I didn't know about it myself until you told me about on IRC. Well, it is well documented. The ignorance and stupidity of many ISP's is just a fact of life. I am a firm believer in Darwinism amongst ISP's and figure the really stupid ones will eventually die off. I am not going to go out an actively shoot them though, because that might be illegal. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
At 20:17 11/05/2002, Rasmus Lerdorf wrote: Ideally every ISP would use it and each virtual host would have such a directory. In reality I've set to see a SINGLE ISP that has used that option. In fact I didn't know about it myself until you told me about on IRC. Well, it is well documented. The ignorance and stupidity of many ISP's is just a fact of life. I am a firm believer in Darwinism amongst ISP's and figure the really stupid ones will eventually die off. I am not going to go out an actively shoot them though, because that might be illegal. Do we have any sort of an PHP-ISP-HOWTO? If not, are there any volunteers to write one? I think it may be a good idea, because Darwinism goes both ways - if too many people get bitten by PHP, they'll switch to other solutions. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
Zeev Suraski wrote: At 20:17 11/05/2002, Rasmus Lerdorf wrote: Ideally every ISP would use it and each virtual host would have such a directory. In reality I've set to see a SINGLE ISP that has used that option. In fact I didn't know about it myself until you told me about on IRC. Well, it is well documented. The ignorance and stupidity of many ISP's is just a fact of life. I am a firm believer in Darwinism amongst ISP's and figure the really stupid ones will eventually die off. I am not going to go out an actively shoot them though, because that might be illegal. Do we have any sort of an PHP-ISP-HOWTO? If not, are there any volunteers to write one? I think it may be a good idea, because Darwinism goes both ways - if too many people get bitten by PHP, they'll switch to other solutions. Zeev I gladly volunteer to help with this effort. Chris -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
That's not really a PHP issue. Many ISP's turn off cgi-bin access so in those cases that won't work. Cerainly some ISPs do that, but most do offer cgi-bin directories in addition to PHP, because many of their customers rely on perl/c etc.. scripts that can be run via cgi-bin. And in that case you can also write cgi-bin programs in PHP then. What's your point? Why do that since php-cgi will still try to read the php.ini and follow safe_mode. It is easier to write a perl script suid it to the user and have it do whatever you want. The only thing accomplished is 1 upset developer and webhost who thinks he is secure because they turned on php's security feature. Sure here is just 1 example: Current directory is /home/user/dir1/dir2/ mkdir(/home/user/dir1/dir2/dir3) fails (Safe Mode Error) mkdir(dir3) works fine This has been replicated with PHP 4.2.0 on 2 servers I've tried this on. Did you file a bug report? I can't replicate this on my server. Do you have symlinks, nfs or something else involved? Yeah I had directories symlinked, although permissions on the directories were fine. I'll post a bug report once I have more exact data. There are numerous and untold ways to cause PHP to eat up the cpu or to crash the child, more then a few ways were posted on this list. That was just the simplest example I could show. Yes, but safe_mode guards against one user getting at another's user's data. So again, I fail to see your point here. No offence but this bullshit. On a system with safe_mode ?php show_source(/etc/passwd); ? Works!! What data did you protect?! Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
Yes, but safe_mode guards against one user getting at another's user's data. So again, I fail to see your point here. No offence but this bullshit. On a system with safe_mode ?php show_source(/etc/passwd); ? Works!! What data did you protect?! None in this case, but that has nothing to do with the problem. That is obviously a bug. Did you submit it? The fact is that the problem cannot be solved purely by UNIX-level permissions. Things like safe-mode or open_basedir are needed. And the ISP that is on the ball will add disable_functions = show_source to their php.ini after reading this message. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
None in this case, but that has nothing to do with the problem. That is obviously a bug. Did you submit it? Bug Report #17155 :) The fact is that the problem cannot be solved purely by UNIX-level permissions. Things like safe-mode or open_basedir are needed. And the ISP that is on the ball will add disable_functions = show_source to their php.ini after reading this message. Heh, I am certain that most ISPs admins are not subscribed to the development list of every software they are running, monitoring such lists would be near impossible due to large cumulative volume of email. I am sure some IPSs will do exactly what you suggest and disable the function, but what about the next function which bypasses safe_mode etc...? Eventually, they'd need to disable every file system function. Btw here is yet another thing against which safemode does not protect. 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. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
Heh, I am certain that most ISPs admins are not subscribed to the development list of every software they are running, monitoring such lists would be near impossible due to large cumulative volume of email. I am sure some IPSs will do exactly what you suggest and disable the function, but what about the next function which bypasses safe_mode etc...? Eventually, they'd need to disable every file system function. Btw here is yet another thing against which safemode does not protect. 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. That's not safe-mode's job. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Bug #16629 apache2filter
Hi, Dunno if that solves that bug entirely, but at least it follows the php.ini on/off config flags, instead of putting 0 and 1 for boolean settings. Index: apache_config.c === RCS file: /repository/php4/sapi/apache2filter/apache_config.c,v retrieving revision 1.19 diff -u -r1.19 apache_config.c --- apache_config.c 22 Apr 2002 20:00:41 - 1.19 +++ apache_config.c 11 May 2002 19:49:01 - @@ -57,6 +57,11 @@ size_t str_len; phpapdebug((stderr, Getting %s=%s for %p (%d)\n, name, value, dummy, zend_hash_num_elements(d-config))); + +if (apr_strnatcasecmp(value, On) == 0) +value = 1; +else if (apr_strnatcasecmp(value, Off) == 0) +value = 0; e.value = apr_pstrdup(cmd-pool, value); e.value_len = strlen(value); e.status = status; MT. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ekilfoil
I plan to develop and maintain PEAR packages, and Stig S. Bakken from the pear-dev mailing list said i need a PHP cvs account. I assume i'll only need access to the /pear directory until pear's CVS is split from php. I already have some modules at http://www.ypass.net/php, and I am planning on making the php-dns module pear compliant. php-dns is a resolver library written in PHP which supports dynamic DNS updates. It was ported from the Net::DNS PERL module. Please let me know if you have any questions. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode
On Sat, 2002-05-11 at 19:27, Zeev Suraski wrote: At 20:17 11/05/2002, Rasmus Lerdorf wrote: Ideally every ISP would use it and each virtual host would have such a directory. In reality I've set to see a SINGLE ISP that has used that option. In fact I didn't know about it myself until you told me about on IRC. Well, it is well documented. The ignorance and stupidity of many ISP's is just a fact of life. I am a firm believer in Darwinism amongst ISP's and figure the really stupid ones will eventually die off. I am not going to go out an actively shoot them though, because that might be illegal. Do we have any sort of an PHP-ISP-HOWTO? If not, are there any volunteers to write one? I think it may be a good idea, because Darwinism goes both ways - if too many people get bitten by PHP, they'll switch to other solutions. Zeev hey all, I'm working at Lycos Europe (nothing to do with Lycos, inc, except for the trademark). We do have a large shared hosting service (both free and paid) over 8 countries. That's Millions of webpages. ALl of them able to use php. I've been working on the PHP4U service (as we call it :)) for almost 2 years now on and off (it started with the MultiMania PHP4U Service a while back before being trasnfered to Lycos Hosting), mainly upgrading to the new php version as soon as i considered it robust. I've definitely come over troubles these past 2 years, Zeev can tell, i've been bugging him with questions since then. The php distribution we first used was a 4.0.4pl1. And I had to patch it to cover our needs and cover some safe_mode security bugs. (Those bugs are now corrected since 4.1.2). I also had to patch other little security bugs we found while the service was rolling and the users were reporting it to us. 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. 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 :) 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
