Michael Paquier <michael.paquier@gmail.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:
regression=# create user public;
ERROR: role name "public" is reserved
LINE 1: create user public;
^
regression=# create user "public";
ERROR: role name "public" is reserved
LINE 1: create user "public";
^
regression=# create user user;
ERROR: syntax error at or near "user"
LINE 1: create user user;
^
regression=# create user "user";
CREATE ROLE
regression=# create user current_user;
ERROR: CURRENT_USER cannot be used as a role name here
LINE 1: create user current_user;
^
regression=# create user "current_user";
CREATE ROLE
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.
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.
And, to return to the original scenario, if you do
initdb -U public
it goes through just fine ... so our defenses against having such a
username have a hole in them.
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.
regards, tom lane