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

KaiGai Kohei wrote:
> > 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.

Right.  I was trying to point out that you can't assume that every
string you cast to ::regseclabel is going to already exist in
pg_security;  in this case, we are doing a not equal so we don't assume
it is already in the table.

> > 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.

Yes, I was going to ask if there was any API we need to follow, and you
are confirming that an insert of a text string must be possible for that
column.  We can do an auto-cast of the string to the internal data type
so the call to the function that inserts into pg_security would be
invisible, but your point that it might create lots of pg_security rows
that aren't referenced is a good one.

> 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.

Interesting.  It is really up to the people who work in the heap fetch
area of the code to tell us how disruptive the security framework can be
in that area of the code.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +