Re: proposal: session server side variables

2016-12-30 14:45 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Please Pavel, could you avoid citing a whole long mail just for commenting
> one point?
>
> * Why is it so necessary for plpgsql variables to be implemented as
>>> persistent entities that are in the catalogs in order for you to
>>> achieve the static checking you want to? Is this due to limitations of
>>> your approach in plpgsql_check, or more fundamental issues? Explain.
>>>
>>
>> There are few reasons:
>>
>> 1. plpgsql_check cannot to know a order of calls of functions.
>>
>
> Indeed.
>
> So any dynamic created object and related operations are not checkable by
>> plpgsql_check (or any tool).
>>
>
> NO. Your first sentence does not imply this very general statement.
>

If you have not unique definition, you cannot to it. There is not
possibility different between typo and decision. We are talking about
static analyze - so code should not be executed - and you don't know what
function will be started first.

>
> Some things that I think can be statically proved within a session, that
> would cover some security concerns:
>
> (1) For statically named private dynamic variables declared/used at
> different points it can be checked without relying on the function order
> that all declarations are consistent, i.e. the same type, same default
> value if any.
>

what is "static" private dynamic variable ? You are using new terminology.
Static variables like Clang static variables are not usable - you would to
share content between different functions.

>
> (2) Then the value of the variable is either the default value (eg NULL)
> or the assigned value at points of assignement, which must be a valid value
> for the type, otherwise the assignement would have failed.
>
> (3) If there is only one assignment in the code, then you know that the
> variable can only have been assigned a non default value from this point.
> Probably nice to have in a security context, but it requires you to be
> sure that you have access to all the code...
>
> (4) For a session boolean, then for code "IF @var IS NOT NULL AND NOT @var
> THEN RAISE 'cannot access'; END", in a sequence, then one can prove that
> for any pl code after this point in the sequence @var has been previously
> assigned to true, otherwise the exception would have been raised.
>

You are speaking about runtime check.There is not a problem to define some
rules for runtime check.

What is not possible in your design

1.

BEGIN
RAISE NOTICE '%', @var;
END;

Without "execution", you cannot to say if usage of @var is correct or not

ok, we can use a DECLARE var

DECLARE @var EXTERNAL
BEGIN
RAISE NOTICE '%', @var;
END;

ok, I can do static check - but

1. anytime I have to repeat DECLARE statement
2. there is not possible to find typo in DECLARE statement

Regards

Pavel

>
>
> AFAICS, for "static" session variables the only difference is that the
> declaration consistency (1) is slightly more built-in, although you still
> have to check that no function DROP/re-CREATE the session variable with a
> different type, which is quite close to checking (1) for a dynamic session
> variable.
>
> Other properties (2), (3), (4) are exactly the same.
>
> 2. [...] 3.
>>
>
> Please could you put your pros & cons in the wiki as well?
>
> Or don't you want to use it?
>
> --
> Fabien.
>