(2010/08/18 12:02), Robert Haas wrote: > 2010/8/17 KaiGai Kohei<kai...@ak.jp.nec.com>: >>> I dunno. None of the above makes me feel very comfortable from a >>> security perspective because I'm concerned any of the above could too >>> easily be overlooked by someone upgrading. It also doesn't really >>> address the concern that, at some point, a child table could have >>> different permissions than a parent table. If we forcibly set the >>> permissions on the child, or ERROR'd if the permissions weren't either >>> the same or empty on the child, and then ERROR'd if someone tried to >>> change the child's permissions later, I'd be happier. >>> >> I also think ERROR should be raised when user tries to assign different >> security properties on child tables from its parent. At least, I think >> it should be configurable using a guc variable. > > If C1, C2, and C3 inherit from P, it's perfectly reasonable to grant > permissions to X on C1 and C2, Y on C3, and Z on C1, C2, C3, and P. I > don't think we should disallow that. Sure, it's possible to do things > that are less sane, but if we put ourselves in the business of > removing useful functionality because it might be misused, we'll put > ourselves out of business. > Hmm. If C1, C2 and C3 are defined to store information for different categories, but shares common data structure, indeed, it is useful.
> Having said that, I'm not sure that the same arguments really hold > water in the world of label based security. Suppose we have > compartmentalized security: P is a table of threats, with C1 > containing data on nukes, C2 containing data on terrorists, and C3 > containing data on foreign militaries. If we create a label for each > of these threat types, we can apply that label to the corresponding > table; but what label shall we assign P? Logically, the label for P > should be set up in such a fashion that the only people who can read P > are those who can read C1, C2, and C3 anyway, but who is to say that > such a label exists? Right. If access privileges on P implicitly allow accesses on children, the P must have a label that only allows people who can access both of the children. However, in SELinux at least, here is no guarantee that we can always find out such a label in the security policy installed. :( > Even if KaiGai's intended implementation of > SE-PostgreSQL supports construction of such a label, who is to say > that EVERY conceivable labeling system will also do so? In fact, it > seems to me that it might be far more reasonable, in a case like this, > to ignore the *parent* label and look only at each *child* label, > which to me is an argument that we should set this up so as to allow > individual users of this hook to do as they like. > It will be helpful. If we can check each children's label, no need to restrict an identical security label within a certain inheritance hierarchy. Of course, other security module may check permissions in different basic, but it seems to me characteristics. > It's also worth pointing out that the hook in ExecCheckRTPerms() does > not presuppose label-based security. It could be used to implement > some other policy altogether, which only strengthens the argument that > we can't know how the user of the hook wants to handle these cases. > If rte->requiredPerms would not be cleared, the user of the hook will be able to check access rights on the child tables, as they like. How about an idea to add a new flag in RangeTblEntry which shows where the RangeTblEntry came from, instead of clearing requiredPerms? If the flag is true, I think ExecCheckRTEPerms() can simply skip checks on the child tables. 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
