(2010/08/10 8:39), Robert Haas wrote:
2010/8/9<kai...@kaigai.gr.jp>:
2. Some of this code refers to "local" security labels. I'm not sure
what's "local" about them - aren't they just security labels? On a
related note, I don't like the trivial wrappers you have here, with
DeleteSecurityLabel around DeleteLocalSecLabel, SetSecurityLabel
around SetLocalSecLabel, etc. Just collapse these into a single set
of functions.
In the feature, I plan to assign security labels on the shared database
objects such as pg_database. The "local" is a contradistinction
towards these "shared" objects.
Oh, I see. I don't think that's entirely clear: and in any event it
seems a bit premature, since we're not at that point yet. Let's just
get rid of this stuff for now as I suggested.
OK. We can add this supportanytime we need it.
5. Why do we think that the relabel hook needs to be passed the number
of expected parents?
We need to prevent relabeling on inherited relations/columns from
the multiple origin, like ALTER RENAME TO.
It requires to pass the expected parents into the provider, or
to check it in the caller.
Please explain further. I don't understand.
Yep, rte->requiredPerms of inherited relations are cleared on the
expand_inherited_rtentry() since the v9.0, so we cannot know what
kind of accesses are required on the individual child relations.
It needs the inherited relations/columns being labeled with same
security label of their parent, because SE-PgSQL always makes same
access control decision on same security labels.
Thus, we want to check whether the relabeling operation breaks the
uniqueness of security label within a certain inheritance tree, or not.
Here is the logic to check relabeling on relation/column.
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/hooks.c#254
It checks two things.
1) The given relation/column must be the origin of inheritance tree
when expected_parents = 0.
2) The given relation/column must not belong to multiple inheritance
tree.
So, the hook need to provide the expected_parents for each relations/columns.
6. What are we doing about the assignment of initial security labels?
I had initially thought that perhaps new objects would just start out
unlabeled, and the user would be responsible for labeling them as
needed. But maybe we can do better. Perhaps we should extend the
security provider hook API with a function that gets called when a
labellable object gets created, and let each loaded security provider
return any label it would like attached. Even if we don't do that
now, esp_relabel_hook_entry needs to be renamed to something more
generic; we will certainly want to add more fields to that structure
later.
Starting with "unlabeled" is wrong, because it does not distinguish
an object created by security sensitive users and insensitive users,
for example. It is similar to relation's relowner is InvalidOid.
I plan the security provider hook on the creation time works two things.
1. It checks user's privilege to create this object.
2. It returns security labels to be assigned.
Then, the caller assigns these returned labels on the new object,
if one or more valid labels are returned.
OK, let's give that a try and see how it looks. I don't think that's
in this version of the patch, right?
Yes, this version of the patch didn't support labeling on creation time
of database objects. It shall be added in separated patch.
7. I think we need to write and include in the fine documentation some
"big picture" documentation about enhanced security providers. Of
course, we have to decide what we want to say. But the SECURITY LABEL
documentation is just kind of hanging out there in space right now; it
needs to connect to a broad introduction to the subject.
OK, I'll try to describe with appropriate granularity.
Do we need an independent section in addition to the introduction of
SECURITY LABEL syntax?
I think so. I suggest a new chapter called "Enhanced Security
Providers" just after "Database Roles and Privileges".
OK,
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
