Darren,
Thanks for the response. I knew about this issue as a security hole,
which is why one of my options was to place the DB files out of the
entire web doc tree. Happily, you took something that I had to learn
the hard way from tech notes and experience and codified it in a way
that confirmed and clarified a few points for me. PHP has experienced
security problems along these lines in the past, and it now discourages
use of PHP as a CGI and recommends using it as a server module.
However, in my design architecture, I was finding it somewhat desirable
that at least some DB files exist in the application directory. I
suppose, though, that I could find ways around that.
Have you or anyone encountered issues regarding my other questions,
that of using SQLite as a web-served DB system? How do the recently
discussed issues of concurrency and the locking of DB tables and files
affect the use of a web site delivered SQLite DB system, and is the
strategy of using multiple DB files (which is what I understood D.
Richard Hipp's suggestion to be) effective enough if one central table
were to have hundreds of thousands of records?
This is an area that I find difficult to test since PHP5 is still only
in beta, so I can't put it on a public server and get a hundred thousand
of my closest friends to try to hit the site at the same time.... But
since some of you seem to be using it with other languages, maybe you
have encountered the situation and found solutions?
Thanks!
V
On Sun, 2003-11-23 at 23:57, Darren Duncan wrote:
> At 9:04 PM -0500 11/23/03, Vania Smrkovski wrote:
> > Speaking to the first question, regarding security of data, aside from
> >some of the obvious, like putting the DB files out of the web document
> >tree, are there any ways to configure SQLite to keep the DB files in
> >some non-readable format? I had hoped to use an architecture where each
> >web application had a SQLite DB in the same folder for session and
> >storage of data useful only to that app, and to have a general SQLite DB
> >file elsewhere for all apps to use, but was somewhat startled when I
> >tried accessing the SQLite file directly in my browser and got almost
> >perfectly readable data dumped to my screen.... I was hoping that I
> >might have overlooked a configuration switch that would make the file
> >unreadable, but have not found this yet....
>
> What you describe is a general website design flaw and/or gaping security hole on
> your part and has nothing specifically to do with SQLite.
>
> The fact is that any individual files on your web server which are not supposed to
> be directly invoked or downloaded by a client web browser (or robot) should not be
> inside any public directory. You should store all of these files, including any
> SQLite databases for sessions, somewhere else on your server. No one can download
> your database if there is no web address that corresponds to it, can they?
>
> For my part, I set up my web applications (all written in Perl 5 currently) like
> this (simplified for illustration):
>
> /users/me
> /users/me/private_files
> /users/me/private_files/mylib1.pm
> /users/me/private_files/mylib2.pm
> /users/me/private_files/mydata1.txt
> /users/me/private_files/mydata2.db
> /users/me/private_files/mymain.pl
> /users/me/public_files
> /users/me/public_files/default.pl -> soft link -> ../private_files/mymain.pl
> /users/me/public_files/myimage1.gif
> /users/me/public_files/myimage2.gif
>
> So only items in public_files can be invoked or downloaded. No one can see the
> items in private_files, which includes the source code of my Perl library files,
> which don't execute. The main program, mymain, is very minimalist and doesn't
> contain any sensitive data; it mainly just calls a function in one of my libraries
> that does the real work; this also means if the web server has a bad day and becomes
> misconfigured, making the perl script a source-downloadable file, no one is seeing
> anything important.
>
> The catch with the above approach is that you have to explicitely change the current
> working directory or use path references to files. You can't simply say "open this
> file in my current directory", since the "current" directory is the public folder.
>
> -- Darren Duncan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Vania Smrkovski
http://www.pandorasdream.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
