Patch for bug# 41822

18 years ago by Rob Thompson — view source — reply

unread

Here is a patch for bug 41822. The expand_filepath() function will not
work in Solaris if a non-root user attempts to read a file under a
directory with only (--x) permissions.

Currently expand_path() returns NULL and no FD is opened, although the
file is readable. This patch adds a last-ditch effort to open includes
using a relative path and returns NULL if it still can't get a file
descriptor.

expand_filepath() returns NULL in solaris because getcwd() returns NULL
under the above conditions.

Thanks,
-Rob

--- ./plain_wrapper.c.old 2007-10-05 02:50:59.000000000 -0400
+++ ./plain_wrapper.c 2007-10-05 02:55:38.000000000 -0400
@@ -885,9 +885,20 @@
return NULL;
}

  if ((realpath = expand_filepath(filename, `NULL` TSRMLS_CC)) ==

NULL) {

```
          return NULL;
```
```
  }
```

   if ((realpath = expand_filepath(filename, `NULL` TSRMLS_CC)) == NULL)

```
           {
```

           if (options & STREAM_OPEN_FOR_INCLUDE) {

                   /* Attempt to open without path expansion anyways.

                      Files in Solaris dirs with --x will

                      not return a realpath, but are accessible */

                   fd = open(filename, open_flags, 0666);

```
                   if (fd != -1) {
```
```
                           ret =
```

php_stream_fopen_from_fd_int_rel(fd, mode, persistent_id);

                           return ret; }

```
                   else {
```

                           return NULL; }

```
                   }
```

           }

  if (persistent) {
          spprintf(&persistent_id, 0, "streams_stdio_%d_%s",

open_flags, realpath);

18 years ago by Antony Dovgal — view source — reply

unread

Here is a patch for bug 41822. The expand_filepath() function will not
work in Solaris if a non-root user attempts to read a file under a
directory with only (--x) permissions.

Currently expand_path() returns NULL and no FD is opened, although the
file is readable. This patch adds a last-ditch effort to open includes
using a relative path and returns NULL if it still can't get a file
descriptor.

Rob, I believe you're looking into wrong place.
You should be patching virtual_file_ex() in TSRM/tsrm_virtual_cwd.c, the root of
all evils is there as this function is used by expand_filepath() and in all other places.

Also, as you might have noticed, we do not use system calls like open() directly, we use VCWD_xxx() wrappers for that.
They are defined in TSRM/ either.

--
Wbr,
Antony Dovgal

18 years ago by Rob Thompson — view source — reply

unread

Hi Antony,

Antony Dovgal wrote:

Rob, I believe you're looking into wrong place.
You should be patching virtual_file_ex() in TSRM/tsrm_virtual_cwd.c, the root of
all evils is there as this function is used by expand_filepath() and in all other places.

Ok, originally was going to try that, but, virtual_file_ex() is being
truthful in this case and correctly returning false and an empty cwd when:

state->cwd_length == 0

..which is exactly what getcwd() is returning. I'm thinking that
changing the tsrm_virtual_cwd code, or even the expand_filepath()
functions to fake a filepath, even with an #ifdef SOLARIS may not be
good style. I don't know though, I'm still learning here.

Also, as you might have noticed, we do not use system calls like open() directly, we use VCWD_xxx() wrappers for that.
They are defined in TSRM/ either.

The use of the open() function was lifted right from later on in the
function call where the FD for the stream is normally created. Is this
something that needs to be fixed too?

Thanks,
-Rob