Thread: Q on SELECT column list pushdown from view to table

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

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

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

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

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

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