Re: "Safe Mode" processing for XSLT

Conal,

Just want to throw in my two cents. I think p:xslt in itself is
harmless, particularly if you didn’t install any extension functions
with direct OS access. Even if the stylesheet uses xsl:result-document,
it won’t write stuff to disk by itself. These documents appear on the
secondary port and are typically handled by p:store if they need to be
stored to disk. So if your users are only able to upload their own XSLT
and if you don’t use their outputs as inputs for p:store or for the
options of EXProc file system steps such as p:delete, then you should be
safe. Apart from bad code that might cause stack overflows or excessive
computing times. Or am I missing something?

Gerrit

On 03.06.2015 06:02, Conal Tuohy wrote:
> Thanks Norm!
> 
> If I understand correctly, then, this existing "safe mode" feature would
> allow me to run "safe" XProc pipelines consisting entirely of "safe"
> steps including XSLT in its own safe mode, but it does not (currently)
> allow me to run individual steps in a safe mode, as part of a larger
> pipeline which included unsafe steps?
> 
> I do need to be able to read and write files, but I could certainly make
> use of that "safe mode" feature to run an extra instance of my XProc
> server, with Calabash configured in safe mode, just as a sandbox for
> running user-supplied XSLT. My unsafe pipelines could use p:http-request
> to request execution of XSLT in the "sandbox" instance of Calabash.
> 
> C
> 
> On 3 June 2015 at 01:34, Norman Walsh <ndw@nwalsh.com
> <mailto:ndw@nwalsh.com>> wrote:
> 
>     Florent Georges <fgeorges@fgeorges.org
>     <mailto:fgeorges@fgeorges.org>> writes:
>     > On 2 June 2015 at 16:31, Norman Walsh wrote:
>     >> Uhm. It forbids all of the fileutils steps, it does seem to attempt to
>     >> forbid access to file: URIs, it rejects attempts to instantiate
>     >> extension steps (rather crudely), and forbids access to
>     >> p;directory-list, p:exec, and p:store.
>     >
>     >   So that's at the Calabash level itself, isn't it?  Not at the p:xslt
>     > level?  Do the same limitations apply (transitively) to p:xslt and
>     > p:xquery?
> 
>     The standard XSLT and XQuery I/O functions go through the resolver
>     which is where the restriction is imposed, so "yes" to a large extent.
>     I'm not promising that there isn't some weird Saxon extension function
>     that I don't know about that does file I/O directly :-)
> 
>                                             Be seeing you,
>                                               norm
> 
>     --
>     Norman Walsh
>     Lead Engineer
>     MarkLogic Corporation
>     Phone: +1 512 761 6676 <tel:%2B1%20512%20761%206676>
>     www.marklogic.com <http://www.marklogic.com>
> 
> 

-- 
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@le-tex.de, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler

Received on Wednesday, 3 June 2015 05:41:40 UTC