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

Re: slapo-dynlist desgin question(s)



Quanah Gibson-Mount wrote:


--On Saturday, January 13, 2007 11:03 AM +0100 Pierangelo Masarati <ando@sys-net.it> 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.

You seem to be under the impression that changing the name of a piece of data changes the nature of the data. If you have an attribute that general users should not be able to see, then they also should not be able to see the dynamic group derived from that attribute. Opening it up in any way is only going to open you to the same liability you claim to want to avoid.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/