KaiGai, * KaiGai Kohei (kai...@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
signature.asc
Description: Digital signature
