Re: BUG #15006: "make check" error if current user is "user"

On Wed, Jan 17, 2018 at 09:15:06PM -0500, Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> Perhaps a stupid question. What's the point behind the logic to forbid a
>> double-quoted "public" but to authorize a double-quoted "user"? The
>> whole thing looks inconsistent to me.
>
> Good question. There may be some backwards-compatibility considerations
> here, but still this is just plain inconsistent:
>
> <snip>
>
> I can see the point of disallowing a user named "public", because
> otherwise syntax like GRANT some-privilege TO PUBLIC is just a trap
> for the unwary DBA, one that could have bad security consequences.
> But it's not clear to me why the same logic doesn't apply to "user",
> "current_user", or "session_user", all of which are equally conflatable
> with a built-in meaning in some security-relevant contexts.

Just forgot to mention that double-quoted user names with upper-case
characters are similarly allowed should still be allowed, like:
=# CREATE ROLE "Public";
CREATE ROLE
=# CREATE ROLE "pG_as";
CREATE ROLE
So those are correctly handled now.

Worth noting also this bit (from IsReservedName), which looks correct to
me:
=# CREATE ROLE "pg_aB";
ERROR: 42939: role name "pg_aB" is reserved
DETAIL: Role names starting with "pg_" are reserved.

> BTW, you might think that those wildly different phrasings of essentially
> the same error come from different places in the code, but no, they are
> from adjacent lines in gram.y. WTF? This seems to be deliberately
> anti-consistent.

Same reaction here :)
I would have expected all the checks to be in user.c and at parsing
level.

> Probably the OP would not be very happy if the outcome of this discussion
> is that "initdb -U user" fails, but I am not seeing a principled reason
> why that should be allowed.

Me neither.
--
Michael