Re: [BUGS] BUG #14600: Passwords in user mappings leaked bypsql \deu+ command
| От | Jeff Janes |
|---|---|
| Тема | Re: [BUGS] BUG #14600: Passwords in user mappings leaked bypsql \deu+ command |
| Дата | |
| Msg-id | CAMkU=1xK998sMHBzd9QQpRBkqZPhcsBuOPiFSPGtOfSzq_FF3w@mail.gmail.com обсуждение исходный текст |
| Ответ на | [BUGS] BUG #14600: Passwords in user mappings leaked by psql \deu+ command (Feike Steenbergen <feikesteenbergen@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Mar 31, 2017 at 11:21 AM, Feike Steenbergen <feikesteenbergen@gmail.com> wrote:
Forwarding message from pgsql-bugs for reviewAttached a patch which copies the logic from commit93a6be63a55a8cd0d73b3fa81eb6a46013a3a974. In the current implementation we only consider privileges of the foreign serverin determining whether or not to show the user mapping details. This patchcopies the same logic (and documentation) used in commit93a6be63a55a8cd0d73b3fa81eb6a46013a3a974 to not always show the user mapping options.
This needs to update the regression tests.
But I'm not sure it is behaviorally correct, either. One of the regression tests fails with:
ERROR: role "33175" does not exist
Which doesn't seem like it should fail in this manner.
Also, this patch allows a user to see the password of their own user mapping where they don't have usage permissions on the server (e.g. their user mapping was created by a superuser, not by them). Without the patch, they cannot do that, and I don't think this patch should change that.
Ideally, I would say they shouldn't be able to see the password for any mapping they didn't create, even if they do have USAGE and they are the user the mapping is for. But I don't see that the creator of the user mapping is stored in the catalog, so perhaps that is not possible.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: