From: Shane Ambler <pgsql@Sheeky.Biz>
To: Bruce Momjian <bruce@momjian.us>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Michael Schmidt <michaelmschmidt@msn.com>
Cc: PostgreSQL General <pgsql-general@postgresql.org>
Subject: Re: Password issue revisited
Date: Wed, 21 Feb 2007 04:19:49 +1030
Message-ID: <45DB34BD.9070406@Sheeky.Biz> (raw)
In-Reply-To: <200702201521.l1KFLL823218@momjian.us>
References: <200702201521.l1KFLL823218@momjian.us>
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> Are we sure we want to do this? (Sorry, didn't notice this thread last
>> time)
>>
>> The default on *all* windows versions since NT 4.0 (which is when the
>> directory we use was added) will put this file in a protected directory.
>> The only case when it's not protected by default is if you're usnig FAT
>> filesystem, in which case there is nothing you can do about it anyway.
>> On unix, the file will often be created in outside-readable mode by
>> default, depending on how your OS is set up.
I believe that .pgpass on *nix won't be used if it is readable by anyone
except the current user.
From the docs -
The permissions on .pgpass must disallow any access to world or group;
achieve this by the command chmod 0600 ~/.pgpass. If the permissions are
less strict than this, the file will be ignored. (The file permissions
are not currently checked on Microsoft Windows, however.)
I would think that if they are using FAT filesystem (which is only
partially supported for developers benefit) then they can't use pgpass.
>> So to reach a situation where the file lives in an unprotected
>> directory, you must actively open up the directory in question. Which is
>> hidden from default view, so you really need to know what you're doing to
>> get there.
>>
>> Not to mention it's a pain to define what permissions are ok and what
>> are not. We're talking ACLs and not filemodes - so how do you decide
>> which accounts are ok to have access, and which are not?
I would say the same as the *nix version - if it is readable or writable
by anyone except the current user it is potentially at risk, the current
user connecting to pgsql is the only use for this file.
Which I believe is the whole point of the TODO entry, stop anyone using
the pgpass file without proper security.
The other thing to consider is that pgpass is the file referenced by
PGPASSFILE - the user can set this to point to a file anywhere on any
drive available.
It is users who only think they know what they are doing that create and
modify it by hand and then kick up a fuss when it causes trouble.
If we want the windows clients to be used then I do think that the
security decisions should not be dropped for windows clients.
> OK, I added a comment to fe-connect.c explaining why we don't need to
> check the permissions of .pgpass, and removed the TODO. Thanks.
>
--
Shane Ambler
pgSQL@Sheeky.Biz
Get Sheeky @ http://Sheeky.Biz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: pgsql@Sheeky.Biz, bruce@momjian.us, magnus@hagander.net, michaelmschmidt@msn.com, pgsql-general@postgresql.org
Subject: Re: Password issue revisited
In-Reply-To: <45DB34BD.9070406@Sheeky.Biz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox