(2010/07/23 12:56), Robert Haas wrote: > 2010/7/22 KaiGai Kohei<kai...@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. > Perhaps, we need to return the caller a state whether one provider checked the given label at least, or not.
If invalid <provider> was specified so nobody checked it, nobody returns the caller a state of "checked", then it raises an error to notice invalid security provider. If valid <provider> was specified, only specified provider checks the given label, and returns the caller a state of "it was checked by xxxx". If it was omitted, all the providers try to check the given label, but it has mutually different format, so one of providers will raise an error at least. It means we have to specify the provider when two or more providers are loaded, but not necessary when just one provider. >>>> 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. > OK, I'll revise it. >>> 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? > Sorry, meaning of the last question was unclear for me.... Is it a idiom? Thanks, -- KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
