Skip site navigation (1) Skip section navigation (2)

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

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Simon Arlott" <simon(at)arlott(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #3809: SSL "unsafe" private key permissions bug
Date: 2007-12-08 21:09:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
"Simon Arlott" <simon(at)arlott(dot)org> writes:

> On 08/12/07 15:31, Tom Lane wrote:
>> "Simon Arlott" <postgresql(dot)simon(at)arlott(dot)org> writes:
>>> FATAL:  unsafe permissions on private key file "server.key"
>>> DETAIL:  File must be owned by the database user and must have no
>>> permissions for "group" or "other".
>>> It should be possible to disable this check in the configuration, so those
>>> of us capable of deciding what's unsafe can do so.
>> You haven't given any reason to think that you are smarter than this
>> check.
> The directory containing the SSL keys has appropriate permissions, I 
> shouldn't have to make a separate copy of them for every application.

Another case where it's important to be able to disable this check is when
you're using a file system which doesn't use the unix bits for permission
checks either at all or in the traditional way.

So for example if the key directory lay on an FAT filesystem which doesn't
have unix bit per file the only way to satisfy the check would be to mount the
filesystem with the option to make every file in the filesystem have those
bits. Storing your keys on a usb stick (which usually use fat filesystems)
isn't really such a crazy idea either.

  Gregory Stark
  Ask me about EnterpriseDB's PostGIS support!

In response to


pgsql-bugs by date

Next:From: Alvaro HerreraDate: 2007-12-08 21:25:07
Subject: Re: BUG #3809: SSL "unsafe" private key permissions bug
Previous:From: A. Ozen AkyurekDate: 2007-12-08 21:04:40
Subject: OleDB and Delphi

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group