Re: [HACKERS] What goes into the security doc?

Tom Lane writes:

> As I think Peter is trying to point out, you could almost get the same
> result just by having a fat index entry under "security", but I think
> people are more likely to notice a chapter or section in the Admin Guide
> with such a title.  Also, once we have such a chapter, we might find it
> reads more naturally to move some of the existing discussions into it,
> leaving only a cross-reference where the material is now.

These are the topics that Dan has identified so far:

file security
database users and privileges
client authentication
libpq password files
external libraries

It makes no sense to put all these topics into one chapter, because they
have nothing in common (except "security"): they apply in different stages
of PostgreSQL use, they are managed by different programs and
environments, and they affect different people.

From that point of view, we already have security documentation:

The chapter "Server Run-time Environment" (currently ch.16) covers
security aspects for system administrators when setting up a server.

The chapter "Database Users and Privileges" (ch. 17) covers security
aspects for database administrators on the SQL level.

The chapter "Client Authentication" (ch. 18) covers security aspects
covers security aspects for database/system administrators with file
system access (depends on local policies who does that).

The section "libpq"/"The Password File" covers one particular aspect of
security of libpq applications.  (There are certainly more interesting
security aspects with libpq applications.  The password file is pretty
uninteresting, because if you don't secure it it's ignored anyway.)

Note that chapters 17 and 18 are exclusively dedicated to security -- you
can't even claim to miss it in the other material, and unless you don't
know what "privileges" and "authentication" are, you can't even miss them
in the table of contents.  And if you start reading chapter 16, the first
two sections are all about securing the server.

The issue that started this was that there was not enough documentation
about choosing good passwords and preferably not using passwords over
non-SSL connections over public networks.  I agree that this could be
improved, and it could be done by regrouping some of the above material.
But we don't need a section that just points to other sections, because
that doesn't improve the substance of the material.  On the contrary, it
is known to confuse and annoy readers.

--
Peter Eisentraut   peter_e@gmx.net