[16195] in Kerberos_V5_Development
Re: Pasword quality pluggable interface project review
daemon@ATHENA.MIT.EDU (Zhanna Tsitkova)
Mon Aug 30 12:49:53 2010
Message-Id: <DBD738F2-15B7-4EB8-A197-EEBB376A93FF@mit.edu>
From: Zhanna Tsitkova <tsitkova@mit.edu>
To: Greg Hudson <ghudson@mit.edu>, mdw@umich.edu
In-Reply-To: <1283183641.9882.164.camel@ray>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 30 Aug 2010 12:49:49 -0400
Cc: "krbdev@MIT.EDU" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Aug 30, 2010, at 11:54 AM, Greg Hudson wrote:
> On Mon, 2010-08-30 at 11:38 -0400, Marcus Watts wrote:
>> By "new plugin model" do you mean krb5int_open_plugin_dirs /
>> krb5int_get_plugin_dir_data or something else? If you mean these
>> functions then it's already done. If it's something else, then
>> I guess it depends on how closely the new functionality matches
>> these.
>
> http://k5wiki.kerberos.org/wiki/Projects/Plugin_support_improvements
>
> What we arrived at doesn't have the properties you discussed about the
> PAM framework:
>
> * Module registrations aren't parameterized (but modules can read
> associations from the profile, so they don't require separate config
> files).
>
> * Module registrations aren't ordered.
>
> * Registration of built-in modules is automatic, although built-in
> modules can be disabled.
>
> * Modules cannot be multiply registered; the end result of module
> registration is a mapping of name to (unique) module, even for
> one-to-many interfaces (such as password quality) where module names
> are
> unimportant.
>
> While we still have the technical freedom to replace this model with
> something more PAM-like, I'm not currently convinced that it's
> desirable.
Well, the password quality is the first plugin module that we attempt
to implement under http://k5wiki.kerberos.org/wiki/Projects/Plugin_support_improvements
, i.e. the first test for the flexibility of the plugin architectural
re-work.
I believe that one must take closer look at the requirements as they
are described by Marcus and some are mentioned above : ordered module
registration, plugin interdependencies, multiple and parameterized
registration of the modules. All of them where discussed before but in
lack of the real use-cases were postponed.
Thanks,
Zhanna
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
