* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > You could COPY over the hba file or sometihng like that :) Or just
> > pg_read_binary_file() on the files in another database, which is accessible
> > through SQL as well.
>
> More directly, he could alter pg_authid to make himself a not-local user.
> But I don't see that it's our responsibility to prevent that. As long as
> the combination of features works in a straightforward way, I'm happy
> with it --- and it would, AFAICS.
That depends on exactly what you mean by 'those features'. There's
quite a difference between "you can set the superuser flag on a local
user and then that user will be a superuser" and "a local user with
superuser flag will only be able to impact the database they are local
to". I agree that there's nothing stopping us from having a "local"
user which is marked as a superuser from a technical level.
What Magnus and I are worried about is the *implication* of such a
configuration is and what the user will think it means. Specifically,
there will be an assumption that "local" users can only access or impact
the databases which they have access to, which wouldn't be accurate for
a "local" user who is a superuser. Certainly, documenting this would
help with that but with as many warnings as we'd have to put up about
that being dangerous and that it isn't actually going to prevent that
superuser from accessing the other databases if they really wanted to,
or prevent them from making a global superuser account, etc, I'm just
not convinced that it's worth it for the "feature" of allowing a "local"
account to be set as superuser- I don't see a huge use-case there.
Thanks,
Stephen