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)
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.
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....
As an example:
Many users of phpMyAdmin drop it in in their shared hosting providers "/home/my_new_website/www" directory (ie it is directly accessible via http). I know that many "grand-poobahs" of Internet security would say this is a bad idea - but I know for a fact many people do it... because it is easy.
For an open source PHP project to include a SQLite DB of any kind, for install by "the masses", would be very open to misuse... It's just too easy to download the _entire_ SQLite database - no SQL injection attacks needed.
I for one would never do it.
I think that most database setups in general don't keep their information encrypted, and the reasons they use username/password pairs is mainly because (a) they're designed to serve multiple users (at the OS level) on the same machine, and (b) they're designed to be accessed over the network.
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)
Would having a password for SQLite access be a bad idea? (In a web scripting application I think not)
And finally, could someone please provide a web scripting use of SQLite where it was a good choice?
Thanks, Adam
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
