Thread: adding PGPASSWORDFILE to libpq

Hello:

I'm giving a try at some TODO items.  Currently it's the turn of the
PGPASSWORDFILE environment variable.  I have modified libpq to make use
of this variable.  I present the first cut here.

I have some questions:
- should there be some reasonable default non-empty value?  If so, how
  can I define it? In terms of $HOME?

- should there be a new parameter in the connection string that allows
  specifying the file that should be used? A new parameter to
  PQsetdbLogin() (breaks old code, I think) ?

- Should I try to use the passwd parameter as password file, and try to
  use it as password if it fails to fopen()?

- Should the password be dependent of the database name?

Currently the format for the file should be

host:port:database:user:password

Any [other] comment on how this is done is welcome.

--
Alvaro Herrera (<alvherre[a]atentus.com>)
A male gynecologist is like an auto mechanic who never owned a car.
- Carrie Snow

Alvaro Herrera <alvherre@atentus.com> writes:
> - should there be some reasonable default non-empty value?  If so, how
>   can I define it? In terms of $HOME?

I don't think so.  This is the sort of thing that I feel a user ought to
have to define explicitly; too much risk of picking up an unintended
file otherwise.

> - should there be a new parameter in the connection string that allows
>   specifying the file that should be used? A new parameter to
>   PQsetdbLogin() (breaks old code, I think) ?

Changing the call signature of PQsetdbLogin is completely out of the
question.

While we could add an option in connection strings, I'm not really sure
I see the need.  Seems like any practical use of this facility would
involve setting PGPASSWORDFILE as an environment variable.  If you're
going to put something in the conninfo string you may as well just give
the password and be done with it.  Remember that the point of the
feature is to be a safer substitute for PGPASSWORD environment variable.

> - Should I try to use the passwd parameter as password file, and try to
>   use it as password if it fails to fopen()?

Also extremely risky.  I do not like "convenience features" that create
security risks ...

> - Should the password be dependent of the database name?

Yes, but see below.

> Currently the format for the file should be
> host:port:database:user:password

You should allow a wildcard (perhaps *) for each of those positions,
but otherwise that seems reasonable.

            regards, tom lane

Alvaro Herrera writes:

> Currently the format for the file should be
>
> host:port:database:user:password

I think just the password.  If you need a different password, select a
different file.

The sort of format you propose makes it much too convenient for users to
build password databases in files, which kind of defeats the point of
passwords.

--
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut wrote:
> Alvaro Herrera writes:
>
> > Currently the format for the file should be
> >
> > host:port:database:user:password
>
> I think just the password.  If you need a different password, select a
> different file.
>
> The sort of format you propose makes it much too convenient for users to
> build password databases in files, which kind of defeats the point of
> passwords.

I fail to see how having different files with passwords is better than
having just one file.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Peter Eisentraut dijo:

> Alvaro Herrera writes:
>
> > Currently the format for the file should be
> >
> > host:port:database:user:password
>
> I think just the password.  If you need a different password, select a
> different file.

All right, maybe there's not a lot of people who will use more than one
password, but who wants to deal with the inconvenience of having lots of
files with passwords if you can have only one?

> The sort of format you propose makes it much too convenient for users to
> build password databases in files, which kind of defeats the point of
> passwords.

What's wrong with providing "too much convenience"?  The file is/should
protected from other users anyway, which I think is the whole point.

Having different files and being forced to identify them by their name or
location is a kind of "password database" anyway.

--
Alvaro Herrera (<alvherre[a]atentus.com>)
"La espina, desde que nace, ya pincha" (Proverbio africano)

Peter Eisentraut <peter_e@gmx.net> writes:
> Alvaro Herrera writes:
>> Currently the format for the file should be
>> host:port:database:user:password

> I think just the password.  If you need a different password, select a
> different file.
> The sort of format you propose makes it much too convenient for users to
> build password databases in files, which kind of defeats the point of
> passwords.

Why is it better to make the user's life more difficult?  If I have
several different database passwords to keep track of, and I'm going
to store them in $HOME/.foo files, I'd rather keep them all in one such
.foo file.  That means only one file to get the permissions right on.
I am not aware of *any* other Unix utility that diverges from this
scheme: cvs does it that way, ftp does it that way, ssh does it that
way, xauth does it that way ... need I go on?

            regards, tom lane