Full_Name: Guillaume Rousse
Submission from: (NULL) (188.8.131.52)
Current implementation of ppolicy only accept an internal plugin as password
checker. However, writing native code is more difficult for many sysadmins than
using script languages. Moreover, it's also less safe, as any crash will
endanger the whole slapd process. Allowing to run an external process for
checking password would be desirable.
If you're talking about writing a checker feature that fork/execs an external
script interpreter, then I'll say up front that this is not a good idea, and
we've already been deprecating anything else that operates this way (like
back-shell). fork()/system()/spawn() whatever don't mix well with pthreads and
will most likely corrupt something.
As for isolation/crash vulnerability - this is a *password checker* - it is
already a sensitive piece of code. If you're deploying a custom module without
adequate testing or code review, you're already in trouble.
You could of course take a similar approach as back-sock - open a socket to
some other daemon that performs your checks for you. You then have to decide
how to behave when the external process isn't answering...
Ultimately, what you do inside your checker module is your own business. I see
no action needed on our part; this ITS will be closed.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/