[Freeipa-devel] [PATCH 0032] Update ACIs to permit users to add/delete their own tokens

[Simo Sorce]

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