Comment 10 for bug 21508

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
uo8UAahlro1HhGm5L6dx5H9eGdgxH6PTKAJYBNdY94Z2iU4K+8N39XVqY3fh6KTQ
3mcPJxI3zG46qoXGKf3N8PRJ4jPv9TMM8pguft8XI7TXIiyrnJMwGYu/brStG0T/
cCRAS2od+nmeJTZ6HCWfnpDtrjJYoQhXNnXEhW5N4I2poJ+A4yx66D6Ho/63LkKh
Ul935HtseZsyoAZDUem1VzT9AowIG68TvkoxoeDh24K7G56e8vEbXg4kVLyMRkX8
ZLHpmpmpEEdj3DbAb54xZFTa5g/K70nr9sCWNZASrw2LQmKPSxJJr2M3392Q4yI=
=ni0i
-----END PGP SIGNATURE-----

--nextPart1405902.FzFxCqVYyD--