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

[thierry bordaz]

On 09/22/2014 09:28 PM, Simo Sorce wrote:
> On Mon, 22 Sep 2014 21:21:04 +0200
> Martin Kosek <mkosek at redhat.com> wrote:
>
>> 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.
> See following mails, the right approach is to use the POST READ control.
>
> Simo.
>
Hello,

Yes that is correct. Mark implemented it with 
https://fedorahosted.org/389/ticket/589 and is present since 1.3.2.18 (F20)

[root at vm-046 ~]# ldapsearch -LLL -h localhost -p 389 -x -b "" -s base 
supportedcontrol | grep 1.3.6.1.1.13.2
supportedcontrol: 1.3.6.1.1.13.2
[root at vm-046 ~]# uname -a
Linux vm-046.idm.lab.bos.redhat.com 3.13.10-200.fc20.x86_64 #1 SMP Mon 
Apr 14 20:34:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

thanks
thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140923/943fc58d/attachment.htm>