(2011/01/06 14:28), Robert Haas wrote: > 2011/1/5 KaiGai Kohei<kai...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
