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
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
