Bruce Momjian wrote:
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.
Yes, it is correct. As someone noted, SQL-level fine-grained access controls are also usefull feature. I understand it. SE-PostgreSQL makes its decision based on the security policy stored in operating system because of the "consistency". However, database objects are invisible for operating system, so we have to add an option to RDBMS.
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.
As I mentioned at the previous message, it is very frequent case when a single web application accesses both filesystem objects and database objects at the same time. The important thing is to turn off at the main. Smaller number of security sensitive codes are betther for consistency and completeness in security. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <[EMAIL PROTECTED]> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
