Re: SQLite security

I don't get this thread either... it's no more or less secure than anything else you store in a file. We are not going to hack libsqlite or change anything else in PHP to cater for this--it really isn't our problem. If you have a cheap provider that insists on putting your private data under the web root, it's time to use someone else or shell out more cash: either upgrade to a better host or pay for the crypto-enabled sqlite library (contact the sqlite author for more information). --Wez. On Tue, 24 Aug 2004 09:22:39 -0700 (Pacific Standard Time), Rasmus Lerdorf <rasmus@php.net> wrote: > On Tue, 24 Aug 2004, Adam Q wrote: > > I thought more about the issue last night and I guess it can be summaried as > > thus: > > In skilled hands an SQLite DB can be potentially more secure than a standard > > DB - but in unskilled hands the reverse is true, and SQLite becomes seriously > > insecure. Standard DBs don't vary to the same extent. > > > > Could we have SQLite DB creation "option" that creates the DB with a header > > that begins <?php? (SQLite DBs are close to normal text in the first 20 chars > > anyway... ) - either way, I'm going to do some testing of Ilia's create table > > option and see if I can get around it. > > > > Wow I can't believe I might be able to use an SQLite DB after all. > > I still don't understand this entire thread. If you insist on making the > file accessible from your DocRoot why can't you simply block any direct > access to it via an Apache rule? > > Something like: > > <Files ~ "\.sql$"> > Order allow,deny > Deny from all > </Files> > > And then name your sqlite files whatever.sql > > And no, we are not going to mangle every sqlite DB we create by sticking > <?php in it and suggesting that people feed their sqlite DB files through > the PHP parser. What if someone comes along and comes up with a hack that > changes the first table name to <?system("rm *") ? I would hate to have > to explain to people that we promoted that sort of idiotic hack. > > -Rasmus > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >