--On Saturday, January 13, 2007 2:07 PM -0800 Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On Saturday, January 13, 2007 1:47 PM -0800 Howard Chu hyc@symas.com wrote:
You seem to be under the impression that changing the name of a piece of data changes the nature of the data. If you have an attribute that general users should not be able to see, then they also should not be able to see the dynamic group derived from that attribute. Opening it up in any way is only going to open you to the same liability you claim to want to avoid.
Please explain to me how they would see dynamic groups I haven't given them access to via acl control.
Please explain how those dynamic groups have any relevance to them if they are not members of the group.
You asked for the ability to use rootdn privileges to evaluate the membership of a dynamic group because the user on whose behalf you are evaluating may not have access to evaluate the membership.
This makes no sense. If the user doesn't have access to evaluate the membership, then clearly the user doesn't have the values that determine membership in the group - thus the user is not a member, so the actual membership of that group is a moot point.
Well, here's an example of why:
I have an application, say "cgi.stanford.edu". cgi.stanford.edu connects to the LDAP servers with "service/cgi@stanford.edu" as its principal. That is mapped to an entry in the "cn=service,cn=applications,dc=stanford,dc=edu" tree. It has no entries in the person tree, and it belongs to no groups. "userA" comes along to access a CGI script that is restricted to only members of a particular group. The CGI servers are now going to query the group to see if "userA" is a member of that group.
Or, in another case.
I have an application, that is perhaps running on "cgi.stanford.edu". It will use my CGI principal's credentials to connecto to the LDAP Servers with "cgi/quanah@stanford.edu" as its principal. That is mapped to an entry in the "cn=cgi,cn=applications,dc=stanford,dc=edu" tree. It has no entries in the person tree, and it belongs to no groups. "userA" comes along to run the script, and I want to see which of the different groups I have they belong to. The script is now going to bind to the LDAP server as itself, and see if "userA" is a member of several different groups.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html