*** Tom Lane <tgl@sss.pgh.pa.us> [14:45 Mon 23.Dec]:
> Radoslaw Stachowiak <radek@alter.pl> writes:
> > and one more suggestion, as this feature is a little bit to strong IMHO.
>
> > Common practice for such files (private keys) is to make them owned by
> > root user and postgres group with 640 mode.
>
> I don't think that's either common practice or a good idea. For one
> thing, it presumes that there *is* a postgres group; which is not a
> requirement we ever had before. For another, root can read or write the
> file if she chooses regardless of ownership or permissions, so it's not
> like doing it that way gains anything.
not true. as i wrote above, 'root' was just example. its just user which
has right to manage ssl keys. This example can be also 'remapped' to
permission 660 (or 460) where owner is postgres, and group is a special
manage group. Current approach blocks such uses, and forces to use
postgres, means giving more power for task which doesnt require it, and,
whats more important, task which is in fact from other 'problem-space'.
so its not 'complain' with least-privilege rule.
> As a counterexample, on a setup like mine (HP-UX), all normal users are
> members of group "users" and so group readability is not much safer than
> world readability. If Postgres neglected to complain about mode 640
> then there'd be little point in having a file-security check at all, on
> this system.
although as i pointed earlier, simple 600 check does not give
more security than other schemas which can be deployed on unix
permissions. in fact it can give _false_ sense of security which is
worse.
> IMHO the existing check is just fine, although the complaint message
> could be a lot more specific (it looks to me like three distinctly
> different sanity checks are being folded into one error message :-().
more meaningful message is highly appreciated :)
dont get me wrong, what I like to express is that current schema dont
give more security while blocks some complicated/creative realworld
permission situations.
.radek.
