Re: Updates of SE-PostgreSQL 8.4devel patches (r1710)

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 <kaigai(at)ak(dot)jp(dot)nec(dot)com>