Ah, I see.
My counterclaim was that there are lots of use cases where one would
want to be extra sure that *only* they, as the owner of the database,
can access the database as a superuser and not someone else. Even if
there is some obscure way for that "someone else" to either connect as
a superuser or to escalate privileges to superuser.
And what I propose would be a means to achieve that at the expense of
extra steps when starting to act as a superuser.
In a nutshell this would be equivalent for two factor authentication
for acting as a superuser -
1) you must be able to log in as a user with superuser attribute
2) you must present proof that you can access the underlying file system
Cheers,
Hannu Krosing
On Wed, Jun 29, 2022 at 12:48 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Wed, 2022-06-29 at 00:05 -0700, Andres Freund wrote:
> > On 2022-06-29 08:51:10 +0200, Laurenz Albe wrote:
> > > On Tue, 2022-06-28 at 16:27 -0700, Andres Freund wrote:
> > > > > Experience shows that 99% of the time one can run PostgreSQL just fine
> > > > > without a superuser
> > > >
> > > > IME that's not at all true. It might not be needed interactively, but that's
> > > > not all the same as not being needed at all.
> > >
> > > I also disagree with that. Not having a superuser is one of the pain
> > > points with using a hosted database: no untrusted procedural languages,
> > > no untrusted extensions (unless someone hacked up PostgreSQL or provided
> > > a workaround akin to a SECURITY DEFINER function), etc.
> >
> > I'm not sure what exactly you're disagreeing with? I'm not saying that
> > superuser isn't needed interactively in general, just that there are
> > reasonably common scenarios in which that's the case.
>
> I was unclear, sorry. I agreed with you that you can't do without superuser
> and disagreed with the claim that 99% of the time nobody needs superuser
> access.
>
> Yours,
> Laurenz Albe