On Mon, 22 Sep 2014 11:14:31 -0400 Nathaniel McCallum <npmccal...@redhat.com> wrote:
> On Mon, 2014-09-22 at 10:55 -0400, Simo Sorce wrote: > > On Mon, 22 Sep 2014 10:02:01 -0400 > > Nathaniel McCallum <npmccal...@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 <mko...@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 ? > > That would fundamentally break the import script in which many tokens > are being created by the same user rapidly. But why would you need this in the script ? > In a phone call with mkosek, we tossed around the idea of framework > support for a (preexisting?) control which notifies the client of > changes to the operation. This would notify the client that the > ipatokenUniqueID changed from "autogenerate" to > "86725e75-a307-4c10-9de5-3ce15b963552". This would resolve all > ambiguity. Notifications can be obtained via syncrepl, but that's not a control, it is a full search and wait mechanism, A little too heavy weight for this use IMO. We could add a control that will return you a DN in the operation result though. IT would be relatively simnple to add one, and would be a generic feature useful in all these cases (including sudo as it would allow us to avoid the search, or at least make it a base search which is faster). Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
