Re: postgresql.key secure storage

From: Marc Munro <marc(at)bloodnok(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: "Saleem EDAH-TALLY <nmset"(at)netcourrier(dot)com
Subject: Re: postgresql.key secure storage
Date: 2009-09-14 04:37:02
Message-ID: 1252903022.21468.8.camel@bloodnok.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 2009-09-13 at 12:04 -0300, pgsql-general-owner(at)postgresql(dot)org
wrote:

> >A user must have the TRUNCATE privilege to truncate a table or be the
> >tables owner.
>
> Well the TRUNCATE example I mentioned is perhaps not explicit of what
> I meant
> to say. A user who can modify data in a client application can also
> modify
> data if he connects directly to the database, bypassing the client
> application, with commands like 'UPDATE tbl SET col = value' Even if a
> few
> rows are concerned, data is yet inconsistent. The only way to prevent
> this is
> by preventing a direct access to the sever via a client like psql for
> example.
> With or without use of SSL, it is not possible, unless I'm missing
> something.

If I understand you correctly, you want to allow a to use an application
that has certain database rights without allowing that same user to have
general database access through, say, psql.

The usual way of doing this, is to have the application run on a
separate application server from the one the user has direct access to.
You can then ensure that the database only allows connections from the
application server.

The user cannot gain knowledgde of the account used by the application
server without breaking into that machine, and if the user somehow
"guesses" the authentication details they will still be unable to use
psql as connections from their own machine would be denied.

I suspect that the problem you are trying to deal with is more complex
than you have actually explained. If the answers you have received so
far don't help, you'll have to provide some more clues.

__
Marc

Browse pgsql-general by date

  From Date Subject
Next Message Peter Eisentraut 2009-09-14 05:51:43 Re: invalid byte sequence for encoding
Previous Message Cory Isaacson 2009-09-14 03:57:50 Checkpoint request failed, permission denied