Re: WITH CHECK and Column-Level Privileges - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: WITH CHECK and Column-Level Privileges
Date
Msg-id 20150115032830.GE3062@tamriel.snowman.net
Whole thread Raw
In response to Re: WITH CHECK and Column-Level Privileges  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah,

* Noah Misch (noah@leadboat.com) wrote:
> On Mon, Jan 12, 2015 at 05:16:40PM -0500, Stephen Frost wrote:
> > Alright, here's an updated patch which doesn't return any detail if no
> > values are visible or if only a partial key is visible.
>
> I browsed this patch.  There's been no mention of foreign key constraints, but
> ri_ReportViolation() deserves similar hardening.  If a user has only DELETE
> privilege on a PK table, FK violation messages should not leak the PK values.
> Modifications to the foreign side are less concerning, since the user will
> often know the attempted value; still, I would lock down both sides.

Ah, yes, good point.

> Please add a comment explaining the safety of each row-emitting message you
> haven't changed.  For example, the one in refresh_by_match_merge() is safe
> because getting there requires MV ownership.

Sure.

> Instead of duplicating an entire ereport() to change whether you include an
> errdetail, use "condition ? errdetail(...) : 0".

Yeah, that's a bit nicer, will do.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Improving RLS qual pushdown
Next
From: Michael Paquier
Date:
Subject: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree)