On 09/22/2014 04:55 PM, 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 ?
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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
