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

Re: slapo-dynlist desgin question(s)

--On Tuesday, January 16, 2007 2:03 PM -0800 Howard Chu <hyc@symas.com> wrote:

Pierangelo Masarati wrote:
Great.  For the listing, honestly I remain on my positions.  A possible
exception, which would probably solve your problem and at the same time
not hinder what access is being applied to data is to design a new
access privilege that means something like "disclose to internal
operations".  This would need to be explicitly added to data that one
wants to be accessible by internal operations but not directly by
regular ops, like in your case.  What I don't like of this access
privilege is that it's too generic: it doesn't allow to tell what an
internal operation would do with that data.  For example, an internal
operation may want to modify it, or give it away or so.  Note that I
have no idea (nor intention: I still remember how much I had to sweat to
add "add" and "zap" privileges!) of how to implement it, right now.

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.


Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html