Bruce Momjian wrote:
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.
Yes, I didn't describe the case explicitly, because the case when
given string is already on pg_security is not an issue.
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.
Common Criteria v3.1 : Part 2 Security functional components
http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R2.pdf
It describes about export/import of user data with security attributes
on FDP_ETC.2 and FDP_ITC.2 section. These items are considered as basic
facilities to be provided by MAC system, and requires it has a capability
to export/import user data with security attributes.
Since CC is designed for general purpose, it does not specify format
of security attribute, but it is quite natural it is a security label
in text representation on MAC system.
At least, previous certified MAC system (like SELinux) interprets it so.
> 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.
Yes, it was the older design in SE-PostgreSQL, and it is worse than
the current implementation.
The current one inserts tuples necessity minimum.
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.
As I noted on the following message, I reconsidered the asymmetric
input/output handler is not a productive idea.
It is still unclear for me why heap_getsysattr() has to return
a value with same format in storage. If we can change the point
of view, it is possible to return a value generated in runtime
based on any other attributes/userdata of tuples.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
