From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(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: | 2014-09-29 15:46:17 |
Message-ID: | 20140929154617.GW16422@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> Well, I think that's an acceptable approach from the point of view of
> fixing the security exposure, but it's far from ideal. Good error
> messages are important for usability. I can live with this as a
> short-term fix, but in the long run I strongly believe we should try
> to do better.
It certainly wouldn't be hard to add the same check around the WITH
OPTION case that's around my proposed solution for the other issues-
just check for SELECT rights on the underlying table. Another question
is if we could/should limit this to the UPDATE case. With the INSERT
case, any columns not provided by the user would be filled out by
defaults, which can likely be seen in the catalog, or the functions in
the catalog for the defaults or for any triggers might be able to be
run by the user executing the INSERT anyway to see what would have been
used in the resulting row. I'm not completely convinced there's no risk
there though..
Thoughts?
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-09-29 15:50:19 | Re: open items for 9.4 |
Previous Message | Stephen Frost | 2014-09-29 15:40:36 | Re: json (b) and null fields |