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