Re: Getting a DB password to work without editing pg_hba.conf,

linux(at)alteeve(dot)com (Madison Kelly) writes:
> In this case I can't predict what a given install's postgresql
> will be used for (outside of my program) because it is meant for
> general distribution (it's a backup program). This obviously makes
> things a lot more complicated. :p

No, it oughtn't.

You shouldn't try to impose anything about this onto the users.

There are really only two options you need to concern yourself about:

1. Perhaps a password may be needed in your configuration.

2. Perhaps it won't. Any number of possible causes:
- Your user may be considered "trusted";
- The password may be stored in ~/.pgpass
- Perhaps in future, authentication may come as some form of SSH key,
stored in a directory somewhere...

> While I developed the program that is what I did, just changed
> from 'ident' to 'trust'. Now though I am trying to keep what the end
> user needs to do to a minimum because I've aimed the backup program
> at more novice users (though not excluively). That is the biggest
> reason why I am trying to work with the stock 'pg_hba.conf' file
> (understanding that it can change from one distro to the
> next). Generally though I've only seen the same 'local...' settings.

What you may want to do, then is to provide _documentation_ to suggest
how they might manage pg_hba.conf.

If people think you're telling them how to manage security, and their
ideas aren't the same as yours, that'll point people away from your
software.

With Slony-I, that was one of the "design choices." It requires
having a database superuser around, but Slony-I does NOT attempt to
impose anything about what authentication methods you prefer to use.
To run Slony-I, you have to use authentication conforming with what
the environment requires.

I believe Jan Wieck's preferences are to be able to use TRUST; the
thought is that you should only be running replication in an
environment that you already know to be secured, where you can trust
anyone that has access to the database hosts. I can mostly go along
with that.

In our production environments, however, we use md5 authentication,
because there are others setting security policy that don't think the
same way about it as Jan does.

Fortunately, Slony-I wasn't designed to require Jan's policy
preferences. It can conform to various kinds of policies. Your
program ought to do the same.

> In my program the database needs to reside on the local machine
> so as far as I am concerned my only worry is the 'local...'
> settings. There may be issues with connections coming in over
> 'host...' connections but I want to deal with one issue at a
> time. :p

It shouldn't much matter where the database is.

> So what purpose does the password on the user account accomplish?
> Is it essentially useless in my scenario?

The password is an authentication token that *may* be required.

For *your* purposes, it doesn't matter if it "accomplishes" anything;
it doesn't matter if it is "useful." It only ought to matter that you
*may* need a password to pass in as part of the DSN used to connect to
the database.
--
select 'cbbrowne' || '@' || 'acm.org';
http://cbbrowne.com/info/nonrdbms.html
Signs of a Klingon Programmer #7: "Klingon function calls do not have
'parameters' -- they have 'arguments' -- and they ALWAYS WIN THEM."