writing to files in any
       location the database can access on the server using
       <command>COPY</command> and other file-access functions.
      </para>
      <para>
       <literal>pg_execute_server_program</literal> allows executing programs
       on the database server as the user the database runs as using
       <command>COPY</command> and other functions which allow executing a
       server-side program.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-signal-autovacuum-worker" xreflabel="pg_signal_autovacuum_worker">
     <term><varname>pg_signal_autovacuum_worker</varname></term>
     <listitem>
      <para>
       <literal>pg_signal_autovacuum_worker</literal> allows signaling
       autovacuum workers to cancel the current table's vacuum or terminate its
       session.  See <xref linkend="functions-admin-signal"/>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-signal-backend" xreflabel="pg_signal_backend">
     <term><varname>pg_signal_backend</varname></term>
     <listitem>
      <para>
       <literal>pg_signal_backend</literal> allows signaling another backend to
       cancel a query or terminate its session.  Note that this role does not
       permit signaling backends owned by a superuser.  See
       <xref linkend="functions-admin-signal"/>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-use-reserved-connections" xreflabel="pg_use_reserved_connections">
     <term><varname>pg_use_reserved_connections</varname></term>
     <listitem>
      <para>
       <literal>pg_use_reserved_connections</literal> allows use of connection
       slots reserved via <xref linkend="guc-reserved-connections"/>.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

 </sect1>

 <sect1 id="perm-functions">
  <title>Function Security</title>

  <para>
   Functions, triggers and row-level security policies allow users to insert
   code into the backend server that other users might execute
   unintentionally. Hence, these mechanisms permit users to <quote>Trojan
   horse</quote> others with relative ease. The strongest protection is tight
   control over who can define objects. Where that is infeasible, write
   queries referring only to objects having trusted owners.  Remove
   from <varname>search_path</varname> any schemas that permit untrusted users
   to create objects.
  </para>

  <para>
   Functions run inside the backend
   server process with the operating system permissions of the
   database server daemon.  If the programming language
   used for the function allows unchecked memory accesses, it is
   possible to change the server's internal data structures.
   Hence, among many other things, such functions can circumvent any
   system access controls.  Function languages that allow such access
   are considered <quote>untrusted</quote>, and
   <productname>PostgreSQL</productname> allows only superusers to
   create functions written in those languages.
  </para>
 </sect1>

</chapter>