On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost <sfr...@snowman.net> wrote: > Second, the information we *don't* have from above is generally > information about what the requesting action is. For example, when > changing ownership of an object, we can't possibly use introspection to > find out the role which is on the receiving end, since at that time > we've just learned it from the parser.
I'm not sure that I follow what you're saying here. I think maybe it would help to discuss a concrete example, which is why I proposed a concept patch. Or perhaps you'd like just to pick out a specific case to discuss. > Now, we might build an entire > new object, pass the "result of this action" OID to the security system > and ask it "can we change OID X into OID Y?", but I don't particularly > like it. We really don't want to do any *changes* to things until after > we've determined the permissions allow for it, and I'm not sure how to > get around that without building an independent introspection system for > "what might be". Perhaps we're comfortable enough saying "we'll just > rollback the command if it turns out to have not been allowed" but I > just don't like it. Feels like a higher risk solution to me. Yeah, that seems like a non-starter. > I don't see a way to get around the second piece since what information > is needed about the action is typically action-specific. Perhaps we > could have an 'action-ID' (uh, we have an ID per command already, no? > Probably doesn't fit the mold close enough though), and then a way to > query information about "what is this action trying to do?". Doesn't > seem likely to be very clean though. Object creation seems to be one of the tougher cases here. When you're altering or dropping an existing object, the decision is likely to be based (in any system) on the properties of that object. When you're creating an object, the decision will of course have to be based on the properties of something else, but different access control models might not agree on the value of "something else". It's not immediately clear to me how to deal with that, but again it's hard for me to discuss it in the abstract. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
