Comment 6 for bug 21508

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