Re: BUG #15006: "make check" error if current user is "user"
От | Tom Lane |
---|---|
Тема | Re: BUG #15006: "make check" error if current user is "user" |
Дата | |
Msg-id | 10654.1516241706@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15006: "make check" error if current user is "user" (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #15006: "make check" error if current user is "user"
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: