From: | Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl>, pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Password strength requirements |
Date: | 2006-12-22 08:57:22 |
Message-ID: | 1166777843.30188.41.camel@zorro.isa-geek.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2006-12-22 at 01:20 -0600, Bruno Wolff III wrote:
> On Thu, Dec 21, 2006 at 23:43:06 +0100,
> Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl> wrote:
> >
> > And everything I need would be very simple to do if there was an
> > option to disable self-change of passwords for ordinary users.
>
> That seems like a feature not many other people are going to want.
> You have the soruce, and it probably wouldn't be too hard to put
> in a hack to do that.
I must say, that I was tempted to try. Even though I'm at all fit to.
In my case, it is not because of blocking of self-password change, but
on quite a similar token I need:
1. password expiration - which works on the database level in such a
way, that when account/password expire, only "alter... password .."
statement is allowed for such a user. *all* other SQL statements should
result in "RAISE EXCEPTION... " - that is: transaction aborted.
2. I also need some additional *per*session* fields (of the
"client_encoding" or "search_path" variaty) in the SET/SHOW environment.
Still, I have *never* hacked the postgres, so I'm a bit reluctant here -
this may be more then a little project I fear.
But if I try, could you pls hint me on which source files and/or
functions should I start with?
Or may be the there is a "quick start for hackers" HOWTO somwhere
around?
BTW: One of the reasons I need the hack for password change/expiry is
that neither of the two 'possible' alternatives: PAM or LDAP, do not
allow for "CREATE USER ..." as per documentation in:
"http://www.postgresql.org/docs/8.2/static/auth-methods.html#AUTH-LDAP" (but may be I'm missinterpreting the docs?)
And LDAP, although most atractive, is further unnecesarly constrained by
a depencecy on SASL.
....and putting more oil into the fire. LDAP is not actually a database
- it's an '...Access Protocol', so we may choose freely the 'LDAP
backend database' ... a good relational database like postgres is an
option here .... and this is a real mass.
So I think postgres should have more extensive *native* support for
password authentication, and I'm willing to hack .... but provided my
lack of experience - pointers to HOWTOs apreciated :)
--
-R
From | Date | Subject | |
---|---|---|---|
Next Message | Joost Kuckartz | 2006-12-22 09:14:08 | Re: Unable to start server - winxp |
Previous Message | Ron Johnson | 2006-12-22 08:19:16 | Re: Partitioning Vs. Split Databases - performance? |