Re: sepgsql contrib module - Mailing list pgsql-hackers

(2011/01/06 14:28), Robert Haas wrote:
> 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.  :-)
> 
Thanks for your reviewing in spite of large chunk.

> 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.
> 
In some previous cases when SELinux model was ported to other systems,
its project was named as SE-(other system), such as SE-BSD, SE-X, etc...
I named it according to this convention, however, it is indeed uncertain
whether 'sepgsql' follows on the convention in pgsql side.

I don't think it is a strong reason why the module is named as 'sepgsql'
instead of 'selinux'. In advertisement context, we can just call it as
SE-PostgreSQL.

> 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.
> 
Yes, it means the sharedir being configured.

I found the following description at the installation.sgml.
I should put this kind of mention on the documentation.

|  <para>
|   These instructions assume that your existing installation is under the
|   <filename>/usr/local/pgsql</> directory, and that the data area is in
|   <filename>/usr/local/pgsql/data</>.  Substitute your paths
|   appropriately.
|  </para>

> 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.
> 
OK, I'll try to find up similar description then fix up both of the
code and documentation.

> 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.
> 
OK, I'll replace an itemization of limitations in this version.

> 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?
> 
I guess these detailed description makes amount of this chapter
disproportionally increase in the future version.
My preference is wikipage to provide this kind of detailed information.
 http://wiki.postgresql.org/wiki/SEPostgreSQL

The contents of above wikipage is now obsoleted, because it assumed
SELinux support as a built-in feature. But it is a good time to fix
up the description.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>