[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapo-dynlist desgin question(s)





--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