On 17.02.11 11:08, clipka wrote:
> Am 17.02.2011 02:07, schrieb dickbalaska:
>> clipka<ano### [at] anonymousorg> wrote:
>>> Am 16.02.2011 20:51, schrieb Darren New:
>>
>>> From the code it is pretty obvious that the original intention is to
>>> eliminate ".." from paths like "foo/bar/../fnord" by contracting it to
>>> "foo/../fnord" - no security stuff intended there.
>>
>> What is the point of doing path contraction, if not for security purposes?
>> Otherwise you are introducing code with no benefit. The OS is going to handle
>> ..../ just fine for you already.
>>
>> Someone above said "../ at the start of the path". Don't forget that
>> foo/../../../../etc/passwd is legal.
>
> You may be right there - but I guess we agree that contracting
> "foo/../../fnord" to "foo/fnord" is bogus,

Indeed, that is a bug. If a path cannot be resolved to a concrete relative 
path in the backend alone, an error message should be issued. Note that this 
is actually an extension to 3.6 behavior, as it was never documented that 
relative paths would work at all, let alone walking of the directory 
structure using ../.

> whatever reason there may be to
> contract "foo/bar/../fnord" to "foo/fnord".

The reason is not apparent in 3.7 because there is no code that makes use of 
this feature yet: When you render over a network, you don't want to transmit 
files twice. Hence the code is supposed to resolve paths where applicable to 
make life easier for those that use ../ notation as undocumented 3.6 
feature. The net result is then a cache of files.

     Thorsten

Post a reply to this message