velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph.R...@dlr.de
Subject Re: security audit
Date Mon, 02 Jun 2003 08:07:45 GMT


Nathan Bubna wrote:
> Will said:
[snip]
>>I believe this is a critical issue for Velocity web developers
> 
> only for those who can't trust their designers.  it's not as critical
> for the rest of us.  that's not to say it needn't be addressed, just
> don't be surprised if you fail to generate a sense of urgency on the
> matter.

I do think Will's point of view is reasonable. OTOH it will increase
the popularity of velocity for service providers. Currently I see some
SP allow PHP and other server-side scripting. If basic velocity can
be configured with a designer-sandbox and be secure per-se it would
be a win-only situation for velocity (with the proper propaganda)!

> 
>>(2)  Event handler allowing developer to control resource pulled up
>>by #include and #parse
> 
> 
>>http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
>>dev@jakarta.apache.org&msgNo=7781
> 
> 
> 
>>Nathan suggests this should be a custom directive.  As a
>>contrasting opinion, I'd like to see this go into the Velocity core,
> 
> as
> 
>>it's a generally useful capability.
> 
> 
> ah, i thought you were proposing to alter the existing directives, not
> an event handler.  mea culpa.
> 
> to revise my stance, it sounds like you have a much better handle on
> how best to implement it.  :)  as for whether it should be in the
> core, i'll be +0 and let others decide.  i certainly don't need it
> (configuring the resource loader path(s) works fine for me), but if
> others really do find it to be "a generally useful capability," then i
> sure won't protest.
> 
> 
>>-- make an included file be relative to the current template.
> 
>> (Easier for the template designer to understand as this is analogous to
>> HTML href's)
> 
> 
> this seems generally useful, but should probably be optional.

The problem is backward compatibility... So the default shoud be BC.
The new feature could provide three modes:
1) BC - everything is template path relative
2) Use the standard practice of paths, where a path starting with a '/'
    is absolute to the template path. Without the path separator at the
    beginning it will be relative to the current template path.
    It still needs consideration if '../' should be allowed in #parse and
    #include statements...
3) Full control of an event handler to resolve the paths of
    included/parsed files. This would enable restrictions on the visibility
    of the underlying file system.

It seems to me using Will's event handler approach could solve all.
The first case would be with none registered, the second an example handler
that should be included in the core, the third one could reside in the
contrib section.

> 
> 
>>-- when a resource is included from a particular pool of pages (e.g.
>>a user web site), pull it from a particular location
> 
> 
>>-- add user-specific permissions for included files
>>
>>The last one is the critical need.
> 
> 
> yes, i can certainly see that it is quite critical for your
> application/use-case.  i do not see this as being at all critical for
> most others.  in fact, AFAICT, such a feature seems very specific to
> applications like yours.

Nope, service providers will not deploy velocity if it is not safe!

> 
> 
>>As I noted in an earlier email, I have about 600 users who can
>>create web templates and upload them into the same resource-
>>space.   Maybe this is a special case.
> 
> 
> i suspect so. :-/
> 
> Nathan Bubna
> nathan@esha.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> 
> 

-- 
:) Christoph Reck


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Mime
View raw message