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 to supported database objects at creation time.
    This label is called a default security label, and is decided according
    to the system security policy, which takes as input the creator's label,
    the label assigned to the new object's parent object and optionally name
    of the constructed object.
   </para>

   <para>
    A new database object basically inherits the security label of the parent
    object, except when the security policy has special rules known as
    type-transition rules, in which case a different label may be applied.
    For schemas, the parent object is the current database; for tables,
    sequences, views, and functions, it is the containing schema; for columns,
    it is the containing table.
   </para>
  </sect3>

  <sect3 id="sepgsql-features-dml-permissions">
   <title>DML Permissions</title>

   <para>
    For tables, <literal>db_table:select</literal>, <literal>db_table:insert</literal>,
    <literal>db_table:update</literal> or <literal>db_table:delete</literal> are
    checked for all the referenced target tables depending on the kind of
    statement; in addition, <literal>db_table:select</literal> is also checked for
    all the tables that contain columns referenced in the
    <literal>WHERE</literal> or <literal>RETURNING</literal> clause, as a data source
    for <literal>UPDATE</literal>, and so on.
   </para>

   <para>
    Column-level permissions will also be checked for each referenced column.
    <literal>db_column:select</literal> is checked on not only the columns being
    read using <literal>SELECT</literal>, but those being referenced in other DML
    statements; <literal>db_column:update</literal> or <literal>db_column:insert</literal>
    will also be checked for columns being modified by <literal>UPDATE</literal> or
    <literal>INSERT</literal>.
   </para>

   <para>
   For example, consider:
<synopsis>
UPDATE t1 SET x = 2, y = func1(y) WHERE z = 100;
</synopsis>

    Here, <literal>db_column:update</literal> will be checked for
    <literal>t1.x</literal>, since it is being updated,
    <literal>db_column:{select update}</literal> will be checked for
    <literal>t1.y</literal>, since it is both updated and referenced, and
    <literal>db_column:select</literal> will be checked for <literal>t1.z</literal>, since
    it is only referenced.
    <literal>db_table:{select update}</literal> will also be checked
    at the table level.
   </para>

   <para>
    For sequences, <literal>db_sequence:get_value</literal> is checked when we
    reference a sequence object using <literal>SELECT</literal>; however, note that we
    do not currently check permissions on execution of corresponding functions
    such as <literal>lastval()</literal>.
   </para>

   <para>
    For views, <literal>db_view:expand</literal> will be checked, then any other
    required permissions will be checked on the objects being
    expanded from the view, individually.
   </para>

   <para>
    For functions, <literal>db_procedure:{execute}</literal>