- From: Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>
- Date: Wed, 03 Jun 2015 07:41:10 +0200
- To: xproc-dev@w3.org
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