Re: Updates of SE-PostgreSQL 8.4devel patches (r1324)

> but the auto-creation of pg_security rows does make this problematic. 
> regproc works because it only supports pre-created pg_proc rows.

Yes, the security label has a different characteristic at the point.

> Can we support two data types, one for read-only and another for
> possible creation?  That is not going to work for a query like
> 
>     SELECT * FROM x WHERE col != 'valid_but_new_security_label'::regseclabel;
> 
> because the cast would fail if the pg_security row doesn't exist, but
> the query itself perhaps might succeed and return rows.

It has a same matter. If user cast a text into the type of possible
creation, it can cause an unnecessary insertion.

> Can we require joins to use pg_security directly?  I wish I could think
> of some magic that indicated the pg_security row should be created.

We should not allow users to join them directly, and should not expose
what identifier is used internally, because some of ISO/IEC15408 has
requirements to export/import user data with meaningful security labels.
The numeric security identifier is just an internal usage.

Here is one another idea.
How do you think asymmetric input/output handlers?

At first, I have to introduce the current implementation.
It can receives user input values as TEXT or ACLITEM[], ant these are
fetched at fetchWritableSystemAttribute() on execMain.c.
Please note that they have no side-effect on the prior stage.
Then, it invokes rowaclSecurityAclToSid() or pgaceSecurityLabelToSid()
to translate the values into security identifier. These functions can
insert a new tuple into pg_security, if not found.
Then, the translated security identifiers are set on the HeapTupleHeader
using HeapTupleSetRowAcl() or HeapTupleSetSecLabel().

If the input handler is asymmetric, it can handle the given user input
as a TEXT or ACLITEM[], and can deliver them fetchWritableSystemAttribute()
as is. But asymmetric output handler can translate given security identifier
into proper user visible data.

However, I don't think it is a fair enough solution. :(
The current implementation seems to me better.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>