--On Thursday, January 18, 2007 7:59 AM +0100 Pierangelo Masarati
<ando(a)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