From 2a3db8cec24d0c95136b74b305bf1f1e41615a4d Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Thu, 28 Mar 2013 15:55:44 -0400 Subject: [PATCH] sepgsql: Documentation improvements. Fixes by me, per griping by Thom Brown. --- doc/src/sgml/sepgsql.sgml | 120 +++++++++++++++++++++----------------- 1 file changed, 68 insertions(+), 52 deletions(-) diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml index 7c7f953f91..da0915bff3 100644 --- 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. - + + + + 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.) + + + - - 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. - - - - 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. -