Re: security label support, part.2
От | Robert Haas |
---|---|
Тема | Re: security label support, part.2 |
Дата | |
Msg-id | AANLkTin6eK96cEwmDuF1doxNFUw7ymFrmsHYN8V_gEBF@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: security label support, part.2 (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: security label support, part.2
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: