Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
On 09/22/2014 09:28 PM, Simo Sorce wrote: On Mon, 22 Sep 2014 21:21:04 +0200 Martin Kosek mko...@redhat.com wrote: 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 generaterename 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@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@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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
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 generaterename 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). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
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 generaterename 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. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
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 generaterename 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. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
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 generaterename 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. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
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 generaterename 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. 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. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
On 09/22/2014 09:14 AM, Nathaniel McCallum 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 generaterename 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. 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. What about the POST READ control? The purpose of this control is to return the contents of the entry (e.g. what would be returned by an LDAP search request) after the update has been applied. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
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 generaterename 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
Re: [Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
On Mon, 22 Sep 2014 21:21:04 +0200 Martin Kosek mko...@redhat.com wrote: 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 generaterename 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. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0069] Adds 389DS plugin to enforce UUID token IDs
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 From aed2d3705a050d24119d2b5124088dfcb76b81d7 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Sun, 21 Sep 2014 14:58:32 -0400 Subject: [PATCH] Adds 389DS plugin to enforce UUID token IDs Users that can rename the token (such as admins) can also create non-UUID token names. https://fedorahosted.org/freeipa/ticket/4456 --- daemons/configure.ac | 1 + daemons/ipa-slapi-plugins/Makefile.am | 1 + .../ipa-slapi-plugins/ipa-otp-tokenid/Makefile.am | 25 +++ .../ipa-otp-tokenid/ipa-otp-tokenid.sym| 1 + .../ipa-otp-tokenid/ipa_otp_tokenid.c | 206 + .../ipa-otp-tokenid/otp-tokenid-conf.ldif | 15 ++ freeipa.spec.in| 2 + ipaserver/install/dsinstance.py| 4 + 8 files changed, 255 insertions(+) create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-tokenid/Makefile.am create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-tokenid/ipa-otp-tokenid.sym create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-tokenid/ipa_otp_tokenid.c create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-tokenid/otp-tokenid-conf.ldif diff --git a/daemons/configure.ac b/daemons/configure.ac index b4507a6d972f854331925e72869898576bdfd76f..55636c9dd62985e54b6bb4599211d96001582d1e 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -315,6 +315,7 @@ AC_CONFIG_FILES([ ipa-slapi-plugins/ipa-enrollment/Makefile ipa-slapi-plugins/ipa-lockout/Makefile ipa-slapi-plugins/ipa-otp-lasttoken/Makefile +ipa-slapi-plugins/ipa-otp-tokenid/Makefile ipa-slapi-plugins/ipa-pwd-extop/Makefile ipa-slapi-plugins/ipa-extdom-extop/Makefile ipa-slapi-plugins/ipa-winsync/Makefile diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am index 06e6ee8b86f138cce05f2184ac98c39ffaf9757f..08ce230686ca4dd16c15f08c40826aefd7023bd8 100644 --- a/daemons/ipa-slapi-plugins/Makefile.am +++ b/daemons/ipa-slapi-plugins/Makefile.am @@ -8,6 +8,7 @@ SUBDIRS = \ ipa-lockout \ ipa-modrdn \ ipa-otp-lasttoken \ + ipa-otp-tokenid \ ipa-pwd-extop \ ipa-extdom-extop \ ipa-uuid \ diff --git a/daemons/ipa-slapi-plugins/ipa-otp-tokenid/Makefile.am b/daemons/ipa-slapi-plugins/ipa-otp-tokenid/Makefile.am new file mode 100644 index ..4889af554c001433b41f7b9e08aa2628e38b6bc7 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-tokenid/Makefile.am @@ -0,0 +1,25 @@ +MAINTAINERCLEANFILES = *~ Makefile.in +PLUGIN_COMMON_DIR = ../common +AM_CPPFLAGS = \ + -I. \ + -I$(srcdir) \ + -I$(PLUGIN_COMMON_DIR) \ + -I/usr/include/dirsrv \ + -DPREFIX=\$(prefix)\ \ + -DBINDIR=\$(bindir)\\ + -DLIBDIR=\$(libdir)\ \ + -DLIBEXECDIR=\$(libexecdir)\ \ + -DDATADIR=\$(datadir)\\ + $(AM_CFLAGS) \ + $(LDAP_CFLAGS) \ + $(WARN_CFLAGS) + +plugindir = $(libdir)/dirsrv/plugins +plugin_LTLIBRARIES = libipa_otp_tokenid.la +libipa_otp_tokenid_la_SOURCES = ipa_otp_tokenid.c +libipa_otp_tokenid_la_LDFLAGS = -avoid-version -export-symbols ipa-otp-tokenid.sym +libipa_otp_tokenid_la_LIBADD = $(LDAP_LIBS) + +appdir = $(IPA_DATA_DIR) +app_DATA = otp-tokenid-conf.ldif +EXTRA_DIST = $(app_DATA) diff --git a/daemons/ipa-slapi-plugins/ipa-otp-tokenid/ipa-otp-tokenid.sym b/daemons/ipa-slapi-plugins/ipa-otp-tokenid/ipa-otp-tokenid.sym new file mode 100644 index ..ed6aaa28c833cfe13f95a3bd0d273b5fcd86 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-tokenid/ipa-otp-tokenid.sym @@ -0,0 +1 @@ +ipa_otp_tokenid_init diff --git a/daemons/ipa-slapi-plugins/ipa-otp-tokenid/ipa_otp_tokenid.c b/daemons/ipa-slapi-plugins/ipa-otp-tokenid/ipa_otp_tokenid.c new file mode 100644 index ..8778ed3aadda98e5beef51b3d06b047b01821f6c --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-otp-tokenid/ipa_otp_tokenid.c @@ -0,0 +1,206 @@ +/** BEGIN COPYRIGHT BLOCK + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 3 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR
