2011/1/6 KaiGai Kohei <kai...@ak.jp.nec.com>: >> 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.
OK. If there's an existing convention of calling things SE-<productname> then let's do the same thing here. As long as it's documented clearly it shouldn't be a problem. >> 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> Why does the user need to know about this at all? Doesn't make install put everything in the right place? >> 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. I'd prefer to have it in the actual documentation. I think SE-PostgreSQL is going to need a lot of documentation. A wiki page risks getting out of date or having the wrong information for the version the user has installed. 9.1 may be quite different from 9.2, for example. I wouldn't worry about the scale of the patch too much as far as documentation goes. In reviewing previous patches you've written, I've often cut large amounts of documentation that I didn't think were important enough to be worth including (and most of the contents of the upcoming features section falls into that category). But that doesn't really take that much time, and it's certainly a lot easier to remove some extra documentation than it is to write something that's missing. Most of what you have here right now describes why you might want to use this feature, rather than what the feature actually does. If you want to start by updating the wiki page, that's fine, and may be an easier way for us to collaborate than doing it by exchanging patches. But ultimately I think it needs to go in the docs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
