On 23/08/2004, at 8:27 PM, Zeev Suraski wrote:
At 15:18 23/08/2004, Adam Q wrote:
On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
At 13:56 23/08/2004, Adam Q wrote:Dear all,
I feel I may have uncovered a potentially large difficulty for the adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it makes it almost useless in a webscripting language.
Why is that? You would have to gain file-level access on the server in order to read any data. With properly set permissions and reasonable security, that shouldn't be possible.
With my own tests there is no way to distinguish between the PHP SQLite process trying to read data from the database (allowed) and Apache trying to download the DB via - http://www.example.com/db/SQLITE.DB (not allowed)
Hrm, well, it's a very bad idea to put the database anywhere under the document root, because then you'd obviously be serving it for everyone to download. Encryption or no encryption, that's a very bad idea.
Instead, you should place the database file outside of the document root (e.g. /usr/local/sqlite). Make sure that this directory is properly writable by the web server process and PHP, and you're done.
Putting the files outside the document root is secure, I agree... But how can you be sure of this with an open source application (as opposed to internally developed)? People are likely to drop your application anywhere in their web tree they think it fits.
And I'm thinking specifically of shared hosting situations (where PHP is used a great deal) where you are unable to change the hosting configuration.
These setups typically run with setuid and/or chroot solutions, which allow you (or the hosting provider) to solve that issue.
How can I ask people to contact their hosting provider for a special setup before using my application?
There's really no need to use anything special, as you can avoid the problem altogether instead of trying to solve it. You are right, though, that if your particular hosting provider forces you to store the database alongside the PHP files, it's not a good idea at all.
Not force... Just a likely possibility
I disagree about the differences in security models. In certain ways database servers are more vulnerable since they are designed to work with remote users, which always opens the door for remote exploits. SQLite, on the other hand, relies completely on the operating system (and the system administrator) to set it up properly, and once that's done - it's rock solid secure.
OK. So I start to see where we are getting our wired crossed.
I am aware of the "best" ways to secure a PHP application. And I agree with you if you put the DB outside the document root and follow security best practices it can be seen as potentially more secure than an SQL server.
But there is also the matter of making to easy for people to d/l and use my application.... Which is my main point.
I would like to distribute a tarball for a PHP application that can be dropped into someones website along the same lines as PostNuke, phpMyAdmin etc (you get the idea). I would like to use a SQLite DB to store the data for this application (so that the user doesn't need a server setup as well), and I wanted to keep it all bundled together for the sake of ease of install.
...Due to the complication of securing this setup SQLite can't be used (IMHO)
And I also agree encrypting the DB is not a really fantastic solution.... but provides a good deal of protection compared to nothing.
Thanks, Adam
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
