Further sepgsql documentation cleanup.

diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
index 2829957ae30f2d6c736d5c6b23f0127a09e07003..9ef2bf9da820208c7fd9d9f8a10f028ae13e71e3 100644 (file)
--- a/doc/src/sgml/sepgsql.sgml
+++ b/doc/src/sgml/sepgsql.sgml
@@ -10,16 +10,17 @@
  
   sepgsql is a loadable module which supports label-based
   mandatory access control (MAC) based on SELinux security
-  policy.  This implementation is not complete, and primarily provides
-  protection for Data Manipulation Language statements (DML).  Support for
-  fine-grained access control of Data Definition Language (DDL) and Data
-  Control Language (DCL) statements may be added in a future release.
- 
- 
-  This extension won't build at all unless the installation was configured
-  with --with-selinux.
+  policy.
  
 
+ 
+   
+     This implementation has signification limitations, and does not enforce
+     mandatory access control for all actions.  See
+     .
+   
+ 
+
  
   Overview
 
@@ -59,48 +60,18 @@
   Installation
 
   
-   This module has several prerequisites.
+    This module can only be used on Linux 2.6.28
+    or higher with SELinux enabled.  It is not
+    available on any other platform, and must be explicitly enabled using
+    --with-selinux.  You will also need libselinux
+    2.0.93 or higher and selinux-policy 3.9.13 or higher
+    (some distributions may backport the necessary rules into older policy
+    versions).
   
 
-  
-   
-    Linux kernel
-    
-     
-      v2.6.28 or later with built with SELinux enabled
-     
-    
-   
-   
-    libselinux
-    
-     
-      v2.0.93 or later
-     
-     
-      This library provides a set of APIs to communicate with
-      SELinux in kernel.
-     
-    
-   
-   
-    selinux-policy
-    
-     
-      v3.9.13 or later
-     
-     
-      The default security policy provides a set of access control rules.
-      Some distributions may backport necessary rules to older policy versions.
-     
-    
-   
-  
   
-
-   sepgsql needs SELinux being
-   available on the platform. You can check the current setting using
-   sestatus.
+   The sestatus command allows you to check the status of
+   SELinux.
 
 $ sestatus
 SELinux status:                 enabled
@@ -115,41 +86,25 @@ Policy from config file:        targeted
   
 
   
-   At compile time, pass the --with-selinux option to
-   the configure script to enable this module.
-
-
-$ ./configure --enable-debug --enable-cassert --with-selinux
-$ make
-$ make install
-
-  
-
-  
-   Following initdb, add '$libdir/sepgsql'
-   to  in
-   the postgresql.conf.  Note that sepgsql
-   must be loaded at server startup.
+   To use this module, you must add include sepgsql
+   in .  The module will not
+   function if loaded in any other manner.  Once the module is loaded, you
+   should execute sepgsql.sql in each database.
+   This will install functions needed for security label management, and
+   assign initial security labels.
   
 
   
-   Next, load the sepgsql.sql script for each database.
-   It installs functions for security label management, and attempts to assign
-   initial labels to the target objects.
-  
-
-  
-   The following instruction assumes your installation is under the
-   /usr/local/pgsql directory, and the database cluster is in
-   /usr/local/pgsql/data. Adjust the paths shown below as
+   The following instructions that assume your installation is under the
+   /usr/local/pgsql directory. Adjust the paths shown below as
    appropriate for your installaton.
   
 
 
-$ initdb -D $PGDATA
+$ initdb
 $ vi $PGDATA/postgresql.conf
 $ for DBNAME in template0 template1 postgres; do
-  postgres --single -F -O -c exit_on_error=true -D $PGDATA $DBNAME \
+  postgres --single -F -O -c exit_on_error=true $DBNAME \
       < /usr/local/pgsql/share/contrib/sepgsql.sql > /dev/null
   done
 
@@ -317,77 +272,15 @@ $ restorecon -R /usr/local/pgsql/
     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.
-    The meaning of the term "parent object" varies by object class, as follows.
+    For schemas, the parent object is the current database; for columns, it
+    is the corresponding table; for tables, sequences, views, and functions,
+    it is the containing schema.
    
-
-   
-    
-     schema
-     
-      
-       The parent object is the current database.
-      
-     
-    
-    
-     table
-     
-      
-       The parent object is the containing schema.
-      
-     
-    
-    
-     column
-     
-      
-       The parent object is the table.
-      
-     
-    
-    
-     sequence
-     
-      
-       The parent object is the containing schema.
-      
-     
-    
-    
-     view
-     
-      
-       The parent object is the containing schema.
-      
-     
-    
-    
-     function
-     
-      
-       The parent object is the containing schema.
-      
-     
-    
-   
   
+
   
    DML Permissions
 
-   
-    This section introduces what permissions shall be checked on DML;
-    SELECT, INSERT, UPDATE and
-    DELETE.
-   
-
-   
-    DML statements are used to reference or modify contents within
-    the specified database objects; such as tables or columns.
-    The access rights of the client are checked on all the objects
-    mentioned in the given statement, and the kind of privileges checked
-    depend on the class of the object and the type of access.
-   
-
    
     For tables, db_table:select, db_table:insert,
     db_table:update or db_table:delete is
@@ -461,7 +354,6 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
    
 
    
-    Here are a few more corner cases.
     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
@@ -545,13 +437,13 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
   
    Miscellaneous
    
-    In this version, we reject the  command across
-    the board, because any module loaded could easily circumvent security
-    policy enforcement.
+    We reject the  command across the board, because
+    any module loaded could easily circumvent security policy enforcement.
    
 
   
  
+
  
   Limitations
 
@@ -649,7 +541,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
  
   Author
   
-   KaiGai Kohei ([email protected])
+   KaiGai Kohei [email protected]