Re: security label support, part.2

2010/8/9 <kaigai(at)kaigai(dot)gr(dot)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.

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

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

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

> BTW, I'll go on the area where internet unconnectable during next
> two days. Perhaps, my reply will run late.

No problem.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company