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.
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.
As I stated in my initial post... Yes it is possible to specifically deny access to the file for Apache/IIS... but for an open source PHP project this creates too many complications to make it feasible. IIS does not recognise ".htaccess" files so including something like that with the project is only part of the way there....
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.
The data in the database may not be encrypted, but I pay good money for the relative security that nobody else can read the data in my database (even in a shared hosting situation) provided by the fact that only I know the password to the database....
With an SQLite database I have only security by "obscurity" I.e. hide the file or make it an unusual name nobody would guess. (with an open source project this is pretty difficult unless you generate a random name on first install)
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.
Would having a password for SQLite access be a bad idea? (In a web scripting application I think not)
Not sure, but it's certainly not the right solution to the problem you mentioned. A good combination of setuid, chroot and proper definition of the per-user document root is the right solution for this problem.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
