Re: SSL Mode

PostgreSQL is designed to _not_ require root access, so we just make
everything owned by the install user.  I don't see how group checks can
help there.  Also, there is no postgres group, at least by default, and
no special handling based on group, though we do allow group permissions
on the /tmp socket file.

I see what you mean by having a separate user who can change the ssl
key, but it it really doesn't work in our current setup, and requires
special permissions be set up by the administrator.

---------------------------------------------------------------------------

Radoslaw Stachowiak wrote:
> *** 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.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073