From: Magnus Hagander <magnus@hagander.net>
To: Shane Ambler <pgsql@Sheeky.Biz>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Michael Schmidt <michaelmschmidt@msn.com>
Cc: PostgreSQL General <pgsql-general@postgresql.org>
Subject: Re: Password issue revisited
Date: Tue, 20 Feb 2007 18:55:35 +0100
Message-ID: <45DB3617.9040107@hagander.net> (raw)
In-Reply-To: <45DB34BD.9070406@Sheeky.Biz>
References: <200702201521.l1KFLL823218@momjian.us>
<45DB34BD.9070406@Sheeky.Biz>
>>> 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.
No, root can always read it. On unix, there is one "root". On windows,
the concept of administrator is less clear.
> 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.
If they are using FAT, the obviously don't care about the security of
the system anyway, so it's not a problem, IMHO. So we only have to care
about people who use NTFS.
>>> 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.
Again, it's a lot harder to actually define it on Windows. What if your
user has access only through a group? What about DENY permissions.
Things like that.
> 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.
That's a very valid point though, didn't think about that.
Still doesn't take away the "how" part, though, but it does take away
part of the "why" part.
//Magnus
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: magnus@hagander.net, pgsql@Sheeky.Biz, bruce@momjian.us, michaelmschmidt@msn.com, pgsql-general@postgresql.org
Subject: Re: Password issue revisited
In-Reply-To: <45DB3617.9040107@hagander.net>
* 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