On Wed, Sep 7, 2011 at 9:39 AM, Thom Brown <t...@linux.com> wrote: > On 7 September 2011 14:34, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >> 2011/9/7 Thom Brown <t...@linux.com>: >> > On 24 August 2011 13:38, Kohei Kaigai <kohei.kai...@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. :)
I think TRUSTED actually does a reasonably good job capturing what we're after here, although I do share a bit of KaiGai's nervousness about terminological confusion. Still, I'd be inclined to go that way if we can't come up with anything better. CREDIBLE is definitely the wrong idea: that means "believable", which sounds more like a statement about the function's results than about its side-effects. I thought about TACITURN, since we need the error messages to not be excessively informative, but that doesn't do a good job characterizing the hazard created by side-effects, or the potential for abuse due to - for example - deliberate division by zero. I also thought about PURE, which is a term that's sometimes used to describe code that throws no errors and has no side effects, and comes pretty close to our actual requirement here, but doesn't necessarily convey that a security concern is involved. Yet another idea would be to use a variant of TRUSTED, such as TRUSTWORTHY, just to avoid confusion with the idea of a trusted procedure, but I'm not that excited about that idea despite have no real specific gripe with it other than length. So at the moment I am leaning toward TRUSTED. Anyone else want to bikeshed? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers