* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas <robertmh...@gmail.com> writes: > > Yeah. I'm not totally sure that is sensible for a MAC environment. > > Heck, it's arguably incorrect (though perhaps quite convenient) in a > > DAC environment. > > IIRC, the reason we did it was that we decided the SQL spec requires it. > So there's not a lot of point in debating the issue, unless you can > convince us we misread the spec.
I've not gone through the spec with regard to this (yet..), but I think we need to consider the whole 'principle of least surprise' here, regardless of what the spec says. For one thing, this isn't how older versions of PG behaved and while I doubt anyone intended to rely on that behavior, it makes me nervous that someone, somewhere, unintentionally relies on it. What I'm thinking of is something like a warning if the permissions on the child don't match those of the parent when the relationship is created, or maybe forcibly setting the permissions on the child (with a NOTICE), so it's at least clear what is going on. Or perhaps, set the permissions on the child only if it doesn't have permissions (with the NOTICE), and issue a WARNING if the child already has permissions set. Perhaps also a WARNING if someone changes the permissions on a child after the relationship has been created too, but let it happen in case someone really wants it.. 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 don't really want to force people doing routine partition additions to have to set the permissions on the child before adding it, but I also don't want to have to figure out "are these two sets of permissions identical", since that's not really trivial to determine. We do have default permissions now though, so maybe requiring the permissions be the same from the get-go is the right idea. Of course, if we change the permissions on the child when the inheiritance relationship is created, we'll need to update those perms every time the parents perms are changed. Just my 2c. Thanks, Stephen
signature.asc
Description: Digital signature