Re: SE-PostgreSQL Specifications
От | Sam Mason |
---|---|
Тема | Re: SE-PostgreSQL Specifications |
Дата | |
Msg-id | 20090726113541.GT5407@samason.me.uk обсуждение исходный текст |
Ответ на | Re: SE-PostgreSQL Specifications (KaiGai Kohei <kaigai@kaigai.gr.jp>) |
Ответы |
Re: SE-PostgreSQL Specifications
Re: SE-PostgreSQL Specifications |
Список | pgsql-hackers |
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?). > For the security policy, I introduce it at the security model section: > > | Access control is conceptually to decide a set of allowed (or denied) > | actions between a certain subject (such as a database client) and an > | object (such as a table), and to apply the decision on user's requests. > | At the database privilege system, ACL stored in database objects itself > | holds a list of allowed actions to certain database roles, and it is > | applied on the user's request. > | SELinux also holds massive sets of allowed actions between a certain > | subject and a certain object, we call them security policy. > > Is it obscure? I find that somewhat opaque as well! sorry > At this point, the SELinux user's guide in Fedora is the most comprehensive > documentation. It is described from the viewpoint of SELinux users, not > experts or developers. > > http://docs.fedoraproject.org/selinux-user-guide/ OK, thanks! -- Sam http://samason.me.uk/
В списке pgsql-hackers по дате отправления: