<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> will be checked when
    user tries to execute a function as a part of query, or using fast-path
    invocation. If this function is a trusted procedure, it also checks
    <literal>db_procedure:{entrypoint}</literal> permission to check whether it
    can perform as entry point of trusted procedure.
   </para>

   <para>
    In order to access any schema object, <literal>db_schema:search</literal>
    permission is required on the containing schema.  When an object is
    referenced without schema qualification, schemas on which this
    permission is not present will not be searched (just as if the user did
    not have <literal>USAGE</literal> privilege on the schema).  If an explicit schema
    qualification is present, an error will occur if the user does not have
    the requisite permission on the named schema.
   </para>

   <para>
    The client must be allowed to access all referenced tables and
    columns, even if they originated from views which were then expanded,
    so that we apply consistent access control rules independent of the manner
    in which the table contents are referenced.
   </para>

   <para>
    The default database privilege system allows database superusers to
    modify system catalogs using DML commands, and reference or modify
    toast tables.  These operations are prohibited when
    <filename>sepgsql</filename> is enabled.
   </para>
  </sect3>

  <sect3 id="sepgsql-features-ddl-permissions">
   <title>DDL Permissions</title>
   <para>
    <productname>SELinux</productname> defines several permissions to control common
    operations for each object type; such as creation, alter, drop and
    relabel of security label. In addition, several object types have
    special permissions to control their characteristic operations; such as
    addition or deletion of name entries within a particular schema.
   </para>
   <para>
    Creating a new database object requires <literal>create</literal> permission.
    <productname>SELinux</productname> will grant or deny this permission based on the
    client's security label and the proposed security label for the new
    object.  In some cases, additional privileges are required:
   </para>

   <itemizedlist>
    <listitem>
     <para>
      <link linkend="sql-createdatabase"><command>CREATE DATABASE</command></link> additionally requires
      <literal>getattr</literal> permission for the source or template database.
     </para>
    </listitem>
    <listitem>
     <para>
      Creating a schema object additionally requires <literal>add_name</literal>
      permission on the parent schema.
     </para>
    </listitem>
    <listitem>
     <para>
      Creating a table additionally requires permission to create each
      individual table column, just as if each table column were a
      separate top-level object.
     </para>
    </listitem>
    <listitem>
     <para>
      Creating a function marked as <literal>LEAKPROOF</literal> additionally
      requires <literal>install</literal>