Bug #52257 [Opn->Nab]: module php5-librdf causes libxslt's security module to fail

Edit report at https://bugs.php.net/bug.php?id=52257&edit=1 ID: 52257 Updated by: mike@php.net Reported by: matth at mlalonde dot net Summary: module php5-librdf causes libxslt's security module to fail -Status: Open +Status: Not a bug Type: Bug Package: XSLT related Operating System: Ubuntu LTS PHP Version: 5.3.2 Block user comment: N Private report: N New Comment: So using XSLTProcessor::setSecurityPrefs() seems to be needed if you use something external (to PHP) like ext-librdf, which overrides the default security preferences. Fine. Previous Comments: ------------------------------------------------------------------------ [2012-07-21 16:12:06] jdmadea at gmail dot com I have some PHP code using librdf. I use php from the command line to run unit tests. I also use it to generate documentation with phpDocumentor which, of course, uses libxslt. It took a while to work out why phpDocumentor was failing. The error, for the sake of people searching and having difficulty finding any info, was: PHP Warning: XSLTProcessor::importStylesheet(): error in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xs l.php on line 62 > It's using libxslt as part of the GRDDL rdf parser to execute XSLT scripts off > the web, never from local files. So it makes sense to refuse any local file > read/write as the default security policy. That seems like an unnecessary policy to me. Surely remote files are generally less safe than local ones. ------------------------------------------------------------------------ [2010-08-06 19:45:04] dave at dajobe dot org (Found the add comment button!) Just to explain a bit more why raptor does this. It's using libxslt as part of the GRDDL rdf parser to execute XSLT scripts off the web, never from local files. So it makes sense to refuse any local file read/write as the default security policy. This does however conflict with general user-use of libxslt on local files in another module, such as PHP's xslt module. So in one memory namespace, you need to be both restrictive and permissive, yet the *default* security policy can only be set libxslt-wide: http://www.xmlsoft.org/XSLT/html/libxslt-security.html#xsltSetDefaultSecurityPrefs The context-specific policy can be different: http://www.xmlsoft.org/XSLT/html/libxslt-security.html#xsltSetCtxtSecurityPrefs ------------------------------------------------------------------------ [2010-08-06 18:58:02] lsmith@php.net some additional infos from Dave Beckett: but anyway, more info at http://bugs.librdf.org/mantis/view.php?id=379 I found I could duplicate the error and as I suspected if I made raptor skip over xsltSetSecurityPrefs() and xsltSetDefaultSecurityPrefs() calls, the program works as expected. I can probably patch raptor to fix this, then patch the librdf-php to use that fix, but that's quite indirect. Seems all libxslt users in the same memory space will have this issue. ------------------------------------------------------------------------ [2010-08-06 15:35:38] lsmith@php.net to add some more context about the issue, i talked to the author of php rdf ext on the #reland freenode IRC channel: [15:23] <dajobe> lsmith: it's not the php module, it's raptor which redland uses [15:23] <dajobe> it sets the libxslt security policy [15:24] <dajobe> http://librdf.org/raptor/api-1.4/raptor-section- general.html#raptor-set-libxslt-security-preferences [15:25] <dajobe> it's hard to do - how is raptor/redland suppose to know when a calling application is also wanting to adjust parameters of a shared library [15:26] <dajobe> it's the calling app's responsibility - php in this case ------------------------------------------------------------------------ [2010-07-30 10:55:44] penny at liip dot ch I had exactly the same problem with the following versions: libxslt1.1 1.1.24-2 php5 5.2.6.dfsg.1-1+lenny8 php5-librdf 1.0.7.1-1+b1 Purging php5-librdf fixed the problem. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=52257 -- Edit this bug report at https://bugs.php.net/bug.php?id=52257&edit=1