KaiGai,
* KaiGai Kohei (kaigai@kaigai.gr.jp) wrote:
> I don't provide both of "security_label" and "security_acl"
> system columns for system/user tables.
> I didn't write it explicitly, it might make you confusing.
>
> User cannot see what security label is assigned to them
> due to lack of system column, so new sepgsql_xxx_getcon()
> functions are provided an interface to see security label.
>
> In this patch, I don't touch new system columns.
I think Bruce's question was where you stored the security_acl and
security_label columns. Based on your response (and a bit of purusal
through the code.google site), it looks like you still have security_acl
and security_label defined as internal columns and being included
for at least system tables (or is it everywhere?). I think what people
are looking for, instead, is either additional columns to just the
existing system tables that need them (eg: pg_class, pg_attribute) or
included in the existing ACL structure (the aclitem structure). Another
option might be a seperate set of tables.
This would further reduce the patch pretty significantly, I suspect,
though you will need to rework some things. In terms of minimally
invasive, I would guess modifying the existing ACL structure for the ACL
info, and a seperate table to track the labels for different
objects/sub-objects (similar to pg_depend) would be your best approach.
That would require no changes to existing system tables, but a few
changes in places where the ACL is handled, and then the hooks in the
right places to do the permission checking.
Just my 2c.
Thanks,
Stephen
