An interesting bit on how PostgreSQL database access rights should be handled.
Karsten ----- Forwarded message from Chris Browne <[EMAIL PROTECTED]> ----- > 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) > > [EMAIL PROTECTED] (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 [EMAIL PROTECTED] 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
