Re: sepgsql contrib module - Mailing list pgsql-hackers

From Robert Haas
Subject Re: sepgsql contrib module
Date
Msg-id AANLkTinsfHoXOgxSJxb0YHikGMHzvBNRcz+jaz+rJ9AO@mail.gmail.com
Whole thread Raw
In response to Re: sepgsql contrib module  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: sepgsql contrib module  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List pgsql-hackers
2011/1/5 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> The attached patch is the modular version of SE-PostgreSQL (take.2).

I'm reading through the documentation and so far it looks pretty
reasonable.  But I have some questions and suggested changes, of
course.  :-)

1. Why is sepgsql the right name for this module, as opposed to, say,
selinux?  We don't call the cube module cubepgsql, or the hstore
module hstorepgsql.  Maybe there's a reason why this case is
different, but I'm not sure.

2. The docs contains some references to /usr/local/pgsql/share..  Does
this really mean "whatever sharedir you established when you ran
configure", i.e. the output of pg_config --sharedir?  I hope so.

3. The language for the sepgsql.permissive GUC suggests that it's
PGC_POSTMASTER, but I'd think PGC_SIGHUP ought to be sufficient.
Either way, please copy the appropriate language from some existing
GUC of the same type instead of inventing a new way to say it.  I also
have no idea what "because it invalidates all the inefficient stuff"
means.

4. Please remove the upcoming features section of the documentation.
This material is appropriate for a page on the wiki, but shouldn't be
part of the official documentation.  Instead, you might want to have a
*short* "Limitations" section.

5. I'm not too sure about this one, but I think it might be good to
elaborate on what we mean by respecting the system SE-Linux policy.
What kinds of objects do we support checks on?  What sorts of checks?
What kind of access can we allow/deny?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Avoiding rewrite in ALTER TABLE ALTER TYPE
Next
From: Noah Misch
Date:
Subject: Re: Avoiding rewrite in ALTER TABLE ALTER TYPE