On Wed, Sep 07, 2011 at 02:09:15PM +0100, Thom Brown wrote:
> On 24 August 2011 13:38, Kohei Kaigai <Kohei.Kaigai@emea.nec.com> wrote:
>
> > The (2) is new stuff from the revision in commit-fest 1st. It enables to
> > supply "NOLEAKY" option on CREATE FUNCTION statement, then the function is
> > allowed to distribute across security barrier. Only superuser can set this
> > option.
> >
>
> "NOLEAKY" doesn't really sound appropriate as it sounds like pidgin English.
> Also, it could be read as "Don't allow leaks in this function". Could we
> instead use something like TRUSTED or something akin to it being allowed to
> do more than safer functions? It then describes its level of behaviour
> rather than what it promises not to do.
I liked NOLEAKY for its semantics, though I probably would have spelled it
"LEAKPROOF". PostgreSQL will trust the function to implement a specific,
relatively-unintuitive security policy. We want the function implementers to
read that policy closely and not rely on any intuition they have about the
"trusted" term of art. Our use of TRUSTED in CREATE LANGUAGE is more
conventional, I think, as is the trusted nature of SECURITY DEFINER. In that
vein, folks who actually need SECURITY DEFINER might first look at TRUSTED;
NOLEAKY would not attract the same unwarranted attention.