[PHP-DEV] phpinfo() output

[Sebastian Bergmann]

  Currently

API Versions: PHP: 20020307 PHP Extension: 20020429 Zend Extension: 
20020903

  is rendered instead of

API Versions: PHP: 20020307
  PHP Extension: 20020429
  Zend Extension: 20020903

-- 
  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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to restrict database access for ext/pgsql

[Jim Mercer]

On Fri, Sep 27, 2002 at 10:50:08AM +0900, Yasuo Ohgaki wrote:
> Ilia A. wrote:
> >list think of this patch. I merely try to explain why I believe this 
> >particular patch is not appropriate for standard PHP distribution.
> 
> It will be yet another safe_mode like feature. i.e.
> it isn't secure as it sounds. Users with a little knowledge
> can access backend with socket function. Therefore, I agree
> with Ilia's opinion.

users with a little knowledge can do all manner of unpleasant things with the
socket function. not to mention system(), and fopen/read/write/fclose.

let us assume that pgsql had an API call PQrestrictdb(list_of_dbs).

and i submitted a patch that allowed for a PHP config var to fill that
list_of_dbs.

would i be running into the same objections?

how else would you propose i pass immutable values from apache to pgsql?

the concept here is security, and i recognize that part of your purpose is
to maintain, and improve the security of php.

but with such stalwart objections to modifications like mine, you are making
php less secure for those of us who want to use extensions by forcing us
to use environment variables which can be overwritten.

my apologies if there is a mechanism which exists, and that i'm not aware of.

-- 
[ Jim Mercer[EMAIL PROTECTED] +1 416 410-5633 ]
[  I want to live forever, or die trying.]

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to restrict database access for ext/pgsql

[Jim Mercer]

On Thu, Sep 26, 2002 at 09:00:17PM -0400, Ilia A. wrote:
> It is not a job of the programming language to implement system, database 
> security. This is simply not done. If you want to secure your PostgreSQL more 
> so that you can with the current tools, the people you should be talking to 
> are the PostgreSQL developers. It is up to them to develop and implement 
> various database access controls and security measures.
> Just because it may be easy to hack up PHP to implement this, it does
> not mean this is the correct approach.

oh, please.

PHP is full of tweaks and hacks specifically to augment and make easier the
job of the people using it.

the whole point of PHP is to make it easier to accomplish things either
with other apps, or by going around them.

at this point i have not seen any technical argument as to why this patch
is inappropriate.

all i've gotten so far is a bunch of crap about whose responsibility it is
to secure things.

the patch i've submitted in no way harms the ability of php to do its job, and
only enhances its ability to help more people make more effective use of PHP.

if php-dev is not interested in such suggestions, i'll back off and not bother
you again.

sorry if my providing a complete patch to add this functionality took you
away from more important things.

-- 
[ Jim Mercer[EMAIL PROTECTED] +1 416 410-5633 ]
[  I want to live forever, or die trying.]

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to restrict database access for ext/pgsql

[Yasuo Ohgaki]

Ilia A. wrote:
> list think of this patch. I merely try to explain why I believe this 
> particular patch is not appropriate for standard PHP distribution.

It will be yet another safe_mode like feature. i.e.
it isn't secure as it sounds. Users with a little knowledge
can access backend with socket function. Therefore, I agree
with Ilia's opinion.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to restrict database access for ext/pgsql

[Jim Mercer]

On Thu, Sep 26, 2002 at 09:31:44PM -0400, Ilia A. wrote:
> > PHP is full of tweaks and hacks specifically to augment and make easier the
> > job of the people using it.
> 
> The only simular hack I can imagine you are referring to is safe_mode, which 
> is a very ugly thing that was only implemented because at the time it was not 
> possible to implement simular functionality on most web servers.

i'm thinking more in line with the extensions.

like --enable-ucd-snmp-hack for example.

the documents tell the user to modify the ucd-snmp code, but if the user
is doesn't do that, they can simply add that to ./configure and away
you go.

> > if php-dev is not interested in such suggestions, i'll back off and not
> > bother you again.
> > sorry if my providing a complete patch to add this functionality took you
> > away from more important things.
> 
> I am hardly in a position to say what all the readers and developers on this 
> list think of this patch. I merely try to explain why I believe this 
> particular patch is not appropriate for standard PHP distribution.

sorry, i might have become a little overheated there.

i've run into this kind of problem before in other environments and it gets me
going.

i'm just a user of the code, and i've come up with what i think is a beneficial
augmentation.  i spent some time investigating the structure of the code,
and trying to ensure that my patch meets with the existing standard of coding
(ie diagnostics, memory allocation/deallocation, etc, etc).

i don't have a vision of what PHP should or shouldn't do at the development
level.

i'm just trying to solve production problems.

i feel that maybe the feeling of this group is too much purist, and too little
production.  (i realize that's painting with a wide brush, sorry)

it would be wonderful if we could spin off children of the web/php process
into their own uid/gid, but that is not easily done (without cgi).

it would also be wonderful if pgsql had intimate knowledge of the innards of
the calling process, but that is not easily done.

i thought about using environment variables to go httpd.conf -> php -> pgsql,
but those are too easily over-ridden by the user's code.

even if pgsql had a mechanism to restrict which dataset a process was attaching
to, we would still need to pass the list of restrictions from httpd.conf,
through php, to pgsql.

as best i can tell, this is the most efficient and safe way to do this.

-- 
[ Jim Mercer[EMAIL PROTECTED] +1 416 410-5633 ]
[  I want to live forever, or die trying.]

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to restrict database access for ext/pgsql

[Ilia A.]

On September 26, 2002 08:48 pm, Jim Mercer wrote:
> On Thu, Sep 26, 2002 at 09:00:17PM -0400, Ilia A. wrote:
> > It is not a job of the programming language to implement system, database
> > security. This is simply not done. If you want to secure your PostgreSQL
> > more so that you can with the current tools, the people you should be
> > talking to are the PostgreSQL developers. It is up to them to develop and
> > implement various database access controls and security measures.
> > Just because it may be easy to hack up PHP to implement this, it does
> > not mean this is the correct approach.
>
> oh, please.
>
> PHP is full of tweaks and hacks specifically to augment and make easier the
> job of the people using it.

The only simular hack I can imagine you are referring to is safe_mode, which 
is a very ugly thing that was only implemented because at the time it was not 
possible to implement simular functionality on most web servers.

>
> the whole point of PHP is to make it easier to accomplish things either
> with other apps, or by going around them.
>
> at this point i have not seen any technical argument as to why this patch
> is inappropriate.
> all i've gotten so far is a bunch of crap about whose responsibility it is
> to secure things.
>



> the patch i've submitted in no way harms the ability of php to do its job,
> and only enhances its ability to help more people make more effective use
> of PHP.
>
> if php-dev is not interested in such suggestions, i'll back off and not
> bother you again.
> sorry if my providing a complete patch to add this functionality took you
> away from more important things.

I am hardly in a position to say what all the readers and developers on this 
list think of this patch. I merely try to explain why I believe this 
particular patch is not appropriate for standard PHP distribution.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to restrict database access for ext/pgsql

[Jim Mercer]

On Thu, Sep 26, 2002 at 08:01:29PM -0400, Dan Kalowsky wrote:
> On Thursday, September 26, 2002, at 06:36 PM, Jon Parise wrote:
> >Isn't it generally better (where "better" means more secure,
> >efficient, and easily maintained) to handle database access control
> >using PostgreSQL's native access mappings?
> 
> Yep.  Thus why it was created :)

please explain to me how you think this might work?

the postgres security model is "table" based, not "database" based.
(a database being a collection of tables)

it is not possible to do the same thing as this patch within pgsql.

given a webserver setup, running as user "web" and group "web", all pgsql
calls are going to come from that user.

theoretically, you could use the username/password facilities of pgsql,
but in order for that to work, you must delegate the ability to
add/remove/modify pgsql users, and then you need to control who can manage
which user.

this patch adds a minor, but very useful, facility to say "this" virtual
host can only access "that" database.

with that facility, it becomes easier to add appropriate security within
that virtual host's data, and not have to worry about other users writing
code that dips into their data.

-- 
[ Jim Mercer[EMAIL PROTECTED] +1 416 410-5633 ]
[  I want to live forever, or die trying.]

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to restrict database access for ext/pgsql

[Dan Kalowsky]

On Thursday, September 26, 2002, at 06:36 PM, Jon Parise wrote:
> Isn't it generally better (where "better" means more secure,
> efficient, and easily maintained) to handle database access control
> using PostgreSQL's native access mappings?
>

Yep.  Thus why it was created :)

 >---<
Dan Kalowsky"Tonight I think I'll walk alone,
http://www.deadmime.org/~dankI'll find myself as I go home"
[EMAIL PROTECTED]- "Temptation",
[EMAIL PROTECTED]  New Order


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] patch to restrict database access for ext/pgsql

[Mike Robinson]

From: Jon Parise 

> Isn't it generally better (where "better" means more secure,
> efficient, and easily maintained) to handle database access
> control using PostgreSQL's native access mappings?

I would think so, and IMHO, that's where pgsql access control
belongs, with pgsql.

Regards
Mike Robinson


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] patch to restrict database access for ext/pgsql

[Jon Parise]

On Thu, Sep 26, 2002 at 02:15:52PM -0400, Jim Mercer wrote:

> this patch adds the config variable pgsql.allowed_dblist

[snip]
 
> although it can be accomplished by other means, setting the variable to a 
> value of ":" effectively locks the code out of pgsql.

Isn't it generally better (where "better" means more secure,
efficient, and easily maintained) to handle database access control
using PostgreSQL's native access mappings?

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/session session.c

[Markus Fischer]

Guys,

_Please_ include bug fixes in NEWS entries (or separately
commit them) so we've complete log.

Browsing back the ChangeLog and finding missing treasures
ain't that funny.

;)

thanks,

- Markus

On Thu, Sep 26, 2002 at 06:12:27PM -, Ilia Alshanetsky wrote : 
> iliaa Thu Sep 26 14:12:27 2002 EDT
> 
>   Modified files:  
> /php4/ext/session session.c 
>   Log:
>   Fixed bug #11643
>   
>   
> Index: php4/ext/session/session.c
> diff -u php4/ext/session/session.c:1.317 php4/ext/session/session.c:1.318
> --- php4/ext/session/session.c:1.317  Thu Sep 26 12:46:21 2002
> +++ php4/ext/session/session.cThu Sep 26 14:12:27 2002
> @@ -17,7 +17,7 @@
> +--+
>   */
>  
> -/* $Id: session.c,v 1.317 2002/09/26 16:46:21 sniper Exp $ */
> +/* $Id: session.c,v 1.318 2002/09/26 18:12:27 iliaa Exp $ */
>  
>  #ifdef HAVE_CONFIG_H
>  #include "config.h"
> @@ -826,6 +826,7 @@
>   int module_number = PS(module_number);
>   int nrand;
>   int lensess;
> + zend_constant *c;
>  
>   PS(apply_trans_sid) = PS(use_trans_sid);
>  
> @@ -919,7 +920,11 @@
>   php_session_send_cookie(TSRMLS_C);
>   }
>  
> -
> + /* check if SID constant exists, if it does destroy it. */
> + if (zend_hash_find(EG(zend_constants), "sid", 4, (void **) &c) != FAILURE) {
> + zend_hash_del(EG(zend_constants), "sid", 4);
> + }
> + 
>   if (define_sid) {
>   smart_str var = {0};
>  
> 
> 
> 
> -- 
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
 Derick, while ($xml) $ass->get_new_ideas();
<[James]> Markus: IE on_user_fart()
-- People doesn't seem to like the new XHTML2 specs :) --

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: open_basedir bug

[Wez Furlong]

It looks like this is the culprit:

http://cvs.php.net/diff.php/php4/main/fopen_wrappers.c?r1=1.142&r2=1.142.2.1&ty=h

But I don't know enough about this particular situation to
decide what the best solution is.

Rasmus: any ideas? (and does this affect HEAD?)

--Wez.

On 09/26/02, "Andrei Zmievski" <[EMAIL PROTECTED]> wrote:
> Wez, have you had a chance to look at #19292?




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Latest cvs: error in mbstring

[Wez Furlong]

Did you ./buildconf and then re-run configure?

--Wez.

On 09/26/02, "Martin Jansen" <[EMAIL PROTECTED]> wrote:
> The following error occurs when building latest CVS:
> 
> ext/mbstring/mbstring.lo: In function `zif_mb_convert_case':
> /home/martin/cvs/php/php4/ext/mbstring/mbstring.c:2499: undefined
> reference to `php_unicode_convert_case'
> collect2: ld returned 1 exit status
> make: *** [sapi/cli/php] Error 1
> 
> -- 
> - Martin   Martin Jansen
> http://martinjansen.com/
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: remote_addr

[Tom Sommer]

Anderson O Muniz wrote:
> Hello,
> 
> I need help I never programmed in php. :/
Then you're in the wrong place. This group is for the development of the 
  PHP sourcecode itself, not a support forum.

> What i am doing wrong?
Everything, try php.general or read the manual from the beginning


-- 
* Tom Sommer
* http://www.tsn.dk
* Computers do not solve problems, they execute solutions


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard config.m4 css.c css.h info.c /main php_ini.c /sapi/aolserver aolserver.c /sapi/apache php_apache.c

[Michael Mauch]

Michael Mauch <[EMAIL PROTECTED]> wrote:
> Colin Viebrock <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> "render nicely" is something else than "total unreadable" to me. Did you 
>>> have a look at it with Netscape Navigator 4? Please fix something for 
>>> it, as it's pretty horrible now.
>> 
>> Can you send me a screen grab?  I did test it under NS 4.7 (Win), and I
>> think you're exaggerating a bit, because it's hardly unreadable.
> 
> With Netscape 4.7x on Linux and Windows, I see a lot of vertical
> whitespace in some places, e.g. directly after "PHP Core" there's a
> screen full of nothing.

Please disregard my previous post - your current version 1.22 of css.c
looks great, at least in Netscape 4.x, Opera 6.0 and Mozilla 1.2a on
Linux.

Regards...
Michael

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Latest cvs: error in mbstring

[Martin Jansen]

The following error occurs when building latest CVS:

ext/mbstring/mbstring.lo: In function `zif_mb_convert_case':
/home/martin/cvs/php/php4/ext/mbstring/mbstring.c:2499: undefined
reference to `php_unicode_convert_case'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

-- 
- Martin   Martin Jansen
http://martinjansen.com/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.3.0

[Sebastian Bergmann]

[EMAIL PROTECTED] wrote:
>>> 
>>>   Good News!
>>> 
>> I so love that show.
> Which show is that?

  Futurama.

-- 
  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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.3.0

[derick]

On Thu, 26 Sep 2002, Andrei Zmievski wrote:

> On Thu, 26 Sep 2002, Sebastian Bergmann wrote:
> > Andrei Zmievski wrote:
> > > Once the critical bugs are fixed, I intend to branch the tree in
> > > preparation for 4.3.0 cycle.
> > 
> >   
> > Good News!
> >   
> 
> I so love that show.

Which show is that?

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.3.0

[Andrei Zmievski]

On Thu, 26 Sep 2002, Sebastian Bergmann wrote:
> Andrei Zmievski wrote:
> > Once the critical bugs are fixed, I intend to branch the tree in
> > preparation for 4.3.0 cycle.
> 
>   
> Good News!
>   

I so love that show.

-Andrei   http://www.gravitonic.com/

"The only true currency in this bankrupt world is what we share with each
other when we're uncool." -- Lester Bangs, from the film 'Almost Famous'

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.3.0

[Sebastian Bergmann]

Andrei Zmievski wrote:
> Once the critical bugs are fixed, I intend to branch the tree in
> preparation for 4.3.0 cycle.

  
Good News!
  

-- 
  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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 4.3.0

[Tal Peer]

Andrei Zmievski wrote:

>All,
>
>Once the critical bugs are fixed, I intend to branch the tree in
>preparation for 4.3.0 cycle. The remaining critical bugs are:
>
>   [15025] Copy of array is affected by reference
>   [19292] random error: open_basedir restriction in effect. File is in
>   wrong directory
>
(c) Bugstah for the nice output of the list ;)

>
>Please make an effort to handle these as soon as possible.
>
>-Andrei   http://www.gravitonic.com/
>
>"Later in this talk, I intend to define
> the universe and give three examples." -- Larry Wall
>
>  
>




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] 4.3.0

[Andrei Zmievski]

All,

Once the critical bugs are fixed, I intend to branch the tree in
preparation for 4.3.0 cycle. The remaining critical bugs are:

[15025] Copy of array is affected by reference
[19292] random error: open_basedir restriction in effect. File is in
wrong directory

Please make an effort to handle these as soon as possible.

-Andrei   http://www.gravitonic.com/

"Later in this talk, I intend to define
 the universe and give three examples." -- Larry Wall

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] remote_addr

[Anderson O Muniz]

Hello,

I need help I never programmed in php. :/

I have a firewall with proxy. Now a put a webcam behind the firewall. If put
the external_ip i see the cam, if i put the internal_ip i see the cam. Now i
made a web page with code below














Nova pagina 1




test">test




When I try to see the page in the internet explorer it shows me:

test">test  and when i put the cursor on it, it shows me :
http://ip_extern

[PHP-DEV] patch to restrict database access for ext/pgsql

[Jim Mercer]

this patch adds the config variable pgsql.allowed_dblist

by default it has no value, meaning all databases are accessible

it can contain a colon delimited list of databases that are accessible.

if the database accessed is not in the list, and the list is not null,
then an error is returned as if the database did not exist

this patch is relative to php-4.2.3

this function would be very useful to apache/virtual hosting.

i have tested with the following in my apache httpd.conf:


php_admin_value pgsql.allowed_dblist"jim:billing"


although it can be accomplished by other means, setting the variable to a 
value of ":" effectively locks the code out of pgsql.

-- 
[ Jim Mercer[EMAIL PROTECTED] +1 416 410-5633 ]
[  I want to live forever, or die trying.]



this patch adds the config variable pgsql.allowed_dblist

by default it has no value, meaning all databases are accessible

it can contain a colon delimited list of databases that are accessible.

if the database accessed is not in the list, and the list is not null,
then an error is returned as if the database did not exist

this patch is relative to php-4.2.3


*** pgsql.c.origThu Sep 26 14:02:04 2002
--- pgsql.c Thu Sep 26 14:02:27 2002
***
*** 304,309 
--- 304,311 
STD_PHP_INI_ENTRY_EX("pgsql.max_persistent","-1",   PHP_INI_SYSTEM,
 OnUpdateInt,max_persistent, php_pgsql_globals,  
pgsql_globals,  display_link_numbers)
STD_PHP_INI_ENTRY_EX("pgsql.max_links", "-1",   PHP_INI_SYSTEM,
 OnUpdateInt,max_links,  php_pgsql_globals,
  pgsql_globals,  display_link_numbers)
STD_PHP_INI_BOOLEAN("pgsql.auto_reset_persistent",  "0",
PHP_INI_SYSTEM, OnUpdateBool,   auto_reset_persistent,  
php_pgsql_globals,  pgsql_globals)
+   STD_PHP_INI_ENTRY("pgsql.allowed_dblist", NULL,   PHP_INI_SYSTEM,
+ OnUpdateString, allowed_dblist,   php_pgsql_globals, pgsql_globals)
  PHP_INI_END()
  /* }}} */
  
***
*** 418,423 
--- 420,428 
char 
*host=NULL,*port=NULL,*options=NULL,*tty=NULL,*dbname=NULL,*connstring=NULL;
char *hashed_details;
int hashed_details_length;
+   char *tmp_allowed_dblist;
+   char *last;
+   char *token;
PGconn *pgsql;

switch(ZEND_NUM_ARGS()) {
***
*** 533,538 
--- 538,565 
RETURN_FALSE;
}
  
+   if (PGG(allowed_dblist) != NULL && PQdb(pgsql) != NULL) {
+   tmp_allowed_dblist = estrdup(PGG(allowed_dblist));
+   token = php_strtok_r(tmp_allowed_dblist, ":", &last);
+   while (token) {
+   if (strcmp(token, PQdb(pgsql)) == 0)
+   break;
+   token = php_strtok_r(NULL, ":", &last);
+   }
+ 
+   efree(tmp_allowed_dblist);
+   if (token == NULL) {
+   php_error(E_WARNING,"%s() unable to connect to 
+"
+   "PostgreSQL server: FATAL 1: Database 
+\"%s\" "
+   "does not exist in the system 
+catalog.",
+   get_active_function_name(TSRMLS_C), 
+PQdb(pgsql));
+   PQfinish(pgsql);
+   pgsql = NULL;
+   efree(hashed_details);
+   RETURN_FALSE;
+   }
+   }
+ 
PQsetNoticeProcessor(pgsql, _notice_handler, NULL);
  
/* hash it up */
***
*** 625,630 
--- 652,679 
efree(hashed_details);
RETURN_FALSE;
}
+ 
+   if (PGG(allowed_dblist) != NULL && PQdb(pgsql) != NULL) {
+   tmp_allowed_dblist = estrdup(PGG(allowed_dblist));
+   token = php_strtok_r(tmp_allowed_dblist, ":", &last);
+   while (token) {
+   if (strcmp(token, PQdb(pgsql)) == 0)
+   break;
+   token = php_strtok_r(NULL, ":", &last);
+   }
+ 
+   efree(tmp_allowed_dblist);
+   if (token == NULL) {
+   php_error(E_WARNING,"%s() unable to connect to 
+"
+   "PostgreSQL se

[PHP-DEV] Re: open_basedir bug

[Andrei Zmievski]

Wez, have you had a chance to look at #19292?

-Andrei   http://www.gravitonic.com/
* My wishlist: http://www.amazon.com/exec/obidos/wishlist/2Q2DIPY7BZLSH/ *

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] Re: cvs: php4 /ext/standard css.c info.c /main php_ini.c /sapi/aolserveraolserver.c /sapi/apache php_apache.c

[Sebastian Bergmann]

Colin Viebrock wrote:
> Jani/Derrick/et al ... is this okay with you now?

  ZTS build is broken, fix coming up right away.

-- 
  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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] php_request_shutdown_for_exec and a bunch of bugs

[Wez Furlong]

Anyone have any ideas or insight on these bug reports:

#15529 ap_cleanup_for_exec not used when creating 
#16548 exec or system a daemon will catch the port for this session
#15642 system() with background execution hangs due to bogus filehandles open 

It appears that the problem is due to this bit of code in main/main.c

void php_request_shutdown_for_exec(void *dummy)
{
TSRMLS_FETCH();

/* used to close fd's in the 3..255 range here, but it's problematic
 */
shutdown_memory_manager(1, 1 TSRMLS_CC);
}

The comment says that closing those fd's is problematic but doesn't say
why - and those PRs appear to need those fd's to be closed in order to be
resolved.

I've tried looking through the CVS log for main/main.c but didn't have
much luck; is this something of a hangover from PHP 3 days or did I just
miss the relevant commit?

--Wez.

-- 
Wez Furlong
The Brain Room Ltd.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] feedback on PHP's WDDX

[Jan Lehnardt]

Hi,
can you please file a bugreport on bugs.php.net and assign it to me (cvs id is
jan). I'll look into this.> 

Jan
-- 
Q: Thank Jan? A: http://geschenke.an.dasmoped.net/
Got an old and spare laptop? Please send me a mail.
Key7BCC EB86 8313 DDA9 25DF  
Fingerprint1805 ECA5 BCB7 BB96 56B0

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard config.m4 css.c css.h info.c /main php_ini.c /sapi/aolserver aolserver.c /sapi/apache php_apache.c

[Michael Mauch]

Colin Viebrock <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> "render nicely" is something else than "total unreadable" to me. Did you 
>> have a look at it with Netscape Navigator 4? Please fix something for 
>> it, as it's pretty horrible now.
> 
> Can you send me a screen grab?  I did test it under NS 4.7 (Win), and I
> think you're exaggerating a bit, because it's hardly unreadable.

With Netscape 4.7x on Linux and Windows, I see a lot of vertical
whitespace in some places, e.g. directly after "PHP Core" there's a
screen full of nothing.

> I guess my other question is how far back are we willing to care about
> browser compatability?  Netscape 4.7 is now 3 years old and accounts for
> less 5% of the traffic we've seen at easyDNS in the last year (I don't
> think the stats program at www.php.net tracks browsers unfortunately).

At work, we still have to use 4.7x on the Unix machines in the intranet.
There's no internet connection, so these won't ever show up in any
browser stats.

The patch below addresses that whitespace problem. According to
, it
only affects Netscape 4.x, and the W3C CSS validator has no problems
with it. I also tested the resulting page on IE5/Win and Mozilla 1.2a
and Opera 6.0 on Linux.

Can you please apply it?

Regards...
Michael

--- php4/ext/standard/css.c~Thu Sep 19 23:57:24 2002
+++ php4/ext/standard/css.c Thu Sep 26 00:26:28 2002
@@ -58,9 +58,13 @@
PUTS("}\n");
PUTS("td, th {");
PUTS("vertical-align: baseline;");
-   PUTS("padding: 3px;");
PUTS("border: 1px solid #00;");
PUTS("}\n");
+   PUTS("@media all { td, th {");
+   PUTS("vertical-align: baseline;");
+   PUTS("padding: 3px;");
+   PUTS("border: 1px solid #00;");
+   PUTS("} }\n");
PUTS("h1 {");
PUTS("text-align: center;");
PUTS("font-size: 160%;");

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] autoconf version

[Justin Erenkrantz]

On Thu, Sep 26, 2002 at 11:03:18AM -0400, Colin Viebrock wrote:
> I'm just wondering if that's a mistake.  Does 2.53 contain buggy cache
> code and is downgrading my version of autoconf really the appropriate
> solution?  Or was the cache issue solved in a later version, and the
> buildconf message needs to be updated?

Yes, autoconf-2.53 has a 'feature' called autom4te.cache which fails
to update when any m4 dependency is changed.  Therefore, yes, it is
very buggy and autoconf 2.53 and higher should be avoided at all
costs.  The only solution is to manually remove autom4te.cache to get
a correct configure script built.  This, of course, negates the
purpose of the cache entirely.  -- justin

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] include statement in php.ini file

[David Viner]

I thought about reading only *.ini files when directories were specified,
and the main reason I didn't implement that is simply because I thought the
PHP include functionality should behave like Apache's Include directive.
Apache's include doesn't worry about ~ files and .ORIG or .OLD or .bak
files, so why should PHP's?  That said, I am happy to rework the patch to
only include files that end in ".ini" if the group feels this is the
appropriate action of an include statement.  (Personally, I think if a user
puts garbage in a directory, then says include that directory, then c'est la
vie.)

If the term "include" is not a good keyword, I'm also happy to rework the
patch to use any keyword the group prefers.  "additional_ini" sounds good to
me, and probably doesn't carry the other control-structure baggage.


dave

-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 5:17 AM
To: Zeev Suraski
Cc: David Viner; Php-Dev@lists. php. net
Subject: RE: [PHP-DEV] [PATCH] include statement in php.ini file


I suppose using a PHP keyword like include may lead to a desire for other
PHP keywords, perhaps something like:

additional_ini = /some/dir
additional_ini = /some/file.ini

Not sure why you want to limit it to one.  Also, they can be nested, so in
/some/dir/foo.ini you might have:

additional_ini = /some/dir/my_ext

My only concern about the full directory scanning and reading every file
is that there could be foo.ini~ created by editors or other such junk in
there.  So perhaps only read in .ini files, or maybe use the new glob code
to allow /some/dir/*.ini to specify.  Probably going a bit too far as
well.

-Rasmus


On Thu, 26 Sep 2002, Zeev Suraski wrote:

> I'm concerned that adding this directive will make lead to control
> structures requirements.  However, it is quite useful for modular
> deployment;  So, my suggestion is:
>
> - Don't introduce 'include'
> - Introduce a special 'additional_ini_directory' (name subject to change)
> which will be read after php.ini loads up.  Only one (at most) such
> directory, full path required.
>
> This gives you (as far as I can tell) the modular deployment features, but
> won't make people beg for 'if'.
>
> Thoughts?
>
> Zeev
>
> At 00:50 26/09/2002, Rasmus Lerdorf wrote:
> >I don't see any obvious problems with this patch except for a couple of
> >extrananeos changes. I was a bit indisposed last week and didn't really
> >follow the discussion leading up to this, but I have read the archive.  I
> >agree that going full out with PHP-parsed .ini files is going too far,
but
> >being able to do a simple include of individual files or directories of
> >files seems like a useful thing to me when building a modular PHP
> >deployment system.
> >
> >-Rasmus
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] autoconf version

[Jon Parise]

On Thu, Sep 26, 2002 at 11:44:37AM -0400, Dan Kalowsky wrote:

> I've been getting this on my OSX machine for awhile.  Thats because 
> autoconf 2.53 is the default for the dev tools.  Seems to be working 
> just fine.
> 
> Not entirely sure whats "buggy" about it, but I don't keep up on the 
> whole autoconf world either.
 
As I recall (check the archives to be certain), autoconf 2.53 does not
always properly update its cache when parts of the autoconf chain
(e.g. an extension's config.m4 file) are changed.  This results in
autoconf building a 'configure' script based on a stale cache.

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] autoconf version

[Dan Kalowsky]

I've been getting this on my OSX machine for awhile.  Thats because 
autoconf 2.53 is the default for the dev tools.  Seems to be working 
just fine.

Not entirely sure whats "buggy" about it, but I don't keep up on the 
whole autoconf world either.

On Thursday, September 26, 2002, at 11:03 AM, Colin Viebrock wrote:

> I run buildconf and get:
>
> ...
> buildconf: autoconf version 2.53 (ok)
> buildconf: Your version of autoconf likely contains buggy cache code.
>Running cvsclean for you.
>To avoid this, install autoconf-2.13 and automake-1.5.
> ...
>
> I'm just wondering if that's a mistake.  Does 2.53 contain buggy cache
> code and is downgrading my version of autoconf really the appropriate
> solution?  Or was the cache issue solved in a later version, and the
> buildconf message needs to be updated?
>
> - Colin
>
>
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
 >---<
Dan Kalowsky"I got my mojo working, but it
http://www.deadmime.org/~dankjust ain't working on you"
[EMAIL PROTECTED]- "Mojo",
[EMAIL PROTECTED]Muddy Waters


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] autoconf version

[derick]

On Thu, 26 Sep 2002, Colin Viebrock wrote:

> I run buildconf and get:
> 
> ...
> buildconf: autoconf version 2.53 (ok)
> buildconf: Your version of autoconf likely contains buggy cache code.
>Running cvsclean for you.
>To avoid this, install autoconf-2.13 and automake-1.5.
> ...
> 
> I'm just wondering if that's a mistake.  Does 2.53 contain buggy cache
> code and is downgrading my version of autoconf really the appropriate
> solution?  Or was the cache issue solved in a later version, and the
> buildconf message needs to be updated?

The message is perfectly OK right now. 2.53 is pretty fucked up :)

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] autoconf version

[Colin Viebrock]

I run buildconf and get:

...
buildconf: autoconf version 2.53 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
   Running cvsclean for you.
   To avoid this, install autoconf-2.13 and automake-1.5.
...

I'm just wondering if that's a mistake.  Does 2.53 contain buggy cache
code and is downgrading my version of autoconf really the appropriate
solution?  Or was the cache issue solved in a later version, and the
buildconf message needs to be updated?

- Colin


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Reimplementing .phps

[Devon O'Dell]

This would work fine, IMHO (although I was told that it wasn't worth it 
by somebody).  I'll implement it in this way and create another patch... 
maybe it'll be usable :)

Devon

Zeev Suraski wrote:

> In order to fix the backwards dependencies issues, as well as simplify 
> the implementation of phps, I suggest to ditch the existing 
> implementation of x-httpd-php-source, and replace it with an 
> almost-regular PHP request.  Instead of reading the code from 
> request_info.path_translated, we would generate a buffer that contains 
> something along the lines of the following code:
>
>  switch ($_GET["mode"]) {
> case "regular":
> highlight_file(%s);
> break;
> case "lineno":
> highlight_file(%s, 1);// or whatever is necessary
> break;
> }
> ?>
>
> where %s is request_info.path_translated, and execute it using 
> eval_string().  It would greatly simplify the implementation and make 
> it much more easy to change/maintain.
>
> Comments?
>
> Zeev



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] include statement in php.ini file

[Rasmus Lerdorf]

I suppose using a PHP keyword like include may lead to a desire for other
PHP keywords, perhaps something like:

additional_ini = /some/dir
additional_ini = /some/file.ini

Not sure why you want to limit it to one.  Also, they can be nested, so in
/some/dir/foo.ini you might have:

additional_ini = /some/dir/my_ext

My only concern about the full directory scanning and reading every file
is that there could be foo.ini~ created by editors or other such junk in
there.  So perhaps only read in .ini files, or maybe use the new glob code
to allow /some/dir/*.ini to specify.  Probably going a bit too far as
well.

-Rasmus


On Thu, 26 Sep 2002, Zeev Suraski wrote:

> I'm concerned that adding this directive will make lead to control
> structures requirements.  However, it is quite useful for modular
> deployment;  So, my suggestion is:
>
> - Don't introduce 'include'
> - Introduce a special 'additional_ini_directory' (name subject to change)
> which will be read after php.ini loads up.  Only one (at most) such
> directory, full path required.
>
> This gives you (as far as I can tell) the modular deployment features, but
> won't make people beg for 'if'.
>
> Thoughts?
>
> Zeev
>
> At 00:50 26/09/2002, Rasmus Lerdorf wrote:
> >I don't see any obvious problems with this patch except for a couple of
> >extrananeos changes. I was a bit indisposed last week and didn't really
> >follow the discussion leading up to this, but I have read the archive.  I
> >agree that going full out with PHP-parsed .ini files is going too far, but
> >being able to do a simple include of individual files or directories of
> >files seems like a useful thing to me when building a modular PHP
> >deployment system.
> >
> >-Rasmus
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] test - ignore

[Derick Rethans]

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions   http://www.jdimedia.nl/
---


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] feedback on PHP's WDDX

[Jimmy]

Hi,

I am using PHP's WDDX and find it very useful, but that's only if I
use it to exchange data between PHP program. Once I have to exchange
the data with other languange I begin to face problem after problem,
mostly because of the way PHP's WDDX interpret the variable type.

The solution for this is, instead of auto-detecting the type of a var,
PHP's WDDX should allow the user to explicitly specify the type they
want the vars to be encoded as.

For example:

$string = "1";
wddx_serialize($string, WDDX_INTEGER);
// var $string will be encoded as integer, instead of string

$file_name = "contain some unicode char";
wddx_serialize($file_name, WDDX_BINARY);
// var $file_name will be encoded as binary, instead of string


Two good reasons why this should be implemented:

1. The main purpose of WDDX is to exchange data between diff lang, and
   auto-detecting var type will break this purpose.  Moreover, the
   type-juggling in PHP will make the case worst.

   For example, consider these two data:

 array ("2" => "Two", "4" => "Four", "5" => "Five");
 array ("0" => "Zero", "1" => "One", "2" => "Two");

   The first one will be interpreted by WDDX as hash (assoc array).
   But the second one, where the key happen to be a sequence
   starting from 0, will be interpreted as normal array, not hash.

2. If users can specify the type of a variable, then PHP's WDDX can support
   all type which is defined in WDDX standard.
   For example binary type. Currently there's no way to create a
   WDDX packet with binary type, because PHP don't have binary type
   variable.  There's a workaround to manually base64 the var, but this
   will require a change at the other end to handle this workaround
   too, which in some cases is not possible.


Regards,
   
--
Jimmy

Your mind is like parachute. It works best when it is open.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] 64 bit PHP (long vs int problems) (fault)

[Vergoz Michael \(SYSDOOR\)]

> Hi,
>
> I has explain that problem in 1 week ago, and what they said to me is
"Your
> not on the good list"
> c.f: We are on PHP-_DEV_ isn't it ?
>
> and, well i'v the sames problem of you plus we can use a long integer in
> PHP.

Sorry, we can not use.

>
> Best Regards,
> Vergoz Michael
>
> - Original Message -
> From: "Jason Greene" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, September 26, 2002 5:52 AM
> Subject: [PHP-DEV] [PATCH] 64 bit PHP (long vs int problems)
>
>
> > Hello all,
> >
> > After attempting to compile php on solaris as a 64 bit executable, and
> > resolving the attempt to link libcrack (32bit lib), I was greated with a
> > nice Bus Error.
> >
> > Upon examining the source, it looks like their are alot of areas where
> > longs and ints are used interchangeably. This is not good since a 64 bit
> > solaris executable has 64 bit longs, and 32 bit ints.
> >
> > I have thrown together an initial patch that fixes this, but it does
> > make make some changes that should be thought about. (such as using a
> > long instead of an int for memmory limit and size counting) However,
> > Overall it should not make too big a difference. (especially on the
> > primarily targetted platforms whose ints and longs are the same)
> >
> > I did not check anything but the core extensions, so those will need to
> > be looked at next.
> >
> > If no one throws any major objects, I will put together a better version
> > of this patch and commit it upon completion.
> >
> > Thanks,
> >
> > --
> > Jason Greene <[EMAIL PROTECTED]>
> >
>
>
> --
--
> 
>
>
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] 64 bit PHP (long vs int problems)

[Vergoz Michael \(SYSDOOR\)]

Hi,

I has explain that problem in 1 week ago, and what they said to me is "Your
not on the good list"
c.f: We are on PHP-_DEV_ isn't it ?

and, well i'v the sames problem of you plus we can use a long integer in
PHP.

Best Regards,
Vergoz Michael

- Original Message -
From: "Jason Greene" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 26, 2002 5:52 AM
Subject: [PHP-DEV] [PATCH] 64 bit PHP (long vs int problems)


> Hello all,
>
> After attempting to compile php on solaris as a 64 bit executable, and
> resolving the attempt to link libcrack (32bit lib), I was greated with a
> nice Bus Error.
>
> Upon examining the source, it looks like their are alot of areas where
> longs and ints are used interchangeably. This is not good since a 64 bit
> solaris executable has 64 bit longs, and 32 bit ints.
>
> I have thrown together an initial patch that fixes this, but it does
> make make some changes that should be thought about. (such as using a
> long instead of an int for memmory limit and size counting) However,
> Overall it should not make too big a difference. (especially on the
> primarily targetted platforms whose ints and longs are the same)
>
> I did not check anything but the core extensions, so those will need to
> be looked at next.
>
> If no one throws any major objects, I will put together a better version
> of this patch and commit it upon completion.
>
> Thanks,
>
> --
> Jason Greene <[EMAIL PROTECTED]>
>






> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: CLI and HTTP header, GLOB_NOSORT

[Yasuo Ohgaki]

I got a little time, so I removed dup of GLOB_NOSORT
definition. Header problem remains.

--
Yasuo Ohgaki

Yasuo Ohgaki wrote:
> Something wrong in current CVS.
> 
> 
> [yohgaki@dev HEAD]$ php
> HTTP/1.0 0 X
> Content-type: text/html; charset=EUC-JP
> 
> PHP Notice:  Constant GLOB_NOSORT already defined in Unknown on line 0
> Unknown(0) : Notice - Constant GLOB_NOSORT already defined
> [yohgaki@dev HEAD]$ php -v
> HTTP/1.0 0 X
> Content-type: text/html; charset=EUC-JP
> 
> PHP Notice:  Constant GLOB_NOSORT already defined in Unknown on line 0
> Unknown(0) : Notice - Constant GLOB_NOSORT already defined
> PHP 4.3.0-dev (cli), Copyright (c) 1997-2002 The PHP Group
> Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
> [yohgaki@dev HEAD]$
> 
> --
> Yasuo Ohgaki
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CLI and HTTP header, GLOB_NOSORT

[Yasuo Ohgaki]

Something wrong in current CVS.


[yohgaki@dev HEAD]$ php
HTTP/1.0 0 X
Content-type: text/html; charset=EUC-JP

PHP Notice:  Constant GLOB_NOSORT already defined in Unknown on line 0
Unknown(0) : Notice - Constant GLOB_NOSORT already defined
[yohgaki@dev HEAD]$ php -v
HTTP/1.0 0 X
Content-type: text/html; charset=EUC-JP

PHP Notice:  Constant GLOB_NOSORT already defined in Unknown on line 0
Unknown(0) : Notice - Constant GLOB_NOSORT already defined
PHP 4.3.0-dev (cli), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
[yohgaki@dev HEAD]$

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php