Search Postgresql Archives

Re: Password strength requirements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux