Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost <sfr...@snowman.net> wrote: > > While we have been working to reduce the number of superuser() checks in > > the backend in favor of having the ability to GRANT explicit rights, one > > of the guideing principles has always been that capabilities which can > > be used to gain superuser rights with little effort should remain > > restricted to the superuser, which is why the lo_import/lo_export hadn't > > been under consideration for superuser-check removal in the analysis I > > provided previously. > > I disagree that that is, or should be, a guiding principle.
It was what I was using as the basis of the work which I did in this area and, at least at that time, there seemed to be little issue with that. > I'm not > sure that anyone other than you and your fellow employees at Crunchy > has ever agreed that this is some kind of principle. You make it > sound like there's a consensus about this, but I think there isn't. It's unclear to me why you're bringing up employers in this discussion, particularly since Tom is the one who just moved things in the direction that you're evidently advocating for. Clearly there isn't consensus if you and others disagree. Things certainly can change over time as well, but if we're going to make a change here then we should make it willfully, plainly, and consistently. > I think our guiding principle should be to get rid of ALL of the > hard-coded superuser checks and let people GRANT what they want. If > they grant a permission that results in somebody escalating to > superuser, they get to keep both pieces. Such risks might be worth > documenting, but we shouldn't obstruct people from doing it. I would certainly like to see the many additional hard-coded superuser checks introduced into PG10 removed and replaced with more fine-grained GRANT-based privileges (either as additional GRANT rights or perhaps through the default roles system). What I dislike about allowing GRANT's of a privilege which allows someone to be superuser is that it makes it *look* like you're only GRANT'ing some subset of reasonable rights when, in reality, you're actually GRANT'ing a great deal more. This is not unlike the discussions we've had in the past around allowing non-owners of a table to modify properties of a table, where the argument has been successfully and clearly made that if you make the ability to change the table a GRANT'able right, then that can be used to become the role which owns the table without much difficulty, and so there isn't really a point in making that right independently GRANT'able. We have some of that explicitly GRANT'able today due to requirements of the spec, but that's outside of our control. > In the same way, Linux will not prevent you from making a binary > setuid regardless of what the binary does. If you make a binary > setuid root that lets someone hack root, that's your fault, not the > operating system. This is actually one of the things that SELinux is intended to address, so I don't agree that it's quite this cut-and-dry. Thanks! Stephen
signature.asc
Description: Digital signature
