pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedQ on SELECT column list pushdown from view to table
6+ messages / 2 participants
[nested] [flat]
* Q on SELECT column list pushdown from view to table
@ 2025-03-25 22:21 Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-25 22:55 ` Re: Q on SELECT column list pushdown from view to table Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 6+ messages in thread
From: Karsten Hilbert @ 2025-03-25 22:21 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
Dear all,
given this schema and role:
create table t_partially_private (
public_col text,
private_col text
);
insert into t_partially_private (public_col, private_col) values ('public value', 'private value');
create view v_partially_private as
select
public_col,
private_col
from
t_partially_private
;
alter view v_partially_private set (security_invoker = TRUE);
create role "restricted-role";
grant select (public_col) on t_partially_private to "restricted-role";
grant select (public_col) on v_partially_private to "restricted-role";
I expected this:
set role "restricted-role";
-- this works:
select public_col from t_partially_private;
-- this fails: with "permission denied on table t_partially_private"
select public_col from v_partially_private;
to work but selecting from the view fails. I would assume
the reason is that the SELECT column list does not narrow
down what the view tries to (sub)select from the table.
If so, is there a reason I don't yet see why this is so ?
What would be the proper way to achieve the above short of
using another view dedicated to the restricted column (in
real life, the views are way more involved, as usual ...).
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Q on SELECT column list pushdown from view to table
2025-03-25 22:21 Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
@ 2025-03-25 22:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-26 17:24 ` Re: Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
0 siblings, 1 reply; 6+ messages in thread
From: Tom Lane @ 2025-03-25 22:55 UTC (permalink / raw)
To: Karsten Hilbert <Karsten.Hilbert@gmx.net>; +Cc: pgsql-general@lists.postgresql.org
Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> I expected this:
> set role "restricted-role";
> -- this works:
> select public_col from t_partially_private;
> -- this fails: with "permission denied on table t_partially_private"
> select public_col from v_partially_private;
> to work but selecting from the view fails.
Works fine if you don't mess with the view's security_invoker
status.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Q on SELECT column list pushdown from view to table
2025-03-25 22:21 Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-25 22:55 ` Re: Q on SELECT column list pushdown from view to table Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-03-26 17:24 ` Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-26 18:30 ` Re: Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-26 20:36 ` Re: Q on SELECT column list pushdown from view to table Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 6+ messages in thread
From: Karsten Hilbert @ 2025-03-26 17:24 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-general@lists.postgresql.org
Am Tue, Mar 25, 2025 at 06:55:34PM -0400 schrieb Tom Lane:
> Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> > I expected this:
>
> > set role "restricted-role";
> > -- this works:
> > select public_col from t_partially_private;
> > -- this fails: with "permission denied on table t_partially_private"
> > select public_col from v_partially_private;
>
> > to work but selecting from the view fails.
>
> Works fine if you don't mess with the view's security_invoker
> status.
I know but doing so was kind of the point.
The views are created by a "database owner" role having
access to all tables. Therefore, roles using the views would
normally gain access to tables they are otherwise not
allowed to read. Hence setting security to invoker made a
lot of sense at first sight ...
Perhaps I am misunderstanding the intent of the feature.
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Q on SELECT column list pushdown from view to table
2025-03-25 22:21 Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-25 22:55 ` Re: Q on SELECT column list pushdown from view to table Tom Lane <tgl@sss.pgh.pa.us>
2025-03-26 17:24 ` Re: Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
@ 2025-03-26 18:30 ` Karsten Hilbert <Karsten.Hilbert@gmx.net>
1 sibling, 0 replies; 6+ messages in thread
From: Karsten Hilbert @ 2025-03-26 18:30 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-general@lists.postgresql.org
Am Wed, Mar 26, 2025 at 06:24:14PM +0100 schrieb Karsten Hilbert:
> > Works fine if you don't mess with the view's security_invoker
> > status.
>
> I know but doing so was kind of the point.
>
> The views are created by a "database owner" role having
> access to all tables. Therefore, roles using the views would
> normally gain access to tables they are otherwise not
> allowed to read.
Or rather, to certain *columns* of tables...
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Q on SELECT column list pushdown from view to table
2025-03-25 22:21 Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-25 22:55 ` Re: Q on SELECT column list pushdown from view to table Tom Lane <tgl@sss.pgh.pa.us>
2025-03-26 17:24 ` Re: Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
@ 2025-03-26 20:36 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-26 21:14 ` Re: Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
1 sibling, 1 reply; 6+ messages in thread
From: Tom Lane @ 2025-03-26 20:36 UTC (permalink / raw)
To: Karsten Hilbert <Karsten.Hilbert@gmx.net>; +Cc: pgsql-general@lists.postgresql.org
Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> Am Tue, Mar 25, 2025 at 06:55:34PM -0400 schrieb Tom Lane:
>> Works fine if you don't mess with the view's security_invoker
>> status.
> I know but doing so was kind of the point.
[ shrug... ] It's not going to work. When the view is inlined into
the calling query, you end up with the exact equivalent of
select public_col from (
select
public_col,
private_col
from
t_partially_private
) as v_partially_private;
With the normal security_definer view processing, the reference
to t_partially_private is treated with the privileges of
v_partially_private's owner, and all is well. But with
security_invoker, the whole thing is treated with the caller's
privileges, and so the reference to private_col fails.
It is intentional that this happens even if the reference to
private_col is subsequently optimized away. To do otherwise
would make implementation artifacts in the optimizer far too
visible, and there's also a very strong case that it would
violate the SQL standard.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Q on SELECT column list pushdown from view to table
2025-03-25 22:21 Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-25 22:55 ` Re: Q on SELECT column list pushdown from view to table Tom Lane <tgl@sss.pgh.pa.us>
2025-03-26 17:24 ` Re: Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-26 20:36 ` Re: Q on SELECT column list pushdown from view to table Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-03-26 21:14 ` Karsten Hilbert <Karsten.Hilbert@gmx.net>
0 siblings, 0 replies; 6+ messages in thread
From: Karsten Hilbert @ 2025-03-26 21:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-general@lists.postgresql.org
Am Wed, Mar 26, 2025 at 04:36:55PM -0400 schrieb Tom Lane:
> It is intentional that this happens even if the reference to
> private_col is subsequently optimized away. To do otherwise
> would make implementation artifacts in the optimizer far too
> visible, and there's also a very strong case that it would
> violate the SQL standard.
That's what I wanted to know.
Thanks,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-03-26 21:14 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-03-25 22:21 Q on SELECT column list pushdown from view to table Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-25 22:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-26 17:24 ` Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-26 18:30 ` Karsten Hilbert <Karsten.Hilbert@gmx.net>
2025-03-26 20:36 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-03-26 21:14 ` Karsten Hilbert <Karsten.Hilbert@gmx.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox