Rob Crittenden wrote:
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.
You mean why are policies located under the realm entry or why are they named
after groups?
DNs of password policies can be normalized. Only DNs of CoS entries can't be for
now.
cos entries other than password policy are stored in cn=cosTemplates so
the uniqueness check will return false positives.
I assume this is a false alarm, (See discussion in Rob's 404 patch thread)
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.
You're not forced to modify the priority, so we do need to catch this condition.
rob
Anyway, I would probably defer from pushing this in any case until we completely
switch to LDAPv3 style DNs.
Pavel
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
