Re: [PHP-DEV] [patch] solaris getcwd() brokeness

2003-02-23 Thread James E. Flemer 
Oh good, it hasn't been forgotten.  I just want to point
out that if committed the open() statement should probably
use O_RDONLY.  [main.c @ ~1542]  I used 0 because I didn't
have time to figure out where to add the correct #include
to get O_RDONLY into main.c.

-James

On Sun, 23 Feb 2003, Wez Furlong wrote:

 Hi Andi (and James)

 Andi: I'd appreciate your comments on this patch, specifically if there
 are any concerns about it doing the right thing.

 Most people here:
 http://bugs.php.net/bug.php?id=21310edit=1

 report that it fixes their problems with solaris.

 I've held off from looking at this, as I didn't want to duplicate any
 effort you have been making.

 --Wez.

 On Sun, 16 Feb 2003, Andi Gutmans wrote:

  At 03:41 PM 2/13/2003 -0500, James E. Flemer wrote:
  RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
  retrieving revision 1.41
  diff -u -b -r1.41 tsrm_virtual_cwd.c
  --- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
  +++ TSRM/tsrm_virtual_cwd.c 13 Feb 2003 20:40:07 -
  @@ -303,7 +303,7 @@
   return (0);
  
#if !defined(TSRM_WIN32)  !defined(NETWARE)
  -   if (IS_ABSOLUTE_PATH(path, path_length)) {
  +   if (IS_ABSOLUTE_PATH(path, path_length) || (state-cwd_length  1)) {
   if (use_realpath  realpath(path, resolved_path)) {
   path = resolved_path;
   path_length = strlen(path);
 
  Will realpath() work in cases where getcwd() didn't work? (btw it's nicer
  to check state-cwd_length == 0 than  1 IMO).
 
  @@ -363,6 +363,7 @@
   }
  
  
  +  if (state-cwd_length  0 || IS_ABSOLUTE_PATH(path, path_length)) {
   ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, tok);
   while (ptr) {
   ptr_length = strlen(ptr);
  @@ -416,6 +417,11 @@
   state-cwd[state-cwd_length+1] = '\0';
   state-cwd_length++;
   }
  +  } else {
  +   state-cwd = (char *) realloc(state-cwd, path_length+1);
  +   memcpy(state-cwd, path, path_length+1);
  +   state-cwd_length = path_length;
  +  }
 
  I'm trying to think if there's some other way of doing this. What is the
  main problem in this loop? Does it add  / or c:\ in the beginning of the
  string?
 
  Andi
 
 
  --
  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] solaris getcwd() brokeness

2003-02-16 Thread James E. Flemer 
When getcwd() fails in certain places, we end up passing a
zero length cwd_state to virtual_file_ex().  This causes
virtual_file_ex() to assume the path to be /, thus:
  include(foo.php);
ends up trying to open, /foo.php, which is wrong.  If you
want to play with this problem, its very easy to simulate
on a non-broken environment, just do:
  #define VCWD_GETCWD(buff, size)  (EACCES)
(or to a func that returns EACCES in case VCWD_GETCWD() is
ever used).

-James

On Sat, 15 Feb 2003, Andi Gutmans wrote:

 Hey,

 The fchdir() part of the patch looks fine but I didn't quite understand the
 rest. PHP only uses realpath() if it doesn't fail, so what is the exact
 problem? What does that other code do?

 Andi

 At 03:29 PM 2/12/2003 -0500, James E. Flemer wrote:
 Well all the fancy new streams code in 4.3.0 seems to
 tickle a Solaris issue with getcwd().  It seems that under
 certain cases solaris' getcwd() fails when other os' work.
 Consequently 4.3.0 causes a huge ammount of breakage for
 some sites running solaris.  Below is a patch that seems to
 work around the problem.  This may not be the best
 approach, but it was an attempt at a quick-fix so that
 4.3.0 would be usable for now.  This problem has bug
 number: #21310 [1].  Comments welcome.  I'd like to commit
 this (or similar) before any more releases are made.
 
 -James [EMAIL PROTECTED]
 
 [1] http://bugs.php.net/21310
 
 ]] Patch sponsored by: The University of Vermont [[
 Index: TSRM/tsrm_virtual_cwd.c
 ===
 RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
 retrieving revision 1.41
 diff -u -b -u -r1.41 tsrm_virtual_cwd.c
 --- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
 +++ TSRM/tsrm_virtual_cwd.c 12 Feb 2003 04:39:11 -
 @@ -303,7 +303,7 @@
  return (0);
 
   #if !defined(TSRM_WIN32)  !defined(NETWARE)
 -   if (IS_ABSOLUTE_PATH(path, path_length)) {
 +   if (IS_ABSOLUTE_PATH(path, path_length) || (state-cwd_length  1))
 {
  if (use_realpath  realpath(path, resolved_path)) {
  path = resolved_path;
  path_length = strlen(path);
 @@ -363,6 +363,7 @@
  }
 
 
 +  if (state-cwd_length  0 || IS_ABSOLUTE_PATH(path, path_length)) {
  ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, tok);
  while (ptr) {
  ptr_length = strlen(ptr);
 @@ -416,6 +417,11 @@
  state-cwd[state-cwd_length+1] = '\0';
  state-cwd_length++;
  }
 +  } else {
 +   state-cwd = (char *) realloc(state-cwd, path_length+1);
 +   memcpy(state-cwd, path, path_length+1);
 +   state-cwd_length = path_length;
 +  }
 
  if (verify_path  verify_path(state)) {
  CWD_STATE_FREE(state);
 Index: main/main.c
 ===
 RCS file: /repository/php4/main/main.c,v
 retrieving revision 1.512.2.5
 diff -u -b -u -r1.512.2.5 main.c
 --- main/main.c 16 Dec 2002 15:44:06 -  1.512.2.5
 +++ main/main.c 12 Feb 2003 04:39:12 -
 @@ -1507,7 +1507,11 @@
   {
  zend_file_handle *prepend_file_p, *append_file_p;
  zend_file_handle prepend_file, append_file;
 +#ifdef VIRTUAL_DIR
  char *old_cwd;
 +#else
 +   int old_cwd_fd;
 +#endif
  char *old_primary_file_path = NULL;
  int retval = 0;
 
 @@ -1515,9 +1519,11 @@
  if (php_handle_special_queries(TSRMLS_C)) {
  return 0;
  }
 +#ifdef VIRTUAL_DIR
   #define OLD_CWD_SIZE 4096
  old_cwd = do_alloca(OLD_CWD_SIZE);
  old_cwd[0] = '\0';
 +#endif
 
  zend_try {
   #ifdef PHP_WIN32
 @@ -1528,7 +1534,11 @@
 
  if (primary_file-type == ZEND_HANDLE_FILENAME
   primary_file-filename) {
 +#ifdef VIRTUAL_DIR
  VCWD_GETCWD(old_cwd, OLD_CWD_SIZE-1);
 +#else
 +   old_cwd_fd = open(., 0);
 +#endif
  VCWD_CHDIR_FILE(primary_file-filename);
  }
 
 @@ -1578,10 +1588,14 @@
 
  } zend_end_try();
 
 +#ifdef VIRTUAL_DIR
  if (old_cwd[0] != '\0') {
  VCWD_CHDIR(old_cwd);
  }
  free_alloca(old_cwd);
 +#else
 +   fchdir(old_cwd_fd);
 +#endif
  return retval;
   }
   /* }}} */
 Index: main/safe_mode.c
 ===
 RCS file: /repository/php4/main/safe_mode.c,v
 retrieving revision 1.51
 diff -u -b -u -r1.51 safe_mode.c
 --- main/safe_mode.c6 Nov 2002 18:07:23 -   1.51
 +++ main/safe_mode.c12 Feb 2003 04:39:12 -
 @@ -121,6 +121,8 @@
  VCWD_REALPATH(filename, path);
  *s = DEFAULT_SLASH;
  } else {
 +   path[0] = '.';
 +   path[1] = '\0';
  VCWD_GETCWD(path

Re: [PHP-DEV] [patch] solaris getcwd() brokeness

2003-02-16 Thread James E. Flemer 
On Sun, 16 Feb 2003, Andi Gutmans wrote:

 At 03:41 PM 2/13/2003 -0500, James E. Flemer wrote:
 RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
 retrieving revision 1.41
 diff -u -b -r1.41 tsrm_virtual_cwd.c
 --- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
 +++ TSRM/tsrm_virtual_cwd.c 13 Feb 2003 20:40:07 -
 @@ -303,7 +303,7 @@
  return (0);
 
   #if !defined(TSRM_WIN32)  !defined(NETWARE)
 -   if (IS_ABSOLUTE_PATH(path, path_length)) {
 +   if (IS_ABSOLUTE_PATH(path, path_length) || (state-cwd_length  1)) {
  if (use_realpath  realpath(path, resolved_path)) {
  path = resolved_path;
  path_length = strlen(path);

 Will realpath() work in cases where getcwd() didn't work? (btw it's nicer
 to check state-cwd_length == 0 than  1 IMO).

Most realpath() implementations call getcwd();  realpath()
on Solaris seems to, so it fails too.

 @@ -363,6 +363,7 @@
  }
 
 
 +  if (state-cwd_length  0 || IS_ABSOLUTE_PATH(path, path_length)) {
  ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, tok);
  while (ptr) {
  ptr_length = strlen(ptr);
 @@ -416,6 +417,11 @@
  state-cwd[state-cwd_length+1] = '\0';
  state-cwd_length++;
  }
 +  } else {
 +   state-cwd = (char *) realloc(state-cwd, path_length+1);
 +   memcpy(state-cwd, path, path_length+1);
 +   state-cwd_length = path_length;
 +  }

 I'm trying to think if there's some other way of doing this. What is the
 main problem in this loop? Does it add  / or c:\ in the beginning of the
 string?

Yes, that loop adds prefix of /.  Like I said, this
probably is not the cleanest solution, but it was quick and
got 4.3 running for now.  I am open to suggestions on
improvement.  One thought of mine was to wrap getcwd() so
that when it fails, it would return ., and then make sure
that nothing *needed* absolute paths.  (I believe the
_once() functions will not like this, or may end up
allowing the same file included multiple times w/o the help
of realpath().)

I sort of wonder why PHP does uses getcwd()/realpath() so
much.  It is commonly recomended to use open(.) and
fchdir() for a directory stack.  Resolving every single
opened file with realpath() seems a waste.  I saw some
discussion on this last month (Subj: Reducing the number of
system calls ...).  If the main issue was _once(), would it
be possible to use inodes to prevent multiple inclusion?
(You'd still need a fstat() to get inodes but no realpath()
or getcwd().)

-James




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

Re: [PHP-DEV] [patch] solaris getcwd() brokeness

2003-02-13 Thread James E. Flemer 
Here's that same patch, but without leaking a file
descriptor.  Any comments yet?  Any objections to
committing it?
-James

On Wed, 12 Feb 2003, James E. Flemer wrote:

 Well all the fancy new streams code in 4.3.0 seems to
 tickle a Solaris issue with getcwd().  It seems that under
 certain cases solaris' getcwd() fails when other os' work.
 Consequently 4.3.0 causes a huge ammount of breakage for
 some sites running solaris.  Below is a patch that seems to
 work around the problem.  This may not be the best
 approach, but it was an attempt at a quick-fix so that
 4.3.0 would be usable for now.  This problem has bug
 number: #21310 [1].  Comments welcome.  I'd like to commit
 this (or similar) before any more releases are made.

 -James [EMAIL PROTECTED]

 [1] http://bugs.php.net/21310

 ]] Patch sponsored by: The University of Vermont [[
-- old patch removed, new patch follows --

Index: TSRM/tsrm_virtual_cwd.c
===
RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
retrieving revision 1.41
diff -u -b -r1.41 tsrm_virtual_cwd.c
--- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
+++ TSRM/tsrm_virtual_cwd.c 13 Feb 2003 20:40:07 -
@@ -303,7 +303,7 @@
return (0);

 #if !defined(TSRM_WIN32)  !defined(NETWARE)
-   if (IS_ABSOLUTE_PATH(path, path_length)) {
+   if (IS_ABSOLUTE_PATH(path, path_length) || (state-cwd_length  1)) {
if (use_realpath  realpath(path, resolved_path)) {
path = resolved_path;
path_length = strlen(path);
@@ -363,6 +363,7 @@
}


+  if (state-cwd_length  0 || IS_ABSOLUTE_PATH(path, path_length)) {
ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, tok);
while (ptr) {
ptr_length = strlen(ptr);
@@ -416,6 +417,11 @@
state-cwd[state-cwd_length+1] = '\0';
state-cwd_length++;
}
+  } else {
+   state-cwd = (char *) realloc(state-cwd, path_length+1);
+   memcpy(state-cwd, path, path_length+1);
+   state-cwd_length = path_length;
+  }

if (verify_path  verify_path(state)) {
CWD_STATE_FREE(state);
Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.512.2.5
diff -u -b -r1.512.2.5 main.c
--- main/main.c 16 Dec 2002 15:44:06 -  1.512.2.5
+++ main/main.c 13 Feb 2003 20:40:07 -
@@ -1507,7 +1507,11 @@
 {
zend_file_handle *prepend_file_p, *append_file_p;
zend_file_handle prepend_file, append_file;
+#ifdef VIRTUAL_DIR
char *old_cwd;
+#else
+   int old_cwd_fd;
+#endif
char *old_primary_file_path = NULL;
int retval = 0;

@@ -1515,9 +1519,11 @@
if (php_handle_special_queries(TSRMLS_C)) {
return 0;
}
+#ifdef VIRTUAL_DIR
 #define OLD_CWD_SIZE 4096
old_cwd = do_alloca(OLD_CWD_SIZE);
old_cwd[0] = '\0';
+#endif

zend_try {
 #ifdef PHP_WIN32
@@ -1528,7 +1534,11 @@

if (primary_file-type == ZEND_HANDLE_FILENAME
 primary_file-filename) {
+#ifdef VIRTUAL_DIR
VCWD_GETCWD(old_cwd, OLD_CWD_SIZE-1);
+#else
+   old_cwd_fd = open(., 0);
+#endif
VCWD_CHDIR_FILE(primary_file-filename);
}

@@ -1578,10 +1588,15 @@

} zend_end_try();

+#ifdef VIRTUAL_DIR
if (old_cwd[0] != '\0') {
VCWD_CHDIR(old_cwd);
}
free_alloca(old_cwd);
+#else
+   fchdir(old_cwd_fd);
+   close(old_cwd_fd);
+#endif
return retval;
 }
 /* }}} */
Index: main/safe_mode.c
===
RCS file: /repository/php4/main/safe_mode.c,v
retrieving revision 1.51
diff -u -b -r1.51 safe_mode.c
--- main/safe_mode.c6 Nov 2002 18:07:23 -   1.51
+++ main/safe_mode.c13 Feb 2003 20:40:07 -
@@ -121,6 +121,8 @@
VCWD_REALPATH(filename, path);
*s = DEFAULT_SLASH;
} else {
+   path[0] = '.';
+   path[1] = '\0';
VCWD_GETCWD(path, sizeof(path));
}
} /* end CHECKUID_ALLOW_ONLY_DIR */


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

[PHP-DEV] [patch] solaris getcwd() brokeness

2003-02-12 Thread James E. Flemer 
Well all the fancy new streams code in 4.3.0 seems to
tickle a Solaris issue with getcwd().  It seems that under
certain cases solaris' getcwd() fails when other os' work.
Consequently 4.3.0 causes a huge ammount of breakage for
some sites running solaris.  Below is a patch that seems to
work around the problem.  This may not be the best
approach, but it was an attempt at a quick-fix so that
4.3.0 would be usable for now.  This problem has bug
number: #21310 [1].  Comments welcome.  I'd like to commit
this (or similar) before any more releases are made.

-James [EMAIL PROTECTED]

[1] http://bugs.php.net/21310

]] Patch sponsored by: The University of Vermont [[
Index: TSRM/tsrm_virtual_cwd.c
===
RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
retrieving revision 1.41
diff -u -b -u -r1.41 tsrm_virtual_cwd.c
--- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
+++ TSRM/tsrm_virtual_cwd.c 12 Feb 2003 04:39:11 -
@@ -303,7 +303,7 @@
return (0);

 #if !defined(TSRM_WIN32)  !defined(NETWARE)
-   if (IS_ABSOLUTE_PATH(path, path_length)) {
+   if (IS_ABSOLUTE_PATH(path, path_length) || (state-cwd_length  1))
{
if (use_realpath  realpath(path, resolved_path)) {
path = resolved_path;
path_length = strlen(path);
@@ -363,6 +363,7 @@
}


+  if (state-cwd_length  0 || IS_ABSOLUTE_PATH(path, path_length)) {
ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, tok);
while (ptr) {
ptr_length = strlen(ptr);
@@ -416,6 +417,11 @@
state-cwd[state-cwd_length+1] = '\0';
state-cwd_length++;
}
+  } else {
+   state-cwd = (char *) realloc(state-cwd, path_length+1);
+   memcpy(state-cwd, path, path_length+1);
+   state-cwd_length = path_length;
+  }

if (verify_path  verify_path(state)) {
CWD_STATE_FREE(state);
Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.512.2.5
diff -u -b -u -r1.512.2.5 main.c
--- main/main.c 16 Dec 2002 15:44:06 -  1.512.2.5
+++ main/main.c 12 Feb 2003 04:39:12 -
@@ -1507,7 +1507,11 @@
 {
zend_file_handle *prepend_file_p, *append_file_p;
zend_file_handle prepend_file, append_file;
+#ifdef VIRTUAL_DIR
char *old_cwd;
+#else
+   int old_cwd_fd;
+#endif
char *old_primary_file_path = NULL;
int retval = 0;

@@ -1515,9 +1519,11 @@
if (php_handle_special_queries(TSRMLS_C)) {
return 0;
}
+#ifdef VIRTUAL_DIR
 #define OLD_CWD_SIZE 4096
old_cwd = do_alloca(OLD_CWD_SIZE);
old_cwd[0] = '\0';
+#endif

zend_try {
 #ifdef PHP_WIN32
@@ -1528,7 +1534,11 @@

if (primary_file-type == ZEND_HANDLE_FILENAME
 primary_file-filename) {
+#ifdef VIRTUAL_DIR
VCWD_GETCWD(old_cwd, OLD_CWD_SIZE-1);
+#else
+   old_cwd_fd = open(., 0);
+#endif
VCWD_CHDIR_FILE(primary_file-filename);
}

@@ -1578,10 +1588,14 @@

} zend_end_try();

+#ifdef VIRTUAL_DIR
if (old_cwd[0] != '\0') {
VCWD_CHDIR(old_cwd);
}
free_alloca(old_cwd);
+#else
+   fchdir(old_cwd_fd);
+#endif
return retval;
 }
 /* }}} */
Index: main/safe_mode.c
===
RCS file: /repository/php4/main/safe_mode.c,v
retrieving revision 1.51
diff -u -b -u -r1.51 safe_mode.c
--- main/safe_mode.c6 Nov 2002 18:07:23 -   1.51
+++ main/safe_mode.c12 Feb 2003 04:39:12 -
@@ -121,6 +121,8 @@
VCWD_REALPATH(filename, path);
*s = DEFAULT_SLASH;
} else {
+   path[0] = '.';
+   path[1] = '\0';
VCWD_GETCWD(path, sizeof(path));
}
} /* end CHECKUID_ALLOW_ONLY_DIR */


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

Re: [PHP-DEV] preg_replace oddity [exploitable]

2003-02-03 Thread James E. Flemer 
On Mon, 3 Feb 2003, Maxim Maletsky wrote:

 James E. Flemer [EMAIL PROTECTED] wrote... :

  I found a more evil example:
 
  ?php
$a = ___! `rm -rf /tmp/sess_*` !___;
$b = preg_replace(/!(.*)!/e, print(\\1);, $a);
  ?
 
  This happily executes rm -rf /tmp/sess_*.  I will not
  give out more examples, but if one examines the code for
  addslashes() it is quite obvious what you can an cannot do
  here.  Thus it is clearly a Bad Thing for someone to use
  preg_replace with the /e modifier and not use quotes around
  the \\n or $n backrefs.
 
  The docs should be updated to include a very noticeable
  warning about this hole.  I am contemplating possible
  solutions for this problem...
--snip--

 In fact, /e eval()uates the code. It does with the replaced result just
 what eval() does with a string PHP code. At most, it could be noted in
 docs.

Yes, I am aware of that, that is what /e is for.  The issue
is not that it eval()s the code, the issue is weather or
not the backrefs (\\1 or $1 etc) are enclosed in single
quotes.  The preg_replace()  code calls php_addslashes() on
the backref data, so if the backref is enclosed in quotes
then there is no way to do anything malicious.  However if
a PHP coder writes a script that uses preg_replace()
without placing quotes around a backref, and the subject
(arg 1) of the function can be supplied by the remote user,
then the remote user can easily insert potentially
dangerous code that will be executed on the server with the
running permision of the web server.

Now consider the use of this expliot in conjunction with a
know local-user expliot for some OS.  PHP provides
convinient easy access to execute arbitrary commands as a
local user...  I think it should be explicitly stated in
the docs for preg_replace() that Bad Things can occur if
backrefs are not enclosed in single quotes, and that mildly
bad things can occur if they are enclosed in double quotes
(i.e. variable expansion of possibly sensative local
variables).

-James


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

Re: [PHP-DEV] preg_replace oddity [exploitable]

2003-02-02 Thread James E. Flemer 
I found a more evil example:

?php
  $a = ___! `rm -rf /tmp/sess_*` !___;
  $b = preg_replace(/!(.*)!/e, print(\\1);, $a);
?

This happily executes rm -rf /tmp/sess_*.  I will not
give out more examples, but if one examines the code for
addslashes() it is quite obvious what you can an cannot do
here.  Thus it is clearly a Bad Thing for someone to use
preg_replace with the /e modifier and not use quotes around
the \\n or $n backrefs.

The docs should be updated to include a very noticeable
warning about this hole.  I am contemplating possible
solutions for this problem...

Also as a side note, it does not seem to be possible to use
'echo' as part of the expression, print must be used.  (Yes
I know why, just pointing it out.)

-James


On Thu, 30 Jan 2003, James E. Flemer wrote:

 Can someone explain what is going on here:

 --- foo.php ---
 ?php
   $a = ___! 52); echo(42 !___;
   $b = preg_replace(/!(.*)!/e, print(\\1);, $a);
   print(\n---\na: $a\nb: $b\n);
 ?
 --- end ---
 --- output ---
 52
 ---
 a: ___! 52); echo(42 !___
 b: ___1___
 --- end ---

 I understand that one is supposed to use single quotes
 around the \\1 in the above preg_replace.  But what happens
 when they do not?  Clearly the echo(42); is not executed,
 and it is not printed by print().  Even more interesting is
 if you put something like echo(\42 in $a, then you get a
 bunch of errors including:
   Fatal error - Failed evaluating code:
   print( 52); echo(\42 );

 It seems like preg_replace() is doing some strange things,
 and might be something that could be exploitable if a
 remote user can supply the first argument, and the second
 argument does not enclose \\n options.

 -James





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

[PHP-DEV] preg_replace oddity

2003-01-30 Thread James E. Flemer 
Can someone explain what is going on here:

--- foo.php ---
?php
  $a = ___! 52); echo(42 !___;
  $b = preg_replace(/!(.*)!/e, print(\\1);, $a);
  print(\n---\na: $a\nb: $b\n);
?
--- end ---
--- output ---
52
---
a: ___! 52); echo(42 !___
b: ___1___
--- end ---

I understand that one is supposed to use single quotes
around the \\1 in the above preg_replace.  But what happens
when they do not?  Clearly the echo(42); is not executed,
and it is not printed by print().  Even more interesting is
if you put something like echo(\42 in $a, then you get a
bunch of errors including:
  Fatal error - Failed evaluating code:
  print( 52); echo(\42 );

It seems like preg_replace() is doing some strange things,
and might be something that could be exploitable if a
remote user can supply the first argument, and the second
argument does not enclose \\n options.

-James


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

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana-Opn]: session.gc_maxlifetimedoes not work

2002-08-17 Thread James E. Flemer 

Would it be difficult to just add a dirty flag somewhere,
so that the session data only gets written out iff a
variable has been added, removed, or changed? That way
existing php code using sessions would have improved
performance. Perhaps combine this idea with Zeev's idea of
using 'touch'. I don't see why adding session_readonly() is
really necessary, the only possible benefit I see is to
avoid the locking issue (with frames etc) on the session
file. The locking issue can be solved with
session_write_close() though, and in the case of a dirty
flag, would not even write anything out.

-James

On Fri, 16 Aug 2002, Rasmus Lerdorf wrote:

 Ok, thinking a bit more about this..  session_readonly() really should be
 implemented.  Imagine a system where you have dynamically generated
 images/flash/pdf or even just a straight framed site.  You use sessions to
 pass information around between not only pages, but also to the
 dynamically generated pieces of a page.  Having the session backend
 rewrite the same session data many times per request is a waste and if you
 know that you are only going to read in the pdf generator script, for
 example, it would be a good idea to open the session readonly from that
 script.  Or not even that fancy.  You have a standard login page where you
 pull some data from a database about the user, stick it in a session and
 then the user clicks through the rest of the site.  It wouldn't be that
 strange to have hundreds of pages that would need to read that session
 data, but never write to it.  With the current implementation we are
 needlessly overwriting the same data on every single request.

 If session_readonly() gets implemented then removing atime support for
 filesystems that support that seems like a step in the wrong direction.
 We should perhaps have a modifier on session mod_files which tells it
 whether it should use atime, mtime or perhaps even ctime.  Another
 configuration directive sucks, but even if we could detect at runtime that
 atime was not supported, silently falling back to mtime doesn't seem like
 a good idea.  I suppose we could change the default to mtime, implement
 session_readonly() and give people the option to switch it to atime.

 -Rasmus

 On Sat, 17 Aug 2002, Zeev Suraski wrote:

  Just wondering - why are we even using atime?  I think lots of filesystems
  don't support it, but regardless of that - as far as I recall from reading
  the session code, if a session is opened for reading - it is also going to
  be rewritten at the end of the session.  So, it should be quite safe to
  check mtime instead of atime.
  Comments?
 
  Zeev
 
  At 04:03 17/08/2002, [EMAIL PROTECTED] wrote:
ID:   3793
Updated by:   [EMAIL PROTECTED]
Reported By:  [EMAIL PROTECTED]
  -Status:   Analyzed
  +Status:   Open
  -Bug Type: Session related
  +Bug Type: Documentation problem
Operating System: Windows 98
PHP Version:  4 .1.2
New Comment:
  
  I really don't see anybody with any interest in writing code to make
  this work on FAT filesystems.  Don't run web servers on crap
  filesystems.  If you do, write your own session handler.  Same goes for
  filesystems where file modification timestamps are ignored.  Write your
  own session handler and manage the garbage collection yourself.  We'll
  need to document this, of course, so marking this as a documentation
  problem.
  
  
  Previous Comments:
  
  
  [2002-07-10 05:10:43] [EMAIL PROTECTED]
  
  I've exactly the same problem with Windows 2000, php 4.2.0 and apache
  1.3
  
  
  
  [2002-03-31 03:49:43] [EMAIL PROTECTED]
  
  After I tried about a week, by just setting the lifetime VERY high
  (4 first), maybe I can give a hint:
  
  With this very high value it worked, so I tried where exactly was the
  critical point. It was somewhat about 32000. Slightly below, all
  session files were deleted as described, slightly over not. But then
  the error reoccurred with the same value.
  
  After some tries I found out the following: I set back the time on the
  server one hour and it worked again. Here the times and the critical
  points:
  
  At 9:24 local time : 30290
  At 10:28 : 34100
  
  34100-30290=3810, which would be 63.5 minutes when interpretad as
  seconds, which is the server's time difference...
  
  Since 10:28 means 37680 s since 0:00, there seems to be an additional
  hour - maybe due to GMT setting (+1) I thought, but it was the
  automatic daylight saving (or is it called summer time???) setting.
  When turned off, at 9:45 the point was at 35100=9.75 hours...
  
  I hope that helps... ;-)
  
  -- mike
  
  
  
  [2002-03-31 02:56:29] [EMAIL PROTECTED]
  
  It seems it never worked under windows.
  Reopen

Re: [PHP-DEV] 4.2.3

2002-08-17 Thread James E. Flemer 

Perhaps the Status field could be expanded so that bugs
that are deemed necessary for the stable branch would
follow a path like:

  open - ... - fixed in current - merged to stable -
  closed (or something like that)

That way if a bug is fixed in current, it will remain
open until it is tested there, merged into stable and
tested there. Clearly not all bugs would need merging to
stable, and most would just be closed right away. At least
this way people could request merging into stable, and one
could search bugs based on status for a list of
to-be-merged bugs before considering any bug-fix releases.
That might help reduce the number of things that get
overlooked on the stable branch.

-James

On Sat, 17 Aug 2002, Xavier Spriet wrote:

 This is quiteconcerning.
 It appears the PHP release process is not suited to the way PHP is developed anymore
 and this can lead in severe inconsistencies.
 What seemed to have happened is that several bugfixes were fixed in CVS instead of 
the bugfix release which if fine with me... but the bugs in question are pretty 
important.
 This seems to be partly due to a lack of communication between developement and QA 
since this problem was aborded weeks ago already and Sebastian Nohn raised that 
question on several occasions.

 The way the developement team and qa can improve the organisation for better 
communication can be solved easily in the upcoming weeks, however, it seems now we 
have to face a more important problem.

 IMHO, it is important that the 64bits architecture related bugs be fixed in the next 
release as most of the people that will be pissed off if it doesn't, are business 
users that absolutely need a modern release to work in their environement or will 
simply stop supporting PHP in their environement/business.

 Many good suggestions have been made, mine is to find out which bugs were fixed in 
CVS and are important and spend the week on backporting them to the bugfix release, 
4.2.3
 We can have a RC1 ready for next monday and no doubt we won't need a RC2 and can 
release later that week.

 Do you guys think this could be done in an acceptable timeframe ?

 Thanks.

   -Original Message-
   From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
   Sent: Sat 17/08/2002 11:37 AM
   To: Rasmus Lerdorf
   Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
   Subject: [PHP-QA] Re: [PHP-DEV] 4.2.3



   It's not a matter of what we call it - I thought it would make sense to
   release a new version based on the 4.2 branch, because 4.3 has TONS of new
   features and is thus very likely to introduce new inconsistencies and
   bugs.  As people have said here several times in the last few weeks, most
   users will be unlikely to install 4.3.0 anyway, until they either hear it's
   ok, or see it mature with a few bugfix releases.
   Just a thought.

   Zeev

   At 18:33 17/08/2002, Rasmus Lerdorf wrote:
   Regardless of what we call it, we need to light a fire under people to get
   a new release out.  The fixes are piling up in CVS.  Stig, could you give
   us a status report?  Do you still have time to push this release?
   
   -R
   
   On Sat, 17 Aug 2002, Zeev Suraski wrote:
   
 Ok then, I retract my suggestion to release 4.2.3.

 Zeev

 At 17:59 17/08/2002, Dan Kalowsky wrote:
 I disagree that it should go out as is, very strongly at that too.
 
 Some fixes not in the 4.2 branches:
 
 - ODBC no longer crashes on Windows upon unloading
 - while not fully tested, ext/java now works for 1.4 JDK's
 - various memory leak fixes provied by Ilia (pack being one of them)
 - a few misc fixes for Win32 platforms
 - nsapi build fix which allows it to build and reported run again
(although I still think we need to decide if we can kill this support)
 - numerous domxml bug fixes have been added as well.
 - QTDOM fix to allow it to compile again and run again
 
 This is one yet to be made, but:
 - a potential fix to have 'make install' work on AIX machines again
finally.
 
 These are just bug fixes.  I don't want to see new functionality added to
 PHP for a potential 4.2.3, but I do want to see a LOT of these bugs
 squished.  There is a fix, why go and release another version of PHP with
 known and non-fixed bugs in it?
 
 It still doesn't seem to compile and work on 64-bit arch's.
 
 But yet again, there are numerous reasons why we should move to release
 PHP 4.3.  The biggest of which in my book is, it supports OSX!  While
 possibly a minor issue to many of the users on this list, it's becoming a
 more significant issue, especially with Jaguar/10.2 being released in a
 few days.  There have

[PHP-DEV] multipart/form-data bug [crossposted]

2002-08-16 Thread James E. Flemer 

Sorry for the cross-post, but I don't know which side is
causing this bug, Apache or PHP.

OS: Solaris 8
Apache: 1.3.26
PHP: 4.2.2 (DSO)

By default, PHP sets max_post_size to 8Mb. If the post
data exceeds that, it seems PHP discards all of it (no post
data gets to the script). In my situation upload_max_filesize
was set higher than 8Mb (tho this may not have any effect
on the bug).

When a big (11Mb) file was posted with multipart/form-data,
PHP ignored all the data, but it seems part of the POST
data was *reparsed* by Apache! In the apache access logs it
shows the post, then the next request looks like this
(wrapped):

 24.58.34.117 - - [16/Aug/2002:11:49:58 -0400]
 -1103527590377401575662824084
 200 6568 - -

This seems to be caused since PHP stopped after reading the
HTTP header (ending in Content-Length: 11993812\n\n). The
next lines in the post were:

 1103527590377401575662824084
 Content-Disposition: form-data; name=bar

 [EMAIL PROTECTED]
 1103527590377401575662824084
  and so on until the tcp session was reset.

Does anyone see something odd here? :-) Enjoy. This does
not happen on FreeBSD/Apache-1.3.26/PHP-cvs.

But hey, I learned that a shortcut for GET / HTTP/1.0\n\n
is -\n, and there are no headers to parse. :-)

-James


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

Re: [PHP-DEV] [PATCH] ext/standard/tests/general_functions/proc_open.phpt

2002-08-03 Thread James E. Flemer 

Committed. Thanks!
-James

On Sat, 3 Aug 2002, Melvyn Sopacua wrote:

 Self explanatory:
 Index: ext/standard/tests/general_functions/proc_open.phpt
 ===
 RCS file:
 /repository/php4/ext/standard/tests/general_functions/proc_open.phpt,v
 retrieving revision 1.1
 diff -u -r1.1 proc_open.phpt
 --- ext/standard/tests/general_functions/proc_open.phpt 23 May 2002
 10:46:06 -  1.1
 +++ ext/standard/tests/general_functions/proc_open.phpt 3 Aug 2002 13:54:59
 -
  -19,6 +19,11 
  $ds,
  $pipes
  );
 +/* As per manual: avoid deadlock */
 +for($i=0;$icount($pipes);$i++)
 +{
 +   fclose($pipes[$i]);
 +}

   proc_close($cat);


 Met vriendelijke groeten / With kind regards,

 Webmaster IDG.nl
 Melvyn Sopacua





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

Re: [PHP-DEV] RE: [Gallery-users] can't create albums (fwd)

2002-05-06 Thread James E. Flemer 

Perhaps this broke it: (it looks like the most recent
change to mkdir())

http://cvs.php.net/diff.php/php4/ext/standard/file.c?r1=1.203r2=1.204ty=u

I am looking into it.
-James

On Mon, 6 May 2002, Rasmus Lerdorf wrote:

 Bug 16905 seems to be real and is biting a few people on *BSD.  It looks
 non-sensical to me and I don't really have decent access to a FreeBSD box
 anymore.  Could someone on FreeBSD take a close look at this one?

 -Rasmus

 -- Forwarded message --
 Date: Mon, 6 May 2002 10:28:10 -0400
 From: Don Wang [EMAIL PROTECTED]
 To: Troy [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: RE: [Gallery-users] can't create albums

 Troy,

 I suspect that you have hit a PHP 4.2 bug (possibly under BSD environment).
 I had exactly same problem before. Bharat solved it for me. His patch is now
 located at:

 List: gallery-users
 Subject:  [Gallery-users] PHP 4.2.0 new album issues
 From: Brian Smyth [EMAIL PROTECTED]
 Date: 2002-05-02 4:18:48
 [Download message RAW]

 Just as an FYI, the issues I (and others) were having are due to a PHP
 bug: http://bugs.php.net/bug.php?id=16905

 Bharat worked around the issue, and a patch is in CVS: \
 http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gallery/gallery/platform/fs_u
 nix.php.di \
 ff?r1=1.12r2=1.13

 It isn't a strictly FreeBSD issue, I encountered the problem on OpenBSD.

 Take care,

 Brian
 --
 Brian Smyth
 [EMAIL PROTECTED] || http://aries.etree.org/~hamal/

 -Original Message-
 From: Mediratta, Bharat [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, May 01, 2002 8:08 PM
 To: 'Don Wang'
 Subject: RE: New Album problem
 Ok, a whole lot of debugging later I've figured out the
 problem.  You're hitting this bug:

 http://bugs.php.net/bug.php?id=16905

 It would have saved a lot of time if I was able to see
 your Apache error log, but I couldn't find it.  At any
 rate, I've patched your code to work around this issue
 and will roll the patch back into the trunk.  Thanks for
 giving me access!

 -Bharat

  -Original Message-
  From: Don Wang [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, May 01, 2002 3:36 PM
  To: Mediratta, Bharat
  Subject: New Album problem
 
 
  Bharat,
 
  When one clicks on new Album, automatically 6 new untitle albums are
  generated. Afterwards, each new click generates two more.
 
  I suspect this bug is php 4.2 upgrade related, although I
  know little about
  php to prove it. Right now I count at least three people
  having the exact
  same problem.

 
 
  List: gallery-users
  Subject:  RE: [Gallery-users] Problem adding new album
  (albums/album01-10)
  From: Mediratta, Bharat [EMAIL PROTECTED]
  Date: 2002-05-01 4:40:20
  [Download message RAW]
 
 
 
   From: Brian Smyth [mailto:[EMAIL PROTECTED]]
  
   When my admin user tries to create a new album, 10 new album
   directories named album01 through album10 (and so on if I try to
   add more albums) are created in my albums/ directory and I get
   a Document contains no data error from my web browser.
   Subsequently, gallery warns me on the top page that album01-10
   are not valid albums and should be deleted.  They are just empty
   directories.
 
  When you click new album once, you get 10 empty albums?  Or
  do you only get one blank album every click?
 
  Also, has anything else changed in your environment, like did
  you upgrade your version of PHP or anything else that might be
  related?
 
  Assuming that you can reproduce this readily, I'd love to
  get onto your machine via ssh or ftp and tinker with the code
  to see if I can figure out what's going wrong.  If that's
  possible please let me know.  Thanks,
 
  -Bharat
 
 


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Troy
 Sent: Monday, May 06, 2002 3:38 AM
 To: [EMAIL PROTECTED]
 Subject: [Gallery-users] can't create albums


 After getting Gallery installed and working I can't create new albums.
 After logging in and trying to create one, I get a page not found, then
 when going back to the main gallery page, It shows 3 albums created
 afterwords, all of which are named the same and have the same location.
 Under each album is the error:

 Warning: stat failed for /usr/local/www/data/gallery/albums//album.dat
 (errno=2 - No such file or directory) in
 /usr/local/www/data/gallery/platform/fs_unix.php on line 73
 Dec 31, 1969. This album contains no items.

 When configuring Gallery I set the Album directory and Albums URL to
 /usr/local/www/data/gallery/albums, the URL to the gallery site is the
 the default of hostname/gallery. The permissions to the albums directory
 are correct, and it is creating these unusable albums in the correct
 place of /gallery/albums. Any help appreciated, thanks.


 ___

 Have big pipes? SourceForge.net is looking for download mirrors. We supply
 the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]


 __[ g

Re: [PHP-DEV] RE: [Gallery-users] can't create albums (fwd)

2002-05-06 Thread James E. Flemer 

Yep, on FreeBSD mode_t is u_int16_t, whereas on Linux it
is a __u_int.

-James

On 6 May 2002, Jim Winstead wrote:

 James E. Flemer [EMAIL PROTECTED] wrote:
  Perhaps this broke it: (it looks like the most recent
  change to mkdir())
 
  http://cvs.php.net/diff.php/php4/ext/standard/file.c?r1=1.203r2=1.204ty=u
 
  I am looking into it.

 passing a pointer to a mode_t (mode) to zend_parse_parameters(), which
 uses it as a pointer to long, is probably the cause of the problem.

 mode should be declared as a long in the function, and cast to a mode_t
 when passed to VCWD_MKDIR.

 jim




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

[PHP-DEV] bugs: try newer version (?)

2002-04-28 Thread James E. Flemer 

Is there some policy about when it's ok to pick try newer
version (bogus) from the quick fix bug menu? Is there
anyway to automate that, so when people report bugs in
4.0.6 they can immediately get a response telling them to
upgrade and see if the problem has been fixed? There are
still 484 open bugs for versions 4.0.x.

Version | Open Bugs
|--
4.0.1*  |2
4.0.2*  |7
4.0.3*  |   11
4.0.4*  |   66
4.0.5   |   61
4.0.6   |  272
4.0*|  484
4.1.0   |   92
4.1.1   |  263
4.1.2   |  170
4.1*|  562
4.2.0   |   83
4.2.1   |1
4.2*|   84

-James


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

RE: [PHP-DEV] bugs: try newer version (?)

2002-04-28 Thread James E. Flemer 

[ James (Cox) can you please quote people correctly ... ]

Sorry for the confusion. I was not implying in any way that
_existing_ bugs be automatically marked as Try Newer
Version, I was suggesting that perhaphs _new_ bugs be
marked that way if they are submitted with a (very) old
release. That seems to be what happens now, but it is done
by hand.

And as for _existing_ bugs ... There are many bugs that are
reported in areas that have had signifigant changes since
4.0.6 (for example). I don't still have 4.0.6 running
anywhere to test them. What, if any, policy is there for
marking old bugs with Try Newer Version? For example, I
could try to duplicate said bug, and if the problem is not
exhibited on my current version it seems legitimate to mark
it as Try Newer Version. But in many cases the reported
OS is Linux, and I run FreeBSD ... should I still force
them to upgrade, since it might be a OS issue?

-James (Flemer)

On Sun, 28 Apr 2002, James Cox wrote:

 Stig said:
  That would effectively be ignoring most bugs.  I don't see how we can
  mark bugs as try a newer version without examining each bug.

 Right.

 what i am trying to get across is that perhaps we can make a move to look at
 all the  4.2 bugs, and see which can be closed off.

 james


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

Re: [PHP-DEV] Re: Bug #16768: mysql_connect(localhost, ...) doesn'tconnect to localhost! (fwd)

2002-04-24 Thread James E. Flemer 

On Wed, 24 Apr 2002, Daniel Swarbrick wrote:

 Yes, I have MySQL running all the time. I noticed this in
 ext/mysql/config.m4 :

   MYSQL_SOCK=/tmp/mysql.sock
   for i in  \
   /var/run/mysqld/mysqld.sock \
   /var/tmp/mysql.sock \
   /var/lib/mysql/mysql.sock \
   /var/mysql/mysql.sock \
   /Private/tmp/mysql.sock \
   ; do
 if test -r $i; then
   MYSQL_SOCK=$i
 fi
   done

 ...which doesn't quite match my socket at /var/run/mysql/mysql.sock -
 defaulting to /tmp/mysql.sock.

Is there any problem with doing something like this:
  /path/to/mysql_config --socket
in ./configure to get the socket path? I think that this
way is a little more likely to get it right in the case
that mysqld is not running at the time of configure. I
suppose we do not even know the /path/to in configure
when using the bundled mysql libs tho huh?

-James


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

Re: [PHP-DEV] RFC: README.SUBMITTING_PATCH (2nd edition)

2002-03-18 Thread James E. Flemer 

What about in-line vs. attachments? For patching,
attachments are probably easier, but for reviewing I find
it useful if the patch is in-line.

-James

On Mon, 18 Mar 2002, Yasuo Ohgaki wrote:

 Hi all,

 I've added David and Zeev's suggestion and added a little.
 Please fix/add/comment. Thank you.

 
 Submitting Patch for PHP
 

 This document describes how to submit patch for PHP. Since you are
 reading this document, you are willing to submit patch for PHP!
 Please keep reading! Submitting patch for PHP is easy.

 How to create patch?
 
 We are working with CVS. You need to get CVS source to create patch
 that we accept.  Visit http://www.php.net/anoncvs.php to get CVS
 source. You can check out older versions, but make sure you get
 default branch (i.e. Do not use -r option when you check out CVS
 source)

 Now you are ready to create patch. Modify source to fix bugs in PHP or
 add new feature to PHP. After you finished editing, please test your
 patch. Read README.TESTING for testing.

 After you finish testing your patch, take diff file using
 cvs diff  your.patch command.

 Read README.TESTING for submitting test script for your patch. This is
 not strictly required, but it is preferred to submit test script along
 with your patch. Making new test script is very easy. It help us to
 understand what you have been fixed or added to PHP.


 Tips for creating patch
 ---
 If you would like to fix multiple bugs. It is easier for us if you
 could create 1 patch for 1 bugs, but it's not strictly required.

 If you would like change/add many lines, you may better to ask module
 maintainer and/or [EMAIL PROTECTED]  Official module maintainers
 can be found in EXTENSIONS file in PHP source.


 Recommended CVS client settings for getting patch file
 --
 Recommended ~/.cvsrc file setting is:
 --
 cvs -z3
 update -d -P
 checkout -P
 diff -u -b -w -B
 --
 diff -u -b -w -B means:
   -b Ignore changes in amount of white space.
   -B Ignore changes that just insert or delete blank lines.
   -u Use the unified output format.
   -w Ignore white space when comparing lines.

 With this CVS setting, you don't have to worry about adding/deleting
 newlines and new spaces.


 Check list for submitting patch
 ---
   - Did you run make test to check if your patch didn't break
 other features?
   - Did you compile PHP with --enable-debug and check php/webserver
 error logs when you test your patch?
   - Did you build PHP for multi-threaded web servers. (Optional)
   - Did you create test script for make test? (Optional)
   - Did you check your patch is unified format and it does not
 contain white space changes? (If you are not using recommended
 cvs setting)
   - Did you update CVS source before you take final patch?


 Where to send your patch?
 -
 You are supposed to send patch to [EMAIL PROTECTED] If you
 are patching module, you should also send patch to the maintainer.
 Official module maintainers are listed in EXTENSION file in source.

 Make sure you add [PATCH] prefix to mail subject. Please make sure
 attach patch file even if patch is really short one. Finally, explain
 what has been fixed/added/changed by your patch.

 If you know bug ID that can be closed by your patch, please note the
 bug ID numbers also.



 How long it will take to get response?
 --
 Since we are volunteers, it may take more than a few days to get
 response. If you didn't get any response in a few days, please let us
 know you have been submitted the patch, but you didn't get any
 response.


 Thank you for sending patch for PHP!





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

Re: [PHP-DEV] opendir SafeMode Multiuser Problem/Patch

2002-03-03 Thread James E. Flemer 

Well actually, open_basedir is not *supposed* to check
UIDs However, safe_mode *is*, and it was not for the
opendir() function So I patched it to do so (in CVS) Also
I noticed that when the CHECKUID_ALLOW_ONLY_DIR flag is
passed to php_checkuid(), that it misses the case where you
are referring to the root directory (because the leading
slash is changed to a null, and so VCWD_STAT was being
passed a null string instead of / or \\) I fixed that
as well

-James

On Fri, 1 Mar 2002, Chand wrote:

 hi,

 Just wanted to let you guys know that the php opendir() function suffers a tiny 
security risk in a multiuser environment Say you have a server with multiple users 
having access to php Those users Homedirs are stored in the same tree (say 
/data/users/)

 With the function as it is now, the user chand (/data/users/chand) would be able to 
open and watch the contents of Rasmus' Home directory (/data/users/rasmus) because 
_php_do_opendir (in ext/standard/dirc) doesn't implement the safe_mode's 
php_checkuid function as I think it should (IMHO) It only checks the open_base_dir 
variable But on a multiuser (multi as in thousands of thousands) environment, you 
can't honestly go that way

 Hence the following patch

 --- /php-410/ext/standard/dirc Sat Aug 11 19:03:36 2001
 +++ ext/standard/dirc  Fri Mar  1 00:46:58 2002
  -151,6 +151,13 
 if (php_check_open_basedir((*arg)-valuestrval TSRMLS_CC)) {
 RETURN_FALSE;
 }
 +
 +   /* CHAND Added Checkuid so that we check a guy can't go see anything 
except from his directory up */
 +   if (!php_checkuid((*arg)-valuestrval, NULL, 3)) {
 +   php_error(E_WARNING, Permission denied to the directory : %s, 
(*arg)-valuestrval);
 +   RETURN_FALSE;
 +   }
 +   /* /CHAND */

 dirp = emalloc(sizeof(php_dir));


 Just tell me if I'm out of the blue here and if what i'm saying is making any sense 
to you Almost every security issue in such an environment i had to patch in earlier 
versions of php were patched in 410 except for this one
 If it could be from now on, it would be pretty cool :)

 Thanks for any comments and for taking my information into consideration Maybe the 
patch I submitted is not the best way to do it (I don't master the php/Zend API) but 
it works fine with me

 Later



 --
 Mark Villemade
 Hosting Services Technical Manager
 MultiMania / Lycos Europe
 (int) +33 1 53 27 24 05





-- 
PHP Development Mailing List http://wwwphpnet/
To unsubscribe, visit: http://wwwphpnet/unsubphp

Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem (fwd)

2002-02-06 Thread James E. Flemer 

Yes, it does disable all LOAD DATA cases, including files
from the server ... Be my guest to extend it. Like I said,
I was writing this for a client, not for the PHP tree.

It would take a few more states in the loop to check for
the LOCAL keyword... because if you notice the syntax is:
   LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE ...
but it shouldn't be to complicated. If it was to become
part of the PHP tree, it should probably be a little more
discriminate. :-)

I am not sure if any regex functions are available to be
called (that are part of the PHP base) ... but if they are,
the saftey check could just try matching a (list of)
regex(s).

-James


On Tue, 5 Feb 2002, Mats Lindh wrote:

 - [EMAIL PROTECTED]% (James E. Flemer):
  This patch I think will catch all cases, unless there is
  some way that mysql can escape characters (\x44 or
  something).

 As far as i can see, this patch will disable all LOAD DATA-cases, this
 will however disable a feature in MySQL for loading files that resides
 ON the server. There is no reason why this shouldnt be allowed if PHP
 is running in safe mode.

 LOAD DATA INFILE LOCAL .. the LOCAL part is the problem. I'd guess
 that just extending it to handle this would solve the problem.





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

Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem (fwd)

2002-02-05 Thread James E. Flemer 

Well, I understand the concerns with trying to patch all
libs that PHP uses. However mysql seems to be a *major*
extension, as in it is very heavily used. I had to write
this patch anyway for a client, so I will post the patch
here. If people don't like it, they can ignore it. If
enough people do like it, we can discuss committing it.

This patch I think will catch all cases, unless there is
some way that mysql can escape characters (\x44 or
something).

-James
 The University of Vermont

On Mon, 4 Feb 2002, Rasmus Lerdorf wrote:

 The fact that 3rd party libs can load arbitrary files is not a new
 concept.  Every time I give a moderately detailed PHP talk I mention the
 fact that there is a way to load a file through the oci8 libs.  Of course
 it can be done through the mysql libs as well.  This is not a new concept.
 All someone woulod have had to do to learn of this vulnerability would
 have been to go to any of the PHP talks I have given in the past 3 years.

 We will not scan queries to catch these.  Safe mode is a crappy fix to a
 problem that isn't ours.

 -Rasmus


 On Tue, 5 Feb 2002, Andi Gutmans wrote:

  We have always said that safe mode isn't very safe. I'm sure there are
  other ways of circumventing it.
  Unless a few people focus specifically on safe mode I don't think this will
  change.
 
  Andi
 
  At 12:26 AM 2/5/2002 -0500, James E. Flemer wrote:
  BTW I just noticed that this has been entered as bug
  #15375.
  
  
  --
  PHP Development Mailing List http://www.php.net/
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 






Index: ext/mysql/php_mysql.c
===
RCS file: /repository/php4/ext/mysql/php_mysql.c,v
retrieving revision 1.115
diff -u -r1.115 php_mysql.c
--- ext/mysql/php_mysql.c   30 Dec 2001 10:00:26 -  1.115
+++ ext/mysql/php_mysql.c   5 Feb 2002 21:25:30 -
@@ -987,6 +987,66 @@
 /* }}} */
 #endif
 
+/* {{{ php_mysql_safety_check
+ */
+static int php_mysql_safety_check(const char *p, int len)
+{
+   int state = 1;
+   const char *end = p + len;
+   
+   while (p  *p  p  end)
+   {
+   switch (state)
+   {
+   case 0: /* skip word */
+   while (*p  p  end  *p != ' '  *p != '\t'  *p != '\r' 
+ *p != '\n')
+   p++;
+   /* FALLTHROUGH */
+   case 2:
+   /* FALLTHROUGH */
+   case 4: /* move to the end of space(s) */
+   if (*p  p  end  *p != ' '  *p != '\t'  *p != '\r'  
+*p != '\n') {
+   state = 0;
+   break;
+   }
+   while (*p  p  end  (*p == ' ' || *p == '\t' || *p == '\r' 
+|| *p == '\n'))
+   p++;
+   state++;
+   break;
+   case 1: /* look for LOAD */
+   if ((*p == 'l' || *p == 'L') 
+   p+3  end 
+   *(p+1)  *(p+2)  *(p+3) 
+   (*(p+1) == 'o' || *(p+1) == 'O') 
+   (*(p+2) == 'a' || *(p+2) == 'A') 
+   (*(p+3) == 'd' || *(p+3) == 'D') ) {
+   p += 4;
+   state++;
+   } else {
+   state = 0;
+   }
+   break;
+   case 3: /* look for DATA */
+   if ((*p == 'd' || *p == 'D') 
+   p+3  end 
+   *(p+1)  *(p+2)  *(p+3) 
+   (*(p+1) == 'a' || *(p+1) == 'A') 
+   (*(p+2) == 't' || *(p+2) == 'T') 
+   (*(p+3) == 'a' || *(p+3) == 'A') ) {
+   p += 4;
+   state++;
+   } else {
+   state = 0;
+   }
+   break;
+   case 5: /* spaceLOADspaceDATAspace found */
+   return 0;
+   }
+   }
+   return 1;
+}
+/* }}} */
+
 /* {{{ php_mysql_do_query_general
  */
 static void php_mysql_do_query_general(zval **query, zval **mysql_link, int link_id, 
zval **db, int use_store, zval *return_value TSRMLS_DC)
@@ -1021,6 +1081,15 @@
} while(0);
 
convert_to_string_ex(query);
+   
+   /* disallow LOAD DATA if safe_mode on */
+   if (PG(safe_mode)) {
+   if (!php_mysql_safety_check(Z_STRVAL_PP(query), Z_STRLEN_PP(query))) {
+   php_error(E_WARNING, MySQL: Statement

[PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem (fwd)

2002-02-04 Thread James E. Flemer 

Comments on this? I am going to take a look at the code in
the mysql extension, and at the code in mysql as well
tomorrow. Not sure if this is directly a PHP problem (vs a
mysql problem), but it is something that PHP *could* block
it seems.
-James

-- Forwarded message --
Date: Sun, 3 Feb 2002 22:21:44 +
From: Dave Wilson [EMAIL PROTECTED]
To: NTBugTraq Mailling List [EMAIL PROTECTED],
 SecurityFocus' BugTraq [EMAIL PROTECTED]
Subject: PHP Safe Mode Filesystem Circumvention Problem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 --

 Security Advisory DW020203-PHP
   Release: 3rd February 2002

 PHP Safe Mode Filesystem Circumvention Problem

 Severity:   Medium to high.
 Affects:PHP, all versions which include safe_mode feature.
 Platform:   UNIX, Microsoft Windows, any platforms on which PHP is available.
 Vendor: http://php.net.
 Discovered: 12th January 2002, Dave Wilson [EMAIL PROTECTED], using
 PHP 4.1.0  Apache 2 on Linux.

 --


VULNERABILITY IN BRIEF

   PHP (since version 3?) includes a commonly used feature known as Safe Mode.
   When enabled, scripts are highly limited in their ability to access or
   execute local files, among other things.

   PHP relies on a wrapper function around all filesystem calls to perform
   access checks, but unforunately the bundled MySQL client library has not
   been modified to perform such checks on LOAD DATA INFILE LOCAL statements.

   If an attacker has access to a MySQL server (either provided by you or
   himself), he can use it as a proxy by which to download files residing on
   the safe_mode-enabled web server. For large ISPs relying on this feature
   for individual customer privacy, it could mean clients accessing each
   other's files, or viewing of files on an improperly secured server.


FIX

   Currently, no fix exists. You may use other PHP safe_mode functions to
   disable the use of the MySQL client library, or secure your servers in a
   proper fashion.. A suggested fix for the PHP developers might be to scan
   mysql_query()s for strings similar to LOAD DATA LOCAL INFILE.

   Happy hackers out there might like to look at libmysql.c:1764 if interested
   in fixing this problem, although that may only be possible from within PHP.


EXAMPLE

   The attached script will (once configured correctly) attempt to read
   /var/log/lastlog via the SQL daemon and return it to the client.

   $ cp safe_mode.php /www
   $ wget -qO lastlog_via_mysql localhost/safe_mode.php
   $ diff /var/log/lastlog lastlog_via_mysql; echo $?
   0


COMMENTS

   Due to the nature of the PHP project, development is very rapid and hence
   many sites do not keep up with latest PHP versions. If a fix was available,
   it would take quite a while to propagate.

   It is likely that this is not an isolated problem in PHP, my bets are on
   PostgreSQL and other PHP database extensions missing this one too.

   The MySQL support has been enabled in PHP by default for as long as I can
   remember.


DAVE WILSON

   Currently residing in Belfast, Northern Ireland, he is available for work
   relating to network security auditing, post-attack recovery and forensics,
   and penetration testing. He may be contacted at [EMAIL PROTECTED]. If
   you have any comments regarding this advisory, please contact him directly.


Sun Feb  3 21:23:03 GMT 2002 -dw


begin 644 safe_mode.php
M/#\*B\JB`@(%!(4!3869E($UO94@4')O8FQE;0H*(`@5AIR!S8W)I
M'0@=VEL;!C;VYN96-T('1O($@9%T86)AV4@V5R=F5R(')U;FYI;F@
M;]C86QL2!OB!O=AEG=IV4LB`@(-R96%T92!A('1E;7!OF%R2!T
M86)L92!W:71H(]N92!C;VQU;6XL('5S92!T:4@3$]!1!$051!('-T871E
M;65N=!T;PH@(!R96%D($@*'!OW-I8FQY()I;F%R2D@9FEL92P@=AE
M;B!R96%DR!I=!B86-K('1O('1H92!C;EE;G0N@H@(!!;GD@='EP92!O
M9B!F:6QE(UA2!P87-S('1HF]U9V@@=AIR`G')O'DG+B!!;'1H;W5G
M:!U;G)E;%T960L('1H:7,*(`@;6%Y(%LV\@8F4@=7-E9!T;R!A8V-E
MW,@9FEL97,@;VX@=AE($1('-EG9EB`H86QT:]U9V@@=AE2!M=7-T
M()EB`@('=OFQD+7)E861A8FQE(]R(EN($UY4U%,9=S()AV5D:7(L
M(%C8V]R9EN9R!T;R!D;V-S*2X**B\*@HD:]S=`](=L;V-A;AOW0G
M.PHD=7-EB`](=R;V]T)SL*)'!AW,@/2`G;5T;65I;B[B1D8B`@(#T@
M)W1EW1?9%T86)AV4G.PH*)9I;5N86UE(#T@)R]V87(O;]G+VQAW1L
M;VG.R`@(`@+RH@1FEL92!T;R!GF%B(9R;VT@6VQO8V%L72!S97)V97(@
M*B\*)QO8V%L(#T@=')U93L@(`@(`@(`@(`@(`@(`@(`@+RH@4F5A
M9!FF]M(QO8V%L(9I;5S7-T96T@*B\*@HD;]C86P@/2`D;]C86P@
M/R`G3$]#04PG(#H@)R[@HDW%L(#T@87)R87D@*`H@(`B55-%(1D8B(L
M@H@(`G0U)%051%(%1%35!/4D%262!404),12`G(X@*1T8FP@/2`G02N
M=EM92`H*2D@+B`G(AA($Q/3D=3$]*2L@H@(`B3$]!1!$051!(1L
M;V-A;!)3D9)3$4@)R1F:6QE;F%M92@24Y43R!404),12`D=)L($9)14Q$
M4R`BB`@(X@(E1%4DU)3D%4140@0ED@(`@(`@)U]?5$A)4U].159%4E](
M05!014Y37U\G((*(`@+B`B15-#05!%1!62`@(`@(`@(`G)R`BB`@
M(X@(DQ)3D53(%1%4DU)3D%4140@0ED@)U]?5$A)4U].159%4E](05!014Y3
M7U\G(BP*B`@()314Q%0U0@82!4D]-(1T8FP@3$E-250@,2(**3L*DAE

Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem (fwd)

2002-02-04 Thread James E. Flemer 

BTW I just noticed that this has been entered as bug
#15375.


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

[PHP-DEV] [patch] safe_mode_include_dir

2002-02-01 Thread James E. Flemer 

Hello ... It's been a while since I've actively been
committing to PHP. So I thought I'd run this by everyone
first.

This is a patch to change the behavior of the PHP.INI
directive safe_mode_include_dir (which I added about 6
months ago). As it is currently, safe_mode_include_dir
takes a single directory (ie. /usr/local/lib/php) and
bypasses UID/GID checks on files included from that
directory.

This patch changes the behavior to allow a path-style list
of directories to be listed (similar to include_path).
While I was at it, I made the code surrounding the check
much more readable by separating the safe_mode_include_dir
check into a separate function (a la open_base_dir_check).

Since a single directory is a valid path-style string, this
patch is completely backward compatible. Unless I broke
anything in the actual checking, which is another reason I
am posting this before I commit it. I cannot get current
CVS to build, so this patch is off of php-4.1.1, but
applies cleanly to php-cvs.

Thanks,
-James



# Patch to change PHP-4.1.1 to allow multiple
# safe_mode_include_dir directories (PATH-style string)
#
# By James Flemer [EMAIL PROTECTED]
# 2002-02-01
#
--- php-4.1.1/main/fopen_wrappers.h.origSat Aug  4 21:42:43 2001
+++ php-4.1.1/main/fopen_wrappers.h Fri Feb  1 12:38:52 2002
@@ -74,6 +74,8 @@
 PHPAPI int php_check_open_basedir(char *path TSRMLS_DC);
 PHPAPI int php_check_specific_open_basedir(char *basedir, char *path TSRMLS_DC);
 
+PHPAPI int php_check_safe_mode_include_dir(char *path TSRMLS_DC);
+
 PHPAPI FILE *php_fopen_with_path(char *filename, char *mode, char *path, char 
**opened_path TSRMLS_DC);
 
 PHPAPI int php_is_url(char *path);
--- php-4.1.1/main/fopen_wrappers.c.origSat Aug  4 21:42:43 2001
+++ php-4.1.1/main/fopen_wrappers.c Fri Feb  1 12:45:04 2002
@@ -221,6 +221,57 @@
 }
 /* }}} */
 
+/* {{{ php_check_safe_mode_include_dir
+ */
+PHPAPI int php_check_safe_mode_include_dir(char *path TSRMLS_DC)
+{
+   /* Only check when safe_mode on and safe_mode_include_dir is available */
+   if (PG(safe_mode)  PG(safe_mode_include_dir) 
+   *PG(safe_mode_include_dir))
+   {
+   char *pathbuf;
+   char *ptr;
+   char *end;
+   char resolved_name[MAXPATHLEN];
+
+   /* Resolve the real path into resolved_name */
+   if (expand_filepath(path, resolved_name TSRMLS_CC) == NULL)
+   return -1;
+
+   pathbuf = estrdup(PG(safe_mode_include_dir));
+
+   ptr = pathbuf;
+
+   while (ptr  *ptr) {
+   end = strchr(ptr, DEFAULT_DIR_SEPARATOR);
+   if (end != NULL) {
+   *end = '\0';
+   end++;
+   }
+
+   /* Check the path */
+#ifdef PHP_WIN32
+   if (strncasecmp(ptr, resolved_name, strlen(ptr)) == 0)
+#else
+   if (strncmp(ptr, resolved_name, strlen(ptr)) == 0)
+#endif
+   {
+   /* File is in the right directory */
+   efree(pathbuf);
+   return 0;
+   }
+
+   ptr = end;
+   }
+   efree(pathbuf);
+   return -1;
+   }
+
+   /* Nothing to check... */
+   return 0;
+}
+/* }}} */
+
 /* {{{ php_fopen_and_set_opened_path
  */
 static FILE *php_fopen_and_set_opened_path(const char *path, char *mode, char 
**opened_path TSRMLS_DC)
@@ -375,13 +426,10 @@
char *pathbuf, *ptr, *end;
char *exec_fname;
char trypath[MAXPATHLEN];
-   char trydir[MAXPATHLEN];
-   char safe_mode_include_dir[MAXPATHLEN];
struct stat sb;
FILE *fp;
int path_length;
int filename_length;
-   int safe_mode_include_dir_length;
int exec_fname_length;
 
if (opened_path) {
@@ -406,32 +454,16 @@
 * files in safe_mode_include_dir (or subdir) are excluded from
 * safe mode GID/UID checks
 */
-   *safe_mode_include_dir   = 0;
-   safe_mode_include_dir_length = 0;
-   if(PG(safe_mode_include_dir)  VCWD_REALPATH(PG(safe_mode_include_dir), 
safe_mode_include_dir)) {
-   safe_mode_include_dir_length = strlen(safe_mode_include_dir);
-   }

/* Absolute path open */
if (IS_ABSOLUTE_PATH(filename, filename_length)) {
-   /* Check to see if file is in safe_mode_include_dir (or subdir) */
-   if (PG(safe_mode)  *safe_mode_include_dir  VCWD_REALPATH(filename, 
trypath)) {
-#ifdef PHP_WIN32
-   if (strncasecmp(safe_mode_include_dir, trypath, 
safe_mode_include_dir_length) == 0)
-#else
-   if

Re: [PHP-DEV] namespace/package feature in PHP 5?

2001-07-19 Thread James E. Flemer 

Are (any of) the Zend lists public? (either to browse or
submit.)

-James

On Thu, 19 Jul 2001, Zeev Suraski wrote:

 Language-level things like this one are being discussed at
 [EMAIL PROTECTED]  This feature was actually discussed quite a lot in

 Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] xmlrpc_error_number causes core dump

2001-07-13 Thread James E. Flemer 

It looks like xmlrpc_error_number [ in main/main.c,
main/php_globals.h ] is typed wrong. It causes apache to
core dump on Solaris 8. It is crashing in OnUpdateString(),
which should be OnUpdateInt() right [main.c]? Also
xmlrpc_error_number should be a long, not a short
[php_globals.h]?

I don't know how xmlrpc_error_number is used tho ... Is it
alright to commit these two changes?

-James


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] include() fall back to scripts' cwd

2001-07-13 Thread James E. Flemer 

Rather than having this be a seperate case at the end of
php_fopen_with_path(), how about it just get appended to
the (local) search path?

I am adding a 'safe_mode_include_dir', which will let you
include files you don't own if they are in the
safe_mode_include_dir. By appending the scripts cwd to the
search path, it will honor this addition.

-James



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] [patch] safe mode gid check

2001-07-09 Thread James E. Flemer 

This is a patch against php-4.0.4pl1.

Description:
  In Safe Mode, when opening files the UID of the script
owner and the UID of the destination file are compared. In
some circumstances it is desired that this check be relaxed
to a GID compare. The attached patch adds a php ini
directive safe_mode_gid (boolean, default: Off). When
this is On, a GID compare is performed if the UID compare
fails.
  Additionally this patch adds a new PHP function
getmygid(), which returns the GID of the executing script
(see getmyuid()).

Author:
  James Flemer [EMAIL PROTECTED]
  CITS / Web Developer
  The University of Vermont

[ Please CC me in all replies, I am not subscribed to the list. ]

Thanks,
-James


--- php-4.0.4pl1/FUNCTION_LIST.txt  2001/07/09 15:11:32 1.1
+++ php-4.0.4pl1/FUNCTION_LIST.txt  2001/07/09 15:10:27
@@ -83,6 +83,7 @@
 
get_current_user
getmyuid
+   getmygid
getmypid
 u  getmyinode
getlastmod
--- php-4.0.4pl1/php.ini-dist   2001/07/09 15:12:08 1.1
+++ php-4.0.4pl1/php.ini-dist   2001/07/09 15:15:27
@@ -90,6 +90,10 @@
 
 ; Safe Mode
 safe_mode  =   Off
+safe_mode_gid  =   Off
+ ; By default, Safe Mode does a UID compare
+  
+ ; check when opening files. If you want to
+  
+ ; relax this to a GID compare, then turn on
+  
+ ; safe_mode_gid.
 safe_mode_exec_dir =
 safe_mode_allowed_env_vars = PHP_  ; Setting 
certain environment variables
   
 ; may be a potential security breach.
--- php-4.0.4pl1/php.ini-optimized  2001/07/09 15:12:11 1.1
+++ php-4.0.4pl1/php.ini-optimized  2001/07/09 15:15:37
@@ -77,6 +77,10 @@
 
 ; Safe Mode
 safe_mode  =   Off
+safe_mode_gid  =   Off
+ ; By default, Safe Mode does a UID compare
+  
+ ; check when opening files. If you want to
+  
+ ; relax this to a GID compare, then turn on
+  
+ ; safe_mode_gid.
 safe_mode_exec_dir =
 safe_mode_allowed_env_vars = PHP_  ; Setting 
certain environment variables
   
 ; may be a potential security breach.
--- php-4.0.4pl1/main/main.c2001/07/08 20:53:18 1.1
+++ php-4.0.4pl1/main/main.c2001/07/09 00:27:42
@@ -228,6 +228,7 @@
STD_PHP_INI_BOOLEAN(register_argc_argv,   1,PHP_INI_ALL,   
 OnUpdateBool,   register_argc_argv, 
php_core_globals,   core_globals)
STD_PHP_INI_BOOLEAN(register_globals, 1,PHP_INI_ALL,   
 OnUpdateBool,   register_globals,   
php_core_globals,   core_globals)
STD_PHP_INI_BOOLEAN(safe_mode,0,
PHP_INI_SYSTEM, OnUpdateBool,   safe_mode, 
 php_core_globals,   core_globals)
+   STD_PHP_INI_BOOLEAN(safe_mode_gid,0,
+PHP_INI_SYSTEM, OnUpdateBool,   safe_mode_gid,
+  php_core_globals,   core_globals)
STD_PHP_INI_BOOLEAN(short_open_tag,   1,
PHP_INI_SYSTEM|PHP_INI_PERDIR,  OnUpdateBool,   short_tags,
 zend_compiler_globals,  compiler_globals)
STD_PHP_INI_BOOLEAN(sql.safe_mode,0,
PHP_INI_SYSTEM, OnUpdateBool,   sql_safe_mode, 
 php_core_globals,   core_globals)
STD_PHP_INI_BOOLEAN(track_errors, 0,
PHP_INI_ALL,OnUpdateBool,   track_errors,  
 php_core_globals,   core_globals)
--- php-4.0.4pl1/main/php_globals.h 2001/07/08 20:53:18 1.1
+++ php-4.0.4pl1/main/php_globals.h 2001/07/09 00:17:38
@@ -63,6 +63,7 @@
zend_bool implicit_flush;
 
zend_bool safe_mode;
+   zend_bool safe_mode_gid;
zend_bool sql_safe_mode;
zend_bool enable_dl;
 
--- php-4.0.4pl1/main/safe_mode.c

Re: [PHP-DEV] [patch] safe mode gid check

2001-07-09 Thread James E. Flemer 

Here is the patch against current CVS.

Use:
  cd php4; patch -p0 php-safe-gid.diff

-James
 CITS / Web Developer
 The University of Vermont

On Mon, 9 Jul 2001, Rasmus Lerdorf wrote:

 Could you recreate this patch against current CVS?
 I think it is a good idea, but your patch doesn't work at all against the
 current code.

 Instructions about getting the code from CVS can be found here:

   http://php.net/anoncvs.php

 -Rasmus

 On Mon, 9 Jul 2001, James E. Flemer wrote:

  This is a patch against php-4.0.4pl1.
 
  Description:
In Safe Mode, when opening files the UID of the script
  owner and the UID of the destination file are compared. In
  some circumstances it is desired that this check be relaxed
  to a GID compare. The attached patch adds a php ini
  directive safe_mode_gid (boolean, default: Off). When
  this is On, a GID compare is performed if the UID compare
  fails.
Additionally this patch adds a new PHP function
  getmygid(), which returns the GID of the executing script
  (see getmyuid()).
 
  Author:
James Flemer [EMAIL PROTECTED]
CITS / Web Developer
The University of Vermont
 
  [ Please CC me in all replies, I am not subscribed to the list. ]
 
  Thanks,
  -James
 



Index: php.ini-dist
===
RCS file: /repository/php4/php.ini-dist,v
retrieving revision 1.86
diff -u -r1.86 php.ini-dist
--- php.ini-dist2001/07/04 03:53:12 1.86
+++ php.ini-dist2001/07/09 16:23:57
@@ -111,6 +111,11 @@
 ;
 safe_mode = Off
 
+; By default, Safe Mode does a UID compare check when
+; opening files. If you want to relax this to a GID compare,
+; then turn on safe_mode_gid.
+safe_mode_gid = Off
+
 ; When safe_mode is on, only executables located in the safe_mode_exec_dir
 ; will be allowed to be executed via the exec family of functions.
 safe_mode_exec_dir =
Index: php.ini-optimized
===
RCS file: /repository/php4/php.ini-optimized,v
retrieving revision 1.40
diff -u -r1.40 php.ini-optimized
--- php.ini-optimized   2001/06/24 22:40:41 1.40
+++ php.ini-optimized   2001/07/09 16:23:57
@@ -81,6 +81,10 @@
 
 ; Safe Mode
 safe_mode  =   Off
+safe_mode_gid  =   Off
+ ; By default, Safe Mode does a UID compare
+  
+ ; check when opening files. If you want to
+  
+ ; relax this to a GID compare, then turn on
+  
+ ; safe_mode_gid.
 safe_mode_exec_dir =
 safe_mode_allowed_env_vars = PHP_  ; Setting 
certain environment variables
   
 ; may be a potential security breach.
Index: ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.357
diff -u -r1.357 basic_functions.c
--- ext/standard/basic_functions.c  2001/07/09 10:20:40 1.357
+++ ext/standard/basic_functions.c  2001/07/09 16:24:03
@@ -268,6 +268,7 @@
 #endif
 
PHP_FE(getmyuid,   
 NULL)
+   PHP_FE(getmygid,   
+ NULL)
PHP_FE(getmypid,   
 NULL)
PHP_FE(getmyinode, 
 NULL)
PHP_FE(getlastmod, 
 NULL)
@@ -846,6 +847,7 @@
BG(mmap_file) = NULL;
 #endif
BG(page_uid) = -1;
+   BG(page_gid) = -1;
BG(page_inode) = -1;
BG(page_mtime) = -1;
 #ifdef HAVE_PUTENV
Index: ext/standard/basic_functions.h
===
RCS file: /repository/php4/ext/standard/basic_functions.h,v
retrieving revision 1.80
diff -u -r1.80 basic_functions.h
--- ext/standard/basic_functions.h  2001/05/22 19:19:04 1.80
+++ ext/standard/basic_functions.h  2001/07/09 16:24:03
@@ -155,6 +155,7 @@
  
/* pageinfo.c */
long page_uid;
+   long page_gid;
long page_inode;
long page_mtime;
 
Index: ext/standard/pageinfo.c
===
RCS file: /repository/php4/ext/standard/pageinfo.c,v
retrieving revision 1.23
diff -u -r1.23 pageinfo.c
--- ext/standard/pageinfo.c 2001/06/06 13:05:51 1.23
+++ ext

[PHP-DEV] safe_mode.c: php_checkuid() mode

2001-07-09 Thread James E. Flemer 

Rasmus, can you clarify the 'mode' parameter in
php_checkuid()? In safe_mode.h there are 5 defined values,
the 5th is: (which is used in fopen_wrappers.c ...)
#define CHECKUID_CHECK_MODE_PARAM 4

However, in safe_mode.c CHECKUID_CHECK_MODE_PARAM is not
used, and furthermore if 'fopen_mode' is not null, 'mode'
is overwritten anyway (depending if fopen_mode ~= 'r')
[line 56ish].

It seems that it exists there for possible expansion ... is
this correct?

So my question is ...
Can/should the 'mode' and the CHECKUID_* defines be changed
to bit flags (like php_fopen_wrapper() mode flags)?

My motivation for this is to be able to check *just* for a
files existence, not checking UID/GID.

Possibly a better way to do this would be to split
php_checkuid() into php_checkexists() and php_checkuid(),
where the former would be called by the latter (as to
not break anything)...
This might be more intuitive, and then I won't have to
duplcate the code to check for the file (as small as it
is).

Any comments?
-James


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] safe_mode.c: php_checkuid() mode

2001-07-09 Thread James E. Flemer 

Nix those mumblings about file existence ... but what about
bits vs not-bits for the mode?
-James

On Mon, 9 Jul 2001, James E. Flemer wrote:

 Rasmus, can you clarify the 'mode' parameter in
 php_checkuid()? In safe_mode.h there are 5 defined values,
 the 5th is: (which is used in fopen_wrappers.c ...)
   #define CHECKUID_CHECK_MODE_PARAM 4

 However, in safe_mode.c CHECKUID_CHECK_MODE_PARAM is not
 used, and furthermore if 'fopen_mode' is not null, 'mode'
 is overwritten anyway (depending if fopen_mode ~= 'r')
 [line 56ish].

 It seems that it exists there for possible expansion ... is
 this correct?

 So my question is ...
 Can/should the 'mode' and the CHECKUID_* defines be changed
 to bit flags (like php_fopen_wrapper() mode flags)?

 My motivation for this is to be able to check *just* for a
 files existence, not checking UID/GID.

 Possibly a better way to do this would be to split
 php_checkuid() into php_checkexists() and php_checkuid(),
 where the former would be called by the latter (as to
 not break anything)...
 This might be more intuitive, and then I won't have to
 duplcate the code to check for the file (as small as it
 is).

 Any comments?
 -James





-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]