Robert Haas wrote:
> On Sat, May 22, 2010 at 4:53 PM, C?dric Villemain
> <cedric.villemain.deb...@gmail.com> wrote:
> > 2010/5/21 Jan Wieck <janwi...@yahoo.com>:
> >> The original idea was that a trusted language does not allow an
> >> unprivileged
> >> user to gain access to any object or data, he does not have access to
> >> without that language.
> >>
> >> This does not include data transformation functionality, like string
> >> processing or the like. As long as the user had legitimate access to the
> >> input datum, then every derived form thereof is OK.
> >
> > I find the current doc enough, add this prose from Jan as a comment
> > might help people perhaps.
>
> Yeah, Jan's description is very clear and to the point.
The attached, applied patch clarifies the meaning of "trusted language"
in the documentation using Jan's description.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
Index: doc/src/sgml/xplang.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v
retrieving revision 1.37
diff -c -c -r1.37 xplang.sgml
*** doc/src/sgml/xplang.sgml 3 Apr 2010 07:22:56 -0000 1.37
--- doc/src/sgml/xplang.sgml 30 May 2010 02:21:53 -0000
***************
*** 151,158 ****
<optional>VALIDATOR <replaceable>validator_function_name</replaceable></optional> ;
</synopsis>
The optional key word <literal>TRUSTED</literal> specifies that
! ordinary database users that have no superuser privileges should
! be allowed to use this language to create functions and trigger
procedures. Since PL functions are executed inside the database
server, the <literal>TRUSTED</literal> flag should only be given
for languages that do not allow access to database server
--- 151,160 ----
<optional>VALIDATOR <replaceable>validator_function_name</replaceable></optional> ;
</synopsis>
The optional key word <literal>TRUSTED</literal> specifies that
! the language does not grant access to data that the user would
! not otherwise have. Trusted languages are designed for ordinary
! database users (those without superuser privilege) and allows them
! to safely create of functions and trigger
procedures. Since PL functions are executed inside the database
server, the <literal>TRUSTED</literal> flag should only be given
for languages that do not allow access to database server
Index: doc/src/sgml/ref/create_language.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_language.sgml,v
retrieving revision 1.50
diff -c -c -r1.50 create_language.sgml
*** doc/src/sgml/ref/create_language.sgml 3 Apr 2010 07:22:58 -0000 1.50
--- doc/src/sgml/ref/create_language.sgml 30 May 2010 02:21:53 -0000
***************
*** 104,114 ****
<listitem>
<para>
! <literal>TRUSTED</literal> specifies that
! the language is safe, that is, it does not offer an
! unprivileged user any functionality to bypass access
! restrictions. If this key word is omitted when registering the
! language, only users with the
<productname>PostgreSQL</productname> superuser privilege can
use this language to create new functions.
</para>
--- 104,113 ----
<listitem>
<para>
! <literal>TRUSTED</literal> specifies that the language does
! not grant access to data that the user would not otherwise
! have. If this key word is omitted
! when registering the language, only users with the
<productname>PostgreSQL</productname> superuser privilege can
use this language to create new functions.
</para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
