> As that means that SQLite extensions can only be loaded through C code > (not through SQL), and if someone can upload and execute code to your > server, your server is compromised anyway, having to edit ini files to > enable extension loading, seems like a bad tradeoff.
I'm sorry to disagree, but changing this would be a bad idea for security. Imagine this scenario: - user can execute SQL statements (that's the case in my app: users can execute read-only statements, this is by design) - user can upload files I'm quite sure that I never want users to be able to load any extension through SQL, or it would mean trouble :( Also, we have recently see malicious extensions able to escape SQLite3 and gain shell access... Sounds bad. So just like in the SQLite3 extension, extension loading should be limited to using the PHP method, not SQL. And we should be able to restrict which extensions can be loaded, at the server level (PHP_INI_SYSTEM), as in mass hosting we don't want hosted sites to be able to load any extension. For other points of the RFC: - forcing to UTF8 is OK for me, I don't think anyone ever requested being able to do something different over the years for the SQLite3 extension. - it would be great to also have ::setAuthorizer in PDOSQLite :) - same for ::backup :) - not sure what would be the best for asserting if a statement is read-only, to get the same as SQLite3Stmt::readOnly(), maybe something like: PDOStatement::getAttribute(PDOSQLite::READ_ONLY_STATEMENT) ? Thanks for your work and time! It's great to finally see some progress on PDO and custom driver features :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
