|
|
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
|
|