Message-Id: <email address hidden>
Date: Tue, 13 Sep 2005 15:37:51 +0200
From: Timo =?iso-8859-15?q?Weing=E4rtner?= <email address hidden>
To: Martin Pitt <email address hidden>,
<email address hidden>
Subject: Re: Bug#327901: postgresql-common: Fails after upgrade because of too strict checking of
permissions on SSL key file
Am Dienstag, 13. September 2005 07:35 schrieb Martin Pitt:
> Timo Weing=E4rtner [2005-09-12 22:46 +0200]:
> > (The key file is made immutable to keep cupsys from changing
> > permissions)
>
> Cupsys really shouldn't change the permissions of conffiles. Please
> file a serious bug against it.
> > If postgres thinks the file is insecure it could issue a warning, but
> > refusing to start is NOT OK.
>
> It has always been like this, this is not a new feature. However, I
> agree that the permission check should be more clever and take ACLs
> into account. I will try to improve the check.
That sounds good, but checking for maximum permissions of something in betw=
een=20
0440 and 0660 would be enough and you wont have to handle ACLs specially.
> > Finally I AM THE ADMIN and I know what I'm doing. I don't need any
> > program pretending to be more clever than me.
>
> I disagree. Even good admins make errors, and a program should not
> attempt to use an insecure SSL certificate. Once you have a
> world-readable private key, you should throw it away and generate a
> new one. Without a failure, you would probably never recognize it.
I was a bit angry when I wrote the bug report, sorry for that. I also made=
=20
errors (deleted the private key accidentally, one more reason to make it=20
immutable).
To have the admin recognize it, generating an email with something like=20
"postgres thinks the private key is insecure. to disable the warning change=
=20
option foo" would be enough.
> > There was no warning to check permissions before upgrading, so I lost
> > accounting data (not serious, it costs me no money).
>
> As I said, the upgrade did not introduce any new checks. The upgrade
> merely restarts the server. I suspect that your server had been
> running for a while, and at that time you introduced the ACLs.
I was sure I restarted postgres via its init script, but perhaps I was wron=
g.
> This causes no data loss, BTW.
In my case it did, because my accounting script relied on the availability =
of=20
the database server (on my list of things I need to change).
> As a quick workaround, you can hardllink or=20
Hard links won't work as the permissions or stored per inode, not per link.
> copy the certificate and set the permissions to postgres:postgres 0400
> (and adapt the path in postgresql.conf, of course).
I don't like duplicating things, because some copies may get forgotten.
As a workaround I disabled SSL (TCP was not active anyways).
Message-Id: <email address hidden> 15?q?Weing= E4rtner? = <email address hidden>
Date: Tue, 13 Sep 2005 15:37:51 +0200
From: Timo =?iso-8859-
To: Martin Pitt <email address hidden>,
<email address hidden>
Subject: Re: Bug#327901: postgresql-common: Fails after upgrade because of too strict checking of
permissions on SSL key file
--nextPart14059 02.FzFxCqVYyD "iso-8859- 15" Transfer- Encoding: quoted-printable Disposition: inline
Content-Type: text/plain;
charset=
Content-
Content-
Am Dienstag, 13. September 2005 07:35 schrieb Martin Pitt:
> Timo Weing=E4rtner [2005-09-12 22:46 +0200]:
> > (The key file is made immutable to keep cupsys from changing
> > permissions)
>
> Cupsys really shouldn't change the permissions of conffiles. Please
> file a serious bug against it.
See Bug #198803.
> > If postgres thinks the file is insecure it could issue a warning, but
> > refusing to start is NOT OK.
>
> It has always been like this, this is not a new feature. However, I
> agree that the permission check should be more clever and take ACLs
> into account. I will try to improve the check.
That sounds good, but checking for maximum permissions of something in betw=
een=20
0440 and 0660 would be enough and you wont have to handle ACLs specially.
> > Finally I AM THE ADMIN and I know what I'm doing. I don't need any
> > program pretending to be more clever than me.
>
> I disagree. Even good admins make errors, and a program should not
> attempt to use an insecure SSL certificate. Once you have a
> world-readable private key, you should throw it away and generate a
> new one. Without a failure, you would probably never recognize it.
I was a bit angry when I wrote the bug report, sorry for that. I also made=
=20
errors (deleted the private key accidentally, one more reason to make it=20
immutable).
To have the admin recognize it, generating an email with something like=20
"postgres thinks the private key is insecure. to disable the warning change=
=20
option foo" would be enough.
> > There was no warning to check permissions before upgrading, so I lost
> > accounting data (not serious, it costs me no money).
>
> As I said, the upgrade did not introduce any new checks. The upgrade
> merely restarts the server. I suspect that your server had been
> running for a while, and at that time you introduced the ACLs.
I was sure I restarted postgres via its init script, but perhaps I was wron=
g.
> This causes no data loss, BTW.
In my case it did, because my accounting script relied on the availability =
of=20
the database server (on my list of things I need to change).
> As a quick workaround, you can hardllink or=20
Hard links won't work as the permissions or stored per inode, not per link.
> copy the certificate and set the permissions to postgres:postgres 0400
> (and adapt the path in postgresql.conf, of course).
I don't like duplicating things, because some copies may get forgotten.
As a workaround I disabled SSL (TCP was not active anyways).
Timo
--nextPart14059 02.FzFxCqVYyD pgp-signature
Content-Type: application/
-----BEGIN PGP SIGNATURE-----
DJtY4AAoJEEn74F OC+06tF00H/ R7TTvZ/ q4hJFm4J3MopxvC x 5L6dx5H9eGdgxH6 PTKAJYBNdY94Z2i U4K+8N39XVqY3fh 6KTQ GKf3N8PRJ4jPv9T MM8pguft8XI7TXI iyrnJMwGYu/ brStG0T/ nmeJTZ6HCWfnpDt rjJYoQhXNnXEhW5 N4I2poJ+ A4yx66D6Ho/ 63LkKh DUem1VzT9AowIG6 8TvkoxoeDh24K7G 56e8vEbXg4kVLyM RkX8 Ab54xZFTa5g/ K70nr9sCWNZASrw 2LQmKPSxJJr2M33 92Q4yI=
Version: GnuPG v1.4.1 (GNU/Linux)
iQEcBAABAgAGBQJ
uo8UAahlro1HhGm
3mcPJxI3zG46qoX
cCRAS2od+
Ul935HtseZsyoAZ
ZLHpmpmpEEdj3Db
=ni0i
-----END PGP SIGNATURE-----
--nextPart14059 02.FzFxCqVYyD- -