<!-- doc/src/sgml/dummy_seclabel.sgml -->

<sect1 id="dummy-seclabel" xreflabel="dummy_seclabel">
 <title>dummy_seclabel</title>

 <indexterm zone="dummy-seclabel">
  <primary>dummy_seclabel</primary>
 </indexterm>

 <para>
  The <filename>dummy_seclabel</> module exists only to support regression
  testing of the <command>SECURITY LABEL</> statement.  It is not intended
  to be used in production.
 </para>

 <sect2>
  <title>Rationale</title>

  <para>
   The <command>SECURITY LABEL</> statement allows the user to assign security
   labels to database objects; however, security labels can only be assigned
   when specifically allowed by a loadable module, so this module is provided
   to allow proper regression testing.
  </para>

  <para>
   Security label providers intended to be used in production will typically be
   dependent on a platform-specific feature such as
   <productname>SE-Linux</productname>.  This module is platform-independent,
   and therefore better-suited to regression testing.
  </para>
 </sect2>

 <sect2>
  <title>Usage</title>

  <para>
   Here's a simple example of usage:
  </para>

<programlisting>
# postgresql.conf
shared_preload_libraries = 'dummy_label'
</programlisting>

<programlisting>
postgres=# CREATE TABLE t (a int, b text);
CREATE TABLE
postgres=# SECURITY LABEL ON TABLE t IS 'classified';
SECURITY LABEL
</programlisting>

  <para>
   The <filename>dummy_seclabel</> module provides only four hardcoded
   labels: <literal>unclassified</>, <literal>classified</>,
   <literal>secret</>, and <literal>top secret</>.
   It does not allow any other strings as security labels.
  </para>
  <para>
   These labels are not used to enforce access controls.  They are only used
   to check whether the <command>SECURITY LABEL</> statement works as expected,
   or not.
  </para>
 </sect2>

 <sect2>
  <title>Author</title>

  <para>
   KaiGai Kohei <email>kaigai@ak.jp.nec.com</email>
  </para>
 </sect2>

</sect1>
