KaiGai Kohei wrote: > The purpose of this patch is to provide function entrypoints for the > upcoming SE-PostgreSQL feature, because I got a few comments that we > hesitate to put sepgsql_xxx() hooks on the main routines directly in > the first commit fest. In addition, I already tried to put SE-PG hooks > within pg_xxx_aclchecks() in this CF, but it was failed due to the > differences in the security models.
Can you elaborate that? It might well be that you need to adapt the SE-PostgreSQL security model to the one that's there already. Putting SE-PG hooks into existing pg_xxx_aclcheck functions is the only low-impact way I can see to implement SE-PostgreSQL. >> * There are two special-purpose shims, ac_database_calculate_size and >> ac_tablespace_calculate_size, that got added for the benefit of >> utils/adt/dbsize.c. What if that code were still in contrib? How is it >> different from a lot of the code that is in contrib now, eg dblink or >> pgrowlocks, to say nothing of third-party modules? Presuming that the >> shim layer can know explicitly about each individual permission-checking >> requirement is a dead-end design. > > Back to the definition of access controls (or reference monitor). > It prevents violated accesses launched by user's requests (SQL). > It is not a job to protect something from malicious internal modules. The issue isn't malicious modules, but modules that have pg_xxx_aclcheck calls in them and haven't been modified to do SE-pgsql checks like you modified all the backend code. As the patch stands, they would perform just the regular acl checks and bypass SE-pgsql. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers