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

[Simo Sorce]

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