MIME-Version: 1.0
In-Reply-To: <20171026220732.GI4496@localhost>
References: 
 <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
 <20171026220732.GI4496@localhost>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Fri, 27 Oct 2017 07:08:43 +0200
Message-ID: 
 <CAFj8pRAemkdaDuoRQzrhs2GU59Bb_yHuquJC6nyrwGHfVdLuLw@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Nico Williams <nico@cryptonector.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="001a1145ac7ac49b6d055c804ac8"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--001a1145ac7ac49b6d055c804ac8
Content-Type: text/plain; charset="UTF-8"

Hi

2017-10-27 0:07 GMT+02:00 Nico Williams <nico@cryptonector.com>:

> On Thu, Oct 26, 2017 at 09:21:24AM +0200, Pavel Stehule wrote:
> > Comments, notes?
>
> I like it.
>
> I would further like to move all of postgresql.conf into the database,
> as much as possible, as well as pg_ident.conf and pg_hba.conf.
>
> Variables like current_user have a sort of nesting context
> functionality: calling a SECURITY DEFINER function "pushes" a new value
> onto current_user, then when the function returns the new value of
> current_user is "popped" and the previous value restored.
>

My proposal doesn't expecting with nesting, because there is only one scope
- schema / session - but I don't think so it is necessary

current_user is a function - it is based on parser magic in Postgres. The
origin from Oracle uses the feature of ADA language. When function has no
parameters then parenthesis are optional. So current_user, current_time are
functions current_user(), current_time().


> It might be nice to be able to generalize this.
>
> Questions that then arise:
>
>  - can one see up the stack?
>  - are there permissions issues with seeing up the stack?
>

these variables are pined to schema - so there is not any relation to
stack. It is like global variables.

Theoretically we can introduce "functional" variables, where the value is
based on immediate evaluation of expression. It can be very similar to
current current_user.

>
>
> I recently posted proposing a feature such that SECURITY DEFINER
> functions could observe the _caller_'s current_user.
>

your use case is good example - this proposed feature doesn't depend on
stack, depends on security context (security context stack) what is super
set of call stack

Regards

Pavel


> Nico
> --
>

--001a1145ac7ac49b6d055c804ac8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi<br><div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2017-10-27 0:07 GMT+02:00 Nico Williams <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector.=
com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Oct 26, 2017 =
at 09:21:24AM +0200, Pavel Stehule wrote:<br>
&gt; Comments, notes?<br>
<br>
I like it.<br>
<br>
I would further like to move all of postgresql.conf into the database,<br>
as much as possible, as well as pg_ident.conf and pg_hba.conf.<br>
<br>
Variables like current_user have a sort of nesting context<br>
functionality: calling a SECURITY DEFINER function &quot;pushes&quot; a new=
 value<br>
onto current_user, then when the function returns the new value of<br>
current_user is &quot;popped&quot; and the previous value restored.<br></bl=
ockquote><div><br></div><div>My proposal doesn&#39;t expecting with nesting=
, because there is only one scope - schema / session - but I don&#39;t thin=
k so it is necessary<br></div><div><br></div><div>current_user is a functio=
n - it is based on parser magic in Postgres. The origin from Oracle uses th=
e feature of ADA language. When function has no parameters then parenthesis=
 are optional. So current_user, current_time are functions current_user(), =
current_time().<br></div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It might be nice to be able to generalize this.<br>
<br>
Questions that then arise:<br>
<br>
=C2=A0- can one see up the stack?<br>
=C2=A0- are there permissions issues with seeing up the stack?<br></blockqu=
ote><div><br></div><div>these variables are pined to schema - so there is n=
ot any relation to stack. It is like global variables. <br></div><div><br><=
/div><div>Theoretically we can introduce &quot;functional&quot; variables, =
where the value is based on immediate evaluation of expression. It can be v=
ery similar to current current_user.<br></div>=C2=A0<blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<br>
I recently posted proposing a feature such that SECURITY DEFINER<br>
functions could observe the _caller_&#39;s current_user.<br></blockquote><d=
iv><br></div><div>your use case is good example - this proposed feature doe=
sn&#39;t depend on stack, depends on security context (security context sta=
ck) what is super set of call stack</div><div><br></div><div>Regards</div><=
div><br></div><div>Pavel<br></div><div><br></div><div> <br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Nico<br>
--<br>
</font></span></blockquote></div><br></div></div></div>

--001a1145ac7ac49b6d055c804ac8--