Re: (ITS#6487) Nssov pam_authz authorizedUserService

[crispy@cluenet.org]

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