<RANT MODE="paranoid security weenie">
<STRONG>No, no, no, and again, no.</STRONG>
In a previous life I was paid to be a "paranoid security weenie", so a
suggestion like below makes my skin crawl. JMP, do not take this
personally, you just happen to be the latest person making this suggestion.
I have seen this comment from too many application programmers (not all,
maybe not a lot, but way too many). It seems as if the effort is too much
to design the security requirements correctly into the application, so
applications, when deployed into a production environment, have all sorts
of problems that would never pass a reasonable security audit. File
permissions are not that hard to implement correctly for most common
situations. Yes, there are some special cases that may need some wizardry,
but this does not appear to be one of them.
</RANT>
Unless you want everyone with any access to the directory containing the
database to be able to muck with the database (including file deletion or
inserting bogus data), use the policy of least privilege. If only your web
server needs write access to the file, make it owned and writable only by
the web server user. If only this application needs access, make a special
ID for this purpose, set the script setuid (use appropriate caution here),
and make the script writable only to that special ID (you could also do
this with a special group / SetGID - probably more appropriate). By
setting the file to be (at most) readable by those not needing write access
to the file, and not readable at all to those not needing access, you
remove a large set of potential problems. If you have certain information
in this DB (such as student ID numbers - SS# in some institutions), you
could also be opening yourself up to liability problems if you leave it
open to the world.
At the most, I would suggest 664, owned by the web server, group assigned
to a special purpose group, with those needing update permissions in the
group assigned to the file.
Try passing a security audit with your $DB directory set mode 777 or files
666. Oracle actually suggested doing that in their manuals (might still?)
in Oracle 6 and 7 (am I dating myself now?).
Brian
--
Brian T. Wightman brian.t.wightman@xxxxxxx
Global Data Management http://pdm.cg.jci.com/
Johnson Controls, Controls Group (414) 524-4025
|---------+---------------------------->
| | jmp@xxxxxxxxxxxx |
| | |
| | 05/21/2004 11:11 |
| | AM |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: ghankerson01@xxxxxxxxxxxxxx
|
| cc: cgiapp@xxxxxxxxxxxxxxxxx
|
| Subject: Re: [cgiapp] Using DBI in CGI::Application
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Le 21 mai 04, à 17:28, Geoffrey G. Hankerson a écrit :
> package Course_manager;
> use base 'CGI::Application';
> use DBI;
> use strict;
> use warnings;
>
> sub setup{
> my $self = shift;
> $self->run_modes(
> 'mode_1'=>'add_instructor',
> 'mode_2'=>'add_course',
> 'mode_3'=>'edit_instructor',
> 'mode_4'=>'edit_exam',
> 'mode_5'=>'update_course'
> );
> $self->start_mode('mode_1');
> $self->mode_param('rm');
> }
>
> sub teardown{
> my $self = shift;
> #my $dbh = $self->param('dbh');
> #$dbh->disconnect();
> }
>
> sub add_instructor{
> my $self = shift;
> my $sql;
> my $dbh;
> my $sth;
> my $output;
> $dbh =
> DBI->connect('dbi:SQLite:/Library/Webserver/CGI-Executables/cgiDev/
> dbitest/exams.db')
> or die "Error: " . $DBI::errstr;
> $sql = "INSERT INTO profs (profName) VALUES ('Prof BBB')";
> #$sql = "SELECT * FROM profs";
> $sth = $dbh->prepare($sql);
> $sth->execute();
> $output = "text";
> return $output;
> }
>
> Apache error log returns this error:
> courseApp.pl: Use of uninitialized value in subroutine entry at
> Course_manager.pm line 37.
> courseApp.pl: DBD::SQLite::st execute failed: at Course_manager.pm
> line
> 37.
>
> Suggestions are appreciated.
Apache must have Read-Write access to the SQLite file DB :
$ chmod 666 /Library/Webserver/CGI-Executables/cgiDev/dbitest/exams.db
JMP
--
http://www.suricate.net/
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
|
