On Fri, 2014-01-10 at 12:15 -0500, Simo Sorce wrote: > On Thu, 2014-01-09 at 21:30 -0800, Noriko Hosoi wrote: > > Simo Sorce wrote: > > > 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 ? > > I uesd this ACI: > > aci: (target=ldap:///o=my.com)(targetattr=*) (version 3.0; acl "userattr > > test"; allow (add,write,delete,read,search,compare) userattr = > > "description#USERDN";) > > > > Please note uid=nuser does not exist yet. Does your question mean by > > this add? Before coming to the ACL code, bind fails... > > $ ldapmodify ... -D 'uid=nuser,o=my.com' -w Nuser -a << EOF > > dn: uid=Nuser, o=my.com > > objectClass: top > > [...] > > uid: Nuser > > description: uid=nuser,o=my.com > > userPassword: {CLEAR}Nuser > > EOF > > ldap_simple_bind: No such object > > ldap_simple_bind: matched: o=my.com > > This is not what I had in mind, our use cases is something like this: > aci: (target=ldap:///dc=bar)(targetattr=*) (version 3.0; acl "userattr > test"; allow (add) userattr = "managedby#USERDN";) > > ldapmodify -D uid=user,dc=bar ... <<EOF
^^^^^^^^ Sorry this should have been ldapadd. Simo. > dn: cn=somobj,dc=bar > ... > managedby: uid=user,dc=bar > > > This should succeed, however if managedby includes anything but > "uid=user,dc=bar" it should fail. > > > >>> 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 ? > > As long as the type of the attribute is not restricted as DN syntax, it > > takes any value including DN. I tested with 'description' (e.g., > > userattr = "description#USERDN") and verified it takes userDN as well as > > any other values. > > > > $ ldapmodify ... -D 'cn=directory manager' -w <pw> > > dn: uid=nuser4,o=my.com > > changetype: modify > > add: description > > description: uid=nuser4,o=my.com > > > > $ ldapmodify ... -D 'uid=nuser4,o=my.com' -w Nuser4 > > dn: uid=nuser4,o=my.com > > changetype: modify > > add: description > > description: uid=nuser0,o=my.com > > > > modifying entry uid=nuser4,o=my.com > > > > $ ldapmodify ... -D 'uid=nuser0,o=my.com' -w Nuser0 > > dn: uid=nuser4,o=my.com > > changetype: modify > > add: description > > description: uid=nuser1,o=my.com > > > > modifying entry uid=nuser4,o=my.com > > > > $ ldapmodify ... -D 'uid=nuser1,o=my.com' -w Nuser1 > > dn: uid=nuser4,o=my.com > > changetype: modify > > add: description > > description: value > > > > $ ldapsearch ... -D 'cn=directory manager' -w <pw> -b > > "uid=nuser4,o=my.com" description > > dn: uid=Nuser4,o=my.com > > description: uid=nuser4,o=my.com > > description: uid=nuser0,o=my.com > > description: uid=nuser1,o=my.com > > description: value > > If I read this correctly, and I am not 100% sure yet, it seem to me this > is exactly the opposite of what IPA needs. > > Our need is that uid=userX,... can only write its own DN as value or the > attributes we are allowing through userattr. > > Simo. > -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel