Re: sepgsql contrib module

(2011/01/06 14:28), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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(at)ak(dot)jp(dot)nec(dot)com>