sepgsql: Documentation improvements.

Fixes by me, per griping by Thom Brown.

diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
index 7c7f953f9191ab6a18b5282780d68ccb01cd53b8..da0915bff3a2954a40f8da15750982a334e30b43 100644 (file)
--- a/doc/src/sgml/sepgsql.sgml
+++ b/doc/src/sgml/sepgsql.sgml
@@ -422,69 +422,85 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
     addition or deletion of name entries within a particular schema.
    
    
-    When a CREATE command is executed, 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 create permission will be checked on the pair
-    of security label of the client and the new object itself.
-    We consider  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.
-   
-   
-    A few additional checks are applied depending on object types.
-    On , getattr permission
-    will be checked on the source or template database of the new database,
-    not only create on the new database.
-    On creation of objects within a particular schema (tables, views,
-    sequences and procedures), add_name will be also checked
-    on the schema, not only create on the new object itself.
-    On , install permission
-    will be checked if leakproof attribute was given, not only
-    create on the new function. This permission will be also
-    checked when user tries to turn on leakproof attribute
-    using  command, with
-    setattr permission on the function being altered.
+    Creating a new database object requires create permission.
+    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:
    
 
+   
+    
+     
+       additionally requires
+      getattr permission for the source or template database.
+     
+    
+    
+     
+      Creating a schema object additionally requires add_name
+      permission on the parent schema.
+     
+    
+    
+     
+      Creating a table additionally requires permission to create each
+      individual table column, just as if each table column were a
+      separate top-level object.
+     
+    
+    
+     
+      Creating a function marked as LEAKPROOF additionally
+      requires install permission.  (This permission is also
+      checked when LEAKPROOF is set for an existing function.)
+     
+    
+   
+
    
     When DROP command is executed, drop will be
-    checked on the object being removed for each object types.  Permissions
-    will be also checked for objects dropped indirectly via CASCADE.
-    Deletion of objects contained within a particular schema (tables, views,
-    sequences and procedures) additionally requires
-    remove_name on the schema.
+    checked on the object being removed.  Permissions will be also checked for
+    objects dropped indirectly via CASCADE.  Deletion of objects
+    contained within a particular schema (tables, views, sequences and
+    procedures) additionally requires remove_name on the schema.
    
 
    
     When ALTER command is executed, setattr will be
-    checked on the object being modified for each object types. 
-    In addition, remove_name and 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:
    
 
-   
-    When objects that are subsidiary of other objects (such as a table's
-    indexes or triggers) are created, dropped or altered,
-    setattr permission will be checked on the main object,
-    instead of the subsidiary object itself.
-   
-
-   
-    When  is executed, setattr
-    and relabelfrom will be checked on the object being relabeled
-    with its old security label, then relabelto with the supplied
-    new security label.
-   
+   
+    
+     
+      Moving an object to a new schema additionally requires
+      remove_name permission on the old schema and
+      add_name permission on the new one.
+     
+    
+    
+     
+      Setting the LEAKPROOF attribute on a function requires
+      install permission.
+     
+    
+    
+     
+      Using  on an object additionally
+      requires relabelfrom permission for the object in
+      conjunction with its old security label and 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
+      SELinux, only setattr should be checked here.
+      This is currently not done due to implementation restrictions.)
+     
+    
+   
 
-   
-    In the case where multiple label providers are installed and the user tries
-    to set a security label, but it is not managed by SELinux,
-    only setattr should be checked here.
-    This is currently not done due to implementation restrictions.
-