pros and cons of two security models - Mailing list pgsql-general

From Chris Travers
Subject pros and cons of two security models
Date
Msg-id CAKt_ZftYOgeHmsO4y=xEiYbOtTSbQp7PLmYv=qeggDmxg7h5vA@mail.gmail.com
Whole thread Raw
Responses Re: pros and cons of two security models  (Stephen Frost <sfrost@snowman.net>)
Re: pros and cons of two security models  (Craig Ringer <ringerc@ringerc.id.au>)
List 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

pgsql-general by date:

Previous
From: Mr Dash Four
Date:
Subject: Re: strange permission error
Next
From: Chris McDonald
Date:
Subject: Re: stored procedure multiple call call question