On Wed, Mar 9, 2022 at 4:31 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I don't think we need syntax to describe it. As I just said in my > other reply, we have a perfectly good precedent for this already > in ordinary object permissions. That is: an object owner always, > implicitly, has GRANT OPTION for all the object's privileges, even > if she revoked the corresponding plain privilege from herself. > > Yeah, this does mean that we're effectively deciding that the creator > of a role is its owner. What's the problem with that?
I don't think that's entirely the wrong concept, but it doesn't make a lot of sense in a world where the creator has to be a superuser. If alice, bob, and charlie are superusers who take turns creating new users, and then we let charlie go due to budget cuts, forcing alice and bob to change the owner of all the users he created to some other superuser as a condition of dropping his account is a waste of everyone's time. They can do exactly the same things to every account on the system after we change the role owner as before. But wait, I hear you cry, what about CREATEROLE? Well, CREATEROLE is generally agreed to be broken right now, and if you don't agree with that, consider that it can grant pg_execute_server_programs to a newly-created account and then explain to me how it's functionally different from superuser. The whole area needs a rethink. I believe everyone involved in the discussion on the other threads agrees that some reform of CREATEROLE is necessary, and more generally with the idea that it's useful for non-superusers to be able to create roles. But the reasons why people want that vary. I want that because I want mini-superusers, where alice can administer the users that alice creates just as if she were a superuser, including having their permissions implicitly and dropping them when she wants them gone, but where alice cannot break out to the operating system as a true superuser could do. I want this because the lack of meaningful privilege separation that led to CVE-2019-9193 being filed spuriously is a very real problem. It's a thing a lot of people want, and I want to give it to them. David Steele, on the other hand, wants to build a user-creating bot that can create accounts but otherwise conforms to the principle of least privilege: the bot can stand up accounts, can grant them membership in a defined set of groups, but cannot exercise the privileges of those accounts (or hack superuser either). Other people may well want other things. And that's why I'm not sure it's really the right idea to say that we don't need syntax for this admin-without-member concept. If we just want to bolt role ownership onto the existing framework without really changing anything else, we can do that without extra syntax and, as you say here, make it an implicit property of role ownership. But I don't see that as has having much value; we just end up with a bunch of superuser owners. Whatever. Now Stephen made the argument that we ought to actually have admin-without-member as a first class concept, something that could be assigned to arbitrary users. Actually, I think he wanted it even more fine grained with that. And I think that could make the concept a lot more useful, but then it needs some kind of understandable syntax. There's a lot of moving parts here. It's not just about coming up with something that sounds generally logical, but about creating a system that has some real-world utility. > > But do we really have to solve this problem before we can clean up > > this session exception? > > I think we need a plan for where we're going. I don't see "clean up > the session exception" as an end in itself; it's part of re-examining > how all of this ought to work. I don't say that we have to have a > complete patch right away, only that we need a coherent end goal. I'd like to have a plan, too, but if this behavior is accidental, I still think we can remove it without making big decisions about future direction. The perfect is the enemy of the good. -- Robert Haas EDB: http://www.enterprisedb.com
