Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jul 26, 2021 at 4:12 PM Robert Haas <robertmh...@gmail.com> wrote: > > I think I may not have expressed myself clearly enough here. What I'm > > concerned about is: Alice should not be permitted to preventing Bob > > from doing something which Bob is allowed to do and Alice is not > > allowed to do. If Alice is the administrator of PostgreSQL's XYZ > > subsystem, she can permit Bob from using it if she wishes. But if Bob > > argh, typo. I meant prevent, not permit. > > > is an administrator of XYZ and Alice is not, there shouldn't be a way > > for Alice to obstruct Bob's access to that system.
> Do you agree? so ... yes and no. There's an awful lot being ascribed to 'administrator' without any definition of it being actually given. We are working in this thread to explicitly split up superuser privileges to allow them to be granted to non-superusers and talking about cases where those privileges end up interacting with each other. Is Alice, as the 'network' manager considered an 'administrator' of XYZ? Is Bob, as the 'database' manager considered an 'administrator'? Perhaps both are, perhaps neither are. It doesn't seem helpful to be vague. If Alice is given the right to create event triggers in a given database, then that's explicitly giving Alice the right to block anyone from dropping tables in that database because that's an inherent part of the event trigger system. Should superusers be able to bypass that? Yes, they probably should be able to and, ideally, they'd be able to do that just in a particular session. Should a user who has been allowed to modify certain GUCs that perhaps Alice hasn't been allowed to modify be able to be prevented from modifying those GUCs by Alice, when neither is a superuser? That's definitely a trickier question and I don't know that I've got an answer offhand. Thanks, Stephen
signature.asc
Description: PGP signature
