Re: Password issue revisited - Mailing list pgsql-general

I assume this is not a TODO.

---------------------------------------------------------------------------

Magnus Hagander wrote:
> >>> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +