Re: BUG #3809: SSL "unsafe" private key permissions bug

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>> Gregory Stark wrote:
>>> Storing your keys on a usb stick (which usually use fat filesystems)
>>> isn't really such a crazy idea either.
>
>> Storing a server SSL key on a USB stick is not crazy? I don't follow.
>> What use case do you have for that?

Sure, private keys are often more sensitive than the data they protect. You
might want them not to be included in backups or to ever live on spinning
disks that you'll have to wipe in case of a disk crash. A stick can be moved
to a backup server when failing over. Once upon a time people used to use
floppies for this purpose (which also use fat filesystems incidentally).

> It's worth pointing out also that we require server.key to be directly
> in the $PGDATA directory, which means that any filesystem limitations on
> its permissions info are going to apply to the $PGDATA directory itself.
>
> Curiously enough, the access-permission checks on both $PGDATA and
> $PGDATA/server.key are diked out in WIN32 builds, but I consider that
> a bug we should fix, not a feature to be extended.

Another filesystem where people get bit by tools which assume they can look
directly at unix permission bits instead of using access() and impose fascist
rules on what they expect to see there is AFS. The unix bits are mostly
meaningless on AFS. So you get users complaining that they're following the
instructions on setting permission and the occasional tool is still
complaining about problems.

I think looking at the unix permission bits and imposing policy is usually a
bad idea but in those few cases where it makes any sense there should always
be a switch to disable it.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!