From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WITH CHECK and Column-Level Privileges |
Date: | 2015-01-15 03:28:30 |
Message-ID: | 20150115032830.GE3062@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah,
* Noah Misch (noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-01-15 04:31:44 | Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree) |
Previous Message | Stephen Frost | 2015-01-15 03:18:10 | Re: Improving RLS qual pushdown |