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>.
>
> 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. |
> `------------------------------------------------------------'
KP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
