Stephen Frost wrote:
> 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?).
In the current working tree, it (security id) is stored within
padding field of HeapTupleHeader, so internal facility can read
it via HeapTupleGetSecLabel(), but I already removed "security_acl"
and "security_label" definition.
Its basic structure is unchanged, the text form of security label
is stored within pg_security system catalog.
> 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.
It should not be held in text form within each tuples.
Please remind why I rework for the feature again.
Its facilities are a bit large to get included at a time,
so its development should be done step-by-step approach and
separatable ones (row-level, largeobjects) are postponed.
This change is extreamly large, almost same as implementing
from zero. I think it is far from step-by-step.
> This would further reduce the patch pretty significantly, I suspect,
> though you will need to rework some things.
No, it need to rework *any* things. :(
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>