At 5:51 PM -0400 2000-06-29, John Cichy wrote:
>Daevid Vincent wrote:
>> Ugh. Okay, let me try to explain this in more detail for those of you who
>> STILL don't see the need.
>> We have *A* mySQL server -- as in one single server for all our database
>> We have *A* web server (Apache + PHP).
>> We are a startup company with 100+ employees in various departments.
>> Each dept has it's own projects and it's own database programmers in some
>> cases (Content, Bug tracking, accounting, HR, etc).
>> mySQL's 'authentication' works just fine if you're restricting the databases
>> and people are using a special program or the command line client to use it.
>> However, the reality is, that all the forms and stuff are web based these
>> days for ease of maintenance and access. Therefore there can only be ONE
>> effective user/password in the database -- that being "nobody" and "secret"
>> that Apache/PHP uses to do SQL. Are you with me so far?
>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.
> > Now, if ANYONE can write code that all uses the web to connect to mySQL to
>> get at data, they can easily write other code to access ANY data in ANY
>> database on the server reguardless of what that 'mysql' database says are
>> the restrictions. Still following?
>Yes, but the design above protects against this.
I don't think so. It doesn't protect you against me discovering your
> > So, now, we have lets say we have someone like me -- yes, I'm an honest,
>> trustworthy person -- who is writing much of these database/web
>> applications. NOBODY at my company (or any company for that matter) is going
>> to want to have their personal data (like how many options they have, or how
>> much money they make or whatever) visible to me (or again, anyone with a
>> little PHP skill and access to the web server). And similarly, I as an
>> employee, don't want other people knowing my vitals either.
>If your are writing code and testing on production database's where sensitive
>information is you have a lot more to worry about then just security. The
>code that accesses personnel records should ask for a userid and
>use this information to access the info the script needs.
Okay, now here there is some security, because you're asking the client
for the name/password, not storing it in a file somewhere that any script
Paul DuBois, paul@stripped