At 1:31 PM +0200 2000-06-30, Carsten H. Pedersen wrote:
> > -----Original Message-----
>> From: Paul DuBois [mailto:paul@stripped]
>> Sent: Friday, June 30, 2000 6:30 AM
>> >I think you have a misconception here, because you can specify a
>> username from
>> >the connection code in the web script you can provide different levels
>> >security on the web, in fact the user nobody (apache) can be
>> disallowed all
>> >access to the database. This puts some work on the DBamins plate
>> but it is
>> >possible to say accounting can only write scripts that will only access
>> >billing records in the DB, while the customer rep programers can
>> >have access to
>> >more sensitive information.
>> I don't see this. Accounting can write scripts that read the customer
>> rep programmers' scripts to find out their password. The Web server has
>> to be able to read everybody's scripts, so if you can write a script,
>> I can write one to read your script. You can write a script that accesses
>> a file outside the Web tree containing the connection password, but I can
>> still write a script to read that file.
>> I don't see any security in this at all.
>Why would the password need to be stored on the machine? There are many
>other places you could store a password (heads of users being a good
The text above says "you can specify a username from the connection code".
I took that to mean "in the code of the script" and was simply pointing
out that all scripts the Web server can run must be readable by the Web
server uid. That means you can't hide passwords in your scripts, for
example, by making the script readable *only* by the Web server; I wanted
to point that out in case someone thought otherwise.
>Yes, it would be more cumbersome for users to enter a password each
>time they access the db / start a session / whatever granularity you
>choose. But implementing security usually is, and is certainly always
>a matter of judging useability/accessability versus security.
>Yes, it will require quite a bit of skill on the part of the
>webadmin/dbadmin. But programming for security *is* difficult and
>there is never an easy way.
Paul DuBois, paul@stripped