Re: DB Authentication Design

From: François Beausoleil <francois(at)teksol(dot)info>
To: Chris Travers <chris(dot)travers(at)gmail(dot)com>
Cc: Forums postgresql <pgsql-general(at)postgresql(dot)org>
Subject: Re: DB Authentication Design
Date: 2014-01-13 13:06:24
Message-ID: 23206D1A-927C-476D-A2FF-A2D22151FC72@teksol.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello Chris,

Le 2014-01-12 à 23:24, Chris Travers a écrit :
>
> On Sun, Jan 12, 2014 at 6:30 AM, François Beausoleil <francois(at)teksol(dot)info> wrote:
> Hi all,
>
> I'm thinking that all apps that connect to the database should have their own user. For example, the web application process is one user, then a report builder process should have another user, and a different process that imports data should have his own too, and so on. Would you generally agree with that?
>
> I'm thinking that by having different users, PGbouncer can create different pools, and better allow me to control concurrency.
>
>
> It really depends on what you are doing, what your security model is, what your concurrency constraints are, etc. What you are describing is a fairly typical approach and it sacrifices some real security possibilities for connection pooling possibilities. The fundamental question is whether the security of your application's user should be tied to the database connection.

This database cluster is not exposed to the outside world. What I really need is a way to control the number of simultaneous execution of queries. Your "per application" approach is a better name for what I described.

I also have web-facing applications, in which case the per-user approach sounds good.

Thanks!
François

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joseph Kregloh 2014-01-13 14:17:41 Re: pg_upgrade & tablespaces
Previous Message sramay 2014-01-13 12:53:50 Re: pg_largeobject related issue with 9.2