[Date Prev][Date Next]
Re: slapo-dynlist desgin question(s)
Quanah Gibson-Mount wrote:
--On Saturday, January 13, 2007 11:03 AM +0100 Pierangelo Masarati
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/