Re: slapo-dynlist desgin question(s)

--On Saturday, January 13, 2007 11:03 AM +0100 Pierangelo Masarati <ando(a)sys-net.it&gt; wrote: > Using the rootdn to generate the list, and > then check access to the list itself may not be correct, because the > dynamic list could become a means to circumvent access control to the > actual data; think of a case where the effective user has no privileges > on the actual data, but has compare, or even read access to the > dynamically generated list. Then, if the list were generated as rootdn, > the user would be able to compare, or even read, on data that is a > derivative of otherwise inaccessible data. I would consider this a > violation of data integrity. Well, I think you are not considering the scenario that I have. Let's assume you have an attribute (privgroup) that contains information about all the groups particular people may be in. People can be in many hundreds to thousands of groups. Any person can create a group, and add other people to those groups. Now, you have doctors involved, who do patient studies. So lets say the doctor creates a priv group for an AIDS study they are doing. So some number of people now have privgroup=drnefarious:aids-patients as a value. So now, we want to implement groups. We can either (a) convert all of the privgroup information into static groups, or (b) convert all of the privgroup information into dynamic groups. Since we already have the information in an attribute, creating dynamic groups seems the best way to do this. Imagine my surprise that doing so meant I'd have to give access to the privgroup attribute to the end user, since that is exactly what I want to avoid for security & legal reasons. You think of it as a derivative of otherwise inaccessible data, while I think of it as giving them access to large amounts of data they shouldn't have access to, which to me is a violation of data integrity. I want them to only access what specifically I say they can. Just because the dynamic group is extrapolated from another attribute's value, does not mean that the end user should be given wholesale access (compare or read) to every value that attribute has. They get to see, and only see, the memberships of the groups they get access to.