Re: proposal: session server side variables

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

>
> Hello again,
>
> 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.
>>
>
> Yes, I assure you that I really know how static analysis works... All the
> properties I described below may be proved without executing the code, that
> was my point...
>
>
> 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.
>>
>
> They are my session variable, I just spelled out some properties to be
> precise about what I am stating, otherwise it is a mess. The name of the
> variable is "static" (statically-named), i.e. it is known directly in the
> code. However the variable creation and value are "dynamic".
>
> Static variables like Clang static variables are not usable - you would to
>> share content between different functions.
>>
>
> Sure. I mean static as in "static analysis", i.e. by looking at the code
> without executing it, as you put it.
>
> (2) (3) (4) [...]
>>>
>> You are speaking about runtime check.
>>
>
> Not really, I was speaking about properties statically provable, which I
> understood was your concern. Now the properties proved may imply a runtime
> assumption, for instance that the code has executed without error up to
> some point in the program, which is basically impossible to prove
> statically.
>
> BEGIN
>> RAISE NOTICE '%', @var;
>> END;
>>
>> Without "execution", you cannot to say if usage of @var is correct or not
>>
>
> It depends about your definition of "correct".
>
> For this very instance it would not matter: if the variable was not
> created beforehand, then an error is raised because it does not exist, if
> it was created before hand, then an error is raised because that is what
> the code is doing... So an error is always raised if the variable is not
> right.
>
> ok, we can use a DECLARE var
>>
>> DECLARE @var EXTERNAL
>>
>
> I do not know what you mean by 'EXTERNAL'.

it means "used as shared in session"

>
>
> BEGIN
>> RAISE NOTICE '%', @var;
>> END;
>>
>> ok, I can do static check - but
>>
>
> 1. anytime I have to repeat DECLARE statement
>>
>
> Yes, twice in the complete use case: one for the function which checks the
> credentials, one for the getter function.
>
> 2. there is not possible to find typo in DECLARE statement
>>
>
> It is possible to find "some" typos, depending on the code: you can check
> that a variable is both assigned and used somewhere, otherwise it is very
> probably a typo. Perl does that *statically*, before executing a script.

"Before execution" .. I am speaking "without execution".

theoretically, if you check all possible functions, you can find some
issues - but you have to check all function on server. Elsewhere you cannot
to find typo in DECLARE statement.

Regards

Pavel

>
>
> --
> Fabien.
>