--On Thursday, January 18, 2007 7:59 AM +0100 Pierangelo Masarati ando@sys-net.it wrote:
Quanah Gibson-Mount wrote:
Another approach may be to view the dyngroup overlay as a proxy, and just configure an identity for it to use. So you can explicitly give it access to whatever attributes it needs to see.
This would certainly work for me, and is I think, what I was trying to ask for originally, except I said the rootdn, when I should have said a proxy ID. ;) Then I could just add
access to suprivilegroup by dyngroupID compare
and be happy.
This already you have now in HEAD. I fear you'd rather need to add
access to suprivilegroup by dyngroupID __READ__
and be (un)happy...
Why would it need read? The acl's should be something like:
access to group by uid=a read by uid=b compare
access to other group by uid=c read
etc
and then in dynlist, I supply a proxy ID that is used internally to do the comparisons to generate the membership. Then only that proxy ID needs to do any sort of internal lookups. The initial user's credentials are still used with the ACLs to see what, if anything, they can do with the generated information.
Something perhaps like:
overlay dynlist
dynlist-proxyID cn=dynlist
Then in my ACL's as well:
access to dn.subtree="cn=people,dc=stanford,dc=edu" attr=suprivilegegroup by dn.base="cn=dynlist" compare
--Quanah
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html