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 <kaigai@ak.jp.nec.com>