Re: security label support, part.2

2010/7/22 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>> Well, I like SECURITY LABEL better because it's more clear about what
>> kind of label we're talking about, but if there's consensus on some
>> other option it's OK with me.  Actually, we need to work the security
>> provider name in there too, I think, so perhaps SECURITY LABEL FOR
>> provider ON object IS labeltext.  I realize it's slightly odd
>> grammatically, but it's no worse than the COMMENT syntax.
>>
> The "FOR <provider>" clause should be optional. I expect most use
> cases installs only one security provider, rather than multiple.
>
> If no explicit <provider> is specified, all the security providers
> check the given security label. If two or more providers are here,
> of course, either of them will raise an error, because they have
> different label formats. It is right.

Hmm.  How about if there's just one provider loaded, you can omit it,
but if you fail to specify it and there's >1 loaded, we just throw an
error saying you didn't specify whose label it is.

>>> So, I expect we need two hooks on relabeling eventually.
>>> (One for relation, one for other object classes)
>>
>> Please explain in more detail.
>>
> For relations, one SECURITY LABEL statement may relabel multiple tables
> when it has child tables, if ONLY clause was not given.
> So, we need to obtain oids to be relabeled using find_all_inheritors(),
> and need to ask providers whether it allows, or not.
> But, obviously, it is specific for relations.
>
> For other object class, the target object to be relabeled is identified
> by <object> in SECURITY LABEL statement. It will be parsed by the upcoming
> parse_object.c feature, then it solves the object name to ObjectAddress.
> So, we can apply access controls after setting up the ObjectAddress with
> common hooks for object classes except for relations, like:
>
>  void check_object_relabel(ObjectAddress object, const char *new_label);

So just construct an ObjectAddress for each relation and call the
check function once for each.

>> I think it is 100% clear that row-level security will require
>> completely separate infrastructure, and therefore I'm not even a tiny
>> bit worried about this.  :-)
>>
> Hmm. Are you saying we may degrade the feature when we switch to the
> completely separate infrastructure? Is it preferable??

Uh... no, not really.  I'm saying that I don't think we're backing
ourselves into a corner.  What makes you think we are?

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