Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revise the permission checking on user mapping DDL commands.

  1. [BUGS] BUG #14600: Passwords in user mappings leaked by psql \deu+ command

    Feike Steenbergen <feikesteenbergen@gmail.com> — 2017-03-31T18:21:23Z

    Forwarding message from pgsql-bugs for review


Attached a patch which copies the logic from commit
93a6be63a55a8cd0d73b3fa81eb6a46013a3a974.

In the current implementation we only consider privileges of the foreign
server
in determining whether or not to show the user mapping details. This patch
copies the same logic (and documentation) used in commit
93a6be63a55a8cd0d73b3fa81eb6a46013a3a974 to not always show the user mapping
options.

regards,

Feike

  2. Re: [BUGS] BUG #14600: Passwords in user mappings leaked by psql \deu+ command

    Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> — 2017-04-03T09:47:47Z

    Please add this to 07/2017 commitfest. It looks like an existing leak, so,
may not be considered as an open item for v10.

On Fri, Mar 31, 2017 at 11:51 PM, Feike Steenbergen <
feikesteenbergen@gmail.com> wrote:

> Forwarding message from pgsql-bugs for review
>
>
> Attached a patch which copies the logic from commit
> 93a6be63a55a8cd0d73b3fa81eb6a46013a3a974.
>
> In the current implementation we only consider privileges of the foreign
> server
> in determining whether or not to show the user mapping details. This patch
> copies the same logic (and documentation) used in commit
> 93a6be63a55a8cd0d73b3fa81eb6a46013a3a974 to not always show the user
> mapping
> options.
>
> regards,
>
> Feike
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>


-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

  3. Re: [BUGS] BUG #14600: Passwords in user mappings leaked by psql \deu+ command

    Jeff Janes <jeff.janes@gmail.com> — 2017-04-03T17:54:24Z

    On Fri, Mar 31, 2017 at 11:21 AM, Feike Steenbergen <
feikesteenbergen@gmail.com> wrote:

> Forwarding message from pgsql-bugs for review
>
>
> Attached a patch which copies the logic from commit
> 93a6be63a55a8cd0d73b3fa81eb6a46013a3a974.
>
> In the current implementation we only consider privileges of the foreign
> server
> in determining whether or not to show the user mapping details. This patch
> copies the same logic (and documentation) used in commit
> 93a6be63a55a8cd0d73b3fa81eb6a46013a3a974 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