[Freeipa-devel] [PATCH] Add new pwpolicy plugin based on baseldap classes.

Rob Crittenden rcritten at redhat.com
Fri Mar 19 20:21:31 UTC 2010


Pavel Zuna wrote:
> Last week, I spent a good amount of time investigating about the way we 
> build/normalize DNs. Most issues, that came up recently originated in 
> the password policy plugin as it needed specially crafted DNs for class 
> of service (CoS) entries. As I was playing around with it, I decided to 
> rewrite it, so that it blends with all the other "baseldap plugins" we 
> have.
> 
> I didn't want to override Rob's original pwpolicy plugin right away, so 
> I named it pwpolicy2, so that we can have both plugins available for now.
> 
> pwpolicy2 includes all functionality the original plugin had including 
> the latest changes like priority uniqueness etc. There is a small 
> interface change - group names are entered as the first positional 
> argument. If no group is specified, the plugin assumes the global 
> password policy. It supports --all/--raw and has fine grained searching 
> capabilities (the original plugin was only able to return all policies). 
> It also shows priority when displaying policies.
> 
> There is a lot of technical changes. It's a complete rewrite. Everything 
> is based on baseldap classes, so the code should be a bit simpler and 
> commands behavior more consistent with other plugins. CoS objects are 
> modeled separately and have their own CRUD commands. I flagged the CoS 
> commands as INTERNAL (see my recent patch), so that users aren't able to 
> access CoS entries directly, but pwpolicy2 can take advantage of our 
> plugin infrastructure to manage them. I think this is a good example of 
> how internal plugin are useful. It's also very handy for testing, you 
> can just remove the INTERNAL flag and use `ipa cosentry-find --all 
> --raw` to check if the entries were created/modified/whatever correctly.
> 
> Unit test included.
> 
> Pavel

nack.

There should be a comment expressing why the policy entry is named the 
way it is and why the DN can't be normalized.

cos entries other than password policy are stored in cn=cosTemplates so 
the uniqueness check will return false positives.

It is not legal for a group policy to not have a cospriority so there is 
no need to catch this condition in pwpolicy2_mod.

rob




More information about the Freeipa-devel mailing list