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. >>> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
