addition or deletion of name entries within a particular schema.
</para>
<para>
- When a <literal>CREATE</> command is executed, <literal>create</> will
- be checked on the object being constructed for each object types.
- A default security label will be assigned to the new database object,
- and the <literal>create</> permission will be checked on the pair
- of security label of the client and the new object itself.
- We consider <xref linkend="sql-createtable"> to construct a table and
- underlying columns at the same time, so it requires the users to have
- permission to create both the table and its columns.
- </para>
- <para>
- A few additional checks are applied depending on object types.
- On <xref linkend="sql-createdatabase">, <literal>getattr</> permission
- will be checked on the source or template database of the new database,
- not only <literal>create</> on the new database.
- On creation of objects within a particular schema (tables, views,
- sequences and procedures), <literal>add_name</> will be also checked
- on the schema, not only <literal>create</> on the new object itself.
- On <xref linkend="sql-createfunction">, <literal>install</> permission
- will be checked if <literal>leakproof</> attribute was given, not only
- <literal>create</> on the new function. This permission will be also
- checked when user tries to turn on <literal>leakproof</> attribute
- using <xref linkend="sql-alterfunction"> command, with
- <literal>setattr</> permission on the function being altered.
+ Creating a new database object requires <literal>create</> permission.
+ <productname>SELinux</> 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>
+ <xref linkend="sql-createdatabase"> additionally requires
+ <literal>getattr</> permission for the source or template database.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Creating a schema object additionally requires <literal>add_name</>
+ 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</> additionally
+ requires <literal>install</> permission. (This permission is also
+ checked when <literal>LEAKPROOF</> is set for an existing function.)
+ </para>
+ </listitem>
+ </itemizedlist>
+
<para>
When <literal>DROP</> command is executed, <literal>drop</> will be
- checked on the object being removed for each object types. Permissions
- will be also checked for objects dropped indirectly via <literal>CASCADE</>.
- Deletion of objects contained within a particular schema (tables, views,
- sequences and procedures) additionally requires
- <literal>remove_name</> on the schema.
+ checked on the object being removed. Permissions will be also checked for
+ objects dropped indirectly via <literal>CASCADE</>. Deletion of objects
+ contained within a particular schema (tables, views, sequences and
+ procedures) additionally requires <literal>remove_name</> on the schema.
</para>
<para>
When <literal>ALTER</> command is executed, <literal>setattr</> will be
- checked on the object being modified for each object types.
- In addition, <literal>remove_name</> and <literal>add_name</>
- will be checked on the old and new schemas, respectively, when an
- object is moved to a new schema.
- For certain object types, additional checks are performed.
+ checked on the object being modified for each object types, except for
+ subsidiary objects such as the indexes or triggers of a table, where
+ permissions are instead checked on the parent object. In some cases,
+ additional permissions are required:
</para>
- <para>
- When objects that are subsidiary of other objects (such as a table's
- indexes or triggers) are created, dropped or altered,
- <literal>setattr</> permission will be checked on the main object,
- instead of the subsidiary object itself.
- </para>
-
- <para>
- When <xref linkend="sql-security-label"> is executed, <literal>setattr</>
- and <literal>relabelfrom</> will be checked on the object being relabeled
- with its old security label, then <literal>relabelto</> with the supplied
- new security label.
- </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Moving an object to a new schema additionally requires
+ <literal>remove_name</> permission on the old schema and
+ <literal>add_name</> permission on the new one.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Setting the <literal>LEAKPROOF</> attribute on a function requires
+ <literal>install</> permission.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Using <xref linkend="sql-security-label"> on an object additionally
+ requires <literal>relabelfrom</> permission for the object in
+ conjunction with its old security label and <literal>relabelto</>
+ permission for the object in conjunction with its new security label.
+ (In cases where multiple label providers are installed and the user
+ tries to set a security label, but it is not managed by
+ <productname>SELinux</>, only <literal>setattr</> should be checked here.
+ This is currently not done due to implementation restrictions.)
+ </para>
+ </listitem>
+ </itemizedlist>
- <para>
- In the case where multiple label providers are installed and the user tries
- to set a security label, but it is not managed by <productname>SELinux</>,
- only <literal>setattr</> should be checked here.
- This is currently not done due to implementation restrictions.
- </para>
</sect3>
<sect3>
projects / postgresql.git / commitdiff