From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Sullivan <ajs(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches |
Date: | 2008-09-29 23:22:23 |
Message-ID: | 200809292322.m8TNMNf23451@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut wrote:
> > The major purpose of this feature is to provide the most important
> > component to run enterprise class web application with least privilege
> > set which is consistent at whole of the system.
>
> How important is this consistency goal in reality? We typically
> recommend that database applications run entirely in the database, for
> transaction integrity reasons and so on. Unless you are doing wild and
> fun things with server-side copy or untrusted procedural languages,
> there really shouldn't be that much use for consistency of access
> control between PostgreSQL and something else. In fact, on top of the
> transactional integrity criterion, having consistent access control is
> one of the reasons to have all your production data in the database
> system and nowhere else.
>
> Of coure, this is an ideal state, and we all of to break that once in a
> while. But hence the honest question, how often does that really happen
> and to what extent, and does that justify the significant investment
> that is being proposed here?
> Then, how does MAC help with SQL injections? Using the existing
> role-based system you can already define least-privilege users that are
> essentially powerless even if SQL injections were to happen. I am not
> aware that important flaws or gaps in our role-based access control
> system have been pointed out that would make it impossible to create
> applications with security levels similar to those achievable with a MAC
> system.
I think there are two goals here. At the SQL-level, we will have
per-role row and column permissions (which seem valuable on their own),
and SE-PostgreSQL allows those permissions to be controlled at the
operating system level rather than at the database level.
I think your major question is how often do you have users that you need
to control at both the SQL _and_ operating system level. I guess the
answer is that security policy suggests controlling things at the lowest
level, and bubling that security up into the database and applications.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2008-09-29 23:24:20 | Re: Updates of SE-PostgreSQL 8.4devel patches |
Previous Message | Josh Berkus | 2008-09-29 23:17:23 | Re: Updates of SE-PostgreSQL 8.4devel patches |