Re: Password strength requirements

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

In response to

Browse pgsql-general by date

  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?