The Roundup code converting a template name (as passed in @template in a
request) to the path to a file is vulnerable to path traversal,
accessing files outside the templates directory, in some circumstances.

Specifically, suppose the templates directory has a subdirectory of the
form <classname>.<something>.  Then a request for

<tracker
URL>/<classname>?@template=<something>/../../../../../../../etc/passwd

will use the contents of <templates
directory>/<classname>.<something>/../../../../../../../etc/passwd as a
template, typically revealing the contents of /etc/passwd.

Normally this would not be an issue because of the need for a
subdirectory with a name in a particular form, starting with a valid
class name (or _generic, etc.).  But creating such subdirectories should
not cause files outside the directory to be disclosed, and it would seem
reasonable for an installation to use subdirectories if it has many
templates relating to a particular class, say a <classname>.templates
directory to collect those templates (so completely disallowing
directory separators in template names would disallow too much; a check
that the file is inside the templates directory, like that done for
serving static files, would be better).

msg5777 on issue 2550891 has a possible patch for this. It turns out
I re-implemented much of the cgi/client.py:Client::serve_static_file
logic to prevent path traversal. The only difference is the static
check uses normpath not realpath.

Note my patch only handles TAL based templates (zopetal and chameleon).
Jinja is handled on the issue.

Closing see changeset: d22eb1d40d0e