[Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs

[Martin Kosek]

On 09/22/2014 04:55 PM, Simo Sorce wrote:
> On Mon, 22 Sep 2014 10:02:01 -0400
> Nathaniel McCallum <npmccallum at redhat.com> wrote:
>
>> On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote:
>>> On Mon, 22 Sep 2014 10:34:54 +0200
>>> Martin Kosek <mkosek at redhat.com> wrote:
>>>
>>>> On 09/22/2014 09:33 AM, thierry bordaz wrote:
>>>>> Hello Nathaniel,
>>>>>
>>>>>     Just a remark, in is_token if the entry is
>>>>> objectclass=ipaToken it returns without freeing the
>>>>> 'objectclass' char array.
>>>>>
>>>>>     thanks
>>>>>     thierry
>>>>>
>>>>> On 09/21/2014 09:07 PM, Nathaniel McCallum wrote:
>>>>>> Users that can rename the token (such as admins) can also
>>>>>> create non-UUID token names.
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/4456
>>>>>>
>>>>>> NOTE: this patch is an alternate approach to my patch 0065.
>>>>>> This version has two main advantages compared to 0065:
>>>>>> 1. Permissions are more flexible (not tied to the admin group).
>>>>>> 2. Enforcement occurs at the DS-level
>>>>>>
>>>>>> It should also be noted that this patch does not enforce UUID
>>>>>> randomness, only syntax. Users can still specify a token ID so
>>>>>> long as it is in UUID format.
>>>>>>
>>>>>> Nathaniel
>>>>
>>>> I am still thinking we may be overcomplicating it. Why cannot we
>>>> use the similar UUID generation mechanism as we do for SUDO
>>>> commands for example:
>>>>
>>>> # ipa sudocmd-add barbar --all --raw
>>>> ---------------------------
>>>> Added Sudo Command "barbar"
>>>> ---------------------------
>>>>    dn:
>>>> ipaUniqueID=3a96de14-4232-11e4-9d66-001a4a104ec9,cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test
>>>>    sudocmd: barbar
>>>>    ipaUniqueID: 3a96de14-4232-11e4-9d66-001a4a104ec9
>>>>    objectClass: ipasudocmd
>>>>    objectClass: ipaobject
>>>>
>>>> It lets DS generate&rename the object's DN when it finds out that
>>>> the ipaUniqueID is set to "autogenerate" (in baseldap.py). We
>>>> could let DS generate the UUID and only add the "autogenerate"
>>>> keyword in otptoken-add command.
>>>>
>>>> For authorization, we can simply allow users to only add tokens
>>>> with "autogenerate" ID, see my example here:
>>>>
>>>> http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html
>>>>
>>>> Admin's or special privilege-owners would have more generous ACI
>>>> allowing other values than just "autogenerate".
>>>>
>>>> IMO, then the whole ipatoken-add mechanism would be a lot simpler
>>>> and we would not need a special DS plugin (unless we want regular
>>>> users to generate their own UUIDs instead of letting IPA DS to
>>>> generate it
>>>> - which I do not think is the case).
>>>
>>> Good point Martin.
>>
>> This is the avenue I first pursued. The problem is that the client has
>> no way to look up the DN after the entry is added. In the case of
>> sudocmd-add, the lookup is performed using the sudocmd attribute (see
>> sudocmd.get_dn()). We have no similar attribute in this case and the
>> lookup cannot be performed.
>
> Well in theory we could search with creatorName and createTimestamp set
> to the user's own DN and a range a few seconds in the past ...
> It is not robust if you add multiple tokens at the same time, but would
> this be a concern for user created tokens ?
>
> Simo.

Ugh, no offense, but this approach sounds really ugly :-) I will wait for 
Thierry or Ludwig's assessment, but I still think there is either existing 
control for the modify operation to return an updated entry or we could create 
one as you suggest down the thread - as this may be useful for other use cases too.

Martin