ID: 41822
Comment by: ab5602 at wayne dot edu
Reported By: ian at onlineloop dot com
Status: Assigned
Bug Type: *Directory/Filesystem functions
Operating System: Solaris 10
PHP Version: 5.2CVS-20070627
Assigned To: tony2001
New Comment:
correction: a) Execute a program that implements getcwd() that is
suid-root.
Previous Comments:
------------------------------------------------------------------------
[2007-10-01 23:41:38] ab5602 at wayne dot edu
Wow, this is strange. I'm very much closer to seeing what is going on
with PHP+Solaris that is causing the issue here Ian. I've tested
pwd/getcwd() with every combination I could think of and this is how
Solaris feels about permissions:
If you are not root AND you want to get your current working directory
that has parents with exclusively 'x' permissions, you must do one of
two things:
a) Execute a getuid() program that is suid-root.
OR: And this is the strange one...
b) Tell Solaris that you already know where you are!!
If it is feasible, I'll see if I can come up with a patch to implement
(b) if your architecture is Solaris and send it to the PHP internals
list. See below for how this works:
-----
# uname -a
SunOS opteron 5.10 Generic_118855-14 i86pc i386 i86pc
# pwd
/
# find ./dirtest/ -ls
449393 1 d--x--x--x 3 root root 512 Oct 1 19:29
./dirtest/
449394 1 d--x--x--x 2 root root 512 Oct 1 19:29
./dirtest/dirtest2
# cd /dirtest/dirtest2
# pwd
/dirtest/dirtest2
# su nobody
# pwd
cannot determine current directory
# cd /dirtest/dirtest2/
# pwd
/dirtest/dirtest2
#
------------------------------------------------------------------------
[2007-10-01 17:33:08] ab5602 at wayne dot edu
Hi, the 'pwd' command works just fine for me too on any platform.
However, suid'd use of the getcwd() function I think is the issue. The
below demonstrates what I think is the going on with how Solaris behaves
vs. how PHP expects the getcwd() command to behave.
The following code was compiled and run on both Linux and Solaris
platforms under a local filesystem and called cwdtest:
#include <stdio.h>
main()
{
char str[200];
if (getcwd(str, sizeof(str)) == NULL)
printf("getcwd failed!!!\n");
else
printf("CWD = %s\n",str);
}
------ Linux ------
# uname -a
Linux messaging2.wayne.edu 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17
EDT 2006 i686 athlon i386 GNU/Linux
# find ./localfs -ls
32001 8 d--x--x--x 3 nobody nobody 4096 Oct 1 13:05
./localfs
32002 8 d--x--x--x 2 nobody nobody 4096 Oct 1 13:12
./localfs/test123
32004 12 -rwsr-xr-x 1 nobody nobody 4878 Oct 1 13:06
./localfs/test123/cwdtest
# su nobody
# cd /localfs/test123
# ./cwdtest
CWD = /localfs/test123
# pwd
/localfs/test123
#
------ Solaris 10 ------
# uname -a
SunOS opteron 5.10 Generic_118855-14 i86pc i386 i86pc
# find ./localfs -ls
449384 1 d--x--x--x 3 nobody nobody 512 Oct 1 13:13
./localfs
449386 1 d--x--x--x 2 nobody nobody 512 Oct 1 13:13
./localfs/test123
449388 7 -rwsr-xr-x 1 nobody nobody 6552 Oct 1 12:57
./localfs/test123/cwdtest
# su nobody
# cd /localfs/test123
# ./cwdtest
getcwd failed!!!
# pwd
/localfs/test123
#
------------------------------------------------------------------------
[2007-10-01 11:37:49] ian at onlineloop dot com
>ab5602> Have you tried adding r-x to every subdir below and
including the path?
This is not an option here. First issue is user data security. All
users have ftp access to the system, and as a reqult of cross
cooperations, users need to be able to go through the users root
directory (note that this is not the system root!), meaning if all
directoriues were r-x, then users could easily see and access data
that is not relevant to them (other access issues that are obvious
here have been taken care of using system groups). Second issue is
we have tens of thousands of directories like this, and changing the
permissions to something else is simply not possible because the
users all have individual requirements, and most have set their own
permission schemes. Third issue is *this used to work!!!*
>ab5602> Also, have a look at: #41899 "Can't open files with leading
relative path of '..' and '..' is not readable."
The bugs are related. I am following both of them as they are both
relevant to us.
>ab5602> ...but getcwd() still returned nothing even then.
Getcwd() needs read permissions on the directory, however in a shell
in a directory with such permissions, pwd still returns the correct
directory even if nothing else can be read, and files with read
permission can also still be read:
[EMAIL PROTECTED]:/home/ian/testdir# ls -la
total 10
drwx--x--x 3 root root 512 Oct 1 13:17 .
drwxr-xr-x 6 ian staff 1536 Oct 1 12:56 ..
-rw-r--r-- 1 root root 24 Oct 1 13:15 afile
drwx--x--x 2 root root 512 Oct 1 13:17 testd2
[EMAIL PROTECTED]:/home/ian/testdir# cd testd2/
[EMAIL PROTECTED]:/home/ian/testdir/testd2# ls -la
total 6
drwx--x--x 2 root root 512 Oct 1 13:17 .
drwx--x--x 3 root root 512 Oct 1 13:17 ..
-rw-r--r-- 1 root root 15 Oct 1 13:17 afile2
[EMAIL PROTECTED]:/home/ian/testdir/testd2# cd ../../
[EMAIL PROTECTED]:/home/ian# su - ian
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
[EMAIL PROTECTED]: cd testdir
[EMAIL PROTECTED]: pwd
/home/ian/testdir
[EMAIL PROTECTED]: ls -la
.: Permission denied
total 2
[EMAIL PROTECTED]: cat afile
Good bye cruel world!!!
[EMAIL PROTECTED]: cd testd2
[EMAIL PROTECTED]: pwd
/home/ian/testdir/testd2
[EMAIL PROTECTED]: cat afile2
Frodo lives!!!
[EMAIL PROTECTED]: ls -la
.: Permission denied
total 2
[EMAIL PROTECTED]: logout
[EMAIL PROTECTED]:/home/ian#
To me, the problem is not something from Sun or Solaris. The
problems are in the way PHP is handling access to the files and
directories. This needs to be fixed so everything works correctly
again.
------------------------------------------------------------------------
[2007-09-30 23:46:14] ab5602 at wayne dot edu
Ok, or, these may be the same problem caused by 2 different root
issues. In your initial post, you mentioned "Directory permissions for
the webserver process are access only (--x).". I just lifted the
following out of PHP source for tsrm_virtual_cwd.c:
/* cwd_length can be 0 when getcwd() fails.
* This can happen under solaris when a dir does not have read
permissions
* but *does* have execute permissions */
Have you tried adding r-x to every subdir below and including the
path?
Previous versions of PHP including 5.0.5 worked for me with a relative
include() parameter, but getcwd() still returned nothing even then.
This did not really cause a problem until include() broke for me. I
believe that PHP now rebuilds a fully qualified path based on getcwd()
when it tries to open the file stream and when you are using relative
includes. This may have changed since earlier versions. I think this
issue is probably related somehow to broken Solaris functions that don't
work if suid:
Also, have a look at: #41899 "Can't open files with leading relative
path of '..' and '..' is not readable."
They all seem related somehow.
------------------------------------------------------------------------
[2007-09-30 22:05:05] ian at onlineloop dot com
NFS has nothing to do with it, this bug is definately *not* at the OS
level. We have all file systems mounted locally, and still have the
problem.
NFS may however cause other problems, particularly userid mapping,
which are more difficult to solve and need to be solved at the OS
level.
All of this stuff worked just fine up until PHP 5.1.6, since PHP
5.2.0 it's broken, and there is apparently no activity to fix this
bug.
------------------------------------------------------------------------
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/41822
--
Edit this bug report at http://bugs.php.net/?id=41822&edit=1
