<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 09/22/2014 09:28 PM, Simo Sorce wrote: </div> <blockquote cite="mid:20140922152858.42d186fa@willson.usersys.redhat.com" type="cite"> <pre wrap="">On Mon, 22 Sep 2014 21:21:04 +0200 Martin Kosek <a class="moz-txt-link-rfc2396E" href="mailto:mkosek@redhat.com"><mkosek@redhat.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 09/22/2014 04:55 PM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Mon, 22 Sep 2014 10:02:01 -0400 Nathaniel McCallum <a class="moz-txt-link-rfc2396E" href="mailto:npmccallum@redhat.com"><npmccallum@redhat.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On Mon, 2014-09-22 at 09:50 -0400, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Mon, 22 Sep 2014 10:34:54 +0200 Martin Kosek <a class="moz-txt-link-rfc2396E" href="mailto:mkosek@redhat.com"><mkosek@redhat.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 09/22/2014 09:33 AM, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">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: </pre> <blockquote type="cite"> <pre wrap="">Users that can rename the token (such as admins) can also create non-UUID token names. <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/4456">https://fedorahosted.org/freeipa/ticket/4456</a> 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 </pre> </blockquote> </blockquote> <pre wrap=""> 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: <a class="moz-txt-link-freetext" href="http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html">http://www.redhat.com/archives/freeipa-devel/2014-September/msg00438.html</a> 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). </pre> </blockquote> <pre wrap=""> Good point Martin. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> See following mails, the right approach is to use the POST READ control. Simo. </pre> </blockquote> Hello, Yes that is correct. Mark implemented it with <a class="moz-txt-link-freetext" href="https://fedorahosted.org/389/ticket/589">https://fedorahosted.org/389/ticket/589</a> and is present since 1.3.2.18 (F20) <tt>[root@vm-046 ~]# ldapsearch -LLL -h localhost -p 389 -x -b "" -s base supportedcontrol | grep 1.3.6.1.1.13.2</tt><tt> </tt><tt>supportedcontrol: 1.3.6.1.1.13.2</tt><tt> </tt><tt>[root@vm-046 ~]# uname -a</tt><tt> </tt><tt>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</tt> thanks thierry </body> </html>