Thread: CATALOG/NOCATALOG for new users

This is a preliminary patch - don't commit it.

What this patch adds are the CATALOG and NOCATALOG clauses to the CREATE
USER and ALTER USER commands.

These clauses affect the usecatupd column.  This makes it easy to create
superusers who cannot manually modify columns (a very nasty power...)

These days, Postgres's built-in command set can do everything you need to
to (except disable triggers and delete all the users...), so I don't see
why people who have the power to create users should also have the power
to munge your entire db server.

There are a few problems that need thinking about, and I would like
comments on how to address them:

1. Should we only allow users who currently hold the catalog perm to grant
it to others?  I think yes, since otherwise a regular superuser can create
themselves another account with the catalog priv.

2. Restoring a dump (or dumpall more specifically perhaps) now requires
that the restoring user is more than just a superuser, they must also hold
the catalog priv.  This is why:

DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database
WHERE datname = 'template0');

And also this:

-X disable-triggers

3. Upgrading from previous postgres will not give their old superusers
back their catalog privilege, unless they dump with 7.5's pg_dump.

Comments?

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> 1. Should we only allow users who currently hold the catalog perm to grant
> it to others?  I think yes, since otherwise a regular superuser can create
> themselves another account with the catalog priv.

That brings up the whole business of just how super is a superuser,
and does it even make sense to try to design a "not quite superuser"
protection state.  I'm not convinced that the usecatupd flag is so well
thought out that we should expose it for general use without some
consideration of alternative designs.

As an example, it might make more sense to create a separate flag bit
that simply grants the ability to add and delete users (non-superusers,
presumably), with none of the other attributes of a superuser.  If I
recall your original concern properly, this would be a safer facility
for what you wanted to accomplish.

> 3. Upgrading from previous postgres will not give their old superusers
> back their catalog privilege, unless they dump with 7.5's pg_dump.

Only if you make it default to NOCATALOG, which is highly debatable in
my mind, since it is non-backwards-compatible.

            regards, tom lane

Tom Lane wrote:
> As an example, it might make more sense to create a separate flag bit
> that simply grants the ability to add and delete users
> (non-superusers, presumably), with none of the other attributes of a
> superuser.  If I recall your original concern properly, this would be
> a safer facility for what you wanted to accomplish.

I agree, this would be a more useful way to slice it up.  Or maybe
someone wants to implement the SQL equivalent of "sudo".