scott.marlowe wrote:
> On Tue, 13 Jan 2004, Keith G. Murphy wrote:
>
>
>>I'm trying to get a feel for what most people are doing or consider best
>>practice.
>>
>>Given a mod_perl application talking to a PostgreSQL database on the
>>same host, where different users are logging onto the web server using
>>LDAP for authentication, do most people
>>
>>1) have the web server connecting to the database using its own user
>>account (possibly through ident), and controlling access to different
>>database entities strictly through the application itself
>>
>>2) have the web server connecting to the database actually using the
>>user's account (possibly using LDAP authentication against PostgreSQL),
>>and controlling access to different database entities through GRANT, etc.
>>
>>Obviously, (2) leads to more database connections, and you still have to
>>have the application do some work in terms of which forms are available
>>to which users, etc. But I'm a little worried about whether it's best
>>security practice.
>
>
> I do 1. different language (PHP) same basic thing though. All security
> is handled by ACLS I build myself in Postgresql and interrogate via my own
> application.
>
Thanks to all for the discussion so far. I have been doing option 1 so
far as well, but was a bit uncomfortable allowing the web server account
to have complete control over the database, and wondered what the
alternatives might be.
At some point, I may try rolling my own PAM module (as Tom Lane
suggested) that uses the user's browser-authenticated username and
password to map to a PostgreSQL username that constitutes a "role"
(assuming that's possible). The benefit I can see to such a scheme is
that it means anyone who might manage to run a process under the web
server's account would still have to have the appropriate username and
password to do anything to the database. And the limited number of
"role" PostgreSQL usernames would mean fewer connections than using the
original usernames, as John Sidney-Woollett pointed out.
