Comment 3 for bug 21508

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/postgresql/8.0/main/server.key«
> 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/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<---
>
> (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://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian Developer http://www.debian.org