From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: session server side variables |
Date: | 2016-12-31 17:11:55 |
Message-ID: | CAFj8pRAYecrEr=W=-0aXA9npGJdP+kW2bFWUm9ZURpaU1kasYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-12-31 17:51 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
> unexpectedly, that would be missed by a PL/pgSQL analysis tool... There is
>>> no miracle.
>>>
>>
>> No - metadata, in my design, are persistent - like tables - so you don't
>> calculate so any functions can drop a variables. The deployment of secure
>> variables is same like table deployment. No dynamic there.
>>
>
> You are missing my point: Static analysis is about proving properties. If
> you need metadata to be persistent, then you should check that it is the
> case, i.e. the static analysis must check that there is no metadata changes
> anywhere. For instance, an analysis tool should reject a function which
> contains:
>
> GRANT UPDATE ON VARIABLE super_secret_variable TO PUBLIC;
>
It doesn't need to reject this functions - but this information is not
visible in any other functions. But this tasks you are do in deployment
scripts - not in functions.
>
> Or does:
>
> DROP VARIABLE super_secret;
> CREATE VARIABLE super_secret ...;
>
But you don't do it in functions - these variables are persistent - you
don't create it or drop inside functions. The content is secure, so you
don't need to hide this variable against other.
>
> If a static analysis tool is specific to one language, then it can only
> checks that all is well in functions in those languages, but as there may
> be functions written in other languages as well then the check is somehow
> partial. This is not a bad thing, it just illustrate that you cannot check
> everything. That is quality ensurance.
>
> [...] Indeed, probably there exists some class of typos that may not be
>>> found by some static analysis implementations on PL/pgSQL functions which
>>> uses basic session variables.
>>>
>>
>> yes, and I would not to append any new case that cannot be covered by
>> plpgsql check. Dynamic SQL and our temporal tables are enough issues
>> already.
>>
>
> I'm not sure that I understand these sentences.
so I don't prefer any design that increase a area where plpgsql_check
should not work.
>
>
> I wrote my notes there.
>>
>
> Great! I restructured a little bit and tried to improve the English. I
> also added questions when some statement that I think are too optimistic,
> or are unclear to me.
we have just different perspectives
Regards
Pavel
>
>
> --
> Fabien.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2016-12-31 17:28:48 | Re: proposal: session server side variables |
Previous Message | Peter Eisentraut | 2016-12-31 17:08:22 | safer node casting |