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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
