Re: proof concept - access to session variables on client side

On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
> 2012/6/26 Magnus Hagander <magnus(at)hagander(dot)net>:
> > On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> >> 2012/6/26 Magnus Hagander <magnus(at)hagander(dot)net>:
> >>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> >>>> Hello
> >>>>
> >>>> I worked on simple patch, that enable access from server side to
> >>>> client side data. It add two new hooks to libpq - one for returning of
> >>>> local context, second for setting of local context.
> >>>>
> >>>> A motivation is integration of possibilities of psql console together
> >>>> with stronger language - plpgsql. Second target is enabling
> >>>> possibility to save a result of some server side process in psql. It
> >>>> improve vars feature in psql.
> >>>>
> >>>> pavel ~/src/postgresql/src $ cat test.sql
> >>>> \echo value of external paremeter is :"myvar"
> >>>>
> >>>> do $$
> >>>> begin
> >>>>  -- we can take any session variable on client side
> >>>>  -- it is safe against to SQL injection
> >>>>  raise notice 'external parameter accessed from plpgsql is "%"',
> >>>> hgetvar('myvar');
> >>>>
> >>>>  -- we can change this session variable and finish transaction
> >>>>  perform hsetvar('myvar', 'Hello, World');
> >>>> end;
> >>>> $$ language plpgsql;
> >>>>
> >>>> \echo new value of session variable is :"myvar"
> >>>>
> >>>> cat test.sql | psql postgres -v myvar=Hello
> >>>> value of external paremeter is "Hello"
> >>>> NOTICE:  external parameter accessed from plpgsql is "Hello"
> >>>> DO
> >>>> new value of session variable is "Hello, World"
> >>>>
> >>>> This is just proof concept - there should be better integration with
> >>>> pl languages, using cache for read on server side, ...
> >>>>
> >>>> Notices?
> >>>
> >>> Why not just use a custom GUC variable instead? E.g. you could have
> >>> psql SET "psql.myvar='Hello, World'", and then you'd need no changes
> >>> at all in the backend? Maybe have a "shorthand interface" for
> >>> accessing GUCs in psql would help in making it easier, but do we
> >>> really need a whole new variable concept?
> >>
> >> GUC variables doesn't help with access to psql's command line
> >> parameters from DO PL code.
> >
> > But with a small change to psql they could, without the need for a
> > whole new type of variable. For example, psql could set all those
> > variable as "psql.<commandlinevarname>", which could then be accessed
> > from the DO PL code just fine.
>
> yes, it is possibility too. It has different issues - it can send
> unwanted variables -

Could you expand on this just a bit? Are you picturing something an
attacker could somehow use, or...?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate