#29362 [Com]: _libiconv_version' undeclared
ID: 29362 Comment by: ksvee at usit dot uio dot no Reported By: webmaster at path dot org Status: No Feedback Bug Type: Compile Failure Operating System: RedHat Linux Enterprise 3 PHP Version: 5.0.0 New Comment: Used a few hours trying to debug this in my build of PHP-5.1.1. The problem seems to exist when having installed libiconv on a linux-box that also support iconv in its glibc (such as RedHat Enterprise WS 3.x). If you have libiconv installed under /usr/local, try giving configure --with-iconv=/usr/local for it to link against that version (assuming iconv.h is found under /usr/local/include). The configure script checks for iconv-support around line 44061, but the --with-iconv-dir doesn't get checked before somewhere around line 95498, and is only used for XMLRPC-EPI, not to compile ext/iconv/iconv.c. For the binaries to link correctly (we use non-standard paths for our builds), you might have to specify the proper CPPFLAGS and LDFLAGS as well, e.g: CPPFLAGS=-I/path/to/include \ LDFLAGS=-L/path/to/lib -Wl,-rpath,/path/to/lib (or '-R' instead of '-Wl,-rpath' depending on arch). Kenneth Svee Previous Comments: [2004-10-16 07:11:34] zac at zacbowling dot com I got the same issue, but I was able to fix it by moving my iconv.h header like previously stated. I'm using a modified version of Debian Woody and PHP 5.0.2 with updated libraries similar to bug report. libiconv-1.9.2, libxml2-2.6.7, and libxslt-1.1.2. Zac Bowling [2004-08-29 04:30:46] sembiance at cosmicrealms dot com I too got this bug, with PHP 4.3.8 I fixed it though. The problem was I had --with-iconv --with-iconv-dir=/usr/local in my configure line. I dropped the first --with-iconv and kept just --with-iconv-dir=/usr/local Did a configure, make and this time no errors. [2004-08-24 17:23:44] adamolszewski at op dot pl Propably one of the most lame way to fix this but it works (almost perfectly). I copied iconv.h from /usr/local/include/iconv.h to /usr/include/iconv.h These two versions were different on my machine. After switching, compilation went almost OK - there were some warnings, but PHP compiled and iconv works OK. [2004-08-09 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2004-07-29 11:09:16] [EMAIL PROTECTED] Please, check that your /usr/local/include/iconv.h is not broken. This variable is defined there and should exist in all versions of libiconv since 2000-12-01. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/29362 -- Edit this bug report at http://bugs.php.net/?id=29362edit=1
#29207 [Opn]: Wrong script uid with safe_mode
ID: 29207
User updated by: ksvee at usit dot uio dot no
Reported By: ksvee at usit dot uio dot no
Status: Open
Bug Type: Filesystem function related
Operating System: Solaris 8
PHP Version: 4.3.10
New Comment:
Try including -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 in CFLAGS
given to configure[1]. It seems it triggers something that prevents the
bug from appering. Haven't really managed to trace the bug yet, but it
might have something to do with the stat/VCWD_STAT in main/safe_mode.c
that sets uid = sb.st_uid, sb being the stat-struct.
I'm now testing 4.3.11-dev (or rather stable cvs release
php4-STABLE-200412220730, as bug #31121 prevents proper compile of
4.3.10 using sun cc[2]) with a generic Apache 1.3.33, and it seems to
be working properly with safe_mode.
[1]: CFLAGS='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' \
CC='cc' CCC='CC' ./configure \
--with-apxs=/path/to/apxs \
--prefix=/my/prefix
[2]: cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
Previous Comments:
[2004-12-21 11:58:47] ksvee at usit dot uio dot no
Verified bug with Apache 1.3.33 and latest release (4.3.10) and latest
stable cvs snapshot (php4-STABLE-200412210930).
[2004-12-13 17:52:07] dsmk at bu dot edu
FYI, I just tested 4.3.10RC2 and its still there.
[2004-12-03 21:38:32] dsmk at bu dot edu
Just wanted to add that I have reproduced the problem
on Solaris 8 with all the versions above 4.3.8 including
4.3.10RC1 and 5.0.2. My production Apache is a security patched 1.3.26
but I have also seen the problem with a
generic 1.3.31.
[2004-07-16 12:53:24] ksvee at usit dot uio dot no
Description:
This is really an old bug that seems to be coming and going, but I
cannot find an open bug on it.
References: bugs #18500, #12683 and #7744
The latest version that this bug is not alive and well is 4.2.3 which
is the one we still use. I've tested (just about) every (release)
version since, and reproduced the bug in all of them. That includes the
latest (4.3.8) tested today, 2004-07-16. I use PHP with Apache 1.3.x
(1.3.31 latest).
Description:
When using SAFE_MODE = ON, php reports uid=1 on the running php-script
as well as its proper uid:
-
[datetag] [error] PHP Warning: Unknown(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not
allowed to access /path/to/script.php owned by uid 26658 in Unknown on
line 0
-
If I chown the script to another user, e.g. root, the report looks like
this:
-
[datetag] [error] PHP Warning: Unknown(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not allowed to access
/path/to/script.php owned by uid 0 in Unknown on line 0
-
If i chown it to uid=1 ('daemon' on my systems) then it seems to work,
except that the file I intend to include also needs to be owned by
daemon. This included file at least seems to have its owner reported
correctly, the full report being:
-
[datetag] [error] PHP Warning: main(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not allowed to access
./filename.inc owned by uid 26658 in /a/b/c/include.php on line 2
[datetag] [error] PHP Warning: main(filename.inc): failed to open
stream: Error 0 in /a/b/c/include.php on line 2
[datetag] [error] PHP Warning: main(): Failed opening 'filename.inc'
for inclusion (include_path='.') in /a/b/c/include.php on line 2
-
We usually use a non-standard config, compiling Apache, PHP, OpenSSL
etc under a specific prefix, but dumbing this to default paths has no
impact.
Using --with-apxs=/path/to/apxs --prefix=/path/to/installprefix as
the only config parameters to PHP too has no impact on the results.
As for php.ini, I've tried using a clean copy of both
php.ini-recommended and php.ini-dist with no other modifications
than setting safe_mode = On. No significant changes.
Rgds,
Kenneth Svee
Reproduce code:
---
# Content of include.php:
?php
include(filename.inc);
?
# (filename.inc is in same dir as include.php, and
# contains just an arbitrary string, e.g.:
I've been included!
Expected result:
# I expected the string in filename.inc:
I've been included!
Actual result:
--
Just the empty page, and the errormessages in Apaches error_log.
--
Edit this bug report at http://bugs.php.net/?id=29207edit=1
#29207 [Opn]: Wrong script uid with safe_mode
ID: 29207
User updated by: ksvee at usit dot uio dot no
Reported By: ksvee at usit dot uio dot no
Status: Open
Bug Type: Filesystem function related
Operating System: Solaris 8
-PHP Version: 4.3.10RC1
+PHP Version: 4.3.10
New Comment:
Verified bug with Apache 1.3.33 and latest release (4.3.10) and latest
stable cvs snapshot (php4-STABLE-200412210930).
Previous Comments:
[2004-12-13 17:52:07] dsmk at bu dot edu
FYI, I just tested 4.3.10RC2 and its still there.
[2004-12-03 21:38:32] dsmk at bu dot edu
Just wanted to add that I have reproduced the problem
on Solaris 8 with all the versions above 4.3.8 including
4.3.10RC1 and 5.0.2. My production Apache is a security patched 1.3.26
but I have also seen the problem with a
generic 1.3.31.
[2004-07-16 12:53:24] ksvee at usit dot uio dot no
Description:
This is really an old bug that seems to be coming and going, but I
cannot find an open bug on it.
References: bugs #18500, #12683 and #7744
The latest version that this bug is not alive and well is 4.2.3 which
is the one we still use. I've tested (just about) every (release)
version since, and reproduced the bug in all of them. That includes the
latest (4.3.8) tested today, 2004-07-16. I use PHP with Apache 1.3.x
(1.3.31 latest).
Description:
When using SAFE_MODE = ON, php reports uid=1 on the running php-script
as well as its proper uid:
-
[datetag] [error] PHP Warning: Unknown(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not
allowed to access /path/to/script.php owned by uid 26658 in Unknown on
line 0
-
If I chown the script to another user, e.g. root, the report looks like
this:
-
[datetag] [error] PHP Warning: Unknown(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not allowed to access
/path/to/script.php owned by uid 0 in Unknown on line 0
-
If i chown it to uid=1 ('daemon' on my systems) then it seems to work,
except that the file I intend to include also needs to be owned by
daemon. This included file at least seems to have its owner reported
correctly, the full report being:
-
[datetag] [error] PHP Warning: main(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not allowed to access
./filename.inc owned by uid 26658 in /a/b/c/include.php on line 2
[datetag] [error] PHP Warning: main(filename.inc): failed to open
stream: Error 0 in /a/b/c/include.php on line 2
[datetag] [error] PHP Warning: main(): Failed opening 'filename.inc'
for inclusion (include_path='.') in /a/b/c/include.php on line 2
-
We usually use a non-standard config, compiling Apache, PHP, OpenSSL
etc under a specific prefix, but dumbing this to default paths has no
impact.
Using --with-apxs=/path/to/apxs --prefix=/path/to/installprefix as
the only config parameters to PHP too has no impact on the results.
As for php.ini, I've tried using a clean copy of both
php.ini-recommended and php.ini-dist with no other modifications
than setting safe_mode = On. No significant changes.
Rgds,
Kenneth Svee
Reproduce code:
---
# Content of include.php:
?php
include(filename.inc);
?
# (filename.inc is in same dir as include.php, and
# contains just an arbitrary string, e.g.:
I've been included!
Expected result:
# I expected the string in filename.inc:
I've been included!
Actual result:
--
Just the empty page, and the errormessages in Apaches error_log.
--
Edit this bug report at http://bugs.php.net/?id=29207edit=1
#29207 [NEW]: Wrong script uid with safe_mode
From: ksvee at usit dot uio dot no
Operating system: Solaris 8
PHP version: 4.3.8
PHP Bug Type: *Directory/Filesystem functions
Bug description: Wrong script uid with safe_mode
Description:
This is really an old bug that seems to be coming and going, but I cannot
find an open bug on it.
References: bugs #18500, #12683 and #7744
The latest version that this bug is not alive and well is 4.2.3 which is
the one we still use. I've tested (just about) every (release) version
since, and reproduced the bug in all of them. That includes the latest
(4.3.8) tested today, 2004-07-16. I use PHP with Apache 1.3.x (1.3.31
latest).
Description:
When using SAFE_MODE = ON, php reports uid=1 on the running php-script as
well as its proper uid:
-
[datetag] [error] PHP Warning: Unknown(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not
allowed to access /path/to/script.php owned by uid 26658 in Unknown on
line 0
-
If I chown the script to another user, e.g. root, the report looks like
this:
-
[datetag] [error] PHP Warning: Unknown(): SAFE MODE Restriction in
effect. The script whose uid is 1 is not allowed to access
/path/to/script.php owned by uid 0 in Unknown on line 0
-
If i chown it to uid=1 ('daemon' on my systems) then it seems to work,
except that the file I intend to include also needs to be owned by daemon.
This included file at least seems to have its owner reported correctly, the
full report being:
-
[datetag] [error] PHP Warning: main(): SAFE MODE Restriction in effect.
The script whose uid is 1 is not allowed to access ./filename.inc owned by
uid 26658 in /a/b/c/include.php on line 2
[datetag] [error] PHP Warning: main(filename.inc): failed to open stream:
Error 0 in /a/b/c/include.php on line 2
[datetag] [error] PHP Warning: main(): Failed opening 'filename.inc' for
inclusion (include_path='.') in /a/b/c/include.php on line 2
-
We usually use a non-standard config, compiling Apache, PHP, OpenSSL etc
under a specific prefix, but dumbing this to default paths has no impact.
Using --with-apxs=/path/to/apxs --prefix=/path/to/installprefix as the
only config parameters to PHP too has no impact on the results.
As for php.ini, I've tried using a clean copy of both
php.ini-recommended and php.ini-dist with no other modifications than
setting safe_mode = On. No significant changes.
Rgds,
Kenneth Svee
Reproduce code:
---
# Content of include.php:
?php
include(filename.inc);
?
# (filename.inc is in same dir as include.php, and
# contains just an arbitrary string, e.g.:
I've been included!
Expected result:
# I expected the string in filename.inc:
I've been included!
Actual result:
--
Just the empty page, and the errormessages in Apaches error_log.
--
Edit bug report at http://bugs.php.net/?id=29207edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29207r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29207r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29207r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29207r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29207r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29207r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29207r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29207r=support
Expected behavior: http://bugs.php.net/fix.php?id=29207r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29207r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29207r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29207r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29207r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29207r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29207r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29207r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29207r=float
#18500 [Com]: Safe mode: php reports wrong uid on file
ID: 18500 Comment by: ksvee at usit dot uio dot no Reported By: b dot courtin at t-online dot net Status: No Feedback Bug Type: PHP options/info functions Operating System: Solaris 2.8 PHP Version: 4.2.1 New Comment: I still experience this bug for php-4.3.4/apache-1.3.29. It seems to have been fixed in 4.2.3 (as this is the only newer version of PHP that works for us on Solaris 8 (SunOS Release 5.8)) and reintroduced in 4.3.X. From 4.3.0 through 4.3.4 this persists. The snapshots tested gave no different results to the releases. On linux (RedHat 7.3 through 9) this has never been a problem. We use a non-standard setup, but have the same configure parameters on both architectures (with the exeption of compiler used; gcc on linux, cc on solaris). I've tried using --with-apxs=/path/to/apxs --prefix=/path/to/prefix as the only options to configure to no avail. Errormessage from tests today (php-4.3.4 release), using the above options to configure: PHP Warning: Unknown(): SAFE MODE Restriction in effect. The script whose uid is 1 is not allowed to access /full/path/to/script.php owned by uid 0 in Unknown on line 0 From php.ini: safe_mode = On 'script.php' is owned by root, so what bothers me is that it at one point finds that the running script (script.php) has uid=1, and at another finds it to be uid=0 (which is correct as fileowner=root = uid=0). Changing owner of script.php does nothing (except getting another uid in the error.log), unless that user has uid=1. In script.php i do an fopen() on 'file.txt'. After doing a 'chmod 1 script.php' the script executes, but I get the same errormessage (followed by a PHP Warning that fopen failed) unless I also do a chmod on file.txt. When both files have uid=1, the script works. Rgds, Kenneth Svee Previous Comments: [2003-02-26 18:48:15] rohan at cs dot rmit dot edu dot au Another comment, also looks related to 12683, I also have compiled in mod_perl 1.x will try to compile without mod_perl and see what happens :) do I need to submit this as a new bug ? or will this one be re-opened ? Cheers Rohan [2003-02-26 18:39:00] rohan at cs dot rmit dot edu dot au Also suffering this bug in 4.3.1/apache 1.3.27 compiled using Sun workshop 7 on Solaris 8 Sparc exact same errors, ie reported uid always = 1 reported gid = file's uid on all file operations fopen() include etc... any progress on this ? [2002-12-30 14:28:27] westman dot 2 at osu dot edu I have been working with trying to get safe_mode to work for almost a week. I have used a number of versions for php, including the recently released 4.3.0 and all of them are giving me this same error message. I have searched the Internet (Google) as well as bugs.php.net, all to no avail. In fact, if I have safe_mode on, I am unable to include any file from ANY directory, even the cwd, unless it is owned by 1 (even though . is enabled both in the include_path and in the safe_mode_include_dirs statements in php.ini): Warning: Unknown(): SAFE MODE Restriction in effect. The script whose uid/gid is 1/5004 is not allowed to access ./prepend.php owned by uid/gid 0/1 in Unknown on line 0 Warning: Unknown(prepend.php): failed to create stream: No such file or directory in Unknown on line 0 Warning: Unknown(): Failed opening 'prepend.php' for inclusion (include_path='.:/opt/apache/php:/opt/apache/php/lib:/opt/apache/php/inc') in Unknown on line 0 Is it possible that safe_mode just doesn't work on Solaris? [2002-11-09 01:00:07] php-bugs at lists dot php dot net No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-10-24 12:19:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Forget the pre1, use the snapshot. And if it really doesn't work, update the version to '4.3.0-dev'. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18500 -- Edit this bug report at http://bugs.php.net/?id=18500edit=1
