On Tue, Jan 15, 2013 at 3:02 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > This patch adds sepgsql the feature of name qualified creation label. > > Background, on creation of a certain database object, sepgsql assigns > a default security label according to the security policy that has a set of > rules to determine a label of new object. > Usually, a new object inherits its parent (e.g table is a parent of column) > object's label, unless it has a particular type_transition rule in the policy. > Type_transition rule allows to describe a particular security label as > default label of new object towards a pair of client and parent object. > For example, the below rule says columns constructed under the table > labeled as "sepgsql_table_t" by client with "staff_t" will have > "staff_column_t", instead of table's label. > TYPE_TRANSITION staff_t sepgsql_table_t:db_column staff_column_t; > > Recently, this rule was enhanced to take 5th argument for object name; > that enables to special case handling exceptionally. > It was originally designed to describe default security labels for files in > /etc directory, because many application put its own configuration files > here, thus, traditional type_transition rule was poor to describe all the > needed defaults. > On the other hand, we can port this concept of database system also. > One example is temporary objects being constructed under the pg_temp > schema. If we could assign a special default label on this, it allows > unprivileged users (who cannot create persistent tables) to create > temporary tables that has no risk of information leak to other users. > Otherwise, we may be able to assign a special security label on > system columns and so on. > > From the perspective of implementation on sepgsql side, all we need > to do is replace old security_compute_create_raw() interface by new > security_compute_create_name_raw(). > If here is no name qualified type_transition rules, it performs as if > existing API, so here is no backword compatible issue. > > This patch can be applied on the latest master branch.
This looks OK on a quick once-over, but should it update the documentation somehow? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
