checked here.
      This is currently not done due to implementation restrictions.)
     </para>
    </listitem>
   </itemizedlist>

  </sect3>

  <sect3 id="sepgsql-features-trusted-procedures">
   <title>Trusted Procedures</title>
   <para>
    Trusted procedures are similar to security definer functions or setuid
    commands. <productname>SELinux</productname> provides a feature to allow trusted
    code to run using a security label different from that of the client,
    generally for the purpose of providing highly controlled access to
    sensitive data (e.g., rows might be omitted, or the precision of stored
    values might be reduced).  Whether or not a function acts as a trusted
    procedure is controlled by its security label and the operating system
    security policy.  For example:
   </para>

<screen>
postgres=# CREATE TABLE customer (
               cid     int primary key,
               cname   text,
               credit  text
           );
CREATE TABLE
postgres=# SECURITY LABEL ON COLUMN customer.credit
               IS 'system_u:object_r:sepgsql_secret_table_t:s0';
SECURITY LABEL
postgres=# CREATE FUNCTION show_credit(int) RETURNS text
             AS 'SELECT regexp_replace(credit, ''-[0-9]+$'', ''-xxxx'', ''g'')
                        FROM customer WHERE cid = $1'
           LANGUAGE sql;
CREATE FUNCTION
postgres=# SECURITY LABEL ON FUNCTION show_credit(int)
               IS 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0';
SECURITY LABEL
</screen>

   <para>
    The above operations should be performed by an administrative user.
   </para>

<screen>
postgres=# SELECT * FROM customer;
ERROR:  SELinux: security policy violation
postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
 cid | cname  |     show_credit
-----+--------+---------------------
   1 | taro   | 1111-2222-3333-xxxx
   2 | hanako | 5555-6666-7777-xxxx
(2 rows)
</screen>

   <para>
    In this case, a regular user cannot reference <literal>customer.credit</literal>
    directly, but a trusted procedure <literal>show_credit</literal> allows the user
    to print the credit card numbers of customers with some of the digits
    masked out.
   </para>
  </sect3>

  <sect3 id="sepgsql-features-dynamic-domain-transitions">
   <title>Dynamic Domain Transitions</title>
   <para>
    It is possible to use SELinux's dynamic domain transition feature
    to switch the security label of the client process, the client domain,
    to a new context, if that is allowed by the security policy.
    The client domain needs the <literal>setcurrent</literal> permission and also
    <literal>dyntransition</literal> from the old to the new domain.
   </para>
   <para>
    Dynamic domain transitions should be considered carefully, because they
    allow users to switch their label, and therefore their privileges,
    at their option, rather than (as in the case of a trusted procedure)
    as mandated by the system.
    Thus, the <literal>dyntransition</literal> permission is only considered
    safe when used to switch to a domain with a smaller set of privileges than
    the original one. For example:
   </para>
<screen>
regression=# select sepgsql_getcon();
                    sepgsql_getcon
-------------------------------------------------------
 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
(1 row)

regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c4');
 sepgsql_setcon
----------------
 t
(1 row)

regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c1023');
ERROR:  SELinux: security policy violation
</screen>
   <para>
    In this example above we were allowed to switch from the larger MCS
    range <literal>c1.c1023</literal> to the smaller range <literal>c1.c4</literal>, but
    switching back was denied.
   </para>
   <para>
    A combination of dynamic domain transition and trusted procedure
    enables an interesting use case that fits the typical process life-cycle