Re: Security setup. - Mailing list pgsql-general

From Chris Travers
Subject Re: Security setup.
Date
Msg-id CAKt_ZfuWbA1DJL0BVS1-bU3Dz98a3PT3-RXFzHfg+mK7byZSDA@mail.gmail.com
Whole thread Raw
In response to Re: Security setup.  (Sim Zacks <sim@compulab.co.il>)
List pgsql-general
On Sun, Sep 11, 2011 at 12:44 AM, Sim Zacks <sim@compulab.co.il> wrote:
> The problem with trust is that it means that any user can type in any other
> users login name and get access without knowing his password. Even if your
> app is the only access point to the database, you still have to worry about
> a user installing psql or other client onto his desktop and accessing the
> database directly.
>
> If your application is logging in, you still don't want to use trust because
> you can put the password into the application. The level of security that
> you require will depend a lot on the application infrastructure. For
> example, if you are using an application server then you can limit access of
> the database to the IP address of the app server and the DBA's computer.
> That way you don't have to worry about anybody installing a rogue client.
>
This is just about exactly right.  Trust means you trust anyone on the
host to be who they say they are.  It's not generally a good thing,
though restricting it to a specific IP address can be useful
sometimes.

Typically I think a lot of people see trust authentication as an
emergency restore option rather than an actual operating method of
security.  I.e. if your dba changes the passwords as an act of
sabotage and then quits you have an option for the new dba to log in
and set new passwords.  In general though nothing good can  come out
of widely trusting authentication to users.

Best Wishes,
Chris travers

pgsql-general by date:

Previous
From: "George Sexton"
Date:
Subject: Locale for Error Messages
Next
From: Bruce Momjian
Date:
Subject: Re: writing block 6850 of relation 1663/17231/1259