diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
index 2829957ae30f2d6c736d5c6b23f0127a09e07003..9ef2bf9da820208c7fd9d9f8a10f028ae13e71e3 100644
--- 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 (kaigai@ak.jp.nec.com)
+ KaiGai Kohei kaigai@ak.jp.nec.com