Re: Per database users/admins, handy for database virtual hosting...
От | Tom Lane |
---|---|
Тема | Re: Per database users/admins, handy for database virtual hosting... |
Дата | |
Msg-id | 23732.1080313761@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Per database users/admins, handy for database virtual hosting... (Sean Chittenden <sean@chittenden.org>) |
Ответы |
Re: Per database users/admins, handy for database virtual hosting...
Re: Per database users/admins, handy for database virtual hosting... |
Список | pgsql-hackers |
Sean Chittenden <sean@chittenden.org> writes: >> You can't think that allowing the same name to appear >> globally and locally is a good idea. > Actually, I do think it is a good idea. >> If I say "GRANT TO foo", who am >> I granting privileges to? > SET username_precedence TO LOCAL,GLOBAL; -- I like GLOBAL more than > CLUSTER > GRANT TO foo; > SET username_precedence TO GLOBAL,LOCAL; > GRANT TO foo; >> And I don't want to say that there is no >> difference because they are the same user. > Agreed, they should be the same user. What? You are contradicting yourself. That "precedence" hack makes sense only if there is a difference. >> That will open up some nasty >> security holes, eg, being able to pretend that you are the global >> postgres superuser if you can set the password for a local user by the >> same name. > Agreed, but if a cluster is using LOCAL USERs, I doubt highly that > CLUSTER/GLOBAL users would be in use much beyond super users. -sc Exactly my point. I think that it might be possible for a locally-privileged DBA to give himself superuser privileges by skating on this confusion between who is whom. Once he creates a local user with the same name as the global superuser, the door is open to problems --- not only possible bugs in our own code, but plain old human error on the part of the real superuser. In short, I say it's a bad idea with no redeeming social value. I can't see any positive use-case for having local usernames that conflict with global ones. regards, tom lane
В списке pgsql-hackers по дате отправления: