Re: SE-PostgreSQL Specifications - Mailing list pgsql-hackers
From | KaiGai Kohei |
---|---|
Subject | Re: SE-PostgreSQL Specifications |
Date | |
Msg-id | 4A6EAF6C.9050304@ak.jp.nec.com Whole thread Raw |
In response to | Re: SE-PostgreSQL Specifications (KaiGai Kohei <kaigai@kaigai.gr.jp>) |
Responses |
Re: SE-PostgreSQL Specifications
(Greg Williamson <gwilliamson39@yahoo.com>)
|
List | pgsql-hackers |
I revised the SE-PostgreSQL Specifications: http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft - Put several external link to introduce something too detail for PostgreSQL documentations. - Paid attention not to use undefined terminology, such as "security context", "security policy" and "mandatory access controls". - Revised whole of the composition in the "Brief overview" section. - Put an example of security policy rule. - "SECURITY_LABEL" option was replaced by "SECURITY_CONTEXT" to avoid meaningless confusion. I believe it become better than previous revision. Thanks, KaiGai Kohei wrote: > Sam Mason wrote: >> On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote: >>> Indeed, the draft used the term of "security context" with minimum >>> introductions, but not enough friendliness for database folks. >>> >>> The purpose of security context is an identifier of any subject and >>> object to describe them in the security policy. Because the security >>> policy is common for operating system, databases, x-window and others, >>> any managed database objects needs its security context. >>> >>> Anyway, I need to introduce them in the security model section. >> >> I'm coming to the conclusion that you really need to link to external >> material here; there must be good (and canonical) definitions of these >> things outside and because SE-PG isn't self contained I really think you >> need to link to them. >> >> This will be somewhat of a break from normal PG documentation because >> so far everything has been self contained, it's chosen its own >> interpretation of the SQL standard and it needs to document that. SE-PG >> will be interacting with much more code from outside and showing which >> parts of these are PG specific vs. which parts are common to all SELinux >> seems important. >> >> If you try to document *everything* you're going to be writing for years >> and give the impression that everything is implemented in SE-PG. A >> dividing line needs to be drawn between what is PG specific and what is >> SELinux (why not SEL?). > > It also seems to me reasonable suggestion. > > However, a reasonable amount (which should be adjusted under discussions) > of description should be self-contained. > For example, "security context is a formatted short string" is not enough > to understand why it is necessary and what is the purpose. > > As Robert suggested, a few example and definition of technical terms > will help database folks to understand what it is, even if self-contained > explanation is not comprehensive from viewpoint of security folks. > > Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
pgsql-hackers by date: