CATUPDATE confusion? - Mailing list pgsql-hackers

From Adam Brightwell
Subject CATUPDATE confusion?
Date
Msg-id CAKRt6CQOvT2KiyKg2gFf7h9k8+JVU1149zLb0EXTkKk7TAQGMQ@mail.gmail.com
Whole thread Raw
Responses Re: CATUPDATE confusion?  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
All,

While reviewing the supporting documentation and functions for role attributes I noticed that there seems to be some confusion (at least for me) with CATUPDATE.

This was prompted by the following comment from Peter about 'has_rolcatupdate' not having a superuser check.

http://www.postgresql.org/message-id/54590BBF.1080008@gmx.net

So, where I find this confusing is that the documentation supports this functionality and the check keeps superuser separate from CATUPDATE... however... comments and implementation in user.c state/do the opposite and couple them together.

Documentation: http://www.postgresql.org/docs/9.4/static/catalog-pg-authid.html - "Role can update system catalogs directly. (Even a superuser cannot do this unless this column is true)"

src/backend/commands/user.c

/* superuser gets catupdate right by default */
new_record[Anum_pg_authid_rolcatupdate - 1] = BoolGetDatum(issuper);

and...

/*
 * issuper/createrole/catupdate/etc
 *
 * XXX It's rather unclear how to handle catupdate.  It's probably best to
 * keep it equal to the superuser status, otherwise you could end up with
 * a situation where no existing superuser can alter the catalogs,
 * including pg_authid!
 */
if (issuper >= 0)
{
  new_record[Anum_pg_authid_rolsuper - 1] = BoolGetDatum(issuper > 0);
  new_record_repl[Anum_pg_authid_rolsuper - 1] = true;

  new_record[Anum_pg_authid_rolcatupdate - 1] = BoolGetDatum(issuper > 0);
  new_record_repl[Anum_pg_authid_rolcatupdate - 1] = true;
}

Perhaps this is not an issue but it seemed odd to me, especially after giving Peter's comment more thought.  So, I suppose the question is whether or not a superuser check should be added to 'has_rolcatupdate' or not?  I believe I understand the reasoning for coupling the two at role creation/alter time, however, is there really a case where a superuser wouldn't be allowed to bypass this check?  Based on the comments, there seems like there is potentially enough concern to allow it.  And if it is allowed, couldn't CATUPDATE then be treated like every other attribute and the coupling with superuser removed?  Thoughts?

Thanks,

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: postgresql.auto.conf comments
Next
From: Robert Haas
Date:
Subject: Re: postgresql.auto.conf comments