Re: Seeking practice recommendation: is there ever a use case to have two or more superusers?
> hjp-pg...@hjp.at wrote: > >> ronljohnso...@gmail.com wrote: >> >> [developers or devops folks] like to "fix" things without documenting what >> they did, and then, when >> something breaks, denying they did anything (or honestly not believing that >> whatever "trivial" thing they did could any major or deliterious impact). > > Which is why you want to automate deployments. When the easiest way to fix > something in production is to just push the change into the repo, this is > what people will do. When doing it the "proper" way is much more complicated > than just fudging it, people will do the latter. Thanks to all who offered their views on my question. It seems that different people will reach different conclusions. I’ll take this as permission to reach my own conclusion. Software systems in general often offer some freedoms that most people think should never be exercise. For example, PG lets you define a domain that has a not null constraint on one, or more, of its data attributes. But the doc https://www.postgresql.org/docs/current/sql-createdomain.html tells you not to do this. (Look for « Best practice therefore is to design a domain's constraints so that a null value is allowed... ».) I was rather slow to grasp the risks that ignoring this advice brings.. But I get it now.) At the other end of the spectrum, there’s generally accepted thinking on how to choose between a procedure or a function for a particular new use case. But there are still plenty of such cases where opinions will vary and where each preference can be defended with reasonable arguments. I haven’t seen anything in the PG doc that warns against creating additional superusers—so I suppose that this fact tells me something. Nevertheless, I remain convinced about what I’d recommend here: The default choice must be to allow only one superuser: the inevitable bootstrap superuser. But I’ll concede that I should see this like many rules of recommended practice. Sometimes they get broken. This seems most often to happen as an expedient because the recommended practice requires too much effort. The general second-order advice for such scenarios is to write down the rationale and to offer it up for peer review. And if there are no peers who care, then all bets are anyway off...
Re: Seeking practice recommendation: is there ever a use case to have two or more superusers?
On Sun, Nov 20, 2022 at 6:48 PM Bryn Llewellyn wrote: > I haven’t seen anything in the PG doc that warns against creating > additional superusers—so I suppose that this fact tells me something. > Nevertheless, I remain convinced about what I’d recommend here: > > The default choice must be to allow only one superuser: the inevitable > bootstrap superuser. > If you are talking about your specific setup then it isn't a recommendation, it's a policy that you are defining. Do what you've concluded is best, you are the one that will end up answering for it. IMO, there is no good blanket recommendation to give to someone else as to how their policy should be written. Security, especially of this sort, needs to be architected. And when doing that evaluation, and drawing those conclusions, there is no reason to exclude, a priori, having multiple named superusers as part of the final policy. Especially since any policy of this requires not only discussion of PostgreSQL itself but operation systems, configuration management, etc David J.
Re: Seeking practice recommendation: is there ever a use case to have two or more superusers?
On 11/20/22 17:48, Bryn Llewellyn wrote: hjp-pg...@hjp.at wrote: ronljohnso...@gmail.com wrote: [developers or devops folks] like to "fix" things without documenting what they did, and then, when something breaks, denying they did anything (or honestly not believing that whatever "trivial" thing they did could any major or deliterious impact). Which is why you want to automate deployments. When the easiest way to fix something in production is to just push the change into the repo, this is what people will do. When doing it the "proper" way is much more complicated than just fudging it, people will do the latter. Thanks to all who offered their views on my question. It seems that different people will reach different conclusions. I’ll take this as permission to reach my own conclusion. Not sure why you think you need permission to take whatever action you desire on a database whose only usage stipulation is that you maintain a copy of the license. -- Adrian Klaver adrian.kla...@aklaver.com
