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

[Simo Sorce]

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 ?

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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York