2010/9/1 KaiGai Kohei <kai...@ak.jp.nec.com>:
> This patch allows external security providers to check privileges
> to create a new relation and to inform the security labels to be
> assigned on the new one.
Review:
I took a brief look at this patch tonight and I think it's on the
wrong track. There's no reason for the hook function to return the
list of security labels and then have the core code turn around and
apply them to the object. If the hook function wants to label the
object, it can just as easily call SetSecurityLabel() itself.
It seems to me that there is a general pattern to the hooks that are
needed here. For each object type for which we wish to have MAC
integration, you need the ability to get control when the object is
created and again when the object is dropped. You might want to deny
the operation, apply labels to the newly created object, do some
logging, or whatever. So it strikes me that you could have a hook
function with a signature like this:
typedef void (*object_access_hook_type)(ObjectType objtype, Oid oid,
int subid, ObjectAccessType op);
...where ObjectAccessType is an enum.
Then you could do something like this:
#define InvokeObjectAccessHook(objtype, oid, subid, op) \
if (object_access_hook != NULL) \
object_access_hook(objtype, oid, subid, op);
Then you can sprinkle calls to that macro in strategically chosen
places to trap create, drop, comment, security label, ... whatever the
object gets manipulated in a way that something like SE-Linux is apt
to care about. So ObjectAccessType can have values like OAT_CREATE,
OAT_DROP, OAT_COMMENT, OAT_SECURITY_LABEL, ...
I would like to mark this patch Returned with Feedback, because I
think the above suggestions are going to amount to a complete rewrite.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
