|Subject:||Re: [Gnumed-devel] good news regarding PostgreSQL|
|Date:||Sat, 04 Feb 2006 09:24:36 +0800|
thanks, will take a look. Don't quite understand about the pg_hba.conf,
but you're saying it's per group rather than per database definition of local and host
type of database access , which is sending of md5 hashes of passwords
( this isn't challenge-authentication, is it ?; can some one spoof the md5 password packets ?)
I've been trying to get kerberos working lately ( mainly because my gsasl is saying something
about credentials when I try to get ldap to work with default configuration).
Postgres does kerberos too , doesn't it?
I'm using tethereal to debug, it seems to help.
On Thu Feb 2 17:07 , Karsten Hilbert sent:
There's good news regarding PostgreSQL authentication
complexity: I have eventually found a way to enable
database-only adding of fully functional GNUmed users.
Previously it seemed necessary to add a line to the
pg_hba.conf file in the file system the PostgreSQL server
was running on (that is, the database machine). This needed
root or postgres system account rights.
We can now add users without need for access to the
filesystem (IOW remotely, too) without having to say
something like "trust all".
Putting the following line into pg_hba.conf *once* at the
proper position will enable this sort of access for all
future GNUmed databases:
for same-machine access:
local samegroup +gm-logins md5
for remote access:
host samegroup +gm-logins md5
The theory behind this is that if the new user is a member
of the appropriate database groups *inside* PostgreSQL
(namely "gm-logins" and a group with the same name as the
database - such as "gnumed_v2") access will be granted -
provided the password is known.
Code to work based on this assumption will be checked in
tonight. I have added a convenience stored procedure
"gm_create_user(username, password)" which will properly
create new GNUmed database users. This procedure should be
used by staff management widget writers ... And, no, the
user executing this procedure does NOT need superuser
database rights :-) Therefor, execution is currently
limited to "gm-dbo" for which to be used with staff widgets
the user must be asked to provide the "gm-dbo" password -
very much like doing "su - root" at the console.
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Gnumed-devel mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|