Re: [GENERAL] cgi with postgres

"Jeff MacDonald " wrote:
> 'what's to stop someone from logging in to hub, writing a script
> with my name in user=user in the dbi::connect function. then
> making it enter a bunch of bogus data.'
> at first i thought gee well just put a passwd on the database,
> then i thought, gee that's stupid since it's stored in plain text.

Depends on how you're set up. You can use host based
authentification, so only valid machines can make changes.
You can shut out shell accounts on the machine, and then
use the host's username/pass function for connection. You
can use postgres crypt'ed passwords, which doesn't store passwords
at all, it stores a block of zeros encrypted using the password....
at least on the machine itself, not in the CGI's...

(Yes, I'm rambling about other issues, but I'll get there...)

If you're only requiring one username, one password, for a file
everybody has access to, well, yes, that's a problem. Which is why
password files usually have permissions on them, so :
-rw------- 1 postgres demigods 8192 Jan 7 11:55 pg_shadow
can only be read/written by user postgres, group demigods.

See:
http://www.postgresql.org/doxlist.html for a rough overview
of how this is supposed to work..

(Still rambling, not about scripted, stored, user/pass access yet)

Yes, yes, you can have connections that are username only. You
can have username and password, in a cgi, which is why you
*don't use real, powerful, usernames and passwords in
scripts*. You use things like www or nobody, which write to
temporary tables. Which are then inspected for accuracy,
or validated, or verified. If your question is framed as
"when I give others access into the bank, how do I know
they won't steal money?", the response is "by not
letting them near the real money". You set up a user for
the db that has the _bare_ minimum, and you never, ever,
use a cgi. or a script, that allows more rights to be
granted.

Put another way: It's a bad move to have suid root programs
available to the regular users for the same reason...

A better metaphor might be: You don't leave your housekeys
at the front door for the mailman to deliver the mail. You
may have a locked mailbox, and when you want to move
the mail, you unlock the box, and _then_ move it. The
user doesn't have privleges to dump bad data into the
secure tables, only insecure tables.

HTH,
-Bop