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

> * 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.

> * 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?

> * 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.

...Robert