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
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

--noriko

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to