postgresql-common: Fails after upgrade because of too strict checking of permissions on SSL key file

Automatically imported from Debian bug report #327901 http://bugs.debian.org/327901

Message-Id: <email address hidden>
Date: Mon, 12 Sep 2005 22:46:14 +0200
From: Timo =?iso-8859-1?q?Weing=E4rtner?= <email address hidden>
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

--nextPart2383273.Tpv9PSYIfr
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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/8.0/main/server.key=AB
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/private/server.tiwe.homelinux.org_key.pem
# owner: root
# group: root
user::r--
user:postgres:r--
user:Debian-exim:r--
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=3Dde_DE@euro (charmap=3DISO-8859-15)

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

--nextPart2383273.Tpv9PSYIfr
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iQEcBAABAgAGBQJDJekdAAoJEEn74FOC+06t0aYH/RXG5NixPnZuRjsXWLDPIObS
udBROTgFr87009g1oV4SW9MWYX/Xi2bhhruUBDdheRgvq4jbxfSVptp7pgQjA2Bb
m55qG9roneV5C6nDcPCz93SJJftikOSptkxXcK7LWl2i55KWauFlwpjAdOzjTVHQ
CRzdq2JUmQ1lH5iBd0N3ULXdG16jMjhZs661RI2b3ZvOU3GVJ1HlGEw1BsLjl8+e
SrB+rmf/tH57OTAkvx2EtxlORFIYXXQcpeIi6Uy5/5Wd9S8Dd3wyte8SJO3WO/vf
QHwDEKv6xQhsxB4FENsUi4O78Pb03vxpjpAzEaukpsXf+LhzMCeoiAqJquet5IE=
=fOEE
-----END PGP SIGNATURE-----

--nextPart2383273.Tpv9PSYIfr--

Please see the Debian bug followup, this is neither a regression, nor a grave
bug. No need to track this in two different places.

Message-ID: <email address hidden>
Date: Tue, 13 Sep 2005 07:35:51 +0200
From: Martin Pitt <email address hidden>
To: Timo =?iso-8859-1?Q?Weing=E4rtner?= <email address hidden>,
 <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-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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/8.0/main/server.key=AB
> 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/private/server.tiwe.homelinux.org_key.pem
> # owner: root
> # group: root
> user::r--
> user:postgres:r--
> user:Debian-exim:r--
> 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://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian Developer http://www.debian.org

--huq68...

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

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

--nextPart1405902.FzFxCqVYyD
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

--nextPart1405902.FzFxCqVYyD
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iQEcBAABAgAGBQJDJtY4AAoJEEn74FOC+06tF00H/R7TTvZ/q4hJFm4J3MopxvCx
uo8UAah...

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-compat2_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/libecpg-compat2_8.0.3-16_i386.deb
libecpg-dev_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/libecpg-dev_8.0.3-16_i386.deb
libecpg5_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/libecpg5_8.0.3-16_i386.deb
libpgtypes2_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/libpgtypes2_8.0.3-16_i386.deb
libpq-dev_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/libpq-dev_8.0.3-16_i386.deb
libpq4_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/libpq4_8.0.3-16_i386.deb
postgresql-8.0_8.0.3-16.diff.gz
  to pool/main/p/postgresql-8.0/postgresql-8.0_8.0.3-16.diff.gz
postgresql-8.0_8.0.3-16.dsc
  to pool/main/p/postgresql-8.0/postgresql-8.0_8.0.3-16.dsc
postgresql-8.0_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/postgresql-8.0_8.0.3-16_i386.deb
postgresql-client-8.0_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/postgresql-client-8.0_8.0.3-16_i386.deb
postgresql-contrib-8.0_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/postgresql-contrib-8.0_8.0.3-16_i386.deb
postgresql-doc-8.0_8.0.3-16_all.deb
  to pool/main/p/postgresql-8.0/postgresql-doc-8.0_8.0.3-16_all.deb
postgresql-plperl-8.0_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/postgresql-plperl-8.0_8.0.3-16_i386.deb
postgresql-plpython-8.0_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/postgresql-plpython-8.0_8.0.3-16_i386.deb
postgresql-pltcl-8.0_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/postgresql-pltcl-8.0_8.0.3-16_i386.deb
postgresql-server-dev-8.0_8.0.3-16_i386.deb
  to pool/main/p/postgresql-8.0/postgresql-server-dev-8.0_8.0.3-16_i386.deb

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-client-8.0 postgresql-plperl-8.0 postgresql-doc-8.0 postgresql-pltcl-8.0 libpgtypes2 libpq-dev libpq4 postgresql-plpython-8.0 postgresql-contrib-8.0 postgresql-server-dev-8.0 libecpg5 libecpg-compat2 postgresql-8.0 libecpg-dev
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...