On Sun, 2007-01-07 at 19:39 +0100, spam@xxxxxxxxxxxxxx wrote:
> On 5 Jan 2007, robert@xxxxxxxxxxxxx wrote:
>
> >
> > On Fri, 2007-01-05 at 22:07 +0100, Jochem Maas wrote:
> >> reply at the bottom ...
> >>
> >> (Karl Pflästerer) wrote:
> >> > Hi
> >> > let's say we have the follwing directory structure:
> >> > directory test, with to subdirectories: a and b; both have ssi
> >> > subdirectory; a has also a subdirectory c with an index.php file in it
> >> > and in b we habe a symbolic link to a/c.
> >> >
> >> > On the shell it looks like this:
> >> > ,----
> >> > | /htdocs/test>ls -gG *
> >> > | a:
> >> > | total 8
> >> > | drwxr-xr-x 2 4096 Jan 4 20:55 c
> >> > | drwxr-xr-x 2 4096 Jan 4 20:51 ssi
> >> > |
> >> > | b:
> >> > | total 4
> >> > | lrwxrwxrwx 1 6 Jan 4 20:53 c -> ../a/c
> >> > | drwxr-xr-x 2 4096 Jan 4 20:53 ssi
> >> > | ~/htdocs/test>cat a/ssi/a.inc
> >> > | In directory a
> >> > |
> >> > | ~/htdocs/test>cat b/ssi/a.inc
> >> > | In directory b
> >> > `----
> >> >
> >> > As you see whe have an a.inc in each ssi. If we call now the index.php
> >> > which does nothing more than to:
> >> > include('../ssi/a.inc')
> >> > what would you expect to read if you called b/c/index.php? I expected to
> >> > read 'In directory b' but I read 'In directory a'.
> >> >
> >> > ,----
> >> > | ~/htdocs/test>(cd a/c && php -f index.php )
> >> > | In directory a
> >> > |
> >> > |
> >> > | ~/htdocs/test>(cd b/c && php -f index.php )
> >> > | In directory a
> >> > `----
> >> >
> >> > In my opinion include() should respect symlinks to directories and not
> >> > dereference them before finding the file to include. Or am I wrong here?
> >>
> >> I have tested using your exact description and get the result, you can
> >> be fairly certain this is not something specific to your server/machine.
> >>
> >> I would tend to agree with your premise - but the php devs may have
> >> decided against this behaviour on purpose.
> >
> > PHP needs to dereference symlinks so it knows exactly where it is in
> > case of security violations. This prevents symlinking into paths for
> > which you don't have access... especially important on shared hosts.
>
> I always thought this kind of check would only be done if you used
> safe_mode. If you're not a shared host there's no need for this kind of
> check. Everyone who has the ability to place a php script on the server
> also has shell access (here at work at least). To explain why I asked
> about this behaviour (so it's not only a convoluted example I showed but
> a simplified version of an existing directory structure (if it would be
> done that way today is another question)) see also MID
> <u3b6mbshf.fsf@xxxxxxxxxxxxxxxxxxxxxx>.
I don't know for sure, I made some assumptions as a case example of why
the dereferencing might occur. Either way though, if you have one
behaviour in one situation, for portability, you had best have the same
behaviour in every situation :) Another question might be... does apache
dereference? If so, maybe PHP is just following suit :)
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
