Skip site navigation (1) Skip section navigation (2)

pros and cons of two security models

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: pros and cons of two security models
Date: 2012-10-03 11:06:56
Message-ID: CAKt_ZftYOgeHmsO4y=xEiYbOtTSbQp7PLmYv=qeggDmxg7h5vA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
Hi all;

I wanted to get opinions of folks who do a lot of this as well.

LedgerSMB uses database user accounts and role grants to restrict access of
the front-end application.  This means:

1)  The database does not trust the application.  The application has no
access to the db in the absence of user-supplied credentials.

2)  Permissions are granted on functions and tables, and the application is
aware of granted roles, and so can make informed decisions about what
options to give the user.

This has a few significant drawbacks.  As far as the web application is
concerned, the  types of supported authentication are limited to those
which are re-usable, which basically means BASIC and KRB5.  This maps to a
much larger number on the web server to db server tier, but often the web
server hop is the most exposed one.  This is a significant problem.  On the
other hand it buys us:

1)  access to every method of authentication Pg supports for non-web apps,
and

2)  access to every method of password auth that Pg supports for web apps

3)  Centralized security logic which means consistent access enforced
through a variety of clients.

Which does everyone else prefer?  Why?  I am asking because this choice has
spawned some controversy around LedgerSMB from time to time, though not as
much as being Pg-only at least looking at public and private discussions of
the software I have seen.

Best Wishes,
Chris Travers

Responses

pgsql-general by date

Next:From: Andreas KretschmerDate: 2012-10-03 13:15:11
Subject: Re: Indexing JSON type
Previous:From: Mr Dash FourDate: 2012-10-03 10:29:30
Subject: Re: strange permission error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group