Обсуждение: SSL Mode
I cannot get the postmaster to start up in SSL mode. I receive the following error: bad permissions on private key file (/var/lib/pgsql/data/server.key) I've checked the permissions and everything seems to be fine. ls -al total 56 drwx------ 6 postgres postgres 4096 Dec 18 17:17 . drwxr--r-- 4 postgres postgres 4096 Dec 18 17:17 .. drwx------ 4 postgres postgres 4096 Dec 18 16:23 base drwx------ 2 postgres postgres 4096 Dec 18 17:17 global drwx------ 2 postgres postgres 4096 Dec 18 16:23 pg_clog -rw------- 1 postgres postgres 2404 Dec 18 16:41 pg_hba.conf -rw------- 1 postgres postgres 1441 Dec 18 16:23 pg_ident.conf -rw------- 1 postgres postgres 4 Dec 18 16:23 PG_VERSION drwx------ 2 postgres postgres 4096 Dec 18 16:23 pg_xlog -rw------- 1 postgres postgres 5224 Dec 18 17:17 postgresql.conf -rw------- 1 postgres postgres 20 Dec 18 17:16 postmaster.opts -rw-r--r-- 1 postgres postgres 3223 Dec 18 17:10 server.crt -rw-r--r-- 1 postgres postgres 887 Dec 18 17:10 server.key I'm using postgresql-7.3-2PGDG. Is this the correct list for this type of question? Thanks. -- Robert Abernethy IV Dynamic Edge, Inc. 734.975.0460
I think the file has to have _restricted_ permissions to be accepted.
The check is:
if (!S_ISREG(buf.st_mode) || (buf.st_mode & 0077) ||
buf.st_uid != getuid())
{
postmaster_error("bad permissions on private key file (%s)", fnbuf);
ExitPostmaster(1);
so my guess is that you have to remove group/other permissions on the
file.
---------------------------------------------------------------------------
Rob Abernethy IV wrote:
> I cannot get the postmaster to start up in SSL mode. I receive the following
> error:
>
> bad permissions on private key file (/var/lib/pgsql/data/server.key)
>
> I've checked the permissions and everything seems to be fine.
>
> ls -al
> total 56
> drwx------ 6 postgres postgres 4096 Dec 18 17:17 .
> drwxr--r-- 4 postgres postgres 4096 Dec 18 17:17 ..
> drwx------ 4 postgres postgres 4096 Dec 18 16:23 base
> drwx------ 2 postgres postgres 4096 Dec 18 17:17 global
> drwx------ 2 postgres postgres 4096 Dec 18 16:23 pg_clog
> -rw------- 1 postgres postgres 2404 Dec 18 16:41 pg_hba.conf
> -rw------- 1 postgres postgres 1441 Dec 18 16:23 pg_ident.conf
> -rw------- 1 postgres postgres 4 Dec 18 16:23 PG_VERSION
> drwx------ 2 postgres postgres 4096 Dec 18 16:23 pg_xlog
> -rw------- 1 postgres postgres 5224 Dec 18 17:17 postgresql.conf
> -rw------- 1 postgres postgres 20 Dec 18 17:16 postmaster.opts
> -rw-r--r-- 1 postgres postgres 3223 Dec 18 17:10 server.crt
> -rw-r--r-- 1 postgres postgres 887 Dec 18 17:10 server.key
>
> I'm using postgresql-7.3-2PGDG.
>
> Is this the correct list for this type of question? Thanks.
>
> --
> Robert Abernethy IV
> Dynamic Edge, Inc.
> 734.975.0460
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@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
That did it. Thanks.
--
Robert Abernethy IV
Dynamic Edge, Inc.
734.975.0460
> I think the file has to have _restricted_ permissions to be accepted.
>
> The check is:
>
> if (!S_ISREG(buf.st_mode) || (buf.st_mode & 0077) ||
> buf.st_uid != getuid())
> {
> postmaster_error("bad permissions on private key file
> (%s)", fnbuf); ExitPostmaster(1);
>
> so my guess is that you have to remove group/other permissions on the
> file.
>
> ---------------------------------------------------------------------------
>
> Rob Abernethy IV wrote:
> > I cannot get the postmaster to start up in SSL mode. I receive the following
> > error:
> >
> > bad permissions on private key file (/var/lib/pgsql/data/server.key)
> >
> > I've checked the permissions and everything seems to be fine.
> >
> > ls -al
> > total 56
> > drwx------ 6 postgres postgres 4096 Dec 18 17:17 .
> > drwxr--r-- 4 postgres postgres 4096 Dec 18 17:17 ..
> > drwx------ 4 postgres postgres 4096 Dec 18 16:23 base
> > drwx------ 2 postgres postgres 4096 Dec 18 17:17 global
> > drwx------ 2 postgres postgres 4096 Dec 18 16:23 pg_clog
> > -rw------- 1 postgres postgres 2404 Dec 18 16:41 pg_hba.conf
> > -rw------- 1 postgres postgres 1441 Dec 18 16:23 pg_ident.conf
> > -rw------- 1 postgres postgres 4 Dec 18 16:23 PG_VERSION
> > drwx------ 2 postgres postgres 4096 Dec 18 16:23 pg_xlog
> > -rw------- 1 postgres postgres 5224 Dec 18 17:17 postgresql.conf
> > -rw------- 1 postgres postgres 20 Dec 18 17:16 postmaster.opts
> > -rw-r--r-- 1 postgres postgres 3223 Dec 18 17:10 server.crt
> > -rw-r--r-- 1 postgres postgres 887 Dec 18 17:10 server.key
> >
> > I'm using postgresql-7.3-2PGDG.
> >
> > Is this the correct list for this type of question? Thanks.
> >
> > --
> > Robert Abernethy IV
> > Dynamic Edge, Inc.
> > 734.975.0460
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> > (send "unregister YourEmailAddressHere" to majordomo@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
"Rob Abernethy IV" <abernethy@dynedge.com> writes:
> I cannot get the postmaster to start up in SSL mode. I receive the following
> error:
> bad permissions on private key file (/var/lib/pgsql/data/server.key)
> -rw-r--r-- 1 postgres postgres 3223 Dec 18 17:10 server.crt
> -rw-r--r-- 1 postgres postgres 887 Dec 18 17:10 server.key
I think it wants the private key file to be mode 600 or less --- a
world-readable private key isn't very private, hmm?
regards, tom lane
On Mon, 23 Dec 2002, Tom Lane wrote: > "Rob Abernethy IV" <abernethy@dynedge.com> writes: > > I cannot get the postmaster to start up in SSL mode. I receive the following > > error: > > bad permissions on private key file (/var/lib/pgsql/data/server.key) > > > -rw-r--r-- 1 postgres postgres 3223 Dec 18 17:10 server.crt > > -rw-r--r-- 1 postgres postgres 887 Dec 18 17:10 server.key > > I think it wants the private key file to be mode 600 or less --- a > world-readable private key isn't very private, hmm? Is this a good candidate for error message improvement?
Dan Langille wrote: > On Mon, 23 Dec 2002, Tom Lane wrote: > > > "Rob Abernethy IV" <abernethy@dynedge.com> writes: > > > I cannot get the postmaster to start up in SSL mode. I receive the following > > > error: > > > bad permissions on private key file (/var/lib/pgsql/data/server.key) > > > > > -rw-r--r-- 1 postgres postgres 3223 Dec 18 17:10 server.crt > > > -rw-r--r-- 1 postgres postgres 887 Dec 18 17:10 server.key > > > > I think it wants the private key file to be mode 600 or less --- a > > world-readable private key isn't very private, hmm? > > Is this a good candidate for error message improvement? Yes. I will take care of it. -- 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
*** Bruce Momjian <pgman@candle.pha.pa.us> [13:42 Mon 23.Dec]:
> > > > -rw-r--r-- 1 postgres postgres 3223 Dec 18 17:10 server.crt
> > > > -rw-r--r-- 1 postgres postgres 887 Dec 18 17:10 server.key
> > >
> > > I think it wants the private key file to be mode 600 or less --- a
> > > world-readable private key isn't very private, hmm?
> >
> > Is this a good candidate for error message improvement?
>
> Yes. I will take care of it.
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. Root is an example of user
which has right to change keys. group readable flag is necesary for
postgres for accessing it, while write permission is not.
its not possible to use such protection schema with current pgsql, while
protection level is the same with both solution.
.radek.
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.
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.
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 :-().
regards, tom lane
*** 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.
Patch attached. Will appear in 7.3.2 and 7.4. --------------------------------------------------------------------------- Bruce Momjian wrote: > Dan Langille wrote: > > On Mon, 23 Dec 2002, Tom Lane wrote: > > > > > "Rob Abernethy IV" <abernethy@dynedge.com> writes: > > > > I cannot get the postmaster to start up in SSL mode. I receive the following > > > > error: > > > > bad permissions on private key file (/var/lib/pgsql/data/server.key) > > > > > > > -rw-r--r-- 1 postgres postgres 3223 Dec 18 17:10 server.crt > > > > -rw-r--r-- 1 postgres postgres 887 Dec 18 17:10 server.key > > > > > > I think it wants the private key file to be mode 600 or less --- a > > > world-readable private key isn't very private, hmm? > > > > Is this a good candidate for error message improvement? > > Yes. I will take care of it. > > -- > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@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 Index: src/backend/libpq/be-secure.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/libpq/be-secure.c,v retrieving revision 1.20 diff -c -c -r1.20 be-secure.c *** src/backend/libpq/be-secure.c 18 Dec 2002 13:15:12 -0000 1.20 --- src/backend/libpq/be-secure.c 23 Dec 2002 22:13:12 -0000 *************** *** 616,622 **** if (!S_ISREG(buf.st_mode) || (buf.st_mode & 0077) || buf.st_uid != getuid()) { ! postmaster_error("bad permissions on private key file (%s)", fnbuf); ExitPostmaster(1); } if (!SSL_CTX_use_PrivateKey_file(SSL_context, fnbuf, SSL_FILETYPE_PEM)) --- 616,624 ---- if (!S_ISREG(buf.st_mode) || (buf.st_mode & 0077) || buf.st_uid != getuid()) { ! postmaster_error("bad permissions on private key file (%s)\n" ! "File must be owned by the proper user and must have no permissions for\n" ! "\"group\" or \"other\".", fnbuf); ExitPostmaster(1); } if (!SSL_CTX_use_PrivateKey_file(SSL_context, fnbuf, SSL_FILETYPE_PEM))
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
On Mon, 23 Dec 2002, Bruce Momjian wrote: > Patch attached. Will appear in 7.3.2 and 7.4. Looks good to me. Thank you.
On Mon, 23 Dec 2002, Bruce Momjian wrote: > > 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. FWIW, I know the FreeBSD port creates both a pgsql user and a pgsql group. I have seen evidence that some Linux distributions create a postgres user.
Dan Langille wrote: > On Mon, 23 Dec 2002, Bruce Momjian wrote: > > > > > 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. > > FWIW, I know the FreeBSD port creates both a pgsql user and a pgsql group. > I have seen evidence that some Linux distributions create a postgres user. Yes, that is true, and if they want to patch be-secure.c, that is fine. However, we don't _assume_ such things exist, and don't require them. That is the (secure) key. ;-) -- 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
Dan Langille <dan@langille.org> writes:
> FWIW, I know the FreeBSD port creates both a pgsql user and a pgsql group.
> I have seen evidence that some Linux distributions create a postgres user.
There are a lot of Unixen in which adduser (or local equivalent) by
default will create a group for each user. However, there are also a
lot of Unixen in which it won't.
It's also worth pointing out that the server.key file lives in $PGDATA,
which we *also* enforce no-group-or-world permissions on. To make
server.key editable by (non-root) users other than postgres, we'd have
to rethink the permissions for $PGDATA as well as server.key itself.
I am really hesitant to weaken those permission checks, though.
regards, tom lane