<screen>
$ sudo setsebool sepgsql_regression_test_mode on
$ getsebool sepgsql_regression_test_mode
sepgsql_regression_test_mode --> on
</screen>

  <para>
   Fourth, verify your shell is operating in the <literal>unconfined_t</literal>
   domain:
  </para>
<screen>
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
</screen>

  <para>
   See <xref linkend="sepgsql-resources"/> for details on adjusting your
   working domain, if necessary.
  </para>

  <para>
   Finally, run the regression test script:
  </para>
<screen>
$ ./test_sepgsql
</screen>

  <para>
   This script will attempt to verify that you have done all the configuration
   steps correctly, and then it will run the regression tests for the
   <filename>sepgsql</filename> module.
  </para>

  <para>
   After completing the tests, it's recommended you disable
   the <literal>sepgsql_regression_test_mode</literal> parameter:
  </para>

<screen>
$ sudo setsebool sepgsql_regression_test_mode off
</screen>

  <para>
   You might prefer to remove the <filename>sepgsql-regtest</filename> policy
   entirely:
  </para>

<screen>
$ sudo semodule -r sepgsql-regtest
</screen>
 </sect2>

 <sect2 id="sepgsql-parameters">
  <title>GUC Parameters</title>

  <variablelist>
   <varlistentry id="guc-sepgsql-permissive" xreflabel="sepgsql.permissive">
    <term>
     <varname>sepgsql.permissive</varname> (<type>boolean</type>)
     <indexterm>
      <primary><varname>sepgsql.permissive</varname> configuration parameter</primary>
     </indexterm>
    </term>
    <listitem>
     <para>
      This parameter enables <filename>sepgsql</filename> to function
      in permissive mode, regardless of the system setting.
      The default is off.
      This parameter can only be set in the <filename>postgresql.conf</filename>
      file or on the server command line.
     </para>

     <para>
      When this parameter is on, <filename>sepgsql</filename> functions
      in permissive mode, even if SELinux in general is working in enforcing
      mode.  This parameter is primarily useful for testing purposes.
     </para>
    </listitem>

   </varlistentry>
   <varlistentry id="guc-sepgsql-debug-audit" xreflabel="sepgsql.debug_audit">
    <term>
     <varname>sepgsql.debug_audit</varname> (<type>boolean</type>)
     <indexterm>
      <primary><varname>sepgsql.debug_audit</varname> configuration parameter</primary>
     </indexterm>
    </term>
    <listitem>
     <para>
      This parameter enables the printing of audit messages regardless of
      the system policy settings.
      The default is off, which means that messages will be printed according
      to the system settings.
     </para>

     <para>
      The security policy of <productname>SELinux</productname> also has rules to
      control whether or not particular accesses are logged.
      By default, access violations are logged, but allowed
      accesses are not.
     </para>

     <para>
      This parameter forces all possible logging to be turned on, regardless
      of the system policy.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </sect2>

 <sect2 id="sepgsql-features">
  <title>Features</title>
  <sect3 id="sepgsql-features-controlled-obj-classes">
   <title>Controlled Object Classes</title>
   <para>
    The security model of <productname>SELinux</productname> describes all the access
    control rules as relationships between a subject entity (typically,
    a client of the database) and an object entity (such as a database
    object), each of which is
    identified by a security label.  If access to an unlabeled object is
    attempted, the object is treated as if it were assigned the label
    <literal>unlabeled_t</literal>.
   </para>

   <para>
    Currently, <filename>sepgsql</filename> allows security labels to be
    assigned to schemas, tables, columns, sequences, views, and functions.
    When <filename>sepgsql</filename> is in use, security labels are
    automatically assigned