Re: 回复：A question about leakproof

On Sun, Oct 16, 2022 at 8:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "qiumingcheng" <qiumingcheng(at)aliyun(dot)com> writes:
> > 1. In the test example I gave, the in4eq function's proleakproof=true,
> but its actual test result is leaking. Does that mean you will adjust it to
> proleakproof=false later?
>
> int4eq is about as leakproof as a function could possibly be: it does
> not leak, it's plain from the code of the function that it does not
> leak, and it calls no other code that might accidentally introduce
> a leak in future.
>
> I think you do not understand what that property actually means.
> Per the CREATE FUNCTION man page:
>
> LEAKPROOF indicates that the function has no side
> effects. It reveals no information about its arguments other than
> by
> its return value. For example, a function which throws an error
> message
> for some argument values but not others, or which includes the
> argument
> values in any error message, is not leakproof.
>
> Please note that this definition talks only about the behavior
> of the function itself. Re-reading your email, you seem to be
> imagining that changes in a query's plan on the basis of changes in
> collected statistics have something to do with this. They do not.
>
>
You omitted including the part about when the system even has to care about
leakproof:

"This affects how the system executes queries against views created with
the security_barrier option or tables with row level security enabled."

A non-leakproof function must not be called with inputs that the current
user is not allowed to see. Allowed being the operative word, if they
could see the value if not for other non-security-related conditions in the
query it is acceptable to call the function with those inputs even if the
end result is simply going to be thrown away later (while inefficient, this
is why function cost is tunable). None of your examples prohibit any row
from being processed by any function and so your spy function may see any
and all rows present in the table.

A leakproof function is allowed to process data that the current user is
not allowed to see - because if the input row ends up being filtered out
the values of the input arguments will never be viewable by the user. They
will neither be in the query output, nor able to be read or inferred by
some kind of side-effect. Your spy function, which is not leakproof,
should never see such prohibited rows - which you seem to have confirmed.
The planner indeed must ensure other security-related filters are applied
first.

David J.