[Gnumed-devel] address@hidden: Re: [GENERAL] Getting a DB password to work without editing pg_hba.conf, ]

[Karsten Hilbert]

An interesting bit on how PostgreSQL database access rights
should be handled.

Karsten

----- Forwarded message from Chris Browne <address@hidden> -----

> Subject: Re: [GENERAL] Getting a DB password to work without editing 
> pg_hba.conf,
> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux)
> 
> address@hidden (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."
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to address@hidden so that your
>        message can get through to the mailing list cleanly
> 

----- End forwarded message -----

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346