I found that there's an alternate way to achieve this same functionality
that's more elegant, probably more efficient, and doesn't require any
patches. The approach uses the authorizedService attributes on the host
entry. With nssov, individual users can be granted or revoked access
based on the slapd ACLs and whether or not they have "compare" access to
the authorizedService attribute. I created groups of users underneath
the host entry - one for each service - and used regex's in the ACLs to
grant compare access to the correct authorizedService attribute when the
user is present in the corresponding group.
Also the buffer sizes were determined to be a non-issue and do not need
to be changed.
Chris Breneman
On Mon, 2010-03-22 at 00:03 -0500, Kean Johnston wrote:
I like what this offers administrators but I have a comment about how
you
handle "wildcards". They aren't wild at all, but "magic strings"
with only
one possible meaning: all users/services with the single magic character
"*". If you have a defined user naming convention like i_whatever for
interns and c_whatever for contractors, it would be useful to be able to
either include or exclude such users from using certain services.
My patch at
http://www.openldap.org/its/index.cgi?findid=6495 does this for
userhost and userservices attributes, and includes negation. Would you be
interested in working with me to expand this to support real wildcards?
Also I suggest you make this two patches, as the patch submission
guidelines clearly state that one patch for 1 feature, and the meaty parts
of this are obfuscated by increasing the buffer sizes which should probably
be in a separate patch.
Regards, Kean