Re: [v9.2] Fix Leaky View Problem - Mailing list pgsql-hackers

From Thom Brown
Subject Re: [v9.2] Fix Leaky View Problem
Date
Msg-id CAA-aLv7+-VoZCDMSsRgwCw5hEHT4ekcL=zokJQ_C7pEjYd9+aQ@mail.gmail.com
Whole thread Raw
In response to Re: [v9.2] Fix Leaky View Problem  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.2] Fix Leaky View Problem
List pgsql-hackers
On 7 September 2011 14:34, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
2011/9/7 Thom Brown <thom@linux.com>:
> 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.
>
Thanks for your comment. I'm not a native English specker, so it is helpful.

"TRUSTED" sounds meaningful for me, however, it is confusable with a concept
of "trusted procedure" in label-based MAC. It is not only SELinux,
Oracle's label
based security also uses this term to mean a procedure that switches user's
credential during its execution.
 http://download.oracle.com/docs/cd/B28359_01/network.111/b28529/storproc.htm

So, how about "CREDIBLE", instead of "TRUSTED"?

I can't say I'm keen on that alternative, but I'm probably not the one to participate in bike-shedding here, so I'll leave comment to you hackers. :)

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] Fix Leaky View Problem
Next
From: Robert Haas
Date:
Subject: Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held