* Tom Lane (t...@sss.pgh.pa.us) wrote: > Magnus Hagander <mag...@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
Description: Digital signature