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. > > https://fedorahosted.org/389/ticket/47653 > > This patch is included in 389-ds-base-1.3.2.10 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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
