On Thu, 2014-01-09 at 15:15 -0800, Noriko Hosoi wrote:
> Simo Sorce wrote:
> > On Thu, 2014-01-09 at 16:32 -0500, Nathaniel McCallum wrote:
> >> This patch is independent from my patches 0028-0031 and can be merged in
> >> any order.
> >> This patch has a bug, but I can't figure it out. We need to set
> >> nsslapd-access-userattr-strict on cn=config to "off".
> > Uhmm what is the effect on ACL evaluation of changing this boolean ?
> Ticket 47653 - Need a way to allow users to create entries assigned
> to themselves
> Bug Description: There are cases where users need to be able to
> create, edit and delete
> their own entries. Using an ACI with the
> "userattr" keyword does not
> work with ADD operations(to prevent a security
> hole). This prevents IPA's
> OTP plugin from performing some necessary operations.
> Fix Description: Added a new config attribute
> "nsslapd-access-userattr-strict". The default
> is "on" or strict. For the IPA case, it would
> need to be set to "off" in
> order to allow the desired behavior.
> This patch is included in 389-ds-base-188.8.131.52 and newer.
Thank you Noriko, but as I mentioned, I already read through the 389ds
patch and it doesn't help me. Below I have a few more questions, I will
add one that is more clear.
> > Is this option simply allowing the use of add/delete ACIs to be
> > specified in conjunction with userattr, so that a user can add an attr
> > only if it contains its own DN ?
So the entry in this case does not exist yet, so my question is whether
the (userattr=attrFoo#userDN) part will actually match that attrFoo is
set to contain the DN of the user that is performing the operation ?
> > Will it allow the user to add multiple values to the same attr as long
> > as one of the is the userDN ? O will it restrict that case ?
This is also important, if attrFoo is a multivalued attribute, does this
option allow any values to be set as long as one of them is userDN ?
Or will it enforce that *only* userDN is add in the add operation ?
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list