Robert Haas wrote:
* ACL_INSERT
The db_table:{insert} and db_column:{insert} for all the target
columns are checked. The table-level permission does not override
column-level permission, so the client need to have privileges
for both of objects. It is same as other permissions.
* ACL_SELECT
The db_table:{select} and db_column:{select} for all the target
columns are checked.
But it applies db_table:{lock} on LockTableCommand().
* ACL_UPDATE
The db_table:{update} and db_column:{update} for all the target
columns are checked.
* ACL_DELETE
The db_table:{delete} is also checked. No column-level checks here.
I'm more or less with you up to this point.
* ACL_TRUNCATE
The db_table:{delete} is also checked.
SE-PostgreSQL does not discriminate between TRUNCATE and DELETE.
But this seems wrong.
We consider these differences are just only the way to remove
all the tuples, not the target of the tables and its result.
* ACL_REFERENCES
* ACL_TRIGGER
SE-PostgreSQL does not care about these privileges.
But, it checks db_procedure:{execute} on trigger invocation time,
and it also checks db_table:{select} on checks of FK constraint
within its secondary SQL execution.
And so do these. Why should there be any asymmetry with regular
PostgreSQL here?
The ACL_REFERENCES is checked when we set up FK constraint, then
ri_PerformCheck() invokes another query to check constraint with
privileges of the table owner. It assumes the owner can access
on the table owned.
However, SE-PostgreSQL works orthogonally to the ownership.
We don't assume the client can access on the FK constrainted
table, and it apply appropriate checks on the secondary query
also, so it does not need to check on FK creation time.
The ACL_TRIGGER is also checked when CREATE TRIGGER.
If someone set a trigger function which is not allowed to execute
from other persons, the other person can invoke this function via
trigger mechanism.
I wonder why the vanilla PostgreSQL does not put pg_proc_aclcheck()
on the ExecCallTriggerFunc().
* ACL_EXECUTE
The db_procedure:{execute} is also checked.
This check is embedded within pg_proc_ackcheck().
Good...
* ACL_USAGE
* ACL_CREATE
* ACL_CREATE_TEMP
SE-PostgreSQL does not care about there privileges.
Again, there doesn't seem to be any reason for this asymmetry. I
think you should change it.
The ACL_CREATE and ACL_CREATE_TEMP are checked on namespace
in which the object newly created belongs. And the ACL_USAGE
is checked on various kind of database objects, but they don't
have its security context.
Funfamentally, SELinux requires to check user's privileges
on the object newly created. The object is labeled as a default
security context (if user does not specify anything) on its
creation.
So, if we implement it now, a facility is necessary to store
a security context of namespace and others.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
