postgresql-common: Fails after upgrade because of too strict checking of permissions on SSL key file
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
postgresql-common (Debian) |
Fix Released
|
Unknown
|
|||
postgresql-common (Ubuntu) |
Invalid
|
High
|
Martin Pitt |
Bug Description
Automatically imported from Debian bug report #327901 http://
Debian Bug Importer (debzilla) wrote : | #1 |
Debian Bug Importer (debzilla) wrote : | #2 |
Message-Id: <email address hidden>
Date: Mon, 12 Sep 2005 22:46:14 +0200
From: Timo =?iso-8859-
To: "Debian Bug Tracking System" <email address hidden>
Subject: postgresql-common: Fails after upgrade because of too strict checking of permissions on SSL
key file
--nextPart23832
Content-Type: text/plain;
charset=
Content-
Content-
Package: postgresql-common
Version: 25
Severity: grave
Justification: causes non-serious data loss
After upgrade from version 23 postgres-8.0 fails to start with:
=2D--8<---8<---
=46ATAL: unsichere Berechtigungen f=FCr private Schl=FCsseldatei =BB/var/l=
ib/postgresql/
DETAIL: Die Datei muss dem Datenbankbenutzer geh=F6ren und keine Berechtig=
ungen f=FCr =BBGruppe=AB oder =BBAndere=AB haben.
=2D--8<---8<---
I don't want to try it with other locale settings because I don't want
to loose more accounting data.
It sais "isecure permissions" and wants the file to be owned by the
database user an have maximum permissions of 0700.
My permissions are:
=2D--8<---8<---
# file: etc/ssl/
# owner: root
# group: root
user::r--
user:postgres:r--
user:Debian-
group::---
mask::r--
other::---
=2D--8<---8<---
(The key file is made immutable to keep cupsys from changing
permissions)
If postgres thinks the file is insecure it could issue a warning, but
refusing to start is NOT OK.
=46inally I AM THE ADMIN and I know what I'm doing. I don't need any
program pretending to be more clever than me.
There was no warning to check permissions before upgrading, so I lost
accounting data (not serious, it costs me no money).
Timo Weing=E4rtner
=2D- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2-swsusp2
Locale: LANG=3Dde_DE@euro, LC_CTYPE=
Versions of packages postgresql-common depends on:
ii adduser 3.67 Add and remove users and groups
Versions of packages postgresql-common recommends:
ii openssl 0.9.7e-3 Secure Socket Layer (SSL) bina=
ry a
=2D- no debconf information
--nextPart23832
Content-Type: application/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iQEcBAABAgAGBQJ
udBROTgFr87009g
m55qG9roneV5C6n
CRzdq2JUmQ1lH5i
SrB+rmf/
QHwDEKv6xQhsxB4
=fOEE
-----END PGP SIGNATURE-----
--nextPart23832
In Debian Bug tracker #327901, Martin Pitt (pitti) wrote : Re: Bug#327901: postgresql-common: Fails after upgrade because of too strict checking of permissions on SSL key file | #3 |
reassign 327901 postgresql-8.0 8.0.1-1
retitle 327901 postgresql-8.0: SSL cert permission check does not respect ACLs
severity important
thanks
Hi Timo!
Timo Weingärtner [2005-09-12 22:46 +0200]:
> ---8<---8<---
> FATAL: unsichere Berechtigungen für private Schlüsseldatei »/var/lib/
> DETAIL: Die Datei muss dem Datenbankbenutzer gehören und keine Berechtigungen für »Gruppe« oder »Andere« haben.
> ---8<---8<---
>
> I don't want to try it with other locale settings because I don't want
> to loose more accounting data.
That's ok, I'm German. :-)
> It sais "isecure permissions" and wants the file to be owned by the
> database user an have maximum permissions of 0700.
Right, but that has always been the case with postgresql-8.0.
postgresql-common does not do this check, it is done by the postgresql
server itself.
> My permissions are:
>
> ---8<---8<---
> # file: etc/ssl/
> # owner: root
> # group: root
> user::r--
> user:postgres:r--
> user:Debian-
> group::---
> mask::r--
> other::---
> ---8<---8<---
>
> (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.
> 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.
> 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. This
causes no data loss, BTW. As a quick workaround, you can hardllink or
copy the certificate and set the permissions to postgres:postgres 0400
(and adapt the path in postgresql.conf, of course).
Thanks for the report,
Martin
--
Martin Pitt http://
Ubuntu Developer http://
Debian Developer http://
In Debian Bug tracker #327901, Martin Pitt (pitti) wrote : severity of 327901 is important | #4 |
# Automatically generated email from bts, devscripts version 2.8.14
severity 327901 important
Martin Pitt (pitti) wrote : | #5 |
Please see the Debian bug followup, this is neither a regression, nor a grave
bug. No need to track this in two different places.
Am Dienstag, 13. September 2005 07:35 schrieb Martin Pitt:
> Timo Weingärtner [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 between
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
errors (deleted the private key accidentally, one more reason to make it
immutable).
To have the admin recognize it, generating an email with something like
"postgres thinks the private key is insecure. to disable the warning change
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 wrong.
> This causes no data loss, BTW.
In my case it did, because my accounting script relied on the availability of
the database server (on my list of things I need to change).
> As a quick workaround, you can hardllink or
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
In Debian Bug tracker #327901, Martin Pitt (pitti) wrote : Bug#327901: fixed in postgresql-8.0 8.0.3-16 | #7 |
Source: postgresql-8.0
Source-Version: 8.0.3-16
We believe that the bug you reported is fixed in the latest version of
postgresql-8.0, which is due to be installed in the Debian FTP archive:
libecpg-
to pool/main/
libecpg-
to pool/main/
libecpg5_
to pool/main/
libpgtypes2_
to pool/main/
libpq-dev_
to pool/main/
libpq4_
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Martin Pitt <email address hidden> (supplier of updated postgresql-8.0 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Wed, 21 Sep 2005 23:20:27 +0200
Source: postgresql-8.0
Binary: postgresql-
Architecture: source i386 all
Version: 8.0.3-16
Distribution: unstable
Urgency: medium
Maintainer: Martin Pitt <email address hidden>
Changed-By: Martin Pitt <email address hidden>
Description:
libecpg-compat2 - older version of run-time library for ECPG programs
libecpg-dev - development files for ECPG (Embedded PostgreSQL for C)
libecpg5 - run-time library for ECPG programs
libpgtypes2 - shared library libpgtypes for PostgreSQL 8.0
libp...
Debian Bug Importer (debzilla) wrote : | #8 |
Message-ID: <email address hidden>
Date: Tue, 13 Sep 2005 07:35:51 +0200
From: Martin Pitt <email address hidden>
To: Timo =?iso-8859-
<email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#327901: postgresql-common: Fails after upgrade because of too strict checking of
permissions on SSL key file
--huq684BweRXVnRxX
Content-Type: text/plain; charset=iso-8859-1
Content-
Content-
reassign 327901 postgresql-8.0 8.0.1-1
retitle 327901 postgresql-8.0: SSL cert permission check does not respect A=
CLs
severity important
thanks
Hi Timo!
Timo Weing=E4rtner [2005-09-12 22:46 +0200]:
> ---8<---8<---
> FATAL: unsichere Berechtigungen f=FCr private Schl=FCsseldatei =BB/var/l=
ib/postgresql/
> DETAIL: Die Datei muss dem Datenbankbenutzer geh=F6ren und keine Berecht=
igungen f=FCr =BBGruppe=AB oder =BBAndere=AB haben.
> ---8<---8<---
>=20
> I don't want to try it with other locale settings because I don't want
> to loose more accounting data.
That's ok, I'm German. :-)
> It sais "isecure permissions" and wants the file to be owned by the
> database user an have maximum permissions of 0700.
Right, but that has always been the case with postgresql-8.0.
postgresql-common does not do this check, it is done by the postgresql
server itself.
> My permissions are:
>=20
> ---8<---8<---
> # file: etc/ssl/
> # owner: root
> # group: root
> user::r--
> user:postgres:r--
> user:Debian-
> group::---
> mask::r--
> other::---
> ---8<---8<---
>=20
> (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.
> 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.
> 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. This
causes no data loss, BTW. As a quick workaround, you can hardllink or
copy the certificate and set the permissions to postgres:postgres 0400
(and adapt the path in postgresql.conf, of course).
Thanks for the report,
Martin
--=20
Martin Pitt http://
Ubuntu Developer http://
Debian Developer http://
--huq68...
Debian Bug Importer (debzilla) wrote : | #9 |
Message-Id: <email address hidden>
Date: Tue, 13 Sep 2005 07:50:11 +0200
From: Martin Pitt <email address hidden>
To: <email address hidden>
Subject: severity of 327901 is important
# Automatically generated email from bts, devscripts version 2.8.14
severity 327901 important
Debian Bug Importer (debzilla) wrote : | #10 |
Message-Id: <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
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
Content-Type: application/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iQEcBAABAgAGBQJ
uo8UAah...
Debian Bug Importer (debzilla) wrote : | #11 |
Message-Id: <email address hidden>
Date: Wed, 21 Sep 2005 14:47:11 -0700
From: Martin Pitt <email address hidden>
To: <email address hidden>
Subject: Bug#327901: fixed in postgresql-8.0 8.0.3-16
Source: postgresql-8.0
Source-Version: 8.0.3-16
We believe that the bug you reported is fixed in the latest version of
postgresql-8.0, which is due to be installed in the Debian FTP archive:
libecpg-
to pool/main/
libecpg-
to pool/main/
libecpg5_
to pool/main/
libpgtypes2_
to pool/main/
libpq-dev_
to pool/main/
libpq4_
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
postgresql-
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Martin Pitt <email address hidden> (supplier of updated postgresql-8.0 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Wed, 21 Sep 2005 23:20:27 +0200
Source: postgresql-8.0
Binary: postgresql-
Architecture: source i386 all
Version: 8.0.3-16
Distribution: unstable
Urgency: medium
Maintainer: Martin Pitt <email address hidden>
Changed-By: Martin Pitt <email address hidden>
Description:
libecpg-compat2 - older version of run-tim...
Automatically imported from Debian bug report #327901 http:// bugs.debian. org/327901