From tbordaz at redhat.com Wed Oct 1 08:16:58 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 01 Oct 2014 10:16:58 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412110144.3732.23.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542ADA8D.10807@redhat.com> <1412110144.3732.23.camel@redhat.com> Message-ID: <542BB87A.6030606@redhat.com> On 09/30/2014 10:49 PM, Nathaniel McCallum wrote: > On Tue, 2014-09-30 at 18:30 +0200, thierry bordaz wrote: >> On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: >> >>> On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: >>>> On Sun, 21 Sep 2014 22:33:47 -0400 >>>> Nathaniel McCallum wrote: >>>> >>>> Comments inline. >>>> >>>>> + >>>>> +#define ch_malloc(type) \ >>>>> + (type*) slapi_ch_malloc(sizeof(type)) >>>>> +#define ch_calloc(count, type) \ >>>>> + (type*) slapi_ch_calloc(count, sizeof(type)) >>>>> +#define ch_free(p) \ >>>>> + slapi_ch_free((void**) &(p)) >>>> please do not redefine slapi functions, it just makes it harder to know >>>> what you used. >>>> >>>> >>>>> +typedef struct { >>>>> + bool exists; >>>>> + long long value; >>>>> +} counter; >>>> please no typedefs of structures, use "struct counter { ... };" and >>>> reference it as "struct counter" in the code. >>>> >>>> Btw, FWIW you could use a value of -1 to indicate non-existence of the >>>> counter value, given counters can only be positive, this would avoid >>>> the need for a struct. >>>> >>>>> +static int >>>>> +send_error(Slapi_PBlock *pb, int rc, char *template, ...) >>>>> +{ >>>>> + va_list ap; >>>>> + int res; >>>>> + >>>>> + va_start(ap, template); >>>>> + res = vsnprintf(NULL, 0, template, ap); >>>>> + va_end(ap); >>>>> + >>>>> + if (res > 0) { >>>>> + char str[res + 1]; >>>>> + >>>>> + va_start(ap, template); >>>>> + res = vsnprintf(str, sizeof(str), template, ap); >>>>> + va_end(ap); >>>>> + >>>>> + if (res > 0) >>>>> + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); >>>>> + } >>>>> + >>>>> + if (res <= 0) >>>>> + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); >>>>> + >>>>> + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); >>>>> + return rc; >>>>> +} >>>> This function seem not really useful, you use send_error() only at the >>>> end of one single function where you could have the classic scheme of >>>> using a done: label and just use directly slapi_ch_smprintf. This would >>>> remove the need to use vsnprintf and all the va_ machinery which is >>>> more than 50% of this function. >>>> >>>> >>>>> +static long long >>>>> +get_value(const LDAPMod *mod, long long def) >>>>> +{ >>>>> + const struct berval *bv; >>>>> + long long val; >>>>> + >>>>> + if (mod == NULL) >>>>> + return def; >>>>> + >>>>> + if (mod->mod_vals.modv_bvals == NULL) >>>>> + return def; >>>>> + >>>>> + bv = mod->mod_vals.modv_bvals[0]; >>>>> + if (bv == NULL) >>>>> + return def; >>>> In general (here and elsewhere) I prefer to always use {} in if clauses. >>>> I have been bitten enough time by people adding an instruction that >>>> should be in the braces but forgot to add braces (defensive programming >>>> style). But up to you. >>>> >>>>> + char buf[bv->bv_len + 1]; >>>>> + memcpy(buf, bv->bv_val, bv->bv_len); >>>>> + buf[sizeof(buf)-1] = '\0'; >>>>> + >>>>> + val = strtoll(buf, NULL, 10); >>>>> + if (val == LLONG_MIN || val == LLONG_MAX) >>>>> + return def; >>>>> + >>>>> + return val; >>>>> +} >>>>> + >>>>> +static struct berval ** >>>>> +make_berval_array(long long value) >>>>> +{ >>>>> + struct berval **bvs; >>>>> + >>>>> + bvs = ch_calloc(2, struct berval*); >>>>> + bvs[0] = ch_malloc(struct berval); >>>>> + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); >>>>> + bvs[0]->bv_len = strlen(bvs[0]->bv_val); >>>>> + >>>>> + return bvs; >>>>> +} >>>>> + >>>>> +static LDAPMod * >>>>> +make_ldapmod(int op, const char *attr, long long value) >>>>> +{ >>>>> + LDAPMod *mod; >>>>> + >>>>> + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); >>>>> + mod->mod_op = op | LDAP_MOD_BVALUES; >>>>> + mod->mod_type = slapi_ch_strdup(attr); >>>>> + mod->mod_bvalues = make_berval_array(value); >>>>> + >>>>> + return mod; >>>>> +} >>>>> + >>>>> +static void >>>>> +convert_ldapmod_to_bval(LDAPMod *mod) >>>>> +{ >>>>> + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) >>>>> + return; >>>>> + >>>>> + mod->mod_op |= LDAP_MOD_BVALUES; >>>>> + >>>>> + if (mod->mod_values == NULL) { >>>>> + mod->mod_bvalues = NULL; >>>>> + return; >>>>> + } >>>>> + >>>>> + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { >>>>> + struct berval *bv = ch_malloc(struct berval); >>>>> + bv->bv_val = mod->mod_values[i]; >>>>> + bv->bv_len = strlen(bv->bv_val); >>>>> + mod->mod_bvalues[i] = bv; >>>>> + } >>>>> +} >>>>> + >>>>> +static counter >>>>> +get_counter(Slapi_Entry *entry, const char *attr) >>>>> +{ >>>>> + Slapi_Attr *sattr = NULL; >>>>> + >>>>> + return (counter) { >>>>> + slapi_entry_attr_find(entry, attr, &sattr) == 0, >>>>> + slapi_entry_attr_get_longlong(entry, attr) >>>>> + }; >>>>> +} >>>>> + >>>>> +static void >>>>> +berval_free_array(struct berval ***bvals) >>>>> +{ >>>>> + for (size_t i = 0; (*bvals)[i] != NULL; i++) { >>>>> + ch_free((*bvals)[i]->bv_val); >>>>> + ch_free((*bvals)[i]); >>>>> + } >>>>> + >>>>> + slapi_ch_free((void**) bvals); >>>>> +} >>>>> + >>>>> +static bool >>>>> +is_replication(Slapi_PBlock *pb) >>>>> +{ >>>>> + int repl = 0; >>>>> + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); >>>>> + return repl != 0; >>>>> +} >>>>> + >>>>> +static const char * >>>>> +get_attribute(Slapi_Entry *entry) >>>>> +{ >>>>> + static struct { >>>>> + const char *clss; >>>>> + const char *attr; >>>>> + } table[] = { >>>>> + { "ipatokenHOTP", "ipatokenHOTPcounter" }, >>>>> + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, >>>>> + { NULL, NULL } >>>>> + }; >>>>> + >>>>> + const char *attr = NULL; >>>>> + char **clsses = NULL; >>>>> + >>>>> + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); >>>>> + if (clsses == NULL) >>>>> + return NULL; >>>>> + >>>>> + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { >>>>> + for (size_t j = 0; attr == NULL && table[j].clss != NULL; >>>>> j++) { >>>>> + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) >>>>> + attr = table[j].attr; >>>>> + } >>>>> + } >>>>> + >>>>> + slapi_ch_array_free(clsses); >>>>> + return attr; >>>>> +} >>>> Can you put a comment here that explains what you are going to do in >>>> each cases in plain English ? This will help people in future figuring >>>> out if/how to modify the code or why something happens a specific way. >>>> It will also help the reviewer follow what is going on. >>>> >>>> >>>>> +static int >>>>> +preop_mod(Slapi_PBlock *pb) >>>>> +{ >>>>> + size_t count = 0, attrs = 0, extras = 0; >>>>> + Slapi_Entry *entry = NULL; >>>>> + const char *attr = NULL; >>>>> + LDAPMod **inmods = NULL; >>>>> + LDAPMod **mods = NULL; >>>>> + counter ctr, orig; >>>>> + >>>>> + /* Get the input values. */ >>>>> + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); >>>>> + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); >>>>> + if (entry == NULL || inmods == NULL) >>>>> + return 0; >>>>> + >>>>> + /* Get the attribute name. */ >>>>> + attr = get_attribute(entry); >>>>> + if (attr == NULL) >>>>> + return 0; /* Not a token. */ >>>>> + >>>>> + /* Count items. */ >>>>> + while (inmods != NULL && inmods[count] != NULL) { >>>> ^^ this one would read much better as: >>>> for (count = 0; inmods[count] != NULL; count++) { >>>> >>>> You do not need to check for insmods != NULL as you already check for >>>> it and return 0 a few lines above. >>>> >>>>> + LDAPMod *mod = inmods[count++]; >>>>> + >>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>>>> + continue; >>>>> + >>>>> + attrs++; >>>>> + switch (mod->mod_op & LDAP_MOD_OP) { >>>>> + case LDAP_MOD_REPLACE: >>>>> + case LDAP_MOD_INCREMENT: >>>>> + extras++; >>>>> + break; >>>>> + } >>>>> + } >>>>> + >>>>> + /* Not operating on the counter/watermark. */ >>>>> + if (attrs == 0) >>>>> + return 0; >>>>> + >>>>> + /* Get the counter. */ >>>>> + orig = ctr = get_counter(entry, attr); >>>>> + >>>>> + /* Filter the modify operations. */ >>>>> + mods = ch_calloc(count + extras + 1, LDAPMod*); >>>>> + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; >>>>> mods[j++] = inmods[i++]) { >>>> Please remove check for insmods != NULL, it is useless, and removing it >>>> will bring back the line under 80columns >>>> >>>>> + LDAPMod *mod = inmods[i]; >>>>> + >>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>>>> + continue; >>>>> + >>>>> + convert_ldapmod_to_bval(mod); >>>>> + >>>>> + switch (mod->mod_op & LDAP_MOD_OP) { >>>>> + case LDAP_MOD_DELETE: >>>>> + ctr.exists = false; >>>>> + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == >>>>> NULL) >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + >>>>> + if (is_replication(pb)) >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + >>>>> + if (mod->mod_bvalues == NULL) >>>>> + mod->mod_bvalues = make_berval_array(ctr.value); >>>>> + break; >>>> I am not sure I understand this segment, why are you touching the >>>> delete operation outside of a replication event ? >>>> Doesn't this defeat and admin tool trying to correctly delete/add to >>>> avoid races ? >>>> >>>>> + case LDAP_MOD_INCREMENT: >>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>>>> ctr.value); + >>>>> + ctr.value += get_value(mod, 1); >>>> uhmmm if you had an ADD followed by INCREMENT operation, would this >>>> cause the value to become value*2+1 instead of just value+1 ? >>>> >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + mod->mod_op &= ~LDAP_MOD_OP; >>>>> + mod->mod_op |= LDAP_MOD_ADD; >>>>> + mod->mod_bvalues = make_berval_array(ctr.value); >>>>> + break; >>>> uhmm why are you converting mod_increment in all cases ? (including >>>> replication) >>>> >>>>> + case LDAP_MOD_REPLACE: >>>>> + if (ctr.exists) >>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>>>> ctr.value); + >>>>> + mod->mod_op &= ~LDAP_MOD_OP; >>>>> + mod->mod_op |= LDAP_MOD_ADD; >>>> same question here, why are you converting a replace coming from >>>> replication into a delete/add ? >>>> >>>>> + case LDAP_MOD_ADD: >>>>> + ctr.value = get_value(mod, 0); >>>>> + ctr.exists = true; >>>>> + break; >>>>> + } >>>>> + } >>>>> + >>>>> + /* Set the modified operations. */ >>>>> + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); >>>>> + ch_free(inmods); >>>>> + >>>>> + /* Ensure we aren't deleting the counter. */ >>>>> + if (orig.exists && !ctr.exists) >>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>>>> + "Will not delete %s", attr); >>>>> + >>>>> + /* Ensure we aren't rolling back the counter. */ >>>>> + if (orig.value > ctr.value) >>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>>>> + "Will not decrement %s", attr); >>>>> + >>>>> + return 0; >>>>> +} >>>> see above about send_error(). >>>> >>>> I think what is needed most is the comment that explains the process >>>> at the to of the main function. >>>> >>>> Simo. >>> All of the above are fixed. >>> >>> Also, I have addressed Thierry's concern about putting the plugin in >>> betxnpreoperation by splitting the plugin into two phases: modification >>> and validation. Now all modifications occur in bepreoperation and all >>> validation occurs in betxnpreoperation. >>> >>> Additionally, I have new code to trigger a new replication in the case >>> where a validation error occurs and we are in a replication transaction. >>> Thus, when A attempts to push an old counter value to B, B will now >>> replicate the latest value back to A. >>> >>> Nathaniel >>> >> Hello, >> >> The plugin looks very good I have very few comments: >> trigger_replication, prepare the pblock for internal op but >> does not call slapi_modify_internal_pb. >> >> At the end of txnpreop_mod, you may prefer to use >> PR_snprintf(msg, sizeof(msg), "%s %s", err, attr) rather than >> strcpy/strcat. >> >> Reading the fix, I still have problems to understand how >> replicated updates will behave. >> Let me give an example of my concern: >> The initial value of the counter is 10. >> On server A, the counter is updated MOD/REPL to the value >> 11/csnA >> On server B, the counter is updated MOD/REPL to the value >> 12/csnB >> For some reason csnB> On server A, MOD/REPL is translated into (DEL 10+ADD 11)/csnA. >> current value is then 11/csnA >> On server B, MOD/REPL is translated into (DEL 10+ADD 12)/csnB. >> current value is then 12/csnB >> >> When server A receives the operation value 12/csnB. preop_mod >> translates it into (DEL 11/ADD 12)/csnB. txnpreop_mod accepts >> the operation because orig.value (11) < ctr.value (12). >> Unfortunately when the operation will be applied the final >> value kept for the counter will be 11 because csnA>csnB. >> >> When server B receives the operation value 11/csnA. preop_mod >> translates it into (DEL 12/ADD 11)/csn A. txnpreop_mod reject >> the operation, updates (DEL 12/ADD 12)/csnB' and returns >> unwilling_to_perform. Later the update csnB' will be sent to A >> but server A will still be in problem to send csnA update. > I see only two ways to solve this problem: > > 1. We modify the CSN upon receipt. I think it is difficult to evaluate all the impacts. the received CSN needs to go into the server RUV (else replication will try again and again to send the same update). Changing the CSN in the operation is also difficult because we need to choose/generate a new CSN. > > 2. We compare the received replication request's CSN with the current > value and perform the writes ourselves. > > I don't think #2 is workable because it will cause a replication storm. > I'm not sure about #1. Suggestions? Actually I was thinking to something like your #2 (see https://lists.fedoraproject.org/pipermail/389-devel/2014-September/003629.html). The difference is that I think we do not need to do additional writes. The problem only occurs with replicated updates. For ldap client update txnpreop_mod is doing the job. When the replicated update is received we have the original value, the new value and the final value (computed by replication urp). The plugin would determine what will be the final value. If the final value < current value, then the plugin could just erase the ADD/DEL from the mods and let the operation continue. If the final value > current value, the plugin would let the operation continue. So a replicated update is always applied (even if counter value is not updated) and replication can continue. To do this the plugin should do the same kind of computation that urp is doing. Possibly duplicate the entry and call entry_apply_mods_wsi (with operation csn). Then compare the original value with the value in the duplicated entry. That means that preop_mod for replicated update, should compute the final value, compare it with current value. Then possibly erase DEL/ADD. In txnpreop_mod, for replicated update there is no work to do as preop_mod already did mods update and value control. > >> You mentioned that synchronize replication was needed. Do you >> mean we need 'synchronous replication' to address the example >> above ? > I think I was referring to this: > http://www.freeipa.org/page/V4/OTPReplayPrevention#Synchronous_Synchronization Ok. I think this address the problem of having different values of a same counter across a set of replication server. It is not exactly the problem I mentioned above. thanks thierry > > Nathaniel > > > From tbabej at redhat.com Wed Oct 1 09:09:19 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 01 Oct 2014 11:09:19 +0200 Subject: [Freeipa-devel] WFH 2014-10-01 Message-ID: <542BC4BF.5000801@redhat.com> -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tbabej at redhat.com Wed Oct 1 09:17:11 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 01 Oct 2014 11:17:11 +0200 Subject: [Freeipa-devel] WFH 2014-10-01 In-Reply-To: <542BC4BF.5000801@redhat.com> References: <542BC4BF.5000801@redhat.com> Message-ID: <542BC697.7050205@redhat.com> Sorry about the noise, my autocompletion somehow filled in a wrong address. On 10/01/2014 11:09 AM, Tomas Babej wrote: -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Wed Oct 1 10:45:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 01 Oct 2014 12:45:13 +0200 Subject: [Freeipa-devel] [PATCH] 0651 - test_service_plugin: Do not lowercase memberof_role Message-ID: <542BDB39.3010707@redhat.com> Additional test fix for the (long-closed) ticket #4192 Pushed under the one-liner rule to: master: 3eca0ff2fe0dc768d5d8645579b243e4328bfb63 ipa-4-1: 9ee2c25487018aa923bb8d18d3df1c9e96638148 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0651-test_service_plugin-Do-not-lowercase-memberof_role.patch Type: text/x-patch Size: 1147 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 1 11:42:16 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 01 Oct 2014 13:42:16 +0200 Subject: [Freeipa-devel] [PATCH 130] Missing DNS tests Message-ID: <542BE898.6070004@redhat.com> This patch adds 2 missing DNS tests: * removing non-existent permission * removing idnssoamname value using dnszone-mod --name-server= Patch attached, belongs to ipa-4-1 and master branches. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0130-DNS-missing-tests.patch Type: text/x-patch Size: 1788 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 1 14:27:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 01 Oct 2014 16:27:05 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Do not require description in UI. In-Reply-To: <54293B06.5080902@redhat.com> References: <542913D6.8020006@redhat.com> <542916C9.9040409@redhat.com> <5429209C.6090005@redhat.com> <54293B06.5080902@redhat.com> Message-ID: <542C0F39.4020907@redhat.com> On 29/09/14 12:57, Martin Kosek wrote: > On 09/29/2014 11:04 AM, David Kupka wrote: >> On 09/29/2014 10:22 AM, Martin Kosek wrote: >>> On 09/29/2014 10:09 AM, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4387 >>> The changes look OK so far, except the test fix. >>> >>> The test_batch_plugin.py test is apparently testing that batch command behaves >>> well in RequirementError for options. Thus, we should not remove it, we should >>> just pick different option. Like filling uid+first options with user-add, but >>> missing the --last option. >>> >>> Martin >>> >> Ok, but the test is bit redundant as there is already test for missing >> givenname that should behave the same way. > I think it is useful to keep the test here, in the previous one no option was > added. > > Anyway, this should not stop this patch from going in. I checked the test > results + Web UI and all looks OK. > > ACK. Pushed to: > master: cd9a4cca1fe17998a342fde000ece5bf46d13d27 > ipa-4-1: b69510b9bf8216d52707968bf520fd2dfa6e1ba7 > > Thanks, > Martin Shouldn't be API minor version incremented? -- Martin Basti From pviktori at redhat.com Wed Oct 1 14:35:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 01 Oct 2014 16:35:17 +0200 Subject: [Freeipa-devel] [PATCH] 0652 - backup/restore: Add files from /etc/ipa/nssdb Message-ID: <542C1125.7030906@redhat.com> https://fedorahosted.org/freeipa/ticket/4597 Honza, does this look right? Does the database at the old location still need to be backed up? I don't have much insight into the /etc/ipa/nssdb changes. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0652-backup-restore-Add-files-from-etc-ipa-nssdb.patch Type: text/x-patch Size: 2262 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 1 14:38:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 01 Oct 2014 16:38:51 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Do not require description in UI. In-Reply-To: <542C0F39.4020907@redhat.com> References: <542913D6.8020006@redhat.com> <542916C9.9040409@redhat.com> <5429209C.6090005@redhat.com> <54293B06.5080902@redhat.com> <542C0F39.4020907@redhat.com> Message-ID: <542C11FB.9010209@redhat.com> On 10/01/2014 04:27 PM, Martin Basti wrote: > On 29/09/14 12:57, Martin Kosek wrote: >> On 09/29/2014 11:04 AM, David Kupka wrote: >>> On 09/29/2014 10:22 AM, Martin Kosek wrote: >>>> On 09/29/2014 10:09 AM, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4387 >>>> The changes look OK so far, except the test fix. >>>> >>>> The test_batch_plugin.py test is apparently testing that batch command behaves >>>> well in RequirementError for options. Thus, we should not remove it, we should >>>> just pick different option. Like filling uid+first options with user-add, but >>>> missing the --last option. >>>> >>>> Martin >>>> >>> Ok, but the test is bit redundant as there is already test for missing >>> givenname that should behave the same way. >> I think it is useful to keep the test here, in the previous one no option was >> added. >> >> Anyway, this should not stop this patch from going in. I checked the test >> results + Web UI and all looks OK. >> >> ACK. Pushed to: >> master: cd9a4cca1fe17998a342fde000ece5bf46d13d27 >> ipa-4-1: b69510b9bf8216d52707968bf520fd2dfa6e1ba7 >> >> Thanks, >> Martin > > Shouldn't be API minor version incremented? > Hrm, it should have! But it will not make sense to do it now, API was already bumped (and released in Alpha) for the Views... Martin From pvoborni at redhat.com Wed Oct 1 16:15:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 01 Oct 2014 18:15:22 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management Message-ID: <542C289A.6040301@redhat.com> Hello list, Patch for: https://fedorahosted.org/freeipa/ticket/4419 Before I start any work on Web UI and tests I would like to gather feedback on: - the new API - member attributes with subtypes management approach - ACI I did not do any ACI work in the patch yet. I assume that we would like to add the attr into 'System: Read Host|Service' permission. But I think that write right should have it's own permission. Patch info: Adds new API: ipa host-add-retrieve-keytab HOSTNAME --users=STR --groups=STR ipa host-add-write-keytab HOSTNAME --users=STR --groups=STR ipa host-remove-retrieve-keytab HOSTNAME --users=STR --groups=STR ipa host-remove-write-keytab HOSTNAME --users=STR --groups=STR ipa service-add-retrieve-keytab PRINCIPAL --users=STR --groups=STR ipa service-add-write-keytab PRINCIPAL --users=STR --groups=STR ipa service-remove-retrieve-keytab PRINCIPAL --users=STR --groups=STR ipa service-remove-write-keytab PRINCIPAL --users=STR --groups=STR these methods add or remove user or group DNs in `ipaallowedtoperform` attr with `read_keys` and `write_keys` subtypes. service|host-mod|show outputs these attrs only with --all option as: Users allowed to retrieve keytab: user1 Groups allowed to retrieve keytab: group1 Users allowed to write keytab: user1 Groups allowed to write keytab: group1 1) This patch implements subtypes support for attributes members. It's done to be relatively reusable but it's confined within the RFE boundaries. I.e. it does not contain support for standard attributes or is not integrated into LDAPAddMember or LDAPRemoveMember commands. It's rather as separate opt-ins. One of the reasons was also not to disturb existing code at the end of 4-1 milestone. 2) I tried to keep the command names or attr label short, but they are still long like a novel. Any shorter recommendations are welcome. 3) Adding of object class is implemented as a reusable method since this code is used on many places and most likely will be also used in new features. Older code may be refactored later. Thanks -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0761-keytab-manipulation-permission-management.patch Type: text/x-patch Size: 26467 bytes Desc: not available URL: From abokovoy at redhat.com Wed Oct 1 16:16:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 1 Oct 2014 19:16:06 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree Message-ID: <20141001161606.GA6186@redhat.com> Hi! Attached are patches to add support of FreeIPA ID views to Schema compatibility plugin (slapi-nis). There are two patches for FreeIPA and a separate patch for slapi-nis. Patches can be applied independently; if old slapi-nis is installed, it will simply work with new configuration but do nothing with respect to answering to requests using host-specific ID views. I included documentation on how slapi-nis ID views feature supposed to work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes are welcome. There are no additional tests in slapi-nis to cover compat trees, we have multiple tests in FreeIPA for this purpose, will be run as part of FreeIPA CI effort. FreeIPA patches add ACIs for accessing ID view-applied entries over compat tree. They also include additional configuration; this configuration is needed to properly resolve ID view overrides when creating compat entries. A second FreeIPA patch adds support to override login shell. This part was missing from the original patchset by Tomas. For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit Bose. There is also a regression (fixed by Sumit as well) that prevents authentication of AD users over PAM which affects authentication over compat tree. With the patch from Sumit authentication works again, both with ID view and without it. -- / Alexander Bokovoy -------------- next part -------------- From 400a6fe320ff5d92311a670e596aba486a8a3bc0 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Sep 2014 14:54:50 +0300 Subject: [PATCH 2/4] Support idviews in compat tree https://fedorahosted.org/freeipa/ticket/3318 --- ACI.txt | 6 ++++++ install/share/71idviews.ldif | 1 + install/share/schema_compat.uldif | 8 ++++++++ install/updates/10-schema_compat.update | 12 ++++++++++++ ipalib/plugins/group.py | 10 ++++++++++ ipalib/plugins/user.py | 11 +++++++++++ ipaserver/install/plugins/update_managed_permissions.py | 11 +++++++++++ 7 files changed, 59 insertions(+) diff --git a/ACI.txt b/ACI.txt index cebdc2c..87c057e 100644 --- a/ACI.txt +++ b/ACI.txt @@ -54,6 +54,8 @@ dn: dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=groups,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "member || memberhost || memberof || memberuid || memberuser")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Group Membership";allow (compare,read,search) userdn = "ldap:///all";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=groups,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "businesscategory || cn || createtimestamp || description || entryusn || gidnumber || ipaexternalmember || ipantsecurityidentifier || ipauniqueid || mepmanagedby || modifytimestamp || o || objectclass || ou || owner || seealso")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Groups";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example @@ -256,6 +258,8 @@ dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "memberof")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Membership";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || displayname || entryusn || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || modifytimestamp || objectclass || sn || title || uid || uidnumber")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Standard Attributes";allow (compare,read,search) userdn = "ldap:///anyone";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gecos || gidnumber || homedirectory || loginshell || modifytimestamp || objectclass || uid || uidnumber")(target = "ldap:///cn=users,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read User Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Remove Users";allow (delete) groupdn = "ldap:///cn=System: Remove Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example @@ -264,6 +268,8 @@ dn: cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example aci: (target = "ldap:///cn=caSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example")(targetfilter = "(objectclass=pkiuser)")(version 3.0;acl "permission:System: Add CA Certificate For Renewal";allow (add) groupdn = "ldap:///cn=System: Add CA Certificate For Renewal,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetfilter = "(objectclass=ipacertificate)")(version 3.0;acl "permission:System: Add Certificate Store Entry";allow (add) groupdn = "ldap:///cn=System: Add Certificate Store Entry,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: dc=ipa,dc=example +aci: (targetattr = "ipaanchoruuid")(target = "ldap:///cn=*,cn=compat,dc=ipa,dc=example")(targetfilter = "(objectclass=ipaOverrideTarget)")(version 3.0;acl "permission:System: Compat Tree ID View targets";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=CAcert,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetattr = "cacertificate")(targetfilter = "(objectclass=pkica)")(version 3.0;acl "permission:System: Modify CA Certificate";allow (write) groupdn = "ldap:///cn=System: Modify CA Certificate,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example diff --git a/install/share/71idviews.ldif b/install/share/71idviews.ldif index 3f8df2e..caa5cff 100644 --- a/install/share/71idviews.ldif +++ b/install/share/71idviews.ldif @@ -5,3 +5,4 @@ objectClasses: (2.16.840.1.113730.3.8.12.29 NAME 'ipaIDView' SUP nsContainer STR objectClasses: (2.16.840.1.113730.3.8.12.30 NAME 'ipaOverrideAnchor' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) MAY ( description ) X-ORIGIN 'IPA v4' ) objectClasses: (2.16.840.1.113730.3.8.12.31 NAME 'ipaUserOverride' DESC 'Override for User Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( uid $ uidNumber $ gidNumber $ homeDirectory $ loginShell $ gecos $ ipaOriginalUid ) X-ORIGIN 'IPA v4' ) objectClasses: (2.16.840.1.113730.3.8.12.32 NAME 'ipaGroupOverride' DESC 'Override for Group Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( gidNumber $ cn ) X-ORIGIN 'IPA v4' ) +objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) diff --git a/install/share/schema_compat.uldif b/install/share/schema_compat.uldif index 6de812f..6769fd1 100644 --- a/install/share/schema_compat.uldif +++ b/install/share/schema_compat.uldif @@ -38,6 +38,10 @@ default:schema-compat-entry-attribute: uidNumber=%{uidNumber} default:schema-compat-entry-attribute: gidNumber=%{gidNumber} default:schema-compat-entry-attribute: loginShell=%{loginShell} default:schema-compat-entry-attribute: homeDirectory=%{homeDirectory} +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","") +default:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} +default:schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") dn: cn=groups, cn=Schema Compatibility, cn=plugins, cn=config default:objectClass: top @@ -52,6 +56,10 @@ default:schema-compat-entry-attribute: objectclass=posixGroup default:schema-compat-entry-attribute: gidNumber=%{gidNumber} default:schema-compat-entry-attribute: memberUid=%{memberUid} default:schema-compat-entry-attribute: memberUid=%deref_r("member","uid") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","") +default:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} +default:schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config add:objectClass: top diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update index aeddadb..e88b492 100644 --- a/install/updates/10-schema_compat.update +++ b/install/updates/10-schema_compat.update @@ -47,3 +47,15 @@ dn: cn=Schema Compatibility,cn=plugins,cn=config # rewritten to the original entry if needed add:nsslapd-pluginprecedence: 49 +dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","")' +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","")' +add:schema-compat-entry-attribute: 'ipaanchoruuid=%{ipaanchoruuid}' +add:schema-compat-entry-attribute: '%ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","")' + +dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","")' +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","")' +add:schema-compat-entry-attribute: 'ipaanchoruuid=%{ipaanchoruuid}' +add:schema-compat-entry-attribute: '%ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","")' + diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index 9c2e308..03e6893 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -212,6 +212,16 @@ class group(LDAPObject): 'objectclass', 'cn', 'memberuid', 'gidnumber', }, }, + 'System: Read Group Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=groups', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'cn', 'memberuid', 'gidnumber', + }, + }, } label = _('User Groups') diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index f95b4fd..e206289 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -435,6 +435,17 @@ class user(LDAPObject): 'homedirectory', 'loginshell', }, }, + 'System: Read User Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=users', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'uid', 'cn', 'gecos', 'gidnumber', 'uidnumber', + 'homedirectory', 'loginshell', + }, + }, } label = _('Users') diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py index df49d5d..032485a 100644 --- a/ipaserver/install/plugins/update_managed_permissions.py +++ b/ipaserver/install/plugins/update_managed_permissions.py @@ -117,6 +117,17 @@ NONOBJECT_PERMISSIONS = { }, 'default_privileges': {'IPA Masters Readers'}, }, + 'System: Compat Tree ID View targets': { + 'replaces_global_anonymous_aci': True, + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=*,cn=compat', api.env.basedn), + 'ipapermtargetfilter': {'(objectclass=ipaOverrideTarget)'}, + 'ipapermbindruletype': 'anonymous', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'ipaAnchorUUID', + }, + }, 'System: Read DNA Configuration': { 'replaces_global_anonymous_aci': True, 'ipapermlocation': DN('cn=dna,cn=ipa,cn=etc', api.env.basedn), -- 2.1.0 -------------- next part -------------- From 1d8f69a01cd1fa7413bc73f6081c5d40aefebbea Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Sep 2014 15:44:31 +0300 Subject: [PATCH 4/4] Support overridding user shell in ID views https://fedorahosted.org/freeipa/ticket/3318 --- ACI.txt | 2 +- API.txt | 9 ++++++--- ipalib/plugins/idviews.py | 8 ++++++-- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/ACI.txt b/ACI.txt index 87c057e..b2192ce 100644 --- a/ACI.txt +++ b/ACI.txt @@ -123,7 +123,7 @@ aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:S dn: cn=views,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || entryusn || gidnumber || ipaanchoruuid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System: Read Group ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "createtimestamp || description || entryusn || homedirectory || ipaanchoruuid || ipaoriginaluid || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "createtimestamp || description || entryusn || homedirectory || ipaanchoruuid || ipaoriginaluid || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ranges,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipabaseid || ipabaserid || ipaidrangesize || ipanttrusteddomainsid || iparangetype || ipasecondarybaserid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaidrange)")(version 3.0;acl "permission:System: Read ID Ranges";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index c5e76c7..41b852b 100644 --- a/API.txt +++ b/API.txt @@ -2104,7 +2104,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,10,3 +args: 2,11,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2112,6 +2112,7 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') option: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', required=False) @@ -2130,7 +2131,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: idoverrideuser_find -args: 2,12,4 +args: 2,13,4 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -2138,6 +2139,7 @@ option: Str('description', attribute=True, autofill=False, cli_name='desc', mult option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, query=True, required=False) option: Str('ipaanchoruuid', attribute=True, autofill=False, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, query=True, required=False) +option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Int('sizelimit?', autofill=False, minvalue=0) @@ -2150,7 +2152,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,13,3 +args: 2,14,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2159,6 +2161,7 @@ option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) option: Flag('rights', autofill=True, default=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index 3b0df02..afaa6f9 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -650,14 +650,14 @@ class idoverrideuser(baseidoverride): 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { 'objectClass', 'ipaAnchorUUID', 'uidNumber', 'description', - 'homeDirectory', 'uid', 'ipaOriginalUid', + 'homeDirectory', 'uid', 'ipaOriginalUid', 'loginShell', }, }, } object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ - 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', + 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', ] takes_params = baseidoverride.takes_params + ( @@ -679,6 +679,10 @@ class idoverrideuser(baseidoverride): cli_name='homedir', label=_('Home directory'), ), + Str('loginshell?', + cli_name='shell', + label=_('Login shell'), + ), Str('ipaoriginaluid?', flags=['no_option', 'no_output'] ), -- 2.1.0 -------------- next part -------------- From 30b5a09cf410fbafb52ab069ebb1ae854eeba8dd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 29 Jul 2014 12:04:34 +0300 Subject: [PATCH] Add support for FreeIPA ID views FreeIPA ID views allow to override POSIX attributes for certain users and groups. A support is added to allow using specific ID view when serving compatibility tree. Each user or group entry which has an override in the view is amended with the overridden values from the view before served out to the LDAP client. A view to use is specified as a part of base DN: cn=,cn=views,cn=compat,$SUFFIX where cn=compat,$SUFFIX is the original compatibility tree base DN. Each entry, when served through the view, gets new DN rewritten to specify the view. Additionally, if override in the view changes uid (for users) or cn (for groups) attribute, the entry's RDN is changed accordingly. For groups memberUid attribute is modified as well in case there is an override in the view that changes uid value of that member. FreeIPA ID views support overrides for users of trusted Active Directory domains. In case of a trusted AD domain's user or group is returned via compatibility tree, view overrides are applied in two stages: 1. SSSD applies default view for AD users 2. slapi-nis applies explicitly specified (host-specific) view on top of the entry returned by SSSD Thus, slapi-nis does not need to apply default view for AD users and if there are no host-specific views in use, there is no need to specify a view in the base DN, making overhead of a default view for AD users lower. --- configure.ac | 14 ++ doc/ipa/sch-ipa.txt | 93 +++++++++++++ src/Makefile.am | 4 + src/back-sch-idview.c | 376 ++++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch-nss.c | 63 ++++++--- src/back-sch.c | 62 +++++++-- src/back-sch.h | 35 +++++ 7 files changed, 618 insertions(+), 29 deletions(-) create mode 100644 src/back-sch-idview.c diff --git a/configure.ac b/configure.ac index 84b84d1..71dbdc7 100644 --- a/configure.ac +++ b/configure.ac @@ -383,6 +383,20 @@ if test "x$use_nsswitch" != xno ; then AC_DEFINE(USE_NSSWITCH,1,[Use nsswitch API to lookup users and groups not found in the LDAP tree]) fi +use_idviews=true +AC_ARG_WITH(idviews, + AS_HELP_STRING([--with-idviews], [Use FreeIPA ID views to override POSIX IDs of users and groups]), + use_idviews=$withval,use_idviews=yes) +if test "x$use_idviews" = xyes ; then + AC_MSG_RESULT([FreeIPA ID views support is enabled]) + AC_DEFINE(USE_IPA_IDVIEWS,1,[Use FreeIPA ID views to override POSIX attributes of users and groups per view.]) + AC_DEFINE(IPA_IDVIEWS_ATTR_ANCHORUUID, ["ipaAnchorUUID"],[FreeIPA attr unique pointer for id overrides]) + AC_DEFINE(IPA_IDVIEWS_ATTR_ORIGINALUID, ["ipaOriginalUid"],[FreeIPA attr original uid value for user id overrides]) +else + AC_MSG_RESULT([FreeIPA ID views support is disabled]) +fi +AM_CONDITIONAL([USE_IPA_IDVIEWS], [test "x$use_idviews" != xno]) + mylibdir=`eval echo "$libdir" | sed "s,NONE,${ac_default_prefix},g"` mylibdir=`eval echo "$mylibdir" | sed "s,NONE,${ac_prefix},g"` case "$server" in diff --git a/doc/ipa/sch-ipa.txt b/doc/ipa/sch-ipa.txt index b5a585b..f560580 100644 --- a/doc/ipa/sch-ipa.txt +++ b/doc/ipa/sch-ipa.txt @@ -87,3 +87,96 @@ on IPA masters. As 'system-auth' PAM service is not used directly by any other application, it is safe to use it for trusted domain users via compatibility path. + +== Support for ID views == + +When FreeIPA 4.1 is in use, Schema compatibility plugin can be configured to +override POSIX attributes according to an identity view (ID View) which +contains overrides for users and groups. + +The overrides are managed by FreeIPA separately for users and groups: + +* management of ID views: + ipa idview-add 'my view' + +* management of an override for a user: + ipa idoverrideuser-add 'my view' auser --login=foo --shell=/bin/ksh \ + --homedir=/home/foo --uid=12345 + +* management of an override for a group: + ipa idoverridegroup-add 'my view' agroup --group-name=bgroup --gid=54321 + +FreeIPA transparently supports overrides for users and groups from trusted AD +domains. This means that for trusted domains, IPA doesn't require to place +POSIX attributes in Active Directory. Instead, a global ID view named 'Default +Trust View' is used to contain POSIX attributes for existing AD users. +Additionally, specialized ID views can be added on top of the 'Default Trust +View' and then assigned to specific hosts. + +Schema compatibility plugin does support ID overrides from a single view. The +feature is designed to allow host-specific ID view, where the view is specified +through the search base. + +For native IPA users default POSIX attributes are stored natively, thus only a +host-specific ID view is applied, if any. For trusted AD users 'Default Trust +View' ID view is applied automatically by SSSD running on the IPA master, thus +Schema compatibility plugin only applies a host-specific ID view, if specified. + +In FreeIPA Schema compatibility is configured to serve entries through the +host-specific ID view with base DN of cn=,cn=views,cn=compat,$SUFFIX. + +=== ID views implementation === +Detailed design of ID views in FreeIPA can be seen here: +http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust + +In Schema compatibility plugin support for ID views is done on top of existing +map cache. It is expected that there are less overrides than non-overridden +entries for IPA users and groups. For trusted AD users POSIX attributes from +'Default Trust View' are applied by SSSD on IPA master. Thus, if there are no +host-specific overrides, trusted AD users treated by Schema compatibility +plugin as before -- as entries which content comes from nssswitch API. + +This approach allows to only keep original entry in the memory and apply +host-specific override only at the time when entry with explicitly requested ID +view is returned as part of a search result. + +In order to map original entry to an override, FreeIPA configuration for Schema +compatibility plugin adds ipaAnchorUUID attribute and ipaOverrideTarget object +class to every generated entry. ipaAnchorUUID is based on ipaUniqueID for IPA +objects and on SID for trusted AD objects: + +* ipaAnchorUUID=:IPA:: for IPA object (user, group)_ + +* ipaAnchorUUID=:SID: for trusted AD user or group + +For ID overrides FreeIPA maintains ipaAnchorUUID with the same value so that an +override can be found by simple matching of the ipaAnchorUUID attribute's +value. FreeIPA also stores original uid value for user objects in ID override +as ipaOriginalUid attribute, to allow mapping back memberUid values for groups. + +When a query request comes, the view in the base DN is detected and remembered. +Base DN is rewritten to exclude the cn=,cn=views so that a normal +search can be performed against cached entries. Additionally, search filter is +analyzed to replace references to rewritten uid (for user) and cn (for group) +attributes by references to the original objects. The references come from the +ID view overrides, if they exist. + +Once search results are gathered for the map, they are processed in order to +apply an override. For users entry attributes overridden with the values from +an override. For groups additional processing is performed on values of +memberUid attribute. + +As opposed to member attribute, memberUid attribute contains only values of uid +attribute of the original member entry. Given that an ID override may redefine +uid value, corresponding memberUid value of a group needs to be rewritten to +include redefined uid value. In order to do that, original memberUid value is +compared with ipaOriginalUid attribute's value to find an override +corresponding to the original user object. If such override is detected, memberUid +value is replaced by the uid value of the override. + +When attributes of the entry are processed and optionally amended with overridden +values, DN of the entry is rewritten as well, to reflect the fact that entry is +served through the view. + +For all returned entries ipaAnchorUUID attribute and ipaOverrideTarget objectclass +are removed. Resulting entry is sent to the client. diff --git a/src/Makefile.am b/src/Makefile.am index e4fe1a9..6f4926e 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -78,6 +78,10 @@ schemacompat_plugin_la_SOURCES += back-sch-pam.c schemacompat_plugin_la_LIBADD += $(PAM_LIBS) endif +if USE_IPA_IDVIEWS +schemacompat_plugin_la_SOURCES += back-sch-idview.c +endif + noinst_LTLIBRARIES = dummy-nis-plugin.la dummy_nis_plugin_la_SOURCES = \ disp-nis.c \ diff --git a/src/back-sch-idview.c b/src/back-sch-idview.c new file mode 100644 index 0000000..9f4025a --- /dev/null +++ b/src/back-sch-idview.c @@ -0,0 +1,376 @@ +/* + * Copyright 2014 Red Hat, Inc. + * + * 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; version 2 of the License. + * + * 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 PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + +#include +#include "../yp/yp.h" + +#ifdef HAVE_TCPD_H +#include +#endif + +#include "backend.h" +#include "back-shr.h" +#include "format.h" +#include "plugin.h" +#include "map.h" +#include "back-sch.h" + +void +idview_get_overrides(struct backend_search_cbdata *cbdata) +{ + char *dn = NULL; + int ret = 0; + const Slapi_DN *suffix = NULL; + Slapi_PBlock *pb; + + if (cbdata->idview == NULL) + return; + + pb = wrap_pblock_new(cbdata->pb); + if (pb == NULL) + return; + + wrap_inc_call_level(); + + suffix = slapi_get_suffix_by_dn(cbdata->target_dn); + dn = slapi_ch_smprintf("cn=%s,cn=views,cn=accounts,%s", cbdata->idview, slapi_sdn_get_dn(suffix)); + /* Fetch all attributes; there is a bug in 389-ds: it gives out all attributes for the entry anyway + * when search returns Slapi_Entry* objects. Instead, we'll do removal later */ + slapi_search_internal_set_pb(pb, dn, LDAP_SCOPE_SUBTREE, + "(objectclass=ipaOverrideAnchor)", NULL, 0, + NULL, NULL, cbdata->state->plugin_identity, 0); + ret = slapi_search_internal_pb(pb); + slapi_ch_free_string(&dn); + + if (ret == 0) { + /* Steal search result entries to avoid re-allocating them */ + slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, &(cbdata->overrides)); + slapi_pblock_set(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, NULL); + } + + wrap_dec_call_level(); + slapi_pblock_destroy(pb); +} + +void +idview_free_overrides(struct backend_search_cbdata *cbdata) +{ + int i = 0; + if (cbdata->overrides != NULL) { + for(i=0; cbdata->overrides[i] != NULL; i++) { + slapi_entry_free(cbdata->overrides[i]); + } + slapi_ch_free((void**)&(cbdata->overrides)); + } +} + +void +idview_process_overrides(struct backend_search_cbdata *cbdata, + const char *key, const char *map, const char *domain, + Slapi_Entry *entry) +{ +#define VIEW_TEMPLATE_KEY_MAP_DOMAIN 0 +#define VIEW_TEMPLATE_KEY_MAP_DOMAIN_NEWKEY 3 +#define VIEW_TEMPLATE_MAP_DOMAIN 1 +#define VIEW_TEMPLATE_DOMAIN 2 + /* After view was applied, entry's DN needs to reflect the view */ + const char *dn_template[] = {"%s,%s,cn=%s,cn=views,%s", /* an entry for user or group */ + "%s,cn=%s,cn=views,%s", /* an entry for a map (container for users or groups) */ + "cn=%s,cn=views,%s", /* an entry is a base of the compat tree */ + "%s=%s,%s,cn=%s,cn=views,%s", /* an entry for user or group which RDN was overridden with new value */ + }; + const char *filterout_attrs[] = {"objectclass", "creatorsname", "modifiersname", + "createtimestamp", "modifytimestamp", "parentid", + "entryusn", "ipaanchoruuid", NULL }; + char *new_dn = NULL, *new_key = NULL, *sep = NULL, *new_val = NULL; + Slapi_Entry *override_entry = NULL; + Slapi_Attr *anchor = NULL, *id_attr = NULL; + Slapi_Value *anchor_value = NULL, *id_value = NULL; + int i, result, dn_template_id; + + if (cbdata->overrides == NULL) { + /* Only retrieve overrides for the view first time when neccessary */ + idview_get_overrides(cbdata); + if (cbdata->overrides == NULL) + return; + } + + /* 1. See if the entry has ipaAnchorUUID and selected idview has an override for it */ + /* The code below intentionally uses Slapi_Value instead of comparing string values to + * avoid allocating additional memory */ + result = slapi_entry_attr_find(entry, IPA_IDVIEWS_ATTR_ANCHORUUID, &anchor); + if ((result == 0) && (anchor != NULL) && (cbdata->overrides != NULL)) { + result = slapi_attr_first_value(anchor, &anchor_value); + for(i = 0; cbdata->overrides[i] != NULL; i++) { + result = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ANCHORUUID, &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + result = slapi_value_compare(id_attr, anchor_value, id_value); + if (result == 0) { + override_entry = cbdata->overrides[i]; + break; + } + } + } + } + + /* 2. If there is indeed an override, replace attribute values except for the ones that should be ignored */ + if (override_entry != NULL) { + Slapi_Attr *entry_attr = NULL, *override_attr = NULL; + result = slapi_entry_first_attr(override_entry, &override_attr); + while (result == 0) { + Slapi_ValueSet *override_valueset = NULL; + char *override_type = NULL; + + /* Filter out override attributes that we don't care about */ + result = slapi_attr_get_type(override_attr, &override_type); + for (i = 0; filterout_attrs[i] != NULL; i++) { + if (strcasecmp(override_type, filterout_attrs[i]) == 0) { + break; + } + } + + if (filterout_attrs[i] == NULL) { + /* Replace the attribute's value with the override */ + result = slapi_entry_attr_find(entry, override_type, &entry_attr); + if (result == 0) { + result = slapi_attr_get_valueset(override_attr, &override_valueset); + result = slapi_attr_set_valueset(entry_attr, override_valueset); + } + } + result = slapi_entry_next_attr(override_entry, override_attr, &override_attr); + } + } + + /* 3. If entry has memberUid, we need to replace memberUid values too, if they were overridden */ + result = slapi_entry_attr_find(entry, "memberUid", &anchor); + if ((result == 0) && (anchor != NULL) && (cbdata->overrides != NULL)) { + int value_idx = 0; + Slapi_ValueSet *new_valueset = slapi_valueset_new(); + + if (new_valueset != NULL) { + /* For each memberUid value, find an override with ipaOriginalUid attribute of the same value */ + value_idx = slapi_attr_first_value(anchor, &anchor_value); + while (value_idx != -1) { + bool_t value_found = FALSE; + for(i = 0; cbdata->overrides[i] != NULL; i++) { + result = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ORIGINALUID, &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + result = slapi_value_compare(id_attr, anchor_value, id_value); + if (result == 0) { + /* If there is an override with ipaOriginalUid: , use its 'uid' value to override */ + result = slapi_entry_attr_find(cbdata->overrides[i], "uid", &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + if (result == 0) { + /* finally: we have an override with ipaOriginalUid: _and_ + * this override is changing the 'uid' attribute so we have something to replace */ + slapi_valueset_add_value(new_valueset, id_value); + value_found = TRUE; + break; + } + } + } + } + } + + if (value_found == FALSE) { + slapi_valueset_add_value(new_valueset, anchor_value); + } + value_idx = slapi_attr_next_value(anchor, value_idx, &anchor_value); + } + + slapi_attr_set_valueset(anchor, new_valueset); + slapi_valueset_free(new_valueset); + } + } + + /* 4. Even if there were no overrides, since we are serving throught the view, replace DN value */ + dn_template_id = (key == NULL ? 1 : 0) + (map == NULL ? 1 : 0); + switch (dn_template_id) { + case VIEW_TEMPLATE_KEY_MAP_DOMAIN: + /* update RDN with proper value from the entry after overrides were applied */ + sep = strchr(key, '='); + if (sep != NULL) { + sep[0] = '\0'; + new_val = slapi_entry_attr_get_charptr(entry, key); + new_dn = slapi_ch_smprintf(dn_template[VIEW_TEMPLATE_KEY_MAP_DOMAIN_NEWKEY], key, new_val, map, cbdata->idview, domain); + slapi_ch_free_string(&new_val); + sep[0] = '='; + } else { + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], key, map, cbdata->idview, domain); + } + break; + case VIEW_TEMPLATE_MAP_DOMAIN: + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], map, cbdata->idview, domain); + break; + case VIEW_TEMPLATE_DOMAIN: + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], cbdata->idview, domain); + break; + }; + slapi_entry_set_dn(entry, new_dn); +} + +void +idview_replace_target_dn(char **target, char **idview) +{ + char *idview_p = NULL; + char *cnviews = NULL; + char *new_target = NULL; + + cnviews = strstr(*target, ",cn=views,"); + if (cnviews != NULL && cnviews != *target) { + cnviews[0] = '\0'; + idview_p = strrchr(*target, ','); + if (idview_p == NULL) { + idview_p = *target; + } else { + idview_p++; + } + if (strstr(idview_p, "cn=") != idview_p) { + cnviews[0] = ','; + return; + } + *idview = slapi_ch_strdup(&idview_p[3]); + if (idview_p != *target) { + idview_p[0] = '\0'; + new_target = slapi_ch_smprintf("%s%s", *target, cnviews+10); + idview_p--; + idview_p[0] = ','; + } else { + new_target = slapi_ch_smprintf("%s", cnviews+10); + } + cnviews[0] = ','; + *target = new_target; + } +} + +struct filter_cb_data { + struct backend_search_cbdata *cbdata; + Slapi_Filter *filter; +}; + +static void +idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct berval *bval, struct backend_search_filter_config *config) +{ + int res, i; + Slapi_Value *filter_val, *value, *anchor_val; + Slapi_Attr *anchor, *attr = NULL; + struct backend_search_cbdata *cbdata = (struct backend_search_cbdata *) config->callback_data; + + if (cbdata == NULL || cbdata->idview == NULL) { + return; + } + + if (filter_type == NULL || config->name == NULL) { + return; + } + + if (cbdata->overrides == NULL) { + /* Only retrieve overrides for the view first time when neccessary */ + idview_get_overrides(cbdata); + } + + if (cbdata->overrides == NULL) { + return; + } + + filter_val = slapi_value_new_berval(bval); + + /* If filter contains an attribute name which is overridden in the view and filter value + * corresponds to the override, replace the filter by (ipaAnchorUUID=...) from the override + * to point to the original because otherwise an entry will not be found in the slapi-nis map */ + for(i=0; cbdata->overrides[i] != NULL; i++) { + res = slapi_entry_attr_find(cbdata->overrides[i], filter_type, &attr); + if ((res == 0) && (attr != NULL)) { + res = slapi_attr_first_value(attr, &value); + res = slapi_value_compare(attr, value, filter_val); + if (res == 0) { + res = slapi_entry_attr_find(cbdata->overrides[i], "ipaAnchorUUID", &anchor); + if (res == 0) { + res = slapi_attr_first_value(anchor, &anchor_val); + slapi_filter_changetype(filter, "ipaanchoruuid"); + slapi_ber_bvdone(bval); + slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); + config->override_found = TRUE; + break; + } + + } + } + } + + slapi_value_free(&filter_val); + +} + +/* Traverse through the filter and replace overridden attribute/value pairs with references to the original + * entries. This allows to properly handle overrides of uid and cn attributes where searches look like + * (&(objectclass=posixAccount)(uid=foobar)) -- if uid=foobar is part of an override for uid=admin, we need + * to point back to uid=admin to be able to find original entry in the slapi-nis cache. + * + * Note that in reality we don't use original value of the uid/cn attribue. Instead, we use ipaAnchorUUID + * to refer to the original entry. */ +void +idview_replace_filter(struct backend_search_cbdata *cbdata) +{ + struct filter_cb_data filter_data = {cbdata, NULL}; + struct backend_search_filter_config config = + {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL, NULL, NULL}; + int res = 0; + + + config.callback = idview_process_filter_cb; + config.callback_data = cbdata; + + res = backend_analyze_search_filter(cbdata->filter, &config); + + if (filter_data.filter != NULL) { + Slapi_Filter *f = cbdata->filter; + cbdata->filter = filter_data.filter; + slapi_filter_free(f, 1); + } + + if (config.name != NULL) { + slapi_ch_free_string(&config.name); + } + +} diff --git a/src/back-sch-nss.c b/src/back-sch-nss.c index f192bb9..db57cb8 100644 --- a/src/back-sch-nss.c +++ b/src/back-sch-nss.c @@ -52,17 +52,6 @@ #include "back-sch.h" #include "format.h" -struct backend_search_filter_config { - bool_t search_user; - bool_t search_group; - bool_t search_uid; - bool_t search_gid; - bool_t search_members; - bool_t name_set; - bool_t wrong_search; - char *name; -}; - static int bvstrcasecmp(const struct berval *bval, const char *s) { @@ -127,6 +116,10 @@ backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) } } + if (config->callback != NULL) { + config->callback(filter, filter_type, bval, config); + } + if ((config->search_uid || config->search_gid || config->search_user || @@ -211,8 +204,6 @@ backend_make_user_entry_from_nsswitch_passwd(struct passwd *pwd, slapi_entry_add_string(entry, "objectClass", "posixAccount"); slapi_entry_add_string(entry, - "objectClass", "extensibleObject"); - slapi_entry_add_string(entry, "uid", pwd->pw_name); slapi_entry_attr_set_uint(entry, "uidNumber", pwd->pw_uid); @@ -240,7 +231,20 @@ backend_make_user_entry_from_nsswitch_passwd(struct passwd *pwd, #ifdef HAVE_SSS_NSS_IDMAP rc = sss_nss_getsidbyid(pwd->pw_uid, &sid_str, &id_type); if ((rc == 0) && (sid_str != NULL)) { +#ifdef USE_IPA_IDVIEWS + char *anchor = NULL; + /* For overrides of AD users to work correctly, we need to generate + * ipaAnchorUUID value so that idviews can be properly searched for the override */ + anchor = slapi_ch_smprintf(":SID:%s", sid_str); + if (anchor != NULL) { + slapi_entry_add_string(entry, "objectClass", "ipaOverrideTarget"); + slapi_entry_add_string(entry, "ipaAnchorUUID", anchor); + slapi_ch_free_string(&anchor); + } +#else + slapi_entry_add_string(entry, "objectClass", "extensibleObject"); slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); +#endif free(sid_str); } #endif @@ -335,8 +339,6 @@ backend_make_group_entry_from_nsswitch_group(struct group *grp, slapi_entry_add_string(entry, "objectClass", "posixGroup"); slapi_entry_add_string(entry, - "objectClass", "extensibleObject"); - slapi_entry_add_string(entry, "cn", grp->gr_name); slapi_entry_attr_set_uint(entry, "gidNumber", grp->gr_gid); @@ -352,7 +354,20 @@ backend_make_group_entry_from_nsswitch_group(struct group *grp, #ifdef HAVE_SSS_NSS_IDMAP rc = sss_nss_getsidbyid(grp->gr_gid, &sid_str, &id_type); if ((rc == 0) && (sid_str != NULL)) { +#ifdef USE_IPA_IDVIEWS + char *anchor = NULL; + /* For overrides of AD users to work correctly, we need to generate + * ipaAnchorUUID value so that idviews can be properly searched for the override */ + anchor = slapi_ch_smprintf(":SID:%s", sid_str); + if (anchor != NULL) { + slapi_entry_add_string(entry, "objectClass", "ipaOverrideTarget"); + slapi_entry_add_string(entry, "ipaAnchorUUID", anchor); + slapi_ch_free_string(&anchor); + } +#else + slapi_entry_add_string(entry, "objectClass", "extensibleObject"); slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); +#endif free(sid_str); } #endif @@ -558,6 +573,16 @@ nsswitch_type_to_name(enum sch_search_nsswitch_t type) return "(unknown)"; } +int +backend_analyze_search_filter(Slapi_Filter *filter, struct backend_search_filter_config *config) +{ + int result, rc; + result = slapi_filter_apply(filter, + backend_search_filter_has_cn_uid, + config, &rc); + return (result != SLAPI_FILTER_SCAN_STOP) ? 1 : 0; +} + /* Check if the filter is one (like uid=) that should trigger an * nsswitch lookup, and if it is, make a note that we should perform such a * lookup. */ @@ -566,15 +591,15 @@ backend_search_nsswitch(struct backend_set_data *set_data, struct backend_search_cbdata *cbdata) { int result, rc; - struct backend_search_filter_config config = {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL}; + struct backend_search_filter_config config = + {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL, NULL, NULL}; struct backend_staged_search *staged = NULL; char *idptr = NULL; unsigned long id; /* First, we search the filter to see if it includes a cn|uid= test. */ - result = slapi_filter_apply(cbdata->filter, - backend_search_filter_has_cn_uid, &config, &rc); - if ((result != SLAPI_FILTER_SCAN_STOP)) { + result = backend_analyze_search_filter(cbdata->filter, &config); + if (result != 0) { return; } diff --git a/src/back-sch.c b/src/back-sch.c index 78f2627..1c388da 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -259,15 +259,6 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, free(nsswitch_min_id); } - if (ret.check_nsswitch != SCH_NSSWITCH_NONE) { - /* If we're adding nsswitch-based entries to this map, make - * sure that we copy the schema-compat-origin and SID - * attributes, so that we can read the former during the BIND - * callback. */ - backend_shr_add_strlist(&ret.attribute_format, "objectClass=%ifeq(\"%{ipaNTSecurityIdentifier}\",\"\",\"\",\"extensibleObject\")"); - backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); - } - *pret = backend_copy_set_config(&ret); if (*pret == NULL) { if (strlen(container) > 0) { @@ -1005,6 +996,7 @@ backend_search_entry_cb(const char *domain, const char *map, bool_t secure, void *backend_data, void *cb_data) { Slapi_DN *sdn; + Slapi_Entry *entry; struct backend_search_cbdata *cbdata; struct backend_entry_data *entry_data; int result; @@ -1043,9 +1035,25 @@ backend_search_entry_cb(const char *domain, const char *map, bool_t secure, cbdata->state->plugin_desc->spd_id, "search matched %s\n", slapi_sdn_get_ndn(sdn)); - slapi_send_ldap_search_entry(cbdata->pb, entry_data->e, NULL, + entry = entry_data->e; +#ifdef USE_IPA_IDVIEWS + if (cbdata->idview != NULL) { + entry = slapi_entry_dup(entry_data->e); + idview_process_overrides(cbdata, key, map, domain, entry); + } + + if (slapi_entry_attr_exists(entry, IPA_IDVIEWS_ATTR_ANCHORUUID) == 1) { + slapi_entry_attr_delete(entry, IPA_IDVIEWS_ATTR_ANCHORUUID); + slapi_entry_delete_string(entry, "objectClass", "ipaOverrideTarget"); + } +#endif + slapi_send_ldap_search_entry(cbdata->pb, entry, NULL, cbdata->attrs, cbdata->attrsonly); cbdata->n_entries++; + + if (entry != entry_data->e) { + slapi_entry_free(entry); + } break; } @@ -1104,6 +1112,13 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, "search matched %s\n", ndn); +#ifdef USE_IPA_IDVIEWS + if (cbdata->idview != NULL) { + idview_process_overrides(cbdata, NULL, + set_data->common.set, + set_data->common.group, set_entry); + } +#endif slapi_send_ldap_search_entry(cbdata->pb, set_entry, NULL, cbdata->attrs, cbdata->attrsonly); @@ -1216,6 +1231,11 @@ backend_search_group_cb(const char *group, void *cb_data) slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, "search matched %s\n", group); +#ifdef USE_IPA_IDVIEWS + if (cbdata->idview != NULL) { + idview_process_overrides(cbdata, NULL, NULL, group, group_entry); + } +#endif slapi_send_ldap_search_entry(cbdata->pb, group_entry, NULL, cbdata->attrs, cbdata->attrsonly); @@ -1313,11 +1333,16 @@ backend_search_cb(Slapi_PBlock *pb) cbdata.n_entries = 0; cbdata.staged = NULL; cbdata.cur_staged = NULL; + cbdata.idview = NULL; + cbdata.overrides = NULL; /* Okay, we can search. */ slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, "searching from \"%s\" for \"%s\" with scope %d%s\n", cbdata.target, cbdata.strfilter, cbdata.scope, backend_sch_scope_as_string(cbdata.scope)); +#ifdef USE_IPA_IDVIEWS + idview_replace_target_dn(&cbdata.target, &cbdata.idview); +#endif cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); /* Check if there's a backend handling this search. */ if (!slapi_be_exist(cbdata.target_dn)) { @@ -1326,10 +1351,18 @@ backend_search_cb(Slapi_PBlock *pb) "slapi_be_exists(\"%s\") = 0, " "ignoring search\n", cbdata.target); slapi_sdn_free(&cbdata.target_dn); + slapi_ch_free_string(&cbdata.idview); +#ifdef USE_IPA_IDVIEWS + idview_free_overrides(&cbdata); +#endif return 0; } + /* Walk the list of groups. */ wrap_inc_call_level(); +#ifdef USE_IPA_IDVIEWS + idview_replace_filter(&cbdata); +#endif if (map_rdlock() == 0) { map_data_foreach_domain(cbdata.state, backend_search_group_cb, &cbdata); @@ -1468,6 +1501,10 @@ backend_search_cb(Slapi_PBlock *pb) cbdata.n_entries, NULL); } slapi_sdn_free(&cbdata.target_dn); + slapi_ch_free_string(&cbdata.idview); +#ifdef USE_IPA_IDVIEWS + idview_free_overrides(&cbdata); +#endif free(cbdata.closest_match); free(cbdata.text); return cbdata.answer ? -1 : 0; @@ -1525,6 +1562,7 @@ static void backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char **group, const char**set) { struct backend_locate_cbdata cbdata; + char *idview = NULL; slapi_pblock_get(pb, SLAPI_PLUGIN_PRIVATE, &cbdata.state); if (cbdata.state->plugin_base == NULL) { @@ -1533,6 +1571,9 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** return; } slapi_pblock_get(pb, SLAPI_TARGET_DN, &cbdata.target); +#ifdef USE_IPA_IDVIEWS + idview_replace_target_dn(&cbdata.target, &idview); +#endif cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); cbdata.entry_data = NULL; cbdata.entry_group = NULL; @@ -1542,6 +1583,7 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** *group = cbdata.entry_group; *set = cbdata.entry_set; slapi_sdn_free(&cbdata.target_dn); + slapi_ch_free_string(&idview); } /* Check if the target DN is part of this group's tree. If it is, return an diff --git a/src/back-sch.h b/src/back-sch.h index 2f4a3df..f74e82d 100644 --- a/src/back-sch.h +++ b/src/back-sch.h @@ -69,6 +69,8 @@ struct backend_search_cbdata { Slapi_PBlock *pb; struct plugin_state *state; char *target, *strfilter, **attrs; + char *idview; + Slapi_Entry **overrides; int scope, sizelimit, timelimit, attrsonly; bool_t check_access; enum sch_search_nsswitch_t check_nsswitch; @@ -87,6 +89,29 @@ struct backend_search_cbdata { struct backend_staged_search *cur_staged; }; +struct backend_search_filter_config { + bool_t search_user; + bool_t search_group; + bool_t search_uid; + bool_t search_gid; + bool_t search_members; + bool_t name_set; + bool_t wrong_search; + bool_t override_found; + char *name; + /* If callback is defined, it is called on each filter after analyzing it */ + void (*callback)(Slapi_Filter *filter, const char *filter_type, struct berval *bval, struct backend_search_filter_config *config); + void *callback_data; +}; + +/* Analyzes the filter to decide what kind of NSS search is it + * Returns 0 on success, 1 on failure + * struct backend_search_filter_config is populated with information about the filter + * config.name should be freed with slapi_ch_free_string() + */ + +int backend_analyze_search_filter(Slapi_Filter *filter, struct backend_search_filter_config *config); + void backend_search_nsswitch(struct backend_set_data *set_data, struct backend_search_cbdata *cbdata); @@ -95,4 +120,14 @@ bool_t backend_retrieve_from_nsswitch(struct backend_staged_search *staged, int backend_sch_do_pam_auth(Slapi_PBlock *pb, const char *username); +#ifdef USE_IPA_IDVIEWS +void idview_get_overrides(struct backend_search_cbdata *cbdata); +void idview_free_overrides(struct backend_search_cbdata *cbdata); +void idview_process_overrides(struct backend_search_cbdata *cbdata, + const char *key, const char *map, const char *domain, + Slapi_Entry *entry); +void idview_replace_target_dn(char **target, char **idview); +void idview_replace_filter(struct backend_search_cbdata *cbdata); +#endif + #endif -- 2.1.0 From jcholast at redhat.com Thu Oct 2 06:54:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 02 Oct 2014 08:54:03 +0200 Subject: [Freeipa-devel] [PATCH] 0652 - backup/restore: Add files from /etc/ipa/nssdb In-Reply-To: <542C1125.7030906@redhat.com> References: <542C1125.7030906@redhat.com> Message-ID: <542CF68B.4040606@redhat.com> Hi, Dne 1.10.2014 v 16:35 Petr Viktorin napsal(a): > https://fedorahosted.org/freeipa/ticket/4597 > > Honza, does this look right? Does the database at the old location still > need to be backed up? I don't have much insight into the /etc/ipa/nssdb > changes. > thanks for the patch, it looks right, but there's one more file to backup: /etc/ipa/nssdb/pwdfile.txt. Honza -- Jan Cholasta From mkosek at redhat.com Thu Oct 2 08:32:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Oct 2014 10:32:49 +0200 Subject: [Freeipa-devel] [PATCH] 483 Sudorule RunAsUser should work with external groups Message-ID: <542D0DB1.5080305@redhat.com> https://fedorahosted.org/freeipa/ticket/4600 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-483-sudorule-runasuser-should-work-with-external-groups.patch Type: text/x-patch Size: 1259 bytes Desc: not available URL: From tbabej at redhat.com Thu Oct 2 08:59:01 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 02 Oct 2014 10:59:01 +0200 Subject: [Freeipa-devel] [PATCH] 483 Sudorule RunAsUser should work with external groups In-Reply-To: <542D0DB1.5080305@redhat.com> References: <542D0DB1.5080305@redhat.com> Message-ID: <542D13D5.6010206@redhat.com> ACK. This is a copy-paste error introduced by af4518b7. On 10/02/2014 10:32 AM, Martin Kosek wrote: > https://fedorahosted.org/freeipa/ticket/4600 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Oct 2 09:08:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 02 Oct 2014 11:08:35 +0200 Subject: [Freeipa-devel] [PATCH] 483 Sudorule RunAsUser should work with external groups In-Reply-To: <542D13D5.6010206@redhat.com> References: <542D0DB1.5080305@redhat.com> <542D13D5.6010206@redhat.com> Message-ID: <542D1613.60805@redhat.com> On 10/02/2014 10:59 AM, Tomas Babej wrote: > ACK. > > This is a copy-paste error introduced by af4518b7. > > On 10/02/2014 10:32 AM, Martin Kosek wrote: >> https://fedorahosted.org/freeipa/ticket/4600 >> Thank you! Pushed to: master: 3b8a7883de4d9c00ad48d436a67d5f69d8fed26a ipa-4-1: 9f6f223b8652cf594831096ce9daceab52160383 ipa-4-0: d099f2036470f19ed8b249b5d2d127981e7f8557 -- Petr? From pviktori at redhat.com Thu Oct 2 09:56:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 02 Oct 2014 11:56:09 +0200 Subject: [Freeipa-devel] [PATCH] 0653 test_forced_client_reenrollment: Don't check for host certificates Message-ID: <542D2139.70702@redhat.com> https://fedorahosted.org/freeipa/ticket/4601 Pushed under the one-liner rule to: master: 21276e8a3fa1028fd9e227151cd20bfd80713810 ipa-4-1: 4ba2ab8ebc7b235a183a6148fe1cb2780f1f5e16 ipa-4-0: d1be74e6ad99a53b1423fd3c55ed6d15c5c6d81f -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0653-test_forced_client_reenrollment-Don-t-check-for-host.patch Type: text/x-patch Size: 1347 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 2 10:42:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 02 Oct 2014 12:42:18 +0200 Subject: [Freeipa-devel] [PATCH] 0018 Check that port 8443 is available when installing PKI. In-Reply-To: <54297123.4040901@redhat.com> References: <54297123.4040901@redhat.com> Message-ID: <542D2C0A.20903@redhat.com> On 09/29/2014 04:48 PM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4564 Looks and works OK. The port checking should be ideally refactored in 4.2 and *instance.py should use some common hooks to define which ports should be checked, but your way be enough for now. What about ipa-replica-install? It could be also run with --setup-ca option. Martin From pviktori at redhat.com Thu Oct 2 11:09:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 02 Oct 2014 13:09:11 +0200 Subject: [Freeipa-devel] [PATCH] 0652 - backup/restore: Add files from /etc/ipa/nssdb In-Reply-To: <542CF68B.4040606@redhat.com> References: <542C1125.7030906@redhat.com> <542CF68B.4040606@redhat.com> Message-ID: <542D3257.1050808@redhat.com> On 10/02/2014 08:54 AM, Jan Cholasta wrote: > Hi, > > Dne 1.10.2014 v 16:35 Petr Viktorin napsal(a): >> https://fedorahosted.org/freeipa/ticket/4597 >> >> Honza, does this look right? Does the database at the old location still >> need to be backed up? I don't have much insight into the /etc/ipa/nssdb >> changes. >> > > thanks for the patch, it looks right, but there's one more file to > backup: /etc/ipa/nssdb/pwdfile.txt. Added. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0652.2-backup-restore-Add-files-from-etc-ipa-nssdb.patch Type: text/x-patch Size: 2639 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 2 11:53:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 02 Oct 2014 13:53:03 +0200 Subject: [Freeipa-devel] [PATCH] 0652 - backup/restore: Add files from /etc/ipa/nssdb In-Reply-To: <542D3257.1050808@redhat.com> References: <542C1125.7030906@redhat.com> <542CF68B.4040606@redhat.com> <542D3257.1050808@redhat.com> Message-ID: <542D3C9F.4020706@redhat.com> Dne 2.10.2014 v 13:09 Petr Viktorin napsal(a): > On 10/02/2014 08:54 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 1.10.2014 v 16:35 Petr Viktorin napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4597 >>> >>> Honza, does this look right? Does the database at the old location still >>> need to be backed up? I don't have much insight into the /etc/ipa/nssdb >>> changes. >>> >> >> thanks for the patch, it looks right, but there's one more file to >> backup: /etc/ipa/nssdb/pwdfile.txt. > > Added. > > ACK. -- Jan Cholasta From pviktori at redhat.com Thu Oct 2 11:54:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 02 Oct 2014 13:54:45 +0200 Subject: [Freeipa-devel] [PATCH] 0652 - backup/restore: Add files from /etc/ipa/nssdb In-Reply-To: <542D3C9F.4020706@redhat.com> References: <542C1125.7030906@redhat.com> <542CF68B.4040606@redhat.com> <542D3257.1050808@redhat.com> <542D3C9F.4020706@redhat.com> Message-ID: <542D3D05.9020504@redhat.com> On 10/02/2014 01:53 PM, Jan Cholasta wrote: > Dne 2.10.2014 v 13:09 Petr Viktorin napsal(a): >> On 10/02/2014 08:54 AM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 1.10.2014 v 16:35 Petr Viktorin napsal(a): >>>> https://fedorahosted.org/freeipa/ticket/4597 >>>> >>>> Honza, does this look right? Does the database at the old location >>>> still >>>> need to be backed up? I don't have much insight into the /etc/ipa/nssdb >>>> changes. >>>> >>> >>> thanks for the patch, it looks right, but there's one more file to >>> backup: /etc/ipa/nssdb/pwdfile.txt. >> >> Added. >> >> > > ACK. > Thanks, pushed to: master: cc085d1d4cc03d4f8ad3b2742d8038d818893cc4 ipa-4-1: 7ada6dd096370b134c868dea57d48d2998ced4d8 -- Petr? From pvoborni at redhat.com Thu Oct 2 14:07:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 02 Oct 2014 16:07:22 +0200 Subject: [Freeipa-devel] [PATCH] 755 webui-ci: case-insensitive record check In-Reply-To: <5423D2EB.1040205@redhat.com> References: <542036EC.90304@redhat.com> <54222FC3.8080508@redhat.com> <5422C66F.3000109@redhat.com> <5422D254.4040807@redhat.com> <5423D2EB.1040205@redhat.com> Message-ID: <542D5C1A.9080601@redhat.com> On 25.9.2014 10:31, Petr Vobornik wrote: > On 24.9.2014 16:16, Endi Sukma Dewata wrote: >> ACK. >> > > Pushed to: > master: dafdd68a6ed7030d7f7a153144b36443603e884f > ipa-4-1: c66b1ec8c81dc65e2807ab54bdb13957eaf55534 Pushed to ipa-4-0: 26116d4cd307d78d45ee919e758a4297b7d711e9 -- Petr Vobornik From pvoborni at redhat.com Thu Oct 2 14:44:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 02 Oct 2014 16:44:39 +0200 Subject: [Freeipa-devel] [PATCH] 762 webui-ci: adjust dnszone-add test to recent DNS changes Message-ID: <542D64D7.1050806@redhat.com> 'idnssoamname', 'ip_address' and 'force' fields were removed from DNS zone adder dialog in #4149 https://fedorahosted.org/freeipa/ticket/4604 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0762-webui-ci-adjust-dnszone-add-test-to-recent-DNS-chang.patch Type: text/x-patch Size: 1036 bytes Desc: not available URL: From dkupka at redhat.com Fri Oct 3 10:18:56 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 03 Oct 2014 12:18:56 +0200 Subject: [Freeipa-devel] [PATCH] 0018 Check that port 8443 is available when installing PKI. In-Reply-To: <542D2C0A.20903@redhat.com> References: <54297123.4040901@redhat.com> <542D2C0A.20903@redhat.com> Message-ID: <542E7810.7090906@redhat.com> On 10/02/2014 12:42 PM, Martin Kosek wrote: > On 09/29/2014 04:48 PM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4564 > > Looks and works OK. The port checking should be ideally refactored in 4.2 and > *instance.py should use some common hooks to define which ports should be > checked, but your way be enough for now. > > What about ipa-replica-install? It could be also run with --setup-ca option. I missed that one. git grep I used did not return it. Thanks. > > Martin > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0018-2-ipa41-Check-that-port-8443-is-available-when-installing-PK.patch Type: text/x-patch Size: 3651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0018-2-master-Check-that-port-8443-is-available-when-installing-PK.patch Type: text/x-patch Size: 3619 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 3 10:22:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Oct 2014 12:22:44 +0200 Subject: [Freeipa-devel] [PATCH] 762 webui-ci: adjust dnszone-add test to recent DNS changes In-Reply-To: <542D64D7.1050806@redhat.com> References: <542D64D7.1050806@redhat.com> Message-ID: <542E78F4.6030701@redhat.com> On 10/02/2014 04:44 PM, Petr Vobornik wrote: > 'idnssoamname', 'ip_address' and 'force' fields were removed from DNS zone > adder dialog in #4149 > > https://fedorahosted.org/freeipa/ticket/4604 Yup, tests pass now: # ipa-run-tests -v --logging-level=DEBUG test_webui.test_dns Basic CRUD: dnsconfig ... ok Forward DNS zones ... ok Test last entry deletion ... ok Basic CRUD: dns ... ok ---------------------------------------------------------------------- Ran 4 tests in 253.646s OK ACK! Pushed to: master: 81e4cac5cdd752184bd1b6ed007e4719f52b7f1d ipa-4-1: 65da8e775ce6fe69287f7faeee6894342c5770de Martin From mbasti at redhat.com Fri Oct 3 10:45:28 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 03 Oct 2014 12:45:28 +0200 Subject: [Freeipa-devel] [PATCH 0131-0132] Add missing attributes to named.conf Message-ID: <542E7E48.2020900@redhat.com> Hello! Patch 131: https://fedorahosted.org/freeipa/ticket/3801#comment:31 Patch 132: I modified named.conf in 131, so I change the rest of paths to be ipaplatform specified. Patches attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0131-Add-missing-attributes-to-named.conf.patch Type: text/x-patch Size: 9430 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0132-Make-named.conf-template-platform-independent.patch Type: text/x-patch Size: 2772 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 3 11:45:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 03 Oct 2014 13:45:34 +0200 Subject: [Freeipa-devel] [PATCH] 0654 sudo integration test: Remove the local user test Message-ID: <542E8C5E.90004@redhat.com> SSSD does not support sudo rules for local users; these should be added in a local sudoers file. https://fedorahosted.org/freeipa/ticket/4608 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0654-sudo-integration-test-Remove-the-local-user-test.patch Type: text/x-patch Size: 2138 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 3 12:21:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Oct 2014 14:21:13 +0200 Subject: [Freeipa-devel] [PATCH] 0654 sudo integration test: Remove the local user test In-Reply-To: <542E8C5E.90004@redhat.com> References: <542E8C5E.90004@redhat.com> Message-ID: <542E94B9.5040209@redhat.com> On 10/03/2014 01:45 PM, Petr Viktorin wrote: > SSSD does not support sudo rules for local users; > these should be added in a local sudoers file. > > https://fedorahosted.org/freeipa/ticket/4608 Works for me, ACK. Pushed to: master: 0cdaf2c48fa7cc44229e9e490fdad0157abdabed ipa-4-1: e6edbe447c1ab56552b8dadefe2548b23576ba0c ipa-4-0: 98e0a4e13c101d3ea1f6f8968b3f4e71624af1e6 Martin From mbasti at redhat.com Fri Oct 3 13:22:31 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 03 Oct 2014 15:22:31 +0200 Subject: [Freeipa-devel] ipa-server-install setup KRA Message-ID: <542EA317.9020306@redhat.com> Hello, I found a TODO in ipa-server-install: # setup_kra is set to False until Dogtag 10.2 is available for IPA to consume # Until then users that want to install the KRA need to use ipa-install-kra # TODO set setup_kra = True when Dogtag 10.2 is available setup_kra = False Dogtag 10.2 is available, should it be setup_kra = True? Martin^2 From pviktori at redhat.com Fri Oct 3 13:24:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 03 Oct 2014 15:24:03 +0200 Subject: [Freeipa-devel] Switching to pytest Message-ID: <542EA373.9020508@redhat.com> https://fedorahosted.org/freeipa/ticket/4610 Our test suite is currently not very maintainable. I want to dedicate some time to improve this. The biggest part of this effort will be switching to a different test framework, [pytest]. Compared to Nose, it makes complicated tests easier to write -- at the expense of using more "magic". Probably the most visible features in pytest are: - Fixtures. Not so easily explained if you haven't used it before, but I'll try. Basically, setup/teardown, test parametrization, and dependencies for injection can be packaged in a named function/object, which individual tests can then very simply use. In IPA, this would for example allow us to say "this tests needs a user in LDAP", and the user will be created/destroyed before/after the test is run (and, depending on confiiguration, it can be reused in the next test to save time). Fixtures can also depend on other fixtures. For example the above user fixture can depend on a LDAP server being installed. This could be a pre-installed server, or a server the tests install automatically, or some kind of mock -- and this could be selectable by configuration/options. Fixtures can also be used select/skip tests, which ticket #4610 callls for. - Assertion rewriting: you can write a simple assert statement, and py.test will give detailed information about what failed in it. This reduces the need for boilerplate-y methods like "assertEqual". (though it's not a silver bullet) I was certainly rather distrustful when I first saw all this -- it's quite questionable from SW engineering best practices point of view. But after using it, I can assure you that it's very well thought out. Testing does require a slightly different set of practices than building software. Pytest is successfully used to test many projects; closest to home for us is probably 389-ds. Most Nose tests can be run as-is with pytest. IPA's "xmlrpc" suite is, unfortunately, weird enough to be the exception, but since it's declarative it should be possible to port. There are three stages to this effort: - Converting the existing suite to run under pytest - Updating the infrastructure (./make-test, plugins, CI config) - Rewriting individual tests to make use of the new features It's rather hard to plan this in more detail, since the first stage is "overcome unknown obstacles". I'll keep you updated. Feedback welcome. [pytest]: http://pytest.org/latest/ -- Petr? From pviktori at redhat.com Fri Oct 3 13:31:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 03 Oct 2014 15:31:28 +0200 Subject: [Freeipa-devel] ipa-server-install setup KRA In-Reply-To: <542EA317.9020306@redhat.com> References: <542EA317.9020306@redhat.com> Message-ID: <542EA530.4050802@redhat.com> On 10/03/2014 03:22 PM, Martin Basti wrote: > Hello, > > I found a TODO in ipa-server-install: > > # setup_kra is set to False until Dogtag 10.2 is available for IPA to > consume > # Until then users that want to install the KRA need to use > ipa-install-kra > # TODO set setup_kra = True when Dogtag 10.2 is available > setup_kra = False > > Dogtag 10.2 is available, should it be setup_kra = True? > This is https://fedorahosted.org/freeipa/ticket/3872 The functionality is not currently exposed to the end user; Endi is working on the plugin for that. I expect enabling this will be a part of his effort. -- Petr? From mbasti at redhat.com Fri Oct 3 13:51:42 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 03 Oct 2014 15:51:42 +0200 Subject: [Freeipa-devel] ipa-server-install setup KRA In-Reply-To: <542EA530.4050802@redhat.com> References: <542EA317.9020306@redhat.com> <542EA530.4050802@redhat.com> Message-ID: <542EA9EE.5070201@redhat.com> On 03/10/14 15:31, Petr Viktorin wrote: > On 10/03/2014 03:22 PM, Martin Basti wrote: >> Hello, >> >> I found a TODO in ipa-server-install: >> >> # setup_kra is set to False until Dogtag 10.2 is available for IPA to >> consume >> # Until then users that want to install the KRA need to use >> ipa-install-kra >> # TODO set setup_kra = True when Dogtag 10.2 is available >> setup_kra = False >> >> Dogtag 10.2 is available, should it be setup_kra = True? >> > > This is https://fedorahosted.org/freeipa/ticket/3872 > > The functionality is not currently exposed to the end user; Endi is > working on the plugin for that. I expect enabling this will be a part > of his effort. > > Thank you! -- Martin Basti From pvoborni at redhat.com Fri Oct 3 14:08:53 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 Oct 2014 16:08:53 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542C289A.6040301@redhat.com> References: <542C289A.6040301@redhat.com> Message-ID: <542EADF5.90901@redhat.com> New revision according to Honza's recommendations. Comments inline. On 1.10.2014 18:15, Petr Vobornik wrote: > Hello list, > > Patch for: https://fedorahosted.org/freeipa/ticket/4419 > > Before I start any work on Web UI and tests I would like to gather > feedback on: > - the new API > - member attributes with subtypes management approach > - ACI > > I did not do any ACI work in the patch yet. I assume that we would like > to add the attr into 'System: Read Host|Service' permission. But I > think that write right should have it's own permission. I have added 2 new permissions. Simo, are they OK? for services: 'System: Manage Service Keytab Permissions': { 'ipapermright': {'read', 'search', 'compare', 'write'}, 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, 'default_privileges': {'Service Administrators', 'Host Administrators'}, }, for hosts: 'System: Manage Host Keytab Permissions': { 'ipapermright': {'read', 'search', 'compare', 'write'}, 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, 'default_privileges': {'Host Administrators'}, }, I'm not sure about the write right for 'objectclass' but it's required in order to add 'ipaallowedoperations' oc. > > Patch info: > Adds new API: > ipa host-add-retrieve-keytab HOSTNAME --users=STR --groups=STR > ipa host-add-write-keytab HOSTNAME --users=STR --groups=STR > ipa host-remove-retrieve-keytab HOSTNAME --users=STR --groups=STR > ipa host-remove-write-keytab HOSTNAME --users=STR --groups=STR > > ipa service-add-retrieve-keytab PRINCIPAL --users=STR --groups=STR > ipa service-add-write-keytab PRINCIPAL --users=STR --groups=STR > ipa service-remove-retrieve-keytab PRINCIPAL --users=STR --groups=STR > ipa service-remove-write-keytab PRINCIPAL --users=STR --groups=STR *-write-keytab commands were changed to *-create-keytab to be consistent with descriptions > > these methods add or remove user or group DNs in `ipaallowedtoperform` > attr with `read_keys` and `write_keys` subtypes. > > service|host-mod|show outputs these attrs only with --all option as: --all is no longer required > > Users allowed to retrieve keytab: user1 > Groups allowed to retrieve keytab: group1 > Users allowed to write keytab: user1 > Groups allowed to write keytab: group1 > > 1) This patch implements subtypes support for attributes members. It's > done to be relatively reusable but it's confined within the RFE > boundaries. I.e. it does not contain support for standard attributes or > is not integrated into LDAPAddMember or LDAPRemoveMember commands. It's > rather as separate opt-ins. One of the reasons was also not to disturb > existing code at the end of 4-1 > milestone. Was replaced by more specific methods more local to a service and a host plugins. > > 3) Adding of object class is implemented as a reusable method since this > code is used on many places and most likely will be also used in new > features. Older code may be refactored later. > > Thanks RPC tests added in patch #763. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0761-1-keytab-manipulation-permission-management.patch Type: text/x-patch Size: 34666 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0763-tests-management-of-keytab-permissions.patch Type: text/x-patch Size: 30459 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 3 14:12:26 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 Oct 2014 16:12:26 +0200 Subject: [Freeipa-devel] [PATCH] 764 webui: management of keytab permissions In-Reply-To: <542C289A.6040301@redhat.com> References: <542C289A.6040301@redhat.com> Message-ID: <542EAECA.4050104@redhat.com> On 1.10.2014 18:15, Petr Vobornik wrote: > Hello list, > > Patch for: https://fedorahosted.org/freeipa/ticket/4419 > Web UI for 4419. Depends on patch 761 (parent thread). -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0764-webui-management-of-keytab-permissions.patch Type: text/x-patch Size: 14508 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 3 14:24:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Oct 2014 16:24:10 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EADF5.90901@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> Message-ID: <542EB18A.6070607@redhat.com> NACK. I will not comment on mechanics, if you get an ACK from Honza, it is good enough. I just do not like the API. It is hard to guess what "host-add-retrieve-keytab" means. That word does not even make much sense. Can we use something more readable? For example: ipa host-add-allowed-operation HOSTNAME --operation read_keys --users=STR --groups STR ipa host-add-allowed-operation HOSTNAME --operation write_keys --users=STR --groups STR and ipa host-remove-allowed-operation HOSTNAME --operation read_keys --users=STR --groups STR ipa host-remove-allowed-operation HOSTNAME --operation write_keys --users=STR --groups STR Same with services. At least to me, it looks more readable. Thanks, Martin On 10/03/2014 04:08 PM, Petr Vobornik wrote: > New revision according to Honza's recommendations. Comments inline. > > On 1.10.2014 18:15, Petr Vobornik wrote: >> Hello list, >> >> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >> >> Before I start any work on Web UI and tests I would like to gather >> feedback on: >> - the new API >> - member attributes with subtypes management approach >> - ACI >> >> I did not do any ACI work in the patch yet. I assume that we would like >> to add the attr into 'System: Read Host|Service' permission. But I >> think that write right should have it's own permission. > > I have added 2 new permissions. Simo, are they OK? > > for services: > 'System: Manage Service Keytab Permissions': { > 'ipapermright': {'read', 'search', 'compare', 'write'}, > 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, > 'default_privileges': {'Service Administrators', 'Host Administrators'}, > }, > > for hosts: > 'System: Manage Host Keytab Permissions': { > 'ipapermright': {'read', 'search', 'compare', 'write'}, > 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, > 'default_privileges': {'Host Administrators'}, > }, > > I'm not sure about the write right for 'objectclass' but it's required in order > to add 'ipaallowedoperations' oc. > >> >> Patch info: >> Adds new API: >> ipa host-add-retrieve-keytab HOSTNAME --users=STR --groups=STR >> ipa host-add-write-keytab HOSTNAME --users=STR --groups=STR >> ipa host-remove-retrieve-keytab HOSTNAME --users=STR --groups=STR >> ipa host-remove-write-keytab HOSTNAME --users=STR --groups=STR >> >> ipa service-add-retrieve-keytab PRINCIPAL --users=STR --groups=STR >> ipa service-add-write-keytab PRINCIPAL --users=STR --groups=STR >> ipa service-remove-retrieve-keytab PRINCIPAL --users=STR --groups=STR >> ipa service-remove-write-keytab PRINCIPAL --users=STR --groups=STR > > *-write-keytab commands were changed to *-create-keytab to be consistent with > descriptions > >> >> these methods add or remove user or group DNs in `ipaallowedtoperform` >> attr with `read_keys` and `write_keys` subtypes. >> >> service|host-mod|show outputs these attrs only with --all option as: > > --all is no longer required > >> >> Users allowed to retrieve keytab: user1 >> Groups allowed to retrieve keytab: group1 >> Users allowed to write keytab: user1 >> Groups allowed to write keytab: group1 >> >> 1) This patch implements subtypes support for attributes members. It's >> done to be relatively reusable but it's confined within the RFE >> boundaries. I.e. it does not contain support for standard attributes or >> is not integrated into LDAPAddMember or LDAPRemoveMember commands. It's >> rather as separate opt-ins. One of the reasons was also not to disturb >> existing code at the end of 4-1 >> milestone. > > Was replaced by more specific methods more local to a service and a host plugins. > >> >> 3) Adding of object class is implemented as a reusable method since this >> code is used on many places and most likely will be also used in new >> features. Older code may be refactored later. >> >> Thanks > > RPC tests added in patch #763. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From simo at redhat.com Fri Oct 3 14:46:14 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 3 Oct 2014 10:46:14 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EADF5.90901@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> Message-ID: <1921241086.3447498.1412347574841.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Petr Vobornik" > To: "freeipa-devel" , "jch >> Jan Cholasta" , "simo Sorce" > > Sent: Friday, October 3, 2014 10:08:53 AM > Subject: Re: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management > > New revision according to Honza's recommendations. Comments inline. > > On 1.10.2014 18:15, Petr Vobornik wrote: > > Hello list, > > > > Patch for: https://fedorahosted.org/freeipa/ticket/4419 > > > > Before I start any work on Web UI and tests I would like to gather > > feedback on: > > - the new API > > - member attributes with subtypes management approach > > - ACI > > > > I did not do any ACI work in the patch yet. I assume that we would like > > to add the attr into 'System: Read Host|Service' permission. But I > > think that write right should have it's own permission. > > I have added 2 new permissions. Simo, are they OK? > > for services: > 'System: Manage Service Keytab Permissions': { > 'ipapermright': {'read', 'search', 'compare', 'write'}, > 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, > 'default_privileges': {'Service Administrators', 'Host > Administrators'}, > }, > > for hosts: > 'System: Manage Host Keytab Permissions': { > 'ipapermright': {'read', 'search', 'compare', 'write'}, > 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, > 'default_privileges': {'Host Administrators'}, > }, > > I'm not sure about the write right for 'objectclass' but it's required > in order to add 'ipaallowedoperations' oc. As long as it allows only to add/remove the specific value it should be fine. Can you please send the raw ACIs ? I still find it difficult to reason on the security of the result withouth looking at the lower level. > > Patch info: > > Adds new API: > > ipa host-add-retrieve-keytab HOSTNAME --users=STR --groups=STR > > ipa host-add-write-keytab HOSTNAME --users=STR --groups=STR > > ipa host-remove-retrieve-keytab HOSTNAME --users=STR --groups=STR > > ipa host-remove-write-keytab HOSTNAME --users=STR --groups=STR > > > > ipa service-add-retrieve-keytab PRINCIPAL --users=STR --groups=STR > > ipa service-add-write-keytab PRINCIPAL --users=STR --groups=STR > > ipa service-remove-retrieve-keytab PRINCIPAL --users=STR --groups=STR > > ipa service-remove-write-keytab PRINCIPAL --users=STR --groups=STR > > *-write-keytab commands were changed to *-create-keytab to be consistent > with descriptions Uhmm these names are a bit difficult to grok, maybe somehting like: ipa service-modify --allowed_operations retrieve_keytab/create_keytab would be easier. Simo. From pvoborni at redhat.com Fri Oct 3 14:47:47 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 Oct 2014 16:47:47 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EB18A.6070607@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> Message-ID: <542EB713.8040605@redhat.com> On 3.10.2014 16:24, Martin Kosek wrote: > NACK. I will not comment on mechanics, if you get an ACK from Honza, it > is good enough. I just do not like the API. It is hard to guess what > "host-add-retrieve-keytab" means. That word does not even make much sense. > > Can we use something more readable? For example: > > ipa host-add-allowed-operation HOSTNAME --operation read_keys > --users=STR --groups STR > ipa host-add-allowed-operation HOSTNAME --operation write_keys > --users=STR --groups STR > > and > > ipa host-remove-allowed-operation HOSTNAME --operation read_keys > --users=STR --groups STR > ipa host-remove-allowed-operation HOSTNAME --operation write_keys > --users=STR --groups STR > > Same with services. At least to me, it looks more readable. > > Thanks, > Martin > Seems to me as adding of allowed operation. Not allowing an operation. What about: ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR or if we expect more operations in a future: ipa host-allow-operation HOSTNAME --operation read-keys --users=STR --groups STR ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR --groups STR ipa host-allow-operation HOSTNAME --operation write-keys --users=STR --groups STR ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR --groups STR or if we want to keep 'add' and 'remove' in command names: ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR personally I'm not a fan o the --operation switch, but could be persuaded by a 'future' usage. -- Petr Vobornik From mkosek at redhat.com Fri Oct 3 14:54:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Oct 2014 16:54:38 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EB713.8040605@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> Message-ID: <542EB8AE.4080000@redhat.com> On 10/03/2014 04:47 PM, Petr Vobornik wrote: > On 3.10.2014 16:24, Martin Kosek wrote: >> NACK. I will not comment on mechanics, if you get an ACK from Honza, it >> is good enough. I just do not like the API. It is hard to guess what >> "host-add-retrieve-keytab" means. That word does not even make much sense. >> >> Can we use something more readable? For example: >> >> ipa host-add-allowed-operation HOSTNAME --operation read_keys >> --users=STR --groups STR >> ipa host-add-allowed-operation HOSTNAME --operation write_keys >> --users=STR --groups STR >> >> and >> >> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >> --users=STR --groups STR >> ipa host-remove-allowed-operation HOSTNAME --operation write_keys >> --users=STR --groups STR >> >> Same with services. At least to me, it looks more readable. >> >> Thanks, >> Martin >> > > Seems to me as adding of allowed operation. Not allowing an operation. > > What about: > > ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR > ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR > ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR > ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR > > or if we expect more operations in a future: > > ipa host-allow-operation HOSTNAME --operation read-keys --users=STR --groups STR > ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR --groups > STR > ipa host-allow-operation HOSTNAME --operation write-keys --users=STR --groups STR > ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR > --groups STR > > or if we want to keep 'add' and 'remove' in command names: > > ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR > ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR > ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR > ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR > > > personally I'm not a fan o the --operation switch, but could be persuaded by a > 'future' usage. ipa host-allow-operation HOSTNAME --operation read-keys --users=STR --groups STR and friends looks the best to me. Given the way the ipaAllowedOperation attribute is designed (countless possible sub types), new future operations can be expected. Simo or Rob, any opinion on this API? Martin From jcholast at redhat.com Fri Oct 3 14:59:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 03 Oct 2014 16:59:37 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EB713.8040605@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> Message-ID: <542EB9D9.6050000@redhat.com> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): > On 3.10.2014 16:24, Martin Kosek wrote: >> NACK. I will not comment on mechanics, if you get an ACK from Honza, it >> is good enough. I just do not like the API. It is hard to guess what >> "host-add-retrieve-keytab" means. That word does not even make much >> sense. >> >> Can we use something more readable? For example: >> >> ipa host-add-allowed-operation HOSTNAME --operation read_keys >> --users=STR --groups STR >> ipa host-add-allowed-operation HOSTNAME --operation write_keys >> --users=STR --groups STR >> >> and >> >> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >> --users=STR --groups STR >> ipa host-remove-allowed-operation HOSTNAME --operation write_keys >> --users=STR --groups STR >> >> Same with services. At least to me, it looks more readable. >> >> Thanks, >> Martin >> > > Seems to me as adding of allowed operation. Not allowing an operation. +1 > > What about: > > ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR > ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR > ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR > ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR I like these the best. Maybe with a -to or -by suffix. > > or if we expect more operations in a future: > > ipa host-allow-operation HOSTNAME --operation read-keys --users=STR > --groups STR > ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR > --groups STR > ipa host-allow-operation HOSTNAME --operation write-keys --users=STR > --groups STR > ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR > --groups STR > > or if we want to keep 'add' and 'remove' in command names: > > ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR > ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR > ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR > ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR > > > personally I'm not a fan o the --operation switch, but could be > persuaded by a 'future' usage. Not a fan either, because it is not consistent with the rest of the framework. Also, non-optional options are not really options. -- Jan Cholasta From mkosek at redhat.com Fri Oct 3 15:02:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 03 Oct 2014 17:02:56 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EB9D9.6050000@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> Message-ID: <542EBAA0.9080805@redhat.com> On 10/03/2014 04:59 PM, Jan Cholasta wrote: > Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): >> On 3.10.2014 16:24, Martin Kosek wrote: >>> NACK. I will not comment on mechanics, if you get an ACK from Honza, it >>> is good enough. I just do not like the API. It is hard to guess what >>> "host-add-retrieve-keytab" means. That word does not even make much >>> sense. >>> >>> Can we use something more readable? For example: >>> >>> ipa host-add-allowed-operation HOSTNAME --operation read_keys >>> --users=STR --groups STR >>> ipa host-add-allowed-operation HOSTNAME --operation write_keys >>> --users=STR --groups STR >>> >>> and >>> >>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >>> --users=STR --groups STR >>> ipa host-remove-allowed-operation HOSTNAME --operation write_keys >>> --users=STR --groups STR >>> >>> Same with services. At least to me, it looks more readable. >>> >>> Thanks, >>> Martin >>> >> >> Seems to me as adding of allowed operation. Not allowing an operation. > > +1 > >> >> What about: >> >> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR >> ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR >> ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR > > I like these the best. Maybe with a -to or -by suffix. > >> >> or if we expect more operations in a future: >> >> ipa host-allow-operation HOSTNAME --operation read-keys --users=STR >> --groups STR >> ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR >> --groups STR >> ipa host-allow-operation HOSTNAME --operation write-keys --users=STR >> --groups STR >> ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR >> --groups STR >> >> or if we want to keep 'add' and 'remove' in command names: >> >> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >> ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR >> ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >> ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >> >> >> personally I'm not a fan o the --operation switch, but could be >> persuaded by a 'future' usage. > > Not a fan either, because it is not consistent with the rest of the framework. > Also, non-optional options are not really options. Right. Though mandatory options is a concept already existing in FreeIPA framework in many places. What I see as a deal breaker is that with --operation switch, we are ready for dozens of potential future operations. With operation hardcoded in command name, we are not. Also note that framework internals can be changed more easily (to achieve more consistency) than API. Martin From pvoborni at redhat.com Fri Oct 3 15:03:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 Oct 2014 17:03:30 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <1921241086.3447498.1412347574841.JavaMail.zimbra@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <1921241086.3447498.1412347574841.JavaMail.zimbra@redhat.com> Message-ID: <542EBAC2.4080203@redhat.com> On 3.10.2014 16:46, Simo Sorce wrote: >>> >>> I did not do any ACI work in the patch yet. I assume that we would like >>> to add the attr into 'System: Read Host|Service' permission. But I >>> think that write right should have it's own permission. >> >> I have added 2 new permissions. Simo, are they OK? >> >> for services: >> 'System: Manage Service Keytab Permissions': { >> 'ipapermright': {'read', 'search', 'compare', 'write'}, >> 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, >> 'default_privileges': {'Service Administrators', 'Host >> Administrators'}, >> }, >> >> for hosts: >> 'System: Manage Host Keytab Permissions': { >> 'ipapermright': {'read', 'search', 'compare', 'write'}, >> 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, >> 'default_privileges': {'Host Administrators'}, >> }, >> >> I'm not sure about the write right for 'objectclass' but it's required >> in order to add 'ipaallowedoperations' oc. > > As long as it allows only to add/remove the specific value it should be fine. > > Can you please send the raw ACIs ? > I still find it difficult to reason on the security of the result withouth > looking at the lower level. > in cn=computers,cn=accounts,dc=example,dc=com: (targetattr = "createtimestamp || entryusn || ipaallowedtoperform || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab Permissions";allow (compare,read,search,write) groupdn = "ldap:///cn=System: Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=example,dc=com";) in cn=services,cn=accounts,dc=idm,dc=example,dc=com: (targetattr = "createtimestamp || entryusn || ipaallowedtoperform || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaservice)")(version 3.0;acl "permission:System: Manage Service Keytab Permissions";allow (compare,read,search,write) groupdn = "ldap:///cn=System: Manage Service Keytab Permissions,cn=permissions,cn=pbac,dc=example,dc=com";) > > Simo. > -- Petr Vobornik From pvoborni at redhat.com Fri Oct 3 16:48:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 03 Oct 2014 18:48:18 +0200 Subject: [Freeipa-devel] [PATCH] 765 webui: allow --force in dnszone-mod and dnsrecord-add Message-ID: <542ED352.6020806@redhat.com> Allow to use --force when changing authoritative nameserver address in DNS zone. Same for dnsrecord-add for NS record. https://fedorahosted.org/freeipa/ticket/4573 Note: dnsrecord-mod doesn't support --force option to skip dns resolution when changing NS record. Question is whether it should be added, or if 'edit' button should be hidden in web ui to force dnsrecord-add + dnsrecord-del combo instead of dnsrecord-mod, or if it's good as is. Note2: -add + -del combo has better UX than -del + -add if there is only one value in the dns record. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0765-webui-allow-force-in-dnszone-mod-and-dnsrecord-add.patch Type: text/x-patch Size: 6144 bytes Desc: not available URL: From tbordaz at redhat.com Fri Oct 3 17:52:36 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 03 Oct 2014 19:52:36 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412015453.18502.7.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> Message-ID: <542EE264.5040308@redhat.com> Hello Nathaniel, An additional comment about the patch. When the new value is detected to be invalid, it is fixed by a repair operation (trigger_replication). I did test it and it is fine to update, with an internal operation, the same entry that is currently updated. Now if you apply the repair operation into a be_preop or a betxn_preop, when it returns from preop the txn of the current operation will overwrite the repaired value. An option is to register a bepost that checks the value from the original entry (SLAPI_ENTRY_PRE_OP) and post entry (SLAPI_ENTRY_POST_OP). Then this postop checks the orginal/final value and can trigger the repair op. This time being outside of the main operation txn, the repair op will be applied. thanks thierry On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: > On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: >> On Sun, 21 Sep 2014 22:33:47 -0400 >> Nathaniel McCallum wrote: >> >> Comments inline. >> >>> + >>> +#define ch_malloc(type) \ >>> + (type*) slapi_ch_malloc(sizeof(type)) >>> +#define ch_calloc(count, type) \ >>> + (type*) slapi_ch_calloc(count, sizeof(type)) >>> +#define ch_free(p) \ >>> + slapi_ch_free((void**) &(p)) >> please do not redefine slapi functions, it just makes it harder to know >> what you used. >> >> >>> +typedef struct { >>> + bool exists; >>> + long long value; >>> +} counter; >> >> please no typedefs of structures, use "struct counter { ... };" and >> reference it as "struct counter" in the code. >> >> Btw, FWIW you could use a value of -1 to indicate non-existence of the >> counter value, given counters can only be positive, this would avoid >> the need for a struct. >> >>> +static int >>> +send_error(Slapi_PBlock *pb, int rc, char *template, ...) >>> +{ >>> + va_list ap; >>> + int res; >>> + >>> + va_start(ap, template); >>> + res = vsnprintf(NULL, 0, template, ap); >>> + va_end(ap); >>> + >>> + if (res > 0) { >>> + char str[res + 1]; >>> + >>> + va_start(ap, template); >>> + res = vsnprintf(str, sizeof(str), template, ap); >>> + va_end(ap); >>> + >>> + if (res > 0) >>> + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); >>> + } >>> + >>> + if (res <= 0) >>> + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); >>> + >>> + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); >>> + return rc; >>> +} >> This function seem not really useful, you use send_error() only at the >> end of one single function where you could have the classic scheme of >> using a done: label and just use directly slapi_ch_smprintf. This would >> remove the need to use vsnprintf and all the va_ machinery which is >> more than 50% of this function. >> >> >>> +static long long >>> +get_value(const LDAPMod *mod, long long def) >>> +{ >>> + const struct berval *bv; >>> + long long val; >>> + >>> + if (mod == NULL) >>> + return def; >>> + >>> + if (mod->mod_vals.modv_bvals == NULL) >>> + return def; >>> + >>> + bv = mod->mod_vals.modv_bvals[0]; >>> + if (bv == NULL) >>> + return def; >> In general (here and elsewhere) I prefer to always use {} in if clauses. >> I have been bitten enough time by people adding an instruction that >> should be in the braces but forgot to add braces (defensive programming >> style). But up to you. >> >>> + char buf[bv->bv_len + 1]; >>> + memcpy(buf, bv->bv_val, bv->bv_len); >>> + buf[sizeof(buf)-1] = '\0'; >>> + >>> + val = strtoll(buf, NULL, 10); >>> + if (val == LLONG_MIN || val == LLONG_MAX) >>> + return def; >>> + >>> + return val; >>> +} >>> + >>> +static struct berval ** >>> +make_berval_array(long long value) >>> +{ >>> + struct berval **bvs; >>> + >>> + bvs = ch_calloc(2, struct berval*); >>> + bvs[0] = ch_malloc(struct berval); >>> + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); >>> + bvs[0]->bv_len = strlen(bvs[0]->bv_val); >>> + >>> + return bvs; >>> +} >>> + >>> +static LDAPMod * >>> +make_ldapmod(int op, const char *attr, long long value) >>> +{ >>> + LDAPMod *mod; >>> + >>> + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); >>> + mod->mod_op = op | LDAP_MOD_BVALUES; >>> + mod->mod_type = slapi_ch_strdup(attr); >>> + mod->mod_bvalues = make_berval_array(value); >>> + >>> + return mod; >>> +} >>> + >>> +static void >>> +convert_ldapmod_to_bval(LDAPMod *mod) >>> +{ >>> + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) >>> + return; >>> + >>> + mod->mod_op |= LDAP_MOD_BVALUES; >>> + >>> + if (mod->mod_values == NULL) { >>> + mod->mod_bvalues = NULL; >>> + return; >>> + } >>> + >>> + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { >>> + struct berval *bv = ch_malloc(struct berval); >>> + bv->bv_val = mod->mod_values[i]; >>> + bv->bv_len = strlen(bv->bv_val); >>> + mod->mod_bvalues[i] = bv; >>> + } >>> +} >>> + >>> +static counter >>> +get_counter(Slapi_Entry *entry, const char *attr) >>> +{ >>> + Slapi_Attr *sattr = NULL; >>> + >>> + return (counter) { >>> + slapi_entry_attr_find(entry, attr, &sattr) == 0, >>> + slapi_entry_attr_get_longlong(entry, attr) >>> + }; >>> +} >>> + >>> +static void >>> +berval_free_array(struct berval ***bvals) >>> +{ >>> + for (size_t i = 0; (*bvals)[i] != NULL; i++) { >>> + ch_free((*bvals)[i]->bv_val); >>> + ch_free((*bvals)[i]); >>> + } >>> + >>> + slapi_ch_free((void**) bvals); >>> +} >>> + >>> +static bool >>> +is_replication(Slapi_PBlock *pb) >>> +{ >>> + int repl = 0; >>> + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); >>> + return repl != 0; >>> +} >>> + >>> +static const char * >>> +get_attribute(Slapi_Entry *entry) >>> +{ >>> + static struct { >>> + const char *clss; >>> + const char *attr; >>> + } table[] = { >>> + { "ipatokenHOTP", "ipatokenHOTPcounter" }, >>> + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, >>> + { NULL, NULL } >>> + }; >>> + >>> + const char *attr = NULL; >>> + char **clsses = NULL; >>> + >>> + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); >>> + if (clsses == NULL) >>> + return NULL; >>> + >>> + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { >>> + for (size_t j = 0; attr == NULL && table[j].clss != NULL; >>> j++) { >>> + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) >>> + attr = table[j].attr; >>> + } >>> + } >>> + >>> + slapi_ch_array_free(clsses); >>> + return attr; >>> +} >> Can you put a comment here that explains what you are going to do in >> each cases in plain English ? This will help people in future figuring >> out if/how to modify the code or why something happens a specific way. >> It will also help the reviewer follow what is going on. >> >> >>> +static int >>> +preop_mod(Slapi_PBlock *pb) >>> +{ >>> + size_t count = 0, attrs = 0, extras = 0; >>> + Slapi_Entry *entry = NULL; >>> + const char *attr = NULL; >>> + LDAPMod **inmods = NULL; >>> + LDAPMod **mods = NULL; >>> + counter ctr, orig; >>> + >>> + /* Get the input values. */ >>> + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); >>> + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); >>> + if (entry == NULL || inmods == NULL) >>> + return 0; >>> + >>> + /* Get the attribute name. */ >>> + attr = get_attribute(entry); >>> + if (attr == NULL) >>> + return 0; /* Not a token. */ >>> + >>> + /* Count items. */ >>> + while (inmods != NULL && inmods[count] != NULL) { >> ^^ this one would read much better as: >> for (count = 0; inmods[count] != NULL; count++) { >> >> You do not need to check for insmods != NULL as you already check for >> it and return 0 a few lines above. >> >>> + LDAPMod *mod = inmods[count++]; >>> + >>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>> + continue; >>> + >>> + attrs++; >>> + switch (mod->mod_op & LDAP_MOD_OP) { >>> + case LDAP_MOD_REPLACE: >>> + case LDAP_MOD_INCREMENT: >>> + extras++; >>> + break; >>> + } >>> + } >>> + >>> + /* Not operating on the counter/watermark. */ >>> + if (attrs == 0) >>> + return 0; >>> + >>> + /* Get the counter. */ >>> + orig = ctr = get_counter(entry, attr); >>> + >>> + /* Filter the modify operations. */ >>> + mods = ch_calloc(count + extras + 1, LDAPMod*); >>> + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; >>> mods[j++] = inmods[i++]) { >> Please remove check for insmods != NULL, it is useless, and removing it >> will bring back the line under 80columns >> >>> + LDAPMod *mod = inmods[i]; >>> + >>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>> + continue; >>> + >>> + convert_ldapmod_to_bval(mod); >>> + >>> + switch (mod->mod_op & LDAP_MOD_OP) { >>> + case LDAP_MOD_DELETE: >>> + ctr.exists = false; >>> + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == >>> NULL) >>> + berval_free_array(&mod->mod_bvalues); >>> + >>> + if (is_replication(pb)) >>> + berval_free_array(&mod->mod_bvalues); >>> + >>> + if (mod->mod_bvalues == NULL) >>> + mod->mod_bvalues = make_berval_array(ctr.value); >>> + break; >> I am not sure I understand this segment, why are you touching the >> delete operation outside of a replication event ? >> Doesn't this defeat and admin tool trying to correctly delete/add to >> avoid races ? >> >>> + case LDAP_MOD_INCREMENT: >>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>> ctr.value); + >>> + ctr.value += get_value(mod, 1); >> uhmmm if you had an ADD followed by INCREMENT operation, would this >> cause the value to become value*2+1 instead of just value+1 ? >> >>> + berval_free_array(&mod->mod_bvalues); >>> + mod->mod_op &= ~LDAP_MOD_OP; >>> + mod->mod_op |= LDAP_MOD_ADD; >>> + mod->mod_bvalues = make_berval_array(ctr.value); >>> + break; >> uhmm why are you converting mod_increment in all cases ? (including >> replication) >> >>> + case LDAP_MOD_REPLACE: >>> + if (ctr.exists) >>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>> ctr.value); + >>> + mod->mod_op &= ~LDAP_MOD_OP; >>> + mod->mod_op |= LDAP_MOD_ADD; >> same question here, why are you converting a replace coming from >> replication into a delete/add ? >> >>> + case LDAP_MOD_ADD: >>> + ctr.value = get_value(mod, 0); >>> + ctr.exists = true; >>> + break; >>> + } >>> + } >>> + >>> + /* Set the modified operations. */ >>> + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); >>> + ch_free(inmods); >>> + >>> + /* Ensure we aren't deleting the counter. */ >>> + if (orig.exists && !ctr.exists) >>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>> + "Will not delete %s", attr); >>> + >>> + /* Ensure we aren't rolling back the counter. */ >>> + if (orig.value > ctr.value) >>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>> + "Will not decrement %s", attr); >>> + >>> + return 0; >>> +} >> >> see above about send_error(). >> >> I think what is needed most is the comment that explains the process >> at the to of the main function. >> >> Simo. > All of the above are fixed. > > Also, I have addressed Thierry's concern about putting the plugin in > betxnpreoperation by splitting the plugin into two phases: modification > and validation. Now all modifications occur in bepreoperation and all > validation occurs in betxnpreoperation. > > Additionally, I have new code to trigger a new replication in the case > where a validation error occurs and we are in a replication transaction. > Thus, when A attempts to push an old counter value to B, B will now > replicate the latest value back to A. > > Nathaniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Fri Oct 3 23:58:02 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 3 Oct 2014 17:58:02 -0600 Subject: [Freeipa-devel] [PATCH 0033] Remove trivial path constants In-Reply-To: <542AE179.6050303@redhat.com> References: <542AE179.6050303@redhat.com> Message-ID: Thanks Petr. Updated patch attached. On Tue, Sep 30, 2014 at 10:59 AM, Petr Viktorin wrote: > On 09/30/2014 05:13 AM, Gabe Alford wrote: > >> Updated patch to fix merge conflicts from recent changes. >> >> On Wed, Sep 24, 2014 at 8:34 PM, Gabe Alford > > wrote: >> >> Hello, >> >> Patch for https://fedorahosted.org/freeipa/ticket/4399. Let me know >> if I missed any. >> >> Thanks, >> >> Gabe >> > > Thanks for the patch, and sorry for the delay! > > ipaserver/tools/ipa-upgradeconfig: > The `filename` and `ca_file` aren't module-level constants; I think in > this case they improve readability. > The ticket calls for removing module-level lines like: > NSSWITCH_CONF = paths.NSSWITCH_CONF > which are just silly, but assigning a name locally to a global constant is > a valid thing to do -- even if the local name just says "the file we're > working on now". > > > - ca_file = paths.ALIAS_CACERT_ASC >> - if os.path.exists(ca_file): >> + if os.path.exists(paths.SYSCONFIG_HTTPD): >> > > Whoops! > > > install/wsgi/plugins.py: > > -PLUGINS_DIR = paths.IPA_JS_PLUGINS_DIR >> - >> > [...] > >> - if not os.path.isdir(PLUGINS_DIR): >> + if not os.path.isdir(paths.IPA_CA_CSR): >> > > Whoops too! > > > ipaplatform/fedora/tasks.py: > ipa-client/ipa-install/ipa-client-install: > ipaserver/install/dsinstance.py: > ipaserver/install/httpinstance.py: > Again, I'd not change the target_fname, filepath. > > > ipapython/sysrestore.py: > Again, `SYSRESTORE_PATH` describes better what we do with `paths.TMP`, so > I'd prefer keeping it. > > > ipaserver/install/adtrustinstance.py: > I don't think we want to convert the self.* to constants. > > > ipaserver/install/certs.py: > I'd leave NSS_DIR as it is, rather than lose the comment. > > > ipapython/ipautil.py: > ipaserver/install/ldapupdate.py: > ipalib/session.py: > ipaserver/install/bindinstance.py: > SHARE_DIR, UPDATES_DIR, and krbccache_dir, NAMED_CONF (respectively) need > to stay, unless you also replace them in everything that uses them. > > Be sure to run make-lint after doing these changes. > > > I've rebased, and I made some of the changes as I went along the review. > You can base another revision on the attached patch. > > -- > Petr? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0033-3-Remove-trivial-path-constants-from-modules.patch Type: text/x-patch Size: 18537 bytes Desc: not available URL: From jcholast at redhat.com Mon Oct 6 08:33:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 06 Oct 2014 10:33:23 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EBAA0.9080805@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> Message-ID: <543253D3.5070701@redhat.com> Dne 3.10.2014 v 17:02 Martin Kosek napsal(a): > On 10/03/2014 04:59 PM, Jan Cholasta wrote: >> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): >>> On 3.10.2014 16:24, Martin Kosek wrote: >>>> NACK. I will not comment on mechanics, if you get an ACK from Honza, it >>>> is good enough. I just do not like the API. It is hard to guess what >>>> "host-add-retrieve-keytab" means. That word does not even make much >>>> sense. >>>> >>>> Can we use something more readable? For example: >>>> >>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys >>>> --users=STR --groups STR >>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys >>>> --users=STR --groups STR >>>> >>>> and >>>> >>>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >>>> --users=STR --groups STR >>>> ipa host-remove-allowed-operation HOSTNAME --operation write_keys >>>> --users=STR --groups STR >>>> >>>> Same with services. At least to me, it looks more readable. >>>> >>>> Thanks, >>>> Martin >>>> >>> >>> Seems to me as adding of allowed operation. Not allowing an operation. >> >> +1 >> >>> >>> What about: >>> >>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR >>> ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR >>> ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR >> >> I like these the best. Maybe with a -to or -by suffix. >> >>> >>> or if we expect more operations in a future: >>> >>> ipa host-allow-operation HOSTNAME --operation read-keys --users=STR >>> --groups STR >>> ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR >>> --groups STR >>> ipa host-allow-operation HOSTNAME --operation write-keys --users=STR >>> --groups STR >>> ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR >>> --groups STR >>> >>> or if we want to keep 'add' and 'remove' in command names: >>> >>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >>> ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR >>> ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >>> ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >>> >>> >>> personally I'm not a fan o the --operation switch, but could be >>> persuaded by a 'future' usage. >> >> Not a fan either, because it is not consistent with the rest of the >> framework. >> Also, non-optional options are not really options. > > Right. Though mandatory options is a concept already existing in FreeIPA > framework in many places. That does not make it right. > What I see as a deal breaker is that with > --operation switch, we are ready for dozens of potential future > operations. With operation hardcoded in command name, we are not. I don't see dozens of operations coming in the near future, there's no need for a premature optimization like this. > > Also note that framework internals can be changed more easily (to > achieve more consistency) than API. I would rather avoid ad-hoc "enhancements" that add more complexity and untransparentness (if that's a word) to the framework, we already have enough of these IMHO. > > Martin -- Jan Cholasta From jcholast at redhat.com Mon Oct 6 10:31:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 06 Oct 2014 12:31:53 +0200 Subject: [Freeipa-devel] [PATCHES] 344-346 Support building RPMs for RHEL/CentOS 7.0 Message-ID: <54326F99.50301@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-344-Split-off-generic-Red-Hat-like-platform-code-from-Fe.patch Type: text/x-patch Size: 60625 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-344-Split-off-generic-Red-Hat-like-platform-code-from-Fe-ipa-4-0.patch Type: text/x-patch Size: 51292 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-344-Split-off-generic-Red-Hat-like-platform-code-from-Fe-ipa-4-1.patch Type: text/x-patch Size: 61382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-345-Add-RHEL-platform-module.patch Type: text/x-patch Size: 7057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-345-Add-RHEL-platform-module-ipa-4-0.patch Type: text/x-patch Size: 7057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-345-Add-RHEL-platform-module-ipa-4-1.patch Type: text/x-patch Size: 7057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-346-Support-building-RPMs-for-RHEL-CentOS-7.0.patch Type: text/x-patch Size: 3546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-346-Support-building-RPMs-for-RHEL-CentOS-7.0-ipa-4-0.patch Type: text/x-patch Size: 3546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-346-Support-building-RPMs-for-RHEL-CentOS-7.0-ipa-4-1.patch Type: text/x-patch Size: 3546 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 6 10:48:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 Oct 2014 12:48:13 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EBAC2.4080203@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <1921241086.3447498.1412347574841.JavaMail.zimbra@redhat.com> <542EBAC2.4080203@redhat.com> Message-ID: <5432736D.2030601@redhat.com> On 10/03/2014 05:03 PM, Petr Vobornik wrote: > On 3.10.2014 16:46, Simo Sorce wrote: >>>> >>>> I did not do any ACI work in the patch yet. I assume that we would like >>>> to add the attr into 'System: Read Host|Service' permission. But I >>>> think that write right should have it's own permission. >>> >>> I have added 2 new permissions. Simo, are they OK? >>> >>> for services: >>> 'System: Manage Service Keytab Permissions': { >>> 'ipapermright': {'read', 'search', 'compare', 'write'}, >>> 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, >>> 'default_privileges': {'Service Administrators', 'Host >>> Administrators'}, >>> }, >>> >>> for hosts: >>> 'System: Manage Host Keytab Permissions': { >>> 'ipapermright': {'read', 'search', 'compare', 'write'}, >>> 'ipapermdefaultattr': {'ipaallowedtoperform', 'objectclass'}, >>> 'default_privileges': {'Host Administrators'}, >>> }, >>> >>> I'm not sure about the write right for 'objectclass' but it's required >>> in order to add 'ipaallowedoperations' oc. >> >> As long as it allows only to add/remove the specific value it should be fine. >> >> Can you please send the raw ACIs ? >> I still find it difficult to reason on the security of the result withouth >> looking at the lower level. >> > > in cn=computers,cn=accounts,dc=example,dc=com: > > (targetattr = "createtimestamp || entryusn || ipaallowedtoperform || > modifytimestamp || objectclass")(targetfilter = > "(objectclass=ipahost)")(version 3.0;acl "permission:System: Manage Host Keytab > Permissions";allow (compare,read,search,write) groupdn = "ldap:///cn=System: > Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=example,dc=com";) > > in cn=services,cn=accounts,dc=idm,dc=example,dc=com: > > (targetattr = "createtimestamp || entryusn || ipaallowedtoperform || > modifytimestamp || objectclass")(targetfilter = > "(objectclass=ipaservice)")(version 3.0;acl "permission:System: Manage Service > Keytab Permissions";allow (compare,read,search,write) groupdn = > "ldap:///cn=System: Manage Service Keytab > Permissions,cn=permissions,cn=pbac,dc=example,dc=com";) I do not think this is what Simo wanted to see. IMO, by "allowing only a specific value" he wanted to allow holders of a permission to only add/update/remove only selected operations, for example ipaallowedtoperform;read_key. The targetattr part should then only target ipaallowedtoperform;read_key and not whole ipaallowedtoperform. (If that is really supported in DS ACI). Martin From mkosek at redhat.com Mon Oct 6 10:53:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 Oct 2014 12:53:57 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <543253D3.5070701@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> <543253D3.5070701@redhat.com> Message-ID: <543274C5.2090902@redhat.com> On 10/06/2014 10:33 AM, Jan Cholasta wrote: > Dne 3.10.2014 v 17:02 Martin Kosek napsal(a): >> On 10/03/2014 04:59 PM, Jan Cholasta wrote: >>> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): >>>> On 3.10.2014 16:24, Martin Kosek wrote: >>>>> NACK. I will not comment on mechanics, if you get an ACK from Honza, it >>>>> is good enough. I just do not like the API. It is hard to guess what >>>>> "host-add-retrieve-keytab" means. That word does not even make much >>>>> sense. >>>>> >>>>> Can we use something more readable? For example: >>>>> >>>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys >>>>> --users=STR --groups STR >>>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys >>>>> --users=STR --groups STR >>>>> >>>>> and >>>>> >>>>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >>>>> --users=STR --groups STR >>>>> ipa host-remove-allowed-operation HOSTNAME --operation write_keys >>>>> --users=STR --groups STR >>>>> >>>>> Same with services. At least to me, it looks more readable. >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>> >>>> Seems to me as adding of allowed operation. Not allowing an operation. >>> >>> +1 >>> >>>> >>>> What about: >>>> >>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >>>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR >>>> ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR >>>> ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR >>> >>> I like these the best. Maybe with a -to or -by suffix. >>> >>>> >>>> or if we expect more operations in a future: >>>> >>>> ipa host-allow-operation HOSTNAME --operation read-keys --users=STR >>>> --groups STR >>>> ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR >>>> --groups STR >>>> ipa host-allow-operation HOSTNAME --operation write-keys --users=STR >>>> --groups STR >>>> ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR >>>> --groups STR >>>> >>>> or if we want to keep 'add' and 'remove' in command names: >>>> >>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >>>> ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR >>>> ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >>>> ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >>>> >>>> >>>> personally I'm not a fan o the --operation switch, but could be >>>> persuaded by a 'future' usage. >>> >>> Not a fan either, because it is not consistent with the rest of the >>> framework. >>> Also, non-optional options are not really options. >> >> Right. Though mandatory options is a concept already existing in FreeIPA >> framework in many places. > > That does not make it right. Right :-) >> What I see as a deal breaker is that with >> --operation switch, we are ready for dozens of potential future >> operations. With operation hardcoded in command name, we are not. > > I don't see dozens of operations coming in the near future, there's no need for > a premature optimization like this. My point was that it will be difficult to switch from having per-operation commands to one general command for all operations later, however far the future is. Given there is no clear agreement on the API (ipa host-allow-operation vs. host-allow-read-keytab+host-allow-write-keytab) yet, I would like to ask Rob or Simo for their opinion/vote here too so that we can select an approach and go with it. Martin From pviktori at redhat.com Mon Oct 6 11:31:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 06 Oct 2014 13:31:37 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542EBAA0.9080805@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> Message-ID: <54327D99.7010106@redhat.com> On 10/03/2014 05:02 PM, Martin Kosek wrote: [...] >> I like these the best. Maybe with a -to or -by suffix. >> >>> >>> or if we expect more operations in a future: >>> >>> ipa host-allow-operation HOSTNAME --operation read-keys --users=STR >>> --groups STR >>> ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR >>> --groups STR >>> ipa host-allow-operation HOSTNAME --operation write-keys --users=STR >>> --groups STR >>> ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR >>> --groups STR >>> >>> or if we want to keep 'add' and 'remove' in command names: >>> >>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >>> ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR >>> ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >>> ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >>> >>> >>> personally I'm not a fan o the --operation switch, but could be >>> persuaded by a 'future' usage. >> >> Not a fan either, because it is not consistent with the rest of the >> framework. >> Also, non-optional options are not really options. To quote optparse docs: > If there is a piece of information that your program absolutely requires > in order to run successfully, that?s what positional arguments are for. How about something like: ipa host-allow-operation HOSTNAME read-keys --users=STR --groups STR ipa host-disallow-operation HOSTNAME read-keys --users=STR --groups STR ipa host-allow-operation HOSTNAME write-keys --users=STR --groups STR ipa host-disallow-operation HOSTNAME write-keys --users=STR --groups STR > Right. Though mandatory options is a concept already existing in FreeIPA > framework in many places. What I see as a deal breaker is that with > --operation switch, we are ready for dozens of potential future > operations. With operation hardcoded in command name, we are not. Positional arguments (multiple *keys) also have their precedents, in DNS or automount plugins. > Also note that framework internals can be changed more easily (to > achieve more consistency) than API. > > Martin -- Petr? From mkosek at redhat.com Mon Oct 6 11:37:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 Oct 2014 13:37:19 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <54327D99.7010106@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> <54327D99.7010106@redhat.com> Message-ID: <54327EEF.6060800@redhat.com> On 10/06/2014 01:31 PM, Petr Viktorin wrote: > On 10/03/2014 05:02 PM, Martin Kosek wrote: > [...] >>> I like these the best. Maybe with a -to or -by suffix. >>> >>>> >>>> or if we expect more operations in a future: >>>> >>>> ipa host-allow-operation HOSTNAME --operation read-keys --users=STR >>>> --groups STR >>>> ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR >>>> --groups STR >>>> ipa host-allow-operation HOSTNAME --operation write-keys --users=STR >>>> --groups STR >>>> ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR >>>> --groups STR >>>> >>>> or if we want to keep 'add' and 'remove' in command names: >>>> >>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >>>> ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR >>>> ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR >>>> ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >>>> >>>> >>>> personally I'm not a fan o the --operation switch, but could be >>>> persuaded by a 'future' usage. >>> >>> Not a fan either, because it is not consistent with the rest of the >>> framework. >>> Also, non-optional options are not really options. > > To quote optparse docs: >> If there is a piece of information that your program absolutely requires >> in order to run successfully, that?s what positional arguments are for. > > How about something like: > > ipa host-allow-operation HOSTNAME read-keys --users=STR --groups STR > ipa host-disallow-operation HOSTNAME read-keys --users=STR --groups STR > ipa host-allow-operation HOSTNAME write-keys --users=STR --groups STR > ipa host-disallow-operation HOSTNAME write-keys --users=STR --groups STR Hmm, works for me - from CLI perspective. Not sure though how easy it is to implement in the current framework. But at least with "takes_args" attribute it should not be difficult to specify the arguments. Martin From simo at redhat.com Mon Oct 6 13:01:01 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 6 Oct 2014 09:01:01 -0400 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <543274C5.2090902@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> <543253D3.5070701@redhat.com> <543274C5.2090902@redhat.com> Message-ID: <20141006090101.28a3a6a4@willson.usersys.redhat.com> On Mon, 06 Oct 2014 12:53:57 +0200 Martin Kosek wrote: > On 10/06/2014 10:33 AM, Jan Cholasta wrote: > > Dne 3.10.2014 v 17:02 Martin Kosek napsal(a): > >> On 10/03/2014 04:59 PM, Jan Cholasta wrote: > >>> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): > >>>> On 3.10.2014 16:24, Martin Kosek wrote: > >>>>> NACK. I will not comment on mechanics, if you get an ACK from > >>>>> Honza, it is good enough. I just do not like the API. It is > >>>>> hard to guess what "host-add-retrieve-keytab" means. That word > >>>>> does not even make much sense. > >>>>> > >>>>> Can we use something more readable? For example: > >>>>> > >>>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys > >>>>> --users=STR --groups STR > >>>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys > >>>>> --users=STR --groups STR > >>>>> > >>>>> and > >>>>> > >>>>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys > >>>>> --users=STR --groups STR > >>>>> ipa host-remove-allowed-operation HOSTNAME --operation > >>>>> write_keys --users=STR --groups STR > >>>>> > >>>>> Same with services. At least to me, it looks more readable. > >>>>> > >>>>> Thanks, > >>>>> Martin > >>>>> > >>>> > >>>> Seems to me as adding of allowed operation. Not allowing an > >>>> operation. > >>> > >>> +1 > >>> > >>>> > >>>> What about: > >>>> > >>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR > >>>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups > >>>> STR ipa host-allow-create-keytab HOSTNAME --users=STR --groups > >>>> STR ipa host-disallow-create-keytab HOSTNAME --users=STR > >>>> --groups STR > >>> > >>> I like these the best. Maybe with a -to or -by suffix. > >>> > >>>> > >>>> or if we expect more operations in a future: > >>>> > >>>> ipa host-allow-operation HOSTNAME --operation read-keys > >>>> --users=STR --groups STR > >>>> ipa host-disallow-operation HOSTNAME --operation read-keys > >>>> --users=STR --groups STR > >>>> ipa host-allow-operation HOSTNAME --operation write-keys > >>>> --users=STR --groups STR > >>>> ipa host-disallow-operation HOSTNAME --operation write-keys > >>>> --users=STR --groups STR > >>>> > >>>> or if we want to keep 'add' and 'remove' in command names: > >>>> > >>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR > >>>> --groups=STR ipa host-add-create-keytab-right HOSTNAME > >>>> --users=STR --groups=STR ipa host-remove-retrieve-keytab-right > >>>> HOSTNAME --users=STR --groups=STR ipa > >>>> host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR > >>>> > >>>> > >>>> personally I'm not a fan o the --operation switch, but could be > >>>> persuaded by a 'future' usage. > >>> > >>> Not a fan either, because it is not consistent with the rest of > >>> the framework. > >>> Also, non-optional options are not really options. > >> > >> Right. Though mandatory options is a concept already existing in > >> FreeIPA framework in many places. > > > > That does not make it right. > > Right :-) > > >> What I see as a deal breaker is that with > >> --operation switch, we are ready for dozens of potential future > >> operations. With operation hardcoded in command name, we are not. > > > > I don't see dozens of operations coming in the near future, there's > > no need for a premature optimization like this. > > My point was that it will be difficult to switch from having > per-operation commands to one general command for all operations > later, however far the future is. > > Given there is no clear agreement on the API (ipa > host-allow-operation vs. > host-allow-read-keytab+host-allow-write-keytab) yet, I would like to > ask Rob or Simo for their opinion/vote here too so that we can select > an approach and go with it. I am not even sure why we are tying this to hosts to be honest. The allow-operation plugin is generic, and we should probably have a command that reflect that like: ipa operations-add/mod/del and options to say what the operation does and what it applies to. Of course the naming needs more thought, but I do not think having a command for this specific narrowed down operations is wise. Actually it may even fit right into the permissions commands (Add a --operation switch ?), as these operations are just a particular type of ACIs/Permissions that apply to abstract operations rather than LDAP operations, so it is a natural extension of our permissions. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Mon Oct 6 13:47:45 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 6 Oct 2014 15:47:45 +0200 Subject: [Freeipa-devel] [RFC] Views - SSSD cache layout Message-ID: <20141006134745.GH31737@localhost.localdomain> Hi, I have started a new section on the design page 'Migrating existing environments to Trust' aka Views about how the data is stored in the cache of SSSD at http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#SSSD_Cache_layout Comments and suggestions are welcome. bye, Sumit From mkosek at redhat.com Mon Oct 6 13:49:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 Oct 2014 15:49:09 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <20141006090101.28a3a6a4@willson.usersys.redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> <543253D3.5070701@redhat.com> <543274C5.2090902@redhat.com> <20141006090101.28a3a6a4@willson.usersys.redhat.com> Message-ID: <54329DD5.5000508@redhat.com> On 10/06/2014 03:01 PM, Simo Sorce wrote: > On Mon, 06 Oct 2014 12:53:57 +0200 > Martin Kosek wrote: > >> On 10/06/2014 10:33 AM, Jan Cholasta wrote: >>> Dne 3.10.2014 v 17:02 Martin Kosek napsal(a): >>>> On 10/03/2014 04:59 PM, Jan Cholasta wrote: >>>>> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): >>>>>> On 3.10.2014 16:24, Martin Kosek wrote: >>>>>>> NACK. I will not comment on mechanics, if you get an ACK from >>>>>>> Honza, it is good enough. I just do not like the API. It is >>>>>>> hard to guess what "host-add-retrieve-keytab" means. That word >>>>>>> does not even make much sense. >>>>>>> >>>>>>> Can we use something more readable? For example: >>>>>>> >>>>>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys >>>>>>> --users=STR --groups STR >>>>>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys >>>>>>> --users=STR --groups STR >>>>>>> >>>>>>> and >>>>>>> >>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >>>>>>> --users=STR --groups STR >>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation >>>>>>> write_keys --users=STR --groups STR >>>>>>> >>>>>>> Same with services. At least to me, it looks more readable. >>>>>>> >>>>>>> Thanks, >>>>>>> Martin >>>>>>> >>>>>> >>>>>> Seems to me as adding of allowed operation. Not allowing an >>>>>> operation. >>>>> >>>>> +1 >>>>> >>>>>> >>>>>> What about: >>>>>> >>>>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >>>>>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups >>>>>> STR ipa host-allow-create-keytab HOSTNAME --users=STR --groups >>>>>> STR ipa host-disallow-create-keytab HOSTNAME --users=STR >>>>>> --groups STR >>>>> >>>>> I like these the best. Maybe with a -to or -by suffix. >>>>> >>>>>> >>>>>> or if we expect more operations in a future: >>>>>> >>>>>> ipa host-allow-operation HOSTNAME --operation read-keys >>>>>> --users=STR --groups STR >>>>>> ipa host-disallow-operation HOSTNAME --operation read-keys >>>>>> --users=STR --groups STR >>>>>> ipa host-allow-operation HOSTNAME --operation write-keys >>>>>> --users=STR --groups STR >>>>>> ipa host-disallow-operation HOSTNAME --operation write-keys >>>>>> --users=STR --groups STR >>>>>> >>>>>> or if we want to keep 'add' and 'remove' in command names: >>>>>> >>>>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR >>>>>> --groups=STR ipa host-add-create-keytab-right HOSTNAME >>>>>> --users=STR --groups=STR ipa host-remove-retrieve-keytab-right >>>>>> HOSTNAME --users=STR --groups=STR ipa >>>>>> host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >>>>>> >>>>>> >>>>>> personally I'm not a fan o the --operation switch, but could be >>>>>> persuaded by a 'future' usage. >>>>> >>>>> Not a fan either, because it is not consistent with the rest of >>>>> the framework. >>>>> Also, non-optional options are not really options. >>>> >>>> Right. Though mandatory options is a concept already existing in >>>> FreeIPA framework in many places. >>> >>> That does not make it right. >> >> Right :-) >> >>>> What I see as a deal breaker is that with >>>> --operation switch, we are ready for dozens of potential future >>>> operations. With operation hardcoded in command name, we are not. >>> >>> I don't see dozens of operations coming in the near future, there's >>> no need for a premature optimization like this. >> >> My point was that it will be difficult to switch from having >> per-operation commands to one general command for all operations >> later, however far the future is. >> >> Given there is no clear agreement on the API (ipa >> host-allow-operation vs. >> host-allow-read-keytab+host-allow-write-keytab) yet, I would like to >> ask Rob or Simo for their opinion/vote here too so that we can select >> an approach and go with it. > > I am not even sure why we are tying this to hosts to be honest. Isn't the use case to for example allow several load balancing nodes host/serverX.example.com get a keytab for host/server.example.com? > The allow-operation plugin is generic, and we should probably have a > command that reflect that like: > ipa operations-add/mod/del and options to say what the > operation does and what it applies to. > > Of course the naming needs more thought, but I do not think having a > command for this specific narrowed down operations is wise. > > Actually it may even fit right into the permissions commands (Add a > --operation switch ?), as these operations are just a particular type > of ACIs/Permissions that apply to abstract operations rather than > LDAP operations, so it is a natural extension of our permissions. > > Simo. Ok, now that's a 180? turn from what we were discussing until now... I really do not think we can go the permission route ATM, the permission plugin is now very bound to how ACIs work and how they are used in FreeIPA tree. Changing the backend from ACI to ipaAllowedOperation would be something completely different. The super-general operation-* command is interesting idea, though it decouples these operations from their targets. I think there is a benefit in seeing an command allowing writing/reading a keytab right in the list of host commands or in host page Web UI. Given the short time before 4.1 release, I think it will be more straightforward to go with ipa host-allow-operation or ipa host-allow-read-keytab/host-allow-write-keytab route. Martin From simo at redhat.com Mon Oct 6 14:01:48 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 6 Oct 2014 10:01:48 -0400 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <54329DD5.5000508@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> <543253D3.5070701@redhat.com> <543274C5.2090902@redhat.com> <20141006090101.28a3a6a4@willson.usersys.redhat.com> <54329DD5.5000508@redhat.com> Message-ID: <20141006100148.31dbfc27@willson.usersys.redhat.com> On Mon, 06 Oct 2014 15:49:09 +0200 Martin Kosek wrote: > On 10/06/2014 03:01 PM, Simo Sorce wrote: > > On Mon, 06 Oct 2014 12:53:57 +0200 > > Martin Kosek wrote: > > > >> On 10/06/2014 10:33 AM, Jan Cholasta wrote: > >>> Dne 3.10.2014 v 17:02 Martin Kosek napsal(a): > >>>> On 10/03/2014 04:59 PM, Jan Cholasta wrote: > >>>>> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): > >>>>>> On 3.10.2014 16:24, Martin Kosek wrote: > >>>>>>> NACK. I will not comment on mechanics, if you get an ACK from > >>>>>>> Honza, it is good enough. I just do not like the API. It is > >>>>>>> hard to guess what "host-add-retrieve-keytab" means. That word > >>>>>>> does not even make much sense. > >>>>>>> > >>>>>>> Can we use something more readable? For example: > >>>>>>> > >>>>>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys > >>>>>>> --users=STR --groups STR > >>>>>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys > >>>>>>> --users=STR --groups STR > >>>>>>> > >>>>>>> and > >>>>>>> > >>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation > >>>>>>> read_keys --users=STR --groups STR > >>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation > >>>>>>> write_keys --users=STR --groups STR > >>>>>>> > >>>>>>> Same with services. At least to me, it looks more readable. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Martin > >>>>>>> > >>>>>> > >>>>>> Seems to me as adding of allowed operation. Not allowing an > >>>>>> operation. > >>>>> > >>>>> +1 > >>>>> > >>>>>> > >>>>>> What about: > >>>>>> > >>>>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups > >>>>>> STR ipa host-disallow-retrieve-keytab HOSTNAME --users=STR > >>>>>> --groups STR ipa host-allow-create-keytab HOSTNAME --users=STR > >>>>>> --groups STR ipa host-disallow-create-keytab HOSTNAME > >>>>>> --users=STR --groups STR > >>>>> > >>>>> I like these the best. Maybe with a -to or -by suffix. > >>>>> > >>>>>> > >>>>>> or if we expect more operations in a future: > >>>>>> > >>>>>> ipa host-allow-operation HOSTNAME --operation read-keys > >>>>>> --users=STR --groups STR > >>>>>> ipa host-disallow-operation HOSTNAME --operation read-keys > >>>>>> --users=STR --groups STR > >>>>>> ipa host-allow-operation HOSTNAME --operation write-keys > >>>>>> --users=STR --groups STR > >>>>>> ipa host-disallow-operation HOSTNAME --operation write-keys > >>>>>> --users=STR --groups STR > >>>>>> > >>>>>> or if we want to keep 'add' and 'remove' in command names: > >>>>>> > >>>>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR > >>>>>> --groups=STR ipa host-add-create-keytab-right HOSTNAME > >>>>>> --users=STR --groups=STR ipa host-remove-retrieve-keytab-right > >>>>>> HOSTNAME --users=STR --groups=STR ipa > >>>>>> host-remove-create-keytab-right HOSTNAME --users=STR > >>>>>> --groups=STR > >>>>>> > >>>>>> > >>>>>> personally I'm not a fan o the --operation switch, but could be > >>>>>> persuaded by a 'future' usage. > >>>>> > >>>>> Not a fan either, because it is not consistent with the rest of > >>>>> the framework. > >>>>> Also, non-optional options are not really options. > >>>> > >>>> Right. Though mandatory options is a concept already existing in > >>>> FreeIPA framework in many places. > >>> > >>> That does not make it right. > >> > >> Right :-) > >> > >>>> What I see as a deal breaker is that with > >>>> --operation switch, we are ready for dozens of potential future > >>>> operations. With operation hardcoded in command name, we are not. > >>> > >>> I don't see dozens of operations coming in the near future, > >>> there's no need for a premature optimization like this. > >> > >> My point was that it will be difficult to switch from having > >> per-operation commands to one general command for all operations > >> later, however far the future is. > >> > >> Given there is no clear agreement on the API (ipa > >> host-allow-operation vs. > >> host-allow-read-keytab+host-allow-write-keytab) yet, I would like > >> to ask Rob or Simo for their opinion/vote here too so that we can > >> select an approach and go with it. > > > > I am not even sure why we are tying this to hosts to be honest. > > Isn't the use case to for example allow several load balancing nodes > host/serverX.example.com get a keytab for host/server.example.com? > > > The allow-operation plugin is generic, and we should probably have a > > command that reflect that like: > > ipa operations-add/mod/del and options to say what the > > operation does and what it applies to. > > > > Of course the naming needs more thought, but I do not think having a > > command for this specific narrowed down operations is wise. > > > > Actually it may even fit right into the permissions commands (Add a > > --operation switch ?), as these operations are just a particular > > type of ACIs/Permissions that apply to abstract operations rather > > than LDAP operations, so it is a natural extension of our > > permissions. > > > > Simo. > > Ok, now that's a 180? turn from what we were discussing until now... > I really do not think we can go the permission route ATM, the > permission plugin is now very bound to how ACIs work and how they are > used in FreeIPA tree. Changing the backend from ACI to > ipaAllowedOperation would be something completely different. > > The super-general operation-* command is interesting idea, though it > decouples these operations from their targets. I think there is a > benefit in seeing an command allowing writing/reading a keytab right > in the list of host commands or in host page Web UI. Given the short > time before 4.1 release, I think it will be more straightforward to > go with > > ipa host-allow-operation This one would be my preference then. Simo. > or > ipa host-allow-read-keytab/host-allow-write-keytab > > route. > > Martin -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Mon Oct 6 14:15:16 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 06 Oct 2014 16:15:16 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <54329DD5.5000508@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> <543253D3.5070701@redhat.com> <543274C5.2090902@redhat.com> <20141006090101.28a3a6a4@willson.usersys.redhat.com> <54329DD5.5000508@redhat.com> Message-ID: <5432A3F4.1080308@redhat.com> On 6.10.2014 15:49, Martin Kosek wrote: > On 10/06/2014 03:01 PM, Simo Sorce wrote: >> On Mon, 06 Oct 2014 12:53:57 +0200 >> Martin Kosek wrote: >> >>> On 10/06/2014 10:33 AM, Jan Cholasta wrote: >>>> Dne 3.10.2014 v 17:02 Martin Kosek napsal(a): >>>>> On 10/03/2014 04:59 PM, Jan Cholasta wrote: >>>>>> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): >>>>>>> On 3.10.2014 16:24, Martin Kosek wrote: >>>>>>>> NACK. I will not comment on mechanics, if you get an ACK from >>>>>>>> Honza, it is good enough. I just do not like the API. It is >>>>>>>> hard to guess what "host-add-retrieve-keytab" means. That word >>>>>>>> does not even make much sense. >>>>>>>> >>>>>>>> Can we use something more readable? For example: >>>>>>>> >>>>>>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys >>>>>>>> --users=STR --groups STR >>>>>>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys >>>>>>>> --users=STR --groups STR >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >>>>>>>> --users=STR --groups STR >>>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation >>>>>>>> write_keys --users=STR --groups STR >>>>>>>> >>>>>>>> Same with services. At least to me, it looks more readable. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> Seems to me as adding of allowed operation. Not allowing an >>>>>>> operation. >>>>>> >>>>>> +1 >>>>>> >>>>>>> >>>>>>> What about: >>>>>>> >>>>>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >>>>>>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups >>>>>>> STR ipa host-allow-create-keytab HOSTNAME --users=STR --groups >>>>>>> STR ipa host-disallow-create-keytab HOSTNAME --users=STR >>>>>>> --groups STR >>>>>> >>>>>> I like these the best. Maybe with a -to or -by suffix. >>>>>> >>>>>>> >>>>>>> or if we expect more operations in a future: >>>>>>> >>>>>>> ipa host-allow-operation HOSTNAME --operation read-keys >>>>>>> --users=STR --groups STR >>>>>>> ipa host-disallow-operation HOSTNAME --operation read-keys >>>>>>> --users=STR --groups STR >>>>>>> ipa host-allow-operation HOSTNAME --operation write-keys >>>>>>> --users=STR --groups STR >>>>>>> ipa host-disallow-operation HOSTNAME --operation write-keys >>>>>>> --users=STR --groups STR >>>>>>> >>>>>>> or if we want to keep 'add' and 'remove' in command names: >>>>>>> >>>>>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR >>>>>>> --groups=STR ipa host-add-create-keytab-right HOSTNAME >>>>>>> --users=STR --groups=STR ipa host-remove-retrieve-keytab-right >>>>>>> HOSTNAME --users=STR --groups=STR ipa >>>>>>> host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >>>>>>> >>>>>>> >>>>>>> personally I'm not a fan o the --operation switch, but could be >>>>>>> persuaded by a 'future' usage. >>>>>> >>>>>> Not a fan either, because it is not consistent with the rest of >>>>>> the framework. >>>>>> Also, non-optional options are not really options. >>>>> >>>>> Right. Though mandatory options is a concept already existing in >>>>> FreeIPA framework in many places. >>>> >>>> That does not make it right. >>> >>> Right :-) >>> >>>>> What I see as a deal breaker is that with >>>>> --operation switch, we are ready for dozens of potential future >>>>> operations. With operation hardcoded in command name, we are not. >>>> >>>> I don't see dozens of operations coming in the near future, there's >>>> no need for a premature optimization like this. >>> >>> My point was that it will be difficult to switch from having >>> per-operation commands to one general command for all operations >>> later, however far the future is. >>> >>> Given there is no clear agreement on the API (ipa >>> host-allow-operation vs. >>> host-allow-read-keytab+host-allow-write-keytab) yet, I would like to >>> ask Rob or Simo for their opinion/vote here too so that we can select >>> an approach and go with it. >> >> I am not even sure why we are tying this to hosts to be honest. > > Isn't the use case to for example allow several load balancing nodes > host/serverX.example.com get a keytab for host/server.example.com? > >> The allow-operation plugin is generic, and we should probably have a >> command that reflect that like: >> ipa operations-add/mod/del and options to say what the >> operation does and what it applies to. >> >> Of course the naming needs more thought, but I do not think having a >> command for this specific narrowed down operations is wise. >> >> Actually it may even fit right into the permissions commands (Add a >> --operation switch ?), as these operations are just a particular type >> of ACIs/Permissions that apply to abstract operations rather than >> LDAP operations, so it is a natural extension of our permissions. >> >> Simo. > > Ok, now that's a 180? turn from what we were discussing until now... I really > do not think we can go the permission route ATM, the permission plugin is now > very bound to how ACIs work and how they are used in FreeIPA tree. Changing the > backend from ACI to ipaAllowedOperation would be something completely different. > > The super-general operation-* command is interesting idea, though it decouples > these operations from their targets. I think there is a benefit in seeing an > command allowing writing/reading a keytab right in the list of host commands or > in host page Web UI. Given the short time before 4.1 release, I think it will > be more straightforward to go with > > ipa host-allow-operation > or > ipa host-allow-read-keytab/host-allow-write-keytab > > route. > > Martin > It also works a bit differently. Permissions defined by admin, using a permission plugin, are part of RBAC. Allowed operations aren't. Binding it with permission plugin might cause confusion. On the other hand, I'm afraid that current implementation clutters up both CLI and Web UI. We don't distinguish common commands and less used ones. Therefore they all are equally visible - not good UX. We will have to focus on this issue sooner or later. The general operaion-* commands might be a subject of discussion. I don't like it because the operations are always bound with particular object. I agree with Martin and would go with 'ipa host-allow-read-keytab/host-allow-write-keytab' commands. Also terminology is not united: write vs create + read vs retrieve. Since ipa-get-keytab uses --retrieve, I would go with 'create' and 'retrieve'. -- Petr Vobornik From mkosek at redhat.com Mon Oct 6 14:17:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 06 Oct 2014 16:17:16 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <5432A3F4.1080308@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> <543253D3.5070701@redhat.com> <543274C5.2090902@redhat.com> <20141006090101.28a3a6a4@willson.usersys.redhat.com> <54329DD5.5000508@redhat.com> <5432A3F4.1080308@redhat.com> Message-ID: <5432A46C.3040804@redhat.com> On 10/06/2014 04:15 PM, Petr Vobornik wrote: > On 6.10.2014 15:49, Martin Kosek wrote: >> On 10/06/2014 03:01 PM, Simo Sorce wrote: >>> On Mon, 06 Oct 2014 12:53:57 +0200 >>> Martin Kosek wrote: >>> >>>> On 10/06/2014 10:33 AM, Jan Cholasta wrote: >>>>> Dne 3.10.2014 v 17:02 Martin Kosek napsal(a): >>>>>> On 10/03/2014 04:59 PM, Jan Cholasta wrote: >>>>>>> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): >>>>>>>> On 3.10.2014 16:24, Martin Kosek wrote: >>>>>>>>> NACK. I will not comment on mechanics, if you get an ACK from >>>>>>>>> Honza, it is good enough. I just do not like the API. It is >>>>>>>>> hard to guess what "host-add-retrieve-keytab" means. That word >>>>>>>>> does not even make much sense. >>>>>>>>> >>>>>>>>> Can we use something more readable? For example: >>>>>>>>> >>>>>>>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys >>>>>>>>> --users=STR --groups STR >>>>>>>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys >>>>>>>>> --users=STR --groups STR >>>>>>>>> >>>>>>>>> and >>>>>>>>> >>>>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >>>>>>>>> --users=STR --groups STR >>>>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation >>>>>>>>> write_keys --users=STR --groups STR >>>>>>>>> >>>>>>>>> Same with services. At least to me, it looks more readable. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Martin >>>>>>>>> >>>>>>>> >>>>>>>> Seems to me as adding of allowed operation. Not allowing an >>>>>>>> operation. >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>>> >>>>>>>> What about: >>>>>>>> >>>>>>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >>>>>>>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups >>>>>>>> STR ipa host-allow-create-keytab HOSTNAME --users=STR --groups >>>>>>>> STR ipa host-disallow-create-keytab HOSTNAME --users=STR >>>>>>>> --groups STR >>>>>>> >>>>>>> I like these the best. Maybe with a -to or -by suffix. >>>>>>> >>>>>>>> >>>>>>>> or if we expect more operations in a future: >>>>>>>> >>>>>>>> ipa host-allow-operation HOSTNAME --operation read-keys >>>>>>>> --users=STR --groups STR >>>>>>>> ipa host-disallow-operation HOSTNAME --operation read-keys >>>>>>>> --users=STR --groups STR >>>>>>>> ipa host-allow-operation HOSTNAME --operation write-keys >>>>>>>> --users=STR --groups STR >>>>>>>> ipa host-disallow-operation HOSTNAME --operation write-keys >>>>>>>> --users=STR --groups STR >>>>>>>> >>>>>>>> or if we want to keep 'add' and 'remove' in command names: >>>>>>>> >>>>>>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR >>>>>>>> --groups=STR ipa host-add-create-keytab-right HOSTNAME >>>>>>>> --users=STR --groups=STR ipa host-remove-retrieve-keytab-right >>>>>>>> HOSTNAME --users=STR --groups=STR ipa >>>>>>>> host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >>>>>>>> >>>>>>>> >>>>>>>> personally I'm not a fan o the --operation switch, but could be >>>>>>>> persuaded by a 'future' usage. >>>>>>> >>>>>>> Not a fan either, because it is not consistent with the rest of >>>>>>> the framework. >>>>>>> Also, non-optional options are not really options. >>>>>> >>>>>> Right. Though mandatory options is a concept already existing in >>>>>> FreeIPA framework in many places. >>>>> >>>>> That does not make it right. >>>> >>>> Right :-) >>>> >>>>>> What I see as a deal breaker is that with >>>>>> --operation switch, we are ready for dozens of potential future >>>>>> operations. With operation hardcoded in command name, we are not. >>>>> >>>>> I don't see dozens of operations coming in the near future, there's >>>>> no need for a premature optimization like this. >>>> >>>> My point was that it will be difficult to switch from having >>>> per-operation commands to one general command for all operations >>>> later, however far the future is. >>>> >>>> Given there is no clear agreement on the API (ipa >>>> host-allow-operation vs. >>>> host-allow-read-keytab+host-allow-write-keytab) yet, I would like to >>>> ask Rob or Simo for their opinion/vote here too so that we can select >>>> an approach and go with it. >>> >>> I am not even sure why we are tying this to hosts to be honest. >> >> Isn't the use case to for example allow several load balancing nodes >> host/serverX.example.com get a keytab for host/server.example.com? >> >>> The allow-operation plugin is generic, and we should probably have a >>> command that reflect that like: >>> ipa operations-add/mod/del and options to say what the >>> operation does and what it applies to. >>> >>> Of course the naming needs more thought, but I do not think having a >>> command for this specific narrowed down operations is wise. >>> >>> Actually it may even fit right into the permissions commands (Add a >>> --operation switch ?), as these operations are just a particular type >>> of ACIs/Permissions that apply to abstract operations rather than >>> LDAP operations, so it is a natural extension of our permissions. >>> >>> Simo. >> >> Ok, now that's a 180? turn from what we were discussing until now... I really >> do not think we can go the permission route ATM, the permission plugin is now >> very bound to how ACIs work and how they are used in FreeIPA tree. Changing the >> backend from ACI to ipaAllowedOperation would be something completely different. >> >> The super-general operation-* command is interesting idea, though it decouples >> these operations from their targets. I think there is a benefit in seeing an >> command allowing writing/reading a keytab right in the list of host commands or >> in host page Web UI. Given the short time before 4.1 release, I think it will >> be more straightforward to go with >> >> ipa host-allow-operation >> or >> ipa host-allow-read-keytab/host-allow-write-keytab >> >> route. >> >> Martin >> > > It also works a bit differently. Permissions defined by admin, using a > permission plugin, are part of RBAC. Allowed operations aren't. Binding it with > permission plugin might cause confusion. > > On the other hand, I'm afraid that current implementation clutters up both CLI > and Web UI. We don't distinguish common commands and less used ones. Therefore > they all are equally visible - not good UX. We will have to focus on this issue > sooner or later. > > The general operaion-* commands might be a subject of discussion. I don't like > it because the operations are always bound with particular object. > > I agree with Martin and would go with 'ipa > host-allow-read-keytab/host-allow-write-keytab' commands. Note that Martin still prefers host-allow-operation with operation being it's argument, as Petr3 suggested. > Also terminology is not united: write vs create + read vs retrieve. Since > ipa-get-keytab uses --retrieve, I would go with 'create' and 'retrieve'. The operation itself in LDAP is named read_key and write_key - so we need to chose what it the canonical naming - ipa-getkeytab CLI or LDAP. Martin From pvoborni at redhat.com Mon Oct 6 14:28:25 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 06 Oct 2014 16:28:25 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <5432A46C.3040804@redhat.com> References: <542C289A.6040301@redhat.com> <542EADF5.90901@redhat.com> <542EB18A.6070607@redhat.com> <542EB713.8040605@redhat.com> <542EB9D9.6050000@redhat.com> <542EBAA0.9080805@redhat.com> <543253D3.5070701@redhat.com> <543274C5.2090902@redhat.com> <20141006090101.28a3a6a4@willson.usersys.redhat.com> <54329DD5.5000508@redhat.com> <5432A3F4.1080308@redhat.com> <5432A46C.3040804@redhat.com> Message-ID: <5432A709.7030208@redhat.com> On 6.10.2014 16:17, Martin Kosek wrote: > On 10/06/2014 04:15 PM, Petr Vobornik wrote: >> On 6.10.2014 15:49, Martin Kosek wrote: >>> On 10/06/2014 03:01 PM, Simo Sorce wrote: >>>> On Mon, 06 Oct 2014 12:53:57 +0200 >>>> Martin Kosek wrote: >>>> >>>>> On 10/06/2014 10:33 AM, Jan Cholasta wrote: >>>>>> Dne 3.10.2014 v 17:02 Martin Kosek napsal(a): >>>>>>> On 10/03/2014 04:59 PM, Jan Cholasta wrote: >>>>>>>> Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a): >>>>>>>>> On 3.10.2014 16:24, Martin Kosek wrote: >>>>>>>>>> NACK. I will not comment on mechanics, if you get an ACK from >>>>>>>>>> Honza, it is good enough. I just do not like the API. It is >>>>>>>>>> hard to guess what "host-add-retrieve-keytab" means. That word >>>>>>>>>> does not even make much sense. >>>>>>>>>> >>>>>>>>>> Can we use something more readable? For example: >>>>>>>>>> >>>>>>>>>> ipa host-add-allowed-operation HOSTNAME --operation read_keys >>>>>>>>>> --users=STR --groups STR >>>>>>>>>> ipa host-add-allowed-operation HOSTNAME --operation write_keys >>>>>>>>>> --users=STR --groups STR >>>>>>>>>> >>>>>>>>>> and >>>>>>>>>> >>>>>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation read_keys >>>>>>>>>> --users=STR --groups STR >>>>>>>>>> ipa host-remove-allowed-operation HOSTNAME --operation >>>>>>>>>> write_keys --users=STR --groups STR >>>>>>>>>> >>>>>>>>>> Same with services. At least to me, it looks more readable. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>> >>>>>>>>> Seems to me as adding of allowed operation. Not allowing an >>>>>>>>> operation. >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>>> >>>>>>>>> What about: >>>>>>>>> >>>>>>>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >>>>>>>>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups >>>>>>>>> STR ipa host-allow-create-keytab HOSTNAME --users=STR --groups >>>>>>>>> STR ipa host-disallow-create-keytab HOSTNAME --users=STR >>>>>>>>> --groups STR >>>>>>>> >>>>>>>> I like these the best. Maybe with a -to or -by suffix. >>>>>>>> >>>>>>>>> >>>>>>>>> or if we expect more operations in a future: >>>>>>>>> >>>>>>>>> ipa host-allow-operation HOSTNAME --operation read-keys >>>>>>>>> --users=STR --groups STR >>>>>>>>> ipa host-disallow-operation HOSTNAME --operation read-keys >>>>>>>>> --users=STR --groups STR >>>>>>>>> ipa host-allow-operation HOSTNAME --operation write-keys >>>>>>>>> --users=STR --groups STR >>>>>>>>> ipa host-disallow-operation HOSTNAME --operation write-keys >>>>>>>>> --users=STR --groups STR >>>>>>>>> >>>>>>>>> or if we want to keep 'add' and 'remove' in command names: >>>>>>>>> >>>>>>>>> ipa host-add-retrieve-keytab-right HOSTNAME --users=STR >>>>>>>>> --groups=STR ipa host-add-create-keytab-right HOSTNAME >>>>>>>>> --users=STR --groups=STR ipa host-remove-retrieve-keytab-right >>>>>>>>> HOSTNAME --users=STR --groups=STR ipa >>>>>>>>> host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR >>>>>>>>> >>>>>>>>> >>>>>>>>> personally I'm not a fan o the --operation switch, but could be >>>>>>>>> persuaded by a 'future' usage. >>>>>>>> >>>>>>>> Not a fan either, because it is not consistent with the rest of >>>>>>>> the framework. >>>>>>>> Also, non-optional options are not really options. >>>>>>> >>>>>>> Right. Though mandatory options is a concept already existing in >>>>>>> FreeIPA framework in many places. >>>>>> >>>>>> That does not make it right. >>>>> >>>>> Right :-) >>>>> >>>>>>> What I see as a deal breaker is that with >>>>>>> --operation switch, we are ready for dozens of potential future >>>>>>> operations. With operation hardcoded in command name, we are not. >>>>>> >>>>>> I don't see dozens of operations coming in the near future, there's >>>>>> no need for a premature optimization like this. >>>>> >>>>> My point was that it will be difficult to switch from having >>>>> per-operation commands to one general command for all operations >>>>> later, however far the future is. >>>>> >>>>> Given there is no clear agreement on the API (ipa >>>>> host-allow-operation vs. >>>>> host-allow-read-keytab+host-allow-write-keytab) yet, I would like to >>>>> ask Rob or Simo for their opinion/vote here too so that we can select >>>>> an approach and go with it. >>>> >>>> I am not even sure why we are tying this to hosts to be honest. >>> >>> Isn't the use case to for example allow several load balancing nodes >>> host/serverX.example.com get a keytab for host/server.example.com? >>> >>>> The allow-operation plugin is generic, and we should probably have a >>>> command that reflect that like: >>>> ipa operations-add/mod/del and options to say what the >>>> operation does and what it applies to. >>>> >>>> Of course the naming needs more thought, but I do not think having a >>>> command for this specific narrowed down operations is wise. >>>> >>>> Actually it may even fit right into the permissions commands (Add a >>>> --operation switch ?), as these operations are just a particular type >>>> of ACIs/Permissions that apply to abstract operations rather than >>>> LDAP operations, so it is a natural extension of our permissions. >>>> >>>> Simo. >>> >>> Ok, now that's a 180? turn from what we were discussing until now... I really >>> do not think we can go the permission route ATM, the permission plugin is now >>> very bound to how ACIs work and how they are used in FreeIPA tree. Changing the >>> backend from ACI to ipaAllowedOperation would be something completely different. >>> >>> The super-general operation-* command is interesting idea, though it decouples >>> these operations from their targets. I think there is a benefit in seeing an >>> command allowing writing/reading a keytab right in the list of host commands or >>> in host page Web UI. Given the short time before 4.1 release, I think it will >>> be more straightforward to go with >>> >>> ipa host-allow-operation >>> or >>> ipa host-allow-read-keytab/host-allow-write-keytab >>> >>> route. >>> >>> Martin >>> >> >> It also works a bit differently. Permissions defined by admin, using a >> permission plugin, are part of RBAC. Allowed operations aren't. Binding it with >> permission plugin might cause confusion. >> >> On the other hand, I'm afraid that current implementation clutters up both CLI >> and Web UI. We don't distinguish common commands and less used ones. Therefore >> they all are equally visible - not good UX. We will have to focus on this issue >> sooner or later. >> >> The general operaion-* commands might be a subject of discussion. I don't like >> it because the operations are always bound with particular object. >> >> I agree with Martin and would go with 'ipa >> host-allow-read-keytab/host-allow-write-keytab' commands. > > Note that Martin still prefers host-allow-operation with operation being it's > argument, as Petr3 suggested. I'm not against it even though I prefer the former one. > >> Also terminology is not united: write vs create + read vs retrieve. Since >> ipa-get-keytab uses --retrieve, I would go with 'create' and 'retrieve'. > > The operation itself in LDAP is named read_key and write_key - so we need to > chose what it the canonical naming - ipa-getkeytab CLI or LDAP. User should not need to know how it's implemented. We should use the same terminology in all our CLIs. > > Martin > -- Petr Vobornik From lkrispen at redhat.com Mon Oct 6 14:30:25 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 06 Oct 2014 16:30:25 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141001161606.GA6186@redhat.com> References: <20141001161606.GA6186@redhat.com> Message-ID: <5432A781.4040004@redhat.com> Hi Alex, one quick comment: I'm afraid the only case where slapi_search_internal_pb() returns -1 is if you don't provide a pblock. In all other cases it returns 0 and you have to check: slapi_pblock_get(search_pb, SLAPI_PLUGIN_INTOP_RESULT, &result); Ludwig Ludwig On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: > Hi! > > Attached are patches to add support of FreeIPA ID views to Schema > compatibility plugin (slapi-nis). There are two patches for FreeIPA and > a separate patch for slapi-nis. Patches can be applied independently; if > old slapi-nis is installed, it will simply work with new configuration > but do nothing with respect to answering to requests using host-specific > ID views. > > I included documentation on how slapi-nis ID views feature supposed to > work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes > are welcome. There are no additional tests in slapi-nis to cover compat > trees, we have multiple tests in FreeIPA for this purpose, will be run > as part of FreeIPA CI effort. > > FreeIPA patches add ACIs for accessing ID view-applied entries over > compat tree. They also include additional configuration; this > configuration is needed to properly resolve ID view overrides when > creating compat entries. > > A second FreeIPA patch adds support to override login shell. This part > was missing from the original patchset by Tomas. > > For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit > Bose. There is also a regression (fixed by Sumit as well) that prevents > authentication of AD users over PAM which affects authentication over > compat tree. With the patch from Sumit authentication works again, both > with ID view and without it. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Oct 6 14:44:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 6 Oct 2014 17:44:13 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <5432A781.4040004@redhat.com> References: <20141001161606.GA6186@redhat.com> <5432A781.4040004@redhat.com> Message-ID: <20141006144413.GR4683@redhat.com> On Mon, 06 Oct 2014, Ludwig Krispenz wrote: >Hi Alex, > >one quick comment: >I'm afraid the only case where slapi_search_internal_pb() returns -1 >is if you don't provide a pblock. In all other cases it returns 0 and >you have to check: >slapi_pblock_get(search_pb, SLAPI_PLUGIN_INTOP_RESULT, &result); Uhm, there are few more cases: - when filter string is NULL; - when scope is wrong - when building a filter struct failed due to memory or syntax error If return from slapi_search_internal_pb() is 0, we are at least got to op_shared_search() so we are dealing with the consequence of actually running the search. I'll add one more check for the result (I had it in one of original versions before simplification), thanks. > >Ludwig > >Ludwig >On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: >>Hi! >> >>Attached are patches to add support of FreeIPA ID views to Schema >>compatibility plugin (slapi-nis). There are two patches for FreeIPA and >>a separate patch for slapi-nis. Patches can be applied independently; if >>old slapi-nis is installed, it will simply work with new configuration >>but do nothing with respect to answering to requests using host-specific >>ID views. >> >>I included documentation on how slapi-nis ID views feature supposed to >>work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes >>are welcome. There are no additional tests in slapi-nis to cover compat >>trees, we have multiple tests in FreeIPA for this purpose, will be run >>as part of FreeIPA CI effort. >> >>FreeIPA patches add ACIs for accessing ID view-applied entries over >>compat tree. They also include additional configuration; this >>configuration is needed to properly resolve ID view overrides when >>creating compat entries. >> >>A second FreeIPA patch adds support to override login shell. This part >>was missing from the original patchset by Tomas. >> >>For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit >>Bose. There is also a regression (fixed by Sumit as well) that prevents >>authentication of AD users over PAM which affects authentication over >>compat tree. With the patch from Sumit authentication works again, both >>with ID view and without it. >> >> >> >>_______________________________________________ >>Freeipa-devel mailing list >>Freeipa-devel at redhat.com >>https://www.redhat.com/mailman/listinfo/freeipa-devel > >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel -- / Alexander Bokovoy From lkrispen at redhat.com Mon Oct 6 14:57:57 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 06 Oct 2014 16:57:57 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141006144413.GR4683@redhat.com> References: <20141001161606.GA6186@redhat.com> <5432A781.4040004@redhat.com> <20141006144413.GR4683@redhat.com> Message-ID: <5432ADF5.20600@redhat.com> On 10/06/2014 04:44 PM, Alexander Bokovoy wrote: > On Mon, 06 Oct 2014, Ludwig Krispenz wrote: >> Hi Alex, >> >> one quick comment: >> I'm afraid the only case where slapi_search_internal_pb() returns -1 >> is if you don't provide a pblock. In all other cases it returns 0 and >> you have to check: >> slapi_pblock_get(search_pb, SLAPI_PLUGIN_INTOP_RESULT, &result); > Uhm, there are few more cases: > > - when filter string is NULL; > - when scope is wrong > - when building a filter struct failed due to memory or syntax error these are returns from search_internal_callback_pb(). But slapi_search_internal_pb() calls slapi_search_internal_pb() which just does: search_internal_callback_pb (pb, &psid, internal_plugin_result_callback, internal_plugin_search_entry_callback, internal_plugin_search_referral_callback); opresult = psid.rc; ... and does not care what search_internal_callback_pb() returns. > > If return from slapi_search_internal_pb() is 0, we are at least got to > op_shared_search() so we are dealing with the consequence of actually > running the search. I'll add one more check for the result (I had it in > one of original versions before simplification), thanks. > >> >> Ludwig >> >> Ludwig >> On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached are patches to add support of FreeIPA ID views to Schema >>> compatibility plugin (slapi-nis). There are two patches for FreeIPA and >>> a separate patch for slapi-nis. Patches can be applied >>> independently; if >>> old slapi-nis is installed, it will simply work with new configuration >>> but do nothing with respect to answering to requests using >>> host-specific >>> ID views. >>> >>> I included documentation on how slapi-nis ID views feature supposed to >>> work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and >>> fixes >>> are welcome. There are no additional tests in slapi-nis to cover compat >>> trees, we have multiple tests in FreeIPA for this purpose, will be run >>> as part of FreeIPA CI effort. >>> >>> FreeIPA patches add ACIs for accessing ID view-applied entries over >>> compat tree. They also include additional configuration; this >>> configuration is needed to properly resolve ID view overrides when >>> creating compat entries. >>> >>> A second FreeIPA patch adds support to override login shell. This part >>> was missing from the original patchset by Tomas. >>> >>> For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit >>> Bose. There is also a regression (fixed by Sumit as well) that prevents >>> authentication of AD users over PAM which affects authentication over >>> compat tree. With the patch from Sumit authentication works again, both >>> with ID view and without it. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > From lkrispen at redhat.com Mon Oct 6 14:59:52 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 06 Oct 2014 16:59:52 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <5432ADF5.20600@redhat.com> References: <20141001161606.GA6186@redhat.com> <5432A781.4040004@redhat.com> <20141006144413.GR4683@redhat.com> <5432ADF5.20600@redhat.com> Message-ID: <5432AE68.6090701@redhat.com> On 10/06/2014 04:57 PM, Ludwig Krispenz wrote: > > On 10/06/2014 04:44 PM, Alexander Bokovoy wrote: >> On Mon, 06 Oct 2014, Ludwig Krispenz wrote: >>> Hi Alex, >>> >>> one quick comment: >>> I'm afraid the only case where slapi_search_internal_pb() returns -1 >>> is if you don't provide a pblock. In all other cases it returns 0 >>> and you have to check: >>> slapi_pblock_get(search_pb, SLAPI_PLUGIN_INTOP_RESULT, &result); >> Uhm, there are few more cases: >> >> - when filter string is NULL; >> - when scope is wrong >> - when building a filter struct failed due to memory or syntax error > these are returns from search_internal_callback_pb(). But > slapi_search_internal_pb() calls slapi_search_internal_pb() which just > does: slapi_search_internal_pb() calls search_internal_pb() > > search_internal_callback_pb (pb, &psid, > internal_plugin_result_callback, > internal_plugin_search_entry_callback, > internal_plugin_search_referral_callback); > opresult = psid.rc; > ... > and does not care what search_internal_callback_pb() returns. >> >> If return from slapi_search_internal_pb() is 0, we are at least got to >> op_shared_search() so we are dealing with the consequence of actually >> running the search. I'll add one more check for the result (I had it in >> one of original versions before simplification), thanks. >> >>> >>> Ludwig >>> >>> Ludwig >>> On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> Attached are patches to add support of FreeIPA ID views to Schema >>>> compatibility plugin (slapi-nis). There are two patches for FreeIPA >>>> and >>>> a separate patch for slapi-nis. Patches can be applied >>>> independently; if >>>> old slapi-nis is installed, it will simply work with new configuration >>>> but do nothing with respect to answering to requests using >>>> host-specific >>>> ID views. >>>> >>>> I included documentation on how slapi-nis ID views feature supposed to >>>> work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and >>>> fixes >>>> are welcome. There are no additional tests in slapi-nis to cover >>>> compat >>>> trees, we have multiple tests in FreeIPA for this purpose, will be run >>>> as part of FreeIPA CI effort. >>>> >>>> FreeIPA patches add ACIs for accessing ID view-applied entries over >>>> compat tree. They also include additional configuration; this >>>> configuration is needed to properly resolve ID view overrides when >>>> creating compat entries. >>>> >>>> A second FreeIPA patch adds support to override login shell. This part >>>> was missing from the original patchset by Tomas. >>>> >>>> For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit >>>> Bose. There is also a regression (fixed by Sumit as well) that >>>> prevents >>>> authentication of AD users over PAM which affects authentication over >>>> compat tree. With the patch from Sumit authentication works again, >>>> both >>>> with ID view and without it. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jdennis at redhat.com Mon Oct 6 21:21:57 2014 From: jdennis at redhat.com (John Dennis) Date: Mon, 06 Oct 2014 17:21:57 -0400 Subject: [Freeipa-devel] Switching to pytest In-Reply-To: <542EA373.9020508@redhat.com> References: <542EA373.9020508@redhat.com> Message-ID: <543307F5.4020902@redhat.com> On 10/03/2014 09:24 AM, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/4610 > > Our test suite is currently not very maintainable. I want to dedicate > some time to improve this. > The biggest part of this effort will be switching to a different test > framework, [pytest]. Compared to Nose, it makes complicated tests easier > to write -- at the expense of using more "magic". Just looking for information, why pytest? Here is why I'm asking. After leaving IPA I went to another large Python based project, OpenStack. OpenStack is really a number of loosely affiliated autonomous projects, each of which gets to decide how they are going to write and run their unit tests. As might be expected it's a bit of a mess. But there has been some convergence lately using tox, testr and testtools in combination. Python like Java has no shortage of test frameworks and that diversity is actually a pain point. What happens is very few folks actually understand the intricacies of test construction and execution (because there are so many options, it can be convoluted, there are many layers and each project does things differently). The net result is a lot of wasted time, I groan every time tests get ported to the test framework de jour, which seems to happen with alarming frequency. I'd really like to see some convergence in the Python community on test frameworks so as a developer you only have to be an expert in one framework because debugging test failures (including simply reproducing the failure) is currently a time sink and just when you think you understand what the heck is going on someone announces we're moving to the next big thing. The proliferation of test frameworks is further compounded by weak documentation. If something goes "boom" it can literally take days to piece together enough information to diagnose the issue (often because there are so many layers). So how does pytest fit in with everything else? Is stable, long term and widely adopted? What about mocking? Is there a consensus on fixtures vs. mocks (that isn't religious). Can pytest handle both? I guess what I'm asking is there some convergence with Python test tools? Or with testing are we in the equivalent of the SCM wars of 5-7 years ago until most everyone figured out git was superior and had the most traction? Picking the test framework other than the one that bubbles to the top and becomes the de facto standard has consequences. I clearly do not have enough information to make a judgment here and any additional information would be very much appreciated. -- John From ftweedal at redhat.com Tue Oct 7 03:31:09 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 7 Oct 2014 13:31:09 +1000 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design Message-ID: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> Hi all, The Dogtag lightweight sub-CAs design has undergone major revision and expansion ahead of beginning the implementation (I plan to begin later this week). This feature will provide an API for admins to create sub-CAs for separate security domains and augment the existing API so that certificates requests can be directed to a particular sub-CA. This feature will be used in FreeIPA for issuing user or service certificates for particular purposes (that will be rejected when use for other purposes). Please review the document and provide feedback. http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs Feedback/suggestions for the REST API (that FreeIPA will use) and ACI considerations (e.g. is it appropriate to use the existing "agent" credential or should a separate credential or more fine-grained ACIs be used) are particularly encouraged. Cheers, Fraser From pviktori at redhat.com Tue Oct 7 08:37:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 07 Oct 2014 10:37:26 +0200 Subject: [Freeipa-devel] Switching to pytest In-Reply-To: <543307F5.4020902@redhat.com> References: <542EA373.9020508@redhat.com> <543307F5.4020902@redhat.com> Message-ID: <5433A646.9010705@redhat.com> On 10/06/2014 11:21 PM, John Dennis wrote: > On 10/03/2014 09:24 AM, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/4610 >> >> Our test suite is currently not very maintainable. I want to dedicate >> some time to improve this. >> The biggest part of this effort will be switching to a different test >> framework, [pytest]. Compared to Nose, it makes complicated tests easier >> to write -- at the expense of using more "magic". > > Just looking for information, why pytest? Nose is not enough, and knowing nothing clearly better (easier, more supportable, more popular*) than pytest, I went with what I know. * unittest/nose is more popular than pytest, of course > Here is why I'm asking. After leaving IPA I went to another large Python > based project, OpenStack. OpenStack is really a number of loosely > affiliated autonomous projects, each of which gets to decide how they > are going to write and run their unit tests. As might be expected it's a > bit of a mess. But there has been some convergence lately using tox, > testr and testtools in combination.Python like Java has no shortage of > test frameworks and that diversity is actually a pain point. What > happens is very few folks actually understand the intricacies of test > construction and execution (because there are so many options, it can be > convoluted, there are many layers and each project does things > differently). The net result is a lot of wasted time, I groan every time > tests get ported to the test framework de jour, which seems to happen > with alarming frequency. > > I'd really like to see some convergence in the Python community on test > frameworks so as a developer you only have to be an expert in one > framework because debugging test failures (including simply reproducing > the failure) is currently a time sink and just when you think you > understand what the heck is going on someone announces we're moving to > the next big thing. The proliferation of test frameworks is further > compounded by weak documentation. If something goes "boom" it can > literally take days to piece together enough information to diagnose the > issue (often because there are so many layers). I sympathize. Do you have a solution, though? Staying with Nose is not one at this point. I'm not too convinced by convergence in OpenStack; it's still just one project. If you have some other arguments for testr/testtools, let me know; I don't see the advantages over pytest. > So how does pytest fit in with everything else? Is stable, long term and > widely adopted? What about mocking? Is there a consensus on fixtures vs. > mocks (that isn't religious). Can pytest handle both? I'm not sure I understand correctly what you mean, but you can wrap mocks/monkeypatching in fixtures. So yes, pytest can handle both. > I guess what I'm asking is there some convergence with Python test > tools? Or with testing are we in the equivalent of the SCM wars of 5-7 > years ago until most everyone figured out git was superior and had the > most traction? Yeah, I guess you could say the testing war is raging on. But even the SCM situation is not clear-cut; e.g. Mozilla or Python use Mercurial, and given the availability of bridge tools, they aren't likely to switch any time soon. And the Linux package manager war is also raging on, with no clear winner. > Picking the test framework other than the one that bubbles to the top > and becomes the de facto standard has consequences. I clearly do not > have enough information to make a judgment here and any additional > information would be very much appreciated. Perhaps it's because I'm in Europe, but every major Python conference I go to has one or two pytest talks. Also, pytest was written by the same people as tox, which (I dare say) is the de-facto standard for test *orchestration* in Python. So in the test framework war I'm betting on this one. -- Petr? From tbordaz at redhat.com Tue Oct 7 09:18:30 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 07 Oct 2014 11:18:30 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141001161606.GA6186@redhat.com> References: <20141001161606.GA6186@redhat.com> Message-ID: <5433AFE6.1060309@redhat.com> On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: > Hi! > > Attached are patches to add support of FreeIPA ID views to Schema > compatibility plugin (slapi-nis). There are two patches for FreeIPA and > a separate patch for slapi-nis. Patches can be applied independently; if > old slapi-nis is installed, it will simply work with new configuration > but do nothing with respect to answering to requests using host-specific > ID views. > > I included documentation on how slapi-nis ID views feature supposed to > work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes > are welcome. There are no additional tests in slapi-nis to cover compat > trees, we have multiple tests in FreeIPA for this purpose, will be run > as part of FreeIPA CI effort. > > FreeIPA patches add ACIs for accessing ID view-applied entries over > compat tree. They also include additional configuration; this > configuration is needed to properly resolve ID view overrides when > creating compat entries. > > A second FreeIPA patch adds support to override login shell. This part > was missing from the original patchset by Tomas. > > For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit > Bose. There is also a regression (fixed by Sumit as well) that prevents > authentication of AD users over PAM which affects authentication over > compat tree. With the patch from Sumit authentication works again, both > with ID view and without it. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Alexander, A question about backend_search_filter_has_cn_uid. It checks if a filter components contains (uid|uidNumber|gidNumber|memberUid) and in this case returns SLAPI_FILTER_SCAN_STOP. This value will interrupt the filter rewriting. In addition, for each component it calls idview_process_filter_cb to override an attribute that needs to be override in the view. So I wonder if it will work for filter like: (&(=xxx) (uid=yyy)) but will stop to early for (&(uid=yyy)(=xxx)) thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Oct 7 09:43:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 12:43:58 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <5433AFE6.1060309@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433AFE6.1060309@redhat.com> Message-ID: <20141007094358.GW4683@redhat.com> On Tue, 07 Oct 2014, thierry bordaz wrote: > A question about backend_search_filter_has_cn_uid. > It checks if a filter components contains > (uid|uidNumber|gidNumber|memberUid) and in this case returns > SLAPI_FILTER_SCAN_STOP. This value will interrupt the filter rewriting. > > In addition, for each component it calls idview_process_filter_cb to > override an attribute that needs to be override in the view. > So I wonder if it will work for filter like: > > (&(=xxx) (uid=yyy)) > > but will stop to early for > > (&(uid=yyy)(=xxx)) We handle the requests which come from various NSS clients here (nss-pam-ldapd, nss_ldap, sssd, and similar). They don't do reordering like you say. Since all these searches never base queries on attributes other the ones we check (uid|uidNumber|gidNumber|memberUid), we don't need to replace other attributes here. I can see there could be a case where we get something like (actual query): (&(gidNumber=1878600500) (|(objectClass=groupOfNames) (objectClass=posixGroup)) (cn=*)(&(gidNumber=*)(!(gidNumber=0)))) and we need to ignore '*' and '0' if they come before explicit gidNumber=, I'll fix this one. Do you think we need to traverse the filter tree until it ends in all cases? In all filter types I've seen we are interested only in a single name and once we've got attributes filled in, we don't need to continue. Maybe for the replacement case of idview_process_filter_cb() we can have some flag in the filter processing config that forces to go through the fliter no matter what? -- / Alexander Bokovoy From lkrispen at redhat.com Tue Oct 7 10:01:23 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 07 Oct 2014 12:01:23 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141001161606.GA6186@redhat.com> References: <20141001161606.GA6186@redhat.com> Message-ID: <5433B9F3.9020806@redhat.com> Hi Alex, slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but this does not free the existing values, cf https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Plug-in_Guide/Plugin_Programming_Guide-Function_Reference-slapi_valueset_set_valueset.html From abokovoy at redhat.com Tue Oct 7 10:12:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 13:12:08 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <5433B9F3.9020806@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433B9F3.9020806@redhat.com> Message-ID: <20141007101208.GZ4683@redhat.com> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >Hi Alex, > >slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but >this does not free the existing values, Here is the problem, I cannot free original values as slapi_attr_get_valueset() returns a copy and I never can get access to the original Slapi_ValueSet. I only can get access to the original Slapi_Value** array which means I could manipulate its content but that probably require resizing it and thus changing a pointer vs->va, to which I don't have access anyway. How can we fix this? -- / Alexander Bokovoy From lkrispen at redhat.com Tue Oct 7 10:22:35 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 07 Oct 2014 12:22:35 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141007101208.GZ4683@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433B9F3.9020806@redhat.com> <20141007101208.GZ4683@redhat.com> Message-ID: <5433BEEB.9010702@redhat.com> On 10/07/2014 12:12 PM, Alexander Bokovoy wrote: > On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >> Hi Alex, >> >> slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but >> this does not free the existing values, > Here is the problem, I cannot free original values as > slapi_attr_get_valueset() returns a copy and I never can get access to > the original Slapi_ValueSet. good point. > > I only can get access to the original Slapi_Value** array which means I > could manipulate its content but that probably require resizing it and > thus changing a pointer vs->va, to which I don't have access anyway. you should never do this, a valueset contains more data than va > How can we fix this? the best thing would probably be to fix slapi_attr_set_valueset or adding a new api function which frees teh old valueset, but this would add a dependency to specific DS version From abokovoy at redhat.com Tue Oct 7 10:39:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 13:39:00 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <5433BEEB.9010702@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433B9F3.9020806@redhat.com> <20141007101208.GZ4683@redhat.com> <5433BEEB.9010702@redhat.com> Message-ID: <20141007103900.GB4683@redhat.com> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: > >On 10/07/2014 12:12 PM, Alexander Bokovoy wrote: >>On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>Hi Alex, >>> >>>slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but >>>this does not free the existing values, >>Here is the problem, I cannot free original values as >>slapi_attr_get_valueset() returns a copy and I never can get access to >>the original Slapi_ValueSet. >good point. >> >>I only can get access to the original Slapi_Value** array which means I >>could manipulate its content but that probably require resizing it and >>thus changing a pointer vs->va, to which I don't have access anyway. >you should never do this, a valueset contains more data than va >>How can we fix this? >the best thing would probably be to fix slapi_attr_set_valueset or >adding a new api function which frees teh old valueset, but this would >add a dependency to specific DS version What about something like this: void slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet *vs2) { if ((vs1 != NULL) && (vs1->num != 0)) { slapi_valueset_done(vs1); } slapi_valueset_init(vs1); valueset_set_valueset(vs1,vs2); } Another option is to fix slapi_attr_set_valueset(): int slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs) { if (a->a_present_values->num != 0) { lapi_valueset_done(&a->a_present_values); } slapi_valueset_set_valueset( &a->a_present_values, vs); return 0; } Other uses of slapi_valueset_set_valueset() are operating on newly created Slapi_ValueSet instances. -- / Alexander Bokovoy From lkrispen at redhat.com Tue Oct 7 10:47:46 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 07 Oct 2014 12:47:46 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141007103900.GB4683@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433B9F3.9020806@redhat.com> <20141007101208.GZ4683@redhat.com> <5433BEEB.9010702@redhat.com> <20141007103900.GB4683@redhat.com> Message-ID: <5433C4D2.2090600@redhat.com> On 10/07/2014 12:39 PM, Alexander Bokovoy wrote: > On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >> >> On 10/07/2014 12:12 PM, Alexander Bokovoy wrote: >>> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>> Hi Alex, >>>> >>>> slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), but >>>> this does not free the existing values, >>> Here is the problem, I cannot free original values as >>> slapi_attr_get_valueset() returns a copy and I never can get access to >>> the original Slapi_ValueSet. >> good point. >>> >>> I only can get access to the original Slapi_Value** array which means I >>> could manipulate its content but that probably require resizing it and >>> thus changing a pointer vs->va, to which I don't have access anyway. >> you should never do this, a valueset contains more data than va >>> How can we fix this? >> the best thing would probably be to fix slapi_attr_set_valueset or >> adding a new api function which frees teh old valueset, but this >> would add a dependency to specific DS version > What about something like this: > > void > slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet > *vs2) > { > if ((vs1 != NULL) && (vs1->num != 0)) { > slapi_valueset_done(vs1); > } > slapi_valueset_init(vs1); > valueset_set_valueset(vs1,vs2); > } > > Another option is to fix slapi_attr_set_valueset(): > > int > slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs) > { > if (a->a_present_values->num != 0) { > lapi_valueset_done(&a->a_present_values); > } > slapi_valueset_set_valueset( &a->a_present_values, vs); > return 0; > } > > Other uses of slapi_valueset_set_valueset() are operating on newly > created Slapi_ValueSet instances. both will be ok (for me), but we have to commit it first and you depend on that version. a more clumsy way would be to get the values and then use slapi_entry_attr_replace_sv() which would free the attr and recreate it From jdennis at redhat.com Tue Oct 7 11:07:43 2014 From: jdennis at redhat.com (John Dennis) Date: Tue, 07 Oct 2014 07:07:43 -0400 Subject: [Freeipa-devel] Switching to pytest In-Reply-To: <5433A646.9010705@redhat.com> References: <542EA373.9020508@redhat.com> <543307F5.4020902@redhat.com> <5433A646.9010705@redhat.com> Message-ID: <5433C97F.9020200@redhat.com> On 10/07/2014 04:37 AM, Petr Viktorin wrote: > So in the test framework war I'm betting on this one. That is the info I was looking for. Thanks!! -- John From abokovoy at redhat.com Tue Oct 7 11:15:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 14:15:13 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <5433C4D2.2090600@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433B9F3.9020806@redhat.com> <20141007101208.GZ4683@redhat.com> <5433BEEB.9010702@redhat.com> <20141007103900.GB4683@redhat.com> <5433C4D2.2090600@redhat.com> Message-ID: <20141007111513.GC4683@redhat.com> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: > >On 10/07/2014 12:39 PM, Alexander Bokovoy wrote: >>On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>> >>>On 10/07/2014 12:12 PM, Alexander Bokovoy wrote: >>>>On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>>>Hi Alex, >>>>> >>>>>slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), >>>>>but this does not free the existing values, >>>>Here is the problem, I cannot free original values as >>>>slapi_attr_get_valueset() returns a copy and I never can get access to >>>>the original Slapi_ValueSet. >>>good point. >>>> >>>>I only can get access to the original Slapi_Value** array which means I >>>>could manipulate its content but that probably require resizing it and >>>>thus changing a pointer vs->va, to which I don't have access anyway. >>>you should never do this, a valueset contains more data than va >>>>How can we fix this? >>>the best thing would probably be to fix slapi_attr_set_valueset or >>>adding a new api function which frees teh old valueset, but this >>>would add a dependency to specific DS version >>What about something like this: >> >>void >>slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet >>*vs2) >>{ >> if ((vs1 != NULL) && (vs1->num != 0)) { >> slapi_valueset_done(vs1); >> } >> slapi_valueset_init(vs1); >> valueset_set_valueset(vs1,vs2); >>} >> >>Another option is to fix slapi_attr_set_valueset(): >> >>int >>slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs) >>{ >> if (a->a_present_values->num != 0) { >> lapi_valueset_done(&a->a_present_values); >> } >> slapi_valueset_set_valueset( &a->a_present_values, vs); >> return 0; >>} >> >>Other uses of slapi_valueset_set_valueset() are operating on newly >>created Slapi_ValueSet instances. >both will be ok (for me), but we have to commit it first and you >depend on that version. > >a more clumsy way would be to get the values and then use >slapi_entry_attr_replace_sv() which would free the attr and recreate >it Actually, you pointed me to a better solution: /* Replace the attribute's value with the override */ result = slapi_entry_attr_exists(entry, override_type); if (result == 0) { result = slapi_attr_get_values(override_attr, &override_valueset); result = slapi_entry_attr_delete_sv(entry, override_type, NULL); result = slapi_entry_add_valueset(entry, override_type, override_valueset); } slapi_entry_delete_values_sv(entry, attr, NULL) will clear whole attribute and then I can add the valueset. This, unfortunately, works via iterating over the whole valueset and adding values one by one but in our case it would be most likely a single element anyway. -- / Alexander Bokovoy From tbordaz at redhat.com Tue Oct 7 11:29:47 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 07 Oct 2014 13:29:47 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141007094358.GW4683@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433AFE6.1060309@redhat.com> <20141007094358.GW4683@redhat.com> Message-ID: <5433CEAB.3080504@redhat.com> On 10/07/2014 11:43 AM, Alexander Bokovoy wrote: > On Tue, 07 Oct 2014, thierry bordaz wrote: >> A question about backend_search_filter_has_cn_uid. >> It checks if a filter components contains >> (uid|uidNumber|gidNumber|memberUid) and in this case returns >> SLAPI_FILTER_SCAN_STOP. This value will interrupt the filter >> rewriting. >> >> In addition, for each component it calls idview_process_filter_cb to >> override an attribute that needs to be override in the view. >> So I wonder if it will work for filter like: >> >> (&(=xxx) (uid=yyy)) >> >> but will stop to early for >> >> (&(uid=yyy)(=xxx)) > We handle the requests which come from various NSS clients here > (nss-pam-ldapd, nss_ldap, sssd, and similar). They don't do reordering > like you say. > > Since all these searches never base queries on attributes other the ones > we check (uid|uidNumber|gidNumber|memberUid), we don't need to replace > other attributes here. > > I can see there could be a case where we get something like (actual > query): (&(gidNumber=1878600500) > (|(objectClass=groupOfNames) > (objectClass=posixGroup)) > (cn=*)(&(gidNumber=*)(!(gidNumber=0)))) > and we need to ignore '*' and '0' if they come before explicit > gidNumber=, I'll fix this one. > > Do you think we need to traverse the filter tree until it ends in all > cases? In all filter types I've seen we are interested only in a single > name and once we've got attributes filled in, we don't need to continue. In idview_process_filter_cb, there is a override of an attribute name into "ipaAnchorUUID". I do not know what attribute required this override, but my concern is that depending on the order of the attributes in the filter, this override may not occur. I agree that if no existing filter is in this case it is not required to go until the end of the filter. Now if new clients starts using such filter pattern, it will also require a change in the plugin. From the performance point of view, it requires more processing at the filter level. unless filters are very long I would not expect a significant impact. > > Maybe for the replacement case of idview_process_filter_cb() we can have > some flag in the filter processing config that forces to go through the > fliter no matter what? Yes that could be an accelerator, when idview_process_filter_cb() has override an attribute into "ipaAnchorUUID" a flag could be reported to backend_search_filter_has_cn_uid to decide to stop the filter processing. To be honest I would prefer a systematic traverse of the filter until its end, even at the cost of additional processing. It would be easier to understand what the rewrite is doing and make it compatible with client enhancements. thanks thierry From abokovoy at redhat.com Tue Oct 7 11:32:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 14:32:55 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141007111513.GC4683@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433B9F3.9020806@redhat.com> <20141007101208.GZ4683@redhat.com> <5433BEEB.9010702@redhat.com> <20141007103900.GB4683@redhat.com> <5433C4D2.2090600@redhat.com> <20141007111513.GC4683@redhat.com> Message-ID: <20141007113255.GD4683@redhat.com> On Tue, 07 Oct 2014, Alexander Bokovoy wrote: >On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >> >>On 10/07/2014 12:39 PM, Alexander Bokovoy wrote: >>>On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>> >>>>On 10/07/2014 12:12 PM, Alexander Bokovoy wrote: >>>>>On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>>>>Hi Alex, >>>>>> >>>>>>slapi_attr_set_valueset() calls >>>>>>slapi_valueset_set_valueset(), but this does not free the >>>>>>existing values, >>>>>Here is the problem, I cannot free original values as >>>>>slapi_attr_get_valueset() returns a copy and I never can get access to >>>>>the original Slapi_ValueSet. >>>>good point. >>>>> >>>>>I only can get access to the original Slapi_Value** array which means I >>>>>could manipulate its content but that probably require resizing it and >>>>>thus changing a pointer vs->va, to which I don't have access anyway. >>>>you should never do this, a valueset contains more data than va >>>>>How can we fix this? >>>>the best thing would probably be to fix slapi_attr_set_valueset >>>>or adding a new api function which frees teh old valueset, but >>>>this would add a dependency to specific DS version >>>What about something like this: >>> >>>void >>>slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet >>>*vs2) >>>{ >>> if ((vs1 != NULL) && (vs1->num != 0)) { >>> slapi_valueset_done(vs1); >>> } >>> slapi_valueset_init(vs1); >>> valueset_set_valueset(vs1,vs2); >>>} >>> >>>Another option is to fix slapi_attr_set_valueset(): >>> >>>int >>>slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs) >>>{ >>> if (a->a_present_values->num != 0) { >>> lapi_valueset_done(&a->a_present_values); >>> } >>> slapi_valueset_set_valueset( &a->a_present_values, vs); >>> return 0; >>>} >>> >>>Other uses of slapi_valueset_set_valueset() are operating on newly >>>created Slapi_ValueSet instances. >>both will be ok (for me), but we have to commit it first and you >>depend on that version. >> >>a more clumsy way would be to get the values and then use >>slapi_entry_attr_replace_sv() which would free the attr and recreate >>it >Actually, you pointed me to a better solution: > > /* Replace the attribute's value with the override */ > result = slapi_entry_attr_exists(entry, override_type); > if (result == 0) { > result = slapi_attr_get_values(override_attr, &override_valueset); > result = slapi_entry_attr_delete_sv(entry, override_type, NULL); > result = slapi_entry_add_valueset(entry, override_type, override_valueset); > } > >slapi_entry_delete_values_sv(entry, attr, NULL) will clear whole >attribute and then I can add the valueset. This, unfortunately, works >via iterating over the whole valueset and adding values one by one but >in our case it would be most likely a single element anyway. Pasted a lot of typos but fixed it already: result = slapi_entry_attr_exists(entry, override_type); if (result == 0) { result = slapi_attr_get_valueset(override_attr, &override_valueset); result = slapi_entry_attr_delete(entry, override_type); result = slapi_entry_add_valueset(entry, override_type, override_valueset); } -- / Alexander Bokovoy From mkosek at redhat.com Tue Oct 7 11:47:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 07 Oct 2014 13:47:05 +0200 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design In-Reply-To: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> References: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> Message-ID: <5433D2B9.7080209@redhat.com> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > Hi all, > > The Dogtag lightweight sub-CAs design has undergone major revision > and expansion ahead of beginning the implementation (I plan to begin > later this week). This feature will provide an API for admins to > create sub-CAs for separate security domains and augment the > existing API so that certificates requests can be directed to a > particular sub-CA. > > This feature will be used in FreeIPA for issuing user or service > certificates for particular purposes (that will be rejected when use > for other purposes). > > Please review the document and provide feedback. > > http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > Feedback/suggestions for the REST API (that FreeIPA will use) and > ACI considerations (e.g. is it appropriate to use the existing > "agent" credential or should a separate credential or more > fine-grained ACIs be used) are particularly encouraged. > > Cheers, > > Fraser Thanks for sharing the design! Couple initial comments: > Creating sub-CAs > > Creation of sub-CAs at any time after the initial spawning of an CA instance > is a requirement. Preferably, restart would not be needed, however, if needed, > it must be able to be performed without manual intervention. I am all for having the operation in effect without requiring restart, especially given the change is in replicated tree. What do you mean by "restart without manual operation"? That Dogtag would restart itself when it detects that subCA would be added? > Key generation and storage Are we referring to http://www.freeipa.org/page/V4/PKCS11_in_LDAP http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema ? Contact people: Jan Cholasta, Petr Spacek > ACI considerations Agent credential is used by FreeIPA web interface, all authorization is then done on python framework level. We can add more agents and then switch the used certificate, but I wonder how to use it in authorization decisions. Apache service will need to to have access to all these agents anyway. First we need to think how fine grained authorization we want to do. I think we will want to be able to for example say that user Foo can generate certificates in specified subCA. I am not sure it is a good way to go, it would also make such private key distribution on IPA replicas + renewal a challenge. Right now, we only have "Virtual Operations" concept to authorize different operations with Dogtag CA, but it does not distinguish between different CAs. We could add a new Virtual Operation for every subCA, but it looks clumsy. But the ACI-based mechanism and our permission system would still be the easiest way to go, IMHO, compared to utilizing PKI agents. Martin From lkrispen at redhat.com Tue Oct 7 11:56:14 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 07 Oct 2014 13:56:14 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141007113255.GD4683@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433B9F3.9020806@redhat.com> <20141007101208.GZ4683@redhat.com> <5433BEEB.9010702@redhat.com> <20141007103900.GB4683@redhat.com> <5433C4D2.2090600@redhat.com> <20141007111513.GC4683@redhat.com> <20141007113255.GD4683@redhat.com> Message-ID: <5433D4DE.40909@redhat.com> On 10/07/2014 01:32 PM, Alexander Bokovoy wrote: > On Tue, 07 Oct 2014, Alexander Bokovoy wrote: >> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>> >>> On 10/07/2014 12:39 PM, Alexander Bokovoy wrote: >>>> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>>> >>>>> On 10/07/2014 12:12 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>>>>> Hi Alex, >>>>>>> >>>>>>> slapi_attr_set_valueset() calls slapi_valueset_set_valueset(), >>>>>>> but this does not free the existing values, >>>>>> Here is the problem, I cannot free original values as >>>>>> slapi_attr_get_valueset() returns a copy and I never can get >>>>>> access to >>>>>> the original Slapi_ValueSet. >>>>> good point. >>>>>> >>>>>> I only can get access to the original Slapi_Value** array which >>>>>> means I >>>>>> could manipulate its content but that probably require resizing >>>>>> it and >>>>>> thus changing a pointer vs->va, to which I don't have access anyway. >>>>> you should never do this, a valueset contains more data than va >>>>>> How can we fix this? >>>>> the best thing would probably be to fix slapi_attr_set_valueset or >>>>> adding a new api function which frees teh old valueset, but this >>>>> would add a dependency to specific DS version >>>> What about something like this: >>>> >>>> void >>>> slapi_valueset_set_valueset(Slapi_ValueSet *vs1, const Slapi_ValueSet >>>> *vs2) >>>> { >>>> if ((vs1 != NULL) && (vs1->num != 0)) { >>>> slapi_valueset_done(vs1); >>>> } >>>> slapi_valueset_init(vs1); >>>> valueset_set_valueset(vs1,vs2); >>>> } >>>> >>>> Another option is to fix slapi_attr_set_valueset(): >>>> >>>> int >>>> slapi_attr_set_valueset(Slapi_Attr *a, const Slapi_ValueSet *vs) >>>> { >>>> if (a->a_present_values->num != 0) { >>>> lapi_valueset_done(&a->a_present_values); >>>> } >>>> slapi_valueset_set_valueset( &a->a_present_values, vs); >>>> return 0; >>>> } >>>> >>>> Other uses of slapi_valueset_set_valueset() are operating on newly >>>> created Slapi_ValueSet instances. >>> both will be ok (for me), but we have to commit it first and you >>> depend on that version. >>> >>> a more clumsy way would be to get the values and then use >>> slapi_entry_attr_replace_sv() which would free the attr and recreate it >> Actually, you pointed me to a better solution: >> >> /* Replace the attribute's value with the override */ >> result = slapi_entry_attr_exists(entry, override_type); >> if (result == 0) { >> result = slapi_attr_get_values(override_attr, &override_valueset); >> result = slapi_entry_attr_delete_sv(entry, override_type, NULL); >> result = slapi_entry_add_valueset(entry, override_type, >> override_valueset); >> } >> >> slapi_entry_delete_values_sv(entry, attr, NULL) will clear whole >> attribute and then I can add the valueset. This, unfortunately, works >> via iterating over the whole valueset and adding values one by one but >> in our case it would be most likely a single element anyway. > Pasted a lot of typos but fixed it already: > result = slapi_entry_attr_exists(entry, override_type); > if (result == 0) { > result = slapi_attr_get_valueset(override_attr, > &override_valueset); > result = slapi_entry_attr_delete(entry, override_type); > result = slapi_entry_add_valueset(entry, override_type, > override_valueset); > } ok From ssorce at redhat.com Tue Oct 7 13:06:29 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 7 Oct 2014 09:06:29 -0400 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design In-Reply-To: <5433D2B9.7080209@redhat.com> References: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> <5433D2B9.7080209@redhat.com> Message-ID: <20141007090629.5135145e@willson.usersys.redhat.com> On Tue, 07 Oct 2014 13:47:05 +0200 Martin Kosek wrote: > On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > > Hi all, > > > > The Dogtag lightweight sub-CAs design has undergone major revision > > and expansion ahead of beginning the implementation (I plan to begin > > later this week). This feature will provide an API for admins to > > create sub-CAs for separate security domains and augment the > > existing API so that certificates requests can be directed to a > > particular sub-CA. > > > > This feature will be used in FreeIPA for issuing user or service > > certificates for particular purposes (that will be rejected when use > > for other purposes). > > > > Please review the document and provide feedback. > > > > http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > > > Feedback/suggestions for the REST API (that FreeIPA will use) and > > ACI considerations (e.g. is it appropriate to use the existing > > "agent" credential or should a separate credential or more > > fine-grained ACIs be used) are particularly encouraged. > > > > Cheers, > > > > Fraser > > Thanks for sharing the design! Couple initial comments: > > > Creating sub-CAs > > > > Creation of sub-CAs at any time after the initial spawning of an CA > > instance is a requirement. Preferably, restart would not be needed, > > however, if needed, it must be able to be performed without manual > > intervention. > > I am all for having the operation in effect without requiring restart, > especially given the change is in replicated tree. What do you mean > by "restart without manual operation"? That Dogtag would restart > itself when it detects that subCA would be added? > > > Key generation and storage > > Are we referring to > http://www.freeipa.org/page/V4/PKCS11_in_LDAP > http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > ? Contact people: Jan Cholasta, Petr Spacek > > > > ACI considerations > > Agent credential is used by FreeIPA web interface, all authorization > is then done on python framework level. We can add more agents and > then switch the used certificate, but I wonder how to use it in > authorization decisions. Apache service will need to to have access > to all these agents anyway. We really need to move to a separate service for agent access, the framework is supposed to not have any more power than the user that connects to it. By giving the framework direct access to credentials we fundamentally change the proposition and erode the security properties of the separation. We have discussed before a proxy process that pass in commands as they come from the framework but assumes agent identity only after checking how the framework authenticated to it (via GSSAPI). > First we need to think how fine grained authorization we want to do. We need to associate a user to an agent credential via a group, so that we can assign the rights via roles. > I think we will want to be able to for example say that user Foo can > generate certificates in specified subCA. I am not sure it is a good > way to go, it would also make such private key distribution on IPA > replicas + renewal a challenge. I do not think we need to start with very fine grained permissions initially. > Right now, we only have "Virtual Operations" concept to authorize > different operations with Dogtag CA, but it does not distinguish > between different CAs. We could add a new Virtual Operation for every > subCA, but it looks clumsy. But the ACI-based mechanism and our > permission system would still be the easiest way to go, IMHO, > compared to utilizing PKI agents. We need to have a different agent certificate per role, and then in the proxy process associate the right agent certificate based on what the framework asks and internal checking that the user is indeed allowed to do so. The framework will select the 'role' to use based on the operation to be performed. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 7 13:29:33 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 07 Oct 2014 09:29:33 -0400 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design In-Reply-To: <20141007090629.5135145e@willson.usersys.redhat.com> References: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> <5433D2B9.7080209@redhat.com> <20141007090629.5135145e@willson.usersys.redhat.com> Message-ID: <5433EABD.5090103@redhat.com> Simo Sorce wrote: > On Tue, 07 Oct 2014 13:47:05 +0200 > Martin Kosek wrote: > >> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: >>> Hi all, >>> >>> The Dogtag lightweight sub-CAs design has undergone major revision >>> and expansion ahead of beginning the implementation (I plan to begin >>> later this week). This feature will provide an API for admins to >>> create sub-CAs for separate security domains and augment the >>> existing API so that certificates requests can be directed to a >>> particular sub-CA. >>> >>> This feature will be used in FreeIPA for issuing user or service >>> certificates for particular purposes (that will be rejected when use >>> for other purposes). >>> >>> Please review the document and provide feedback. >>> >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs >>> >>> Feedback/suggestions for the REST API (that FreeIPA will use) and >>> ACI considerations (e.g. is it appropriate to use the existing >>> "agent" credential or should a separate credential or more >>> fine-grained ACIs be used) are particularly encouraged. >>> >>> Cheers, >>> >>> Fraser >> >> Thanks for sharing the design! Couple initial comments: >> >>> Creating sub-CAs >>> >>> Creation of sub-CAs at any time after the initial spawning of an CA >>> instance is a requirement. Preferably, restart would not be needed, >>> however, if needed, it must be able to be performed without manual >>> intervention. >> >> I am all for having the operation in effect without requiring restart, >> especially given the change is in replicated tree. What do you mean >> by "restart without manual operation"? That Dogtag would restart >> itself when it detects that subCA would be added? >> >>> Key generation and storage >> >> Are we referring to >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema >> ? Contact people: Jan Cholasta, Petr Spacek >> >> >>> ACI considerations >> >> Agent credential is used by FreeIPA web interface, all authorization >> is then done on python framework level. We can add more agents and >> then switch the used certificate, but I wonder how to use it in >> authorization decisions. Apache service will need to to have access >> to all these agents anyway. > > We really need to move to a separate service for agent access, the > framework is supposed to not have any more power than the user that > connects to it. By giving the framework direct access to credentials we > fundamentally change the proposition and erode the security properties > of the separation. > > We have discussed before a proxy process that pass in commands as they > come from the framework but assumes agent identity only after checking > how the framework authenticated to it (via GSSAPI). > >> First we need to think how fine grained authorization we want to do. > > We need to associate a user to an agent credential via a group, so that > we can assign the rights via roles. > >> I think we will want to be able to for example say that user Foo can >> generate certificates in specified subCA. I am not sure it is a good >> way to go, it would also make such private key distribution on IPA >> replicas + renewal a challenge. > > I do not think we need to start with very fine grained permissions > initially. > >> Right now, we only have "Virtual Operations" concept to authorize >> different operations with Dogtag CA, but it does not distinguish >> between different CAs. We could add a new Virtual Operation for every >> subCA, but it looks clumsy. But the ACI-based mechanism and our >> permission system would still be the easiest way to go, IMHO, >> compared to utilizing PKI agents. > > We need to have a different agent certificate per role, and then in the > proxy process associate the right agent certificate based on what the > framework asks and internal checking that the user is indeed allowed to > do so. > > The framework will select the 'role' to use based on the operation to > be performed. I totally agree in principle but this will add significant complexity to replication and renewal. Each agent cert will need to be tracked by certmonger and renewed automatically. The basic framework for that is in place and IIRC fairly generalized so this should be relatively simple, but we've had a few bumps in the road to renewal. What I think will be more challenging is dealing with distribution of additional agent certs to other masters. We handle it now via ipa-replica-manage. Given that it is a requirement to be able to generate sub-CAs post-install there needs to be some mechanism to share this certificate amongst the other IPA masters. On the bright side Fraser has already considered some of this, at least for sub-CA key distribution, but there are no no details fleshed out yet. rob From ssorce at redhat.com Tue Oct 7 13:40:12 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 7 Oct 2014 09:40:12 -0400 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design In-Reply-To: <5433EABD.5090103@redhat.com> References: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> <5433D2B9.7080209@redhat.com> <20141007090629.5135145e@willson.usersys.redhat.com> <5433EABD.5090103@redhat.com> Message-ID: <20141007094012.184c3812@willson.usersys.redhat.com> On Tue, 07 Oct 2014 09:29:33 -0400 Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 07 Oct 2014 13:47:05 +0200 > > Martin Kosek wrote: > > > >> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > >>> Hi all, > >>> > >>> The Dogtag lightweight sub-CAs design has undergone major revision > >>> and expansion ahead of beginning the implementation (I plan to > >>> begin later this week). This feature will provide an API for > >>> admins to create sub-CAs for separate security domains and > >>> augment the existing API so that certificates requests can be > >>> directed to a particular sub-CA. > >>> > >>> This feature will be used in FreeIPA for issuing user or service > >>> certificates for particular purposes (that will be rejected when > >>> use for other purposes). > >>> > >>> Please review the document and provide feedback. > >>> > >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > >>> > >>> Feedback/suggestions for the REST API (that FreeIPA will use) and > >>> ACI considerations (e.g. is it appropriate to use the existing > >>> "agent" credential or should a separate credential or more > >>> fine-grained ACIs be used) are particularly encouraged. > >>> > >>> Cheers, > >>> > >>> Fraser > >> > >> Thanks for sharing the design! Couple initial comments: > >> > >>> Creating sub-CAs > >>> > >>> Creation of sub-CAs at any time after the initial spawning of an > >>> CA instance is a requirement. Preferably, restart would not be > >>> needed, however, if needed, it must be able to be performed > >>> without manual intervention. > >> > >> I am all for having the operation in effect without requiring > >> restart, especially given the change is in replicated tree. What > >> do you mean by "restart without manual operation"? That Dogtag > >> would restart itself when it detects that subCA would be added? > >> > >>> Key generation and storage > >> > >> Are we referring to > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > >> ? Contact people: Jan Cholasta, Petr Spacek > >> > >> > >>> ACI considerations > >> > >> Agent credential is used by FreeIPA web interface, all > >> authorization is then done on python framework level. We can add > >> more agents and then switch the used certificate, but I wonder how > >> to use it in authorization decisions. Apache service will need to > >> to have access to all these agents anyway. > > > > We really need to move to a separate service for agent access, the > > framework is supposed to not have any more power than the user that > > connects to it. By giving the framework direct access to > > credentials we fundamentally change the proposition and erode the > > security properties of the separation. > > > > We have discussed before a proxy process that pass in commands as > > they come from the framework but assumes agent identity only after > > checking how the framework authenticated to it (via GSSAPI). > > > >> First we need to think how fine grained authorization we want to > >> do. > > > > We need to associate a user to an agent credential via a group, so > > that we can assign the rights via roles. > > > >> I think we will want to be able to for example say that user Foo > >> can generate certificates in specified subCA. I am not sure it is > >> a good way to go, it would also make such private key distribution > >> on IPA replicas + renewal a challenge. > > > > I do not think we need to start with very fine grained permissions > > initially. > > > >> Right now, we only have "Virtual Operations" concept to authorize > >> different operations with Dogtag CA, but it does not distinguish > >> between different CAs. We could add a new Virtual Operation for > >> every subCA, but it looks clumsy. But the ACI-based mechanism and > >> our permission system would still be the easiest way to go, IMHO, > >> compared to utilizing PKI agents. > > > > We need to have a different agent certificate per role, and then in > > the proxy process associate the right agent certificate based on > > what the framework asks and internal checking that the user is > > indeed allowed to do so. > > > > The framework will select the 'role' to use based on the operation > > to be performed. > > I totally agree in principle but this will add significant complexity > to replication and renewal. We already have this issue with DNSSEC, so I think we can solve it the same way (storing keys in LDAP encrypted with a master key). > Each agent cert will need to be tracked by certmonger and renewed > automatically. The basic framework for that is in place and IIRC > fairly generalized so this should be relatively simple, but we've had > a few bumps in the road to renewal. Alternatively I think we can avoid this by having the proxy process store the certs in LDAP (encrypted with the current main agent cert) and renew them by calling out to certmonger if the certs are close to expiration. We can make it simpler than it is now. > What I think will be more challenging is dealing with distribution of > additional agent certs to other masters. We handle it now via > ipa-replica-manage. See above :) > Given that it is a requirement to be able to generate sub-CAs > post-install there needs to be some mechanism to share this > certificate amongst the other IPA masters. > > On the bright side Fraser has already considered some of this, at > least for sub-CA key distribution, but there are no no details > fleshed out yet. This is critical in general, so having this privileged process on the ipa side is necessary. It can handle access to keys for other uses too. For example I would like to use the same mechanism to switch to have only an encrypted krbMaster key in LDAP and use this privileged process pull it, unencrypt it with the local cert and then store it in a keytab for the KDC to use). This is clearly a future development but it is something we really need to move towards instead of adding "simpler" workarounds in the current code. Simo. -- Simo Sorce * Red Hat, Inc * New York From redhatrises at gmail.com Tue Oct 7 13:58:01 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 7 Oct 2014 07:58:01 -0600 Subject: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns Message-ID: Hello, Fix for https://fedorahosted.org/freeipa/ticket/4613 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Tue Oct 7 13:58:42 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 7 Oct 2014 07:58:42 -0600 Subject: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns In-Reply-To: References: Message-ID: Forgot to add patch. On Tue, Oct 7, 2014 at 7:58 AM, Gabe Alford wrote: > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4613 > > Thanks, > > Gabe > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0034-Missing-requires-on-python-dns-in-spec-file.patch Type: text/x-patch Size: 1350 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 7 14:32:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 07 Oct 2014 16:32:24 +0200 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design In-Reply-To: <20141007094012.184c3812@willson.usersys.redhat.com> References: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> <5433D2B9.7080209@redhat.com> <20141007090629.5135145e@willson.usersys.redhat.com> <5433EABD.5090103@redhat.com> <20141007094012.184c3812@willson.usersys.redhat.com> Message-ID: <5433F978.2070704@redhat.com> On 7.10.2014 15:40, Simo Sorce wrote: > On Tue, 07 Oct 2014 09:29:33 -0400 > Rob Crittenden wrote: > >> Simo Sorce wrote: >>> On Tue, 07 Oct 2014 13:47:05 +0200 >>> Martin Kosek wrote: >>> >>>> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: >>>>> Hi all, >>>>> >>>>> The Dogtag lightweight sub-CAs design has undergone major revision >>>>> and expansion ahead of beginning the implementation (I plan to >>>>> begin later this week). This feature will provide an API for >>>>> admins to create sub-CAs for separate security domains and >>>>> augment the existing API so that certificates requests can be >>>>> directed to a particular sub-CA. >>>>> >>>>> This feature will be used in FreeIPA for issuing user or service >>>>> certificates for particular purposes (that will be rejected when >>>>> use for other purposes). >>>>> >>>>> Please review the document and provide feedback. >>>>> >>>>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs >>>>> >>>>> Feedback/suggestions for the REST API (that FreeIPA will use) and >>>>> ACI considerations (e.g. is it appropriate to use the existing >>>>> "agent" credential or should a separate credential or more >>>>> fine-grained ACIs be used) are particularly encouraged. >>>>> >>>>> Cheers, >>>>> >>>>> Fraser >>>> >>>> Thanks for sharing the design! Couple initial comments: >>>> >>>>> Creating sub-CAs >>>>> >>>>> Creation of sub-CAs at any time after the initial spawning of an >>>>> CA instance is a requirement. Preferably, restart would not be >>>>> needed, however, if needed, it must be able to be performed >>>>> without manual intervention. >>>> >>>> I am all for having the operation in effect without requiring >>>> restart, especially given the change is in replicated tree. What >>>> do you mean by "restart without manual operation"? That Dogtag >>>> would restart itself when it detects that subCA would be added? >>>> >>>>> Key generation and storage >>>> >>>> Are we referring to >>>> http://www.freeipa.org/page/V4/PKCS11_in_LDAP >>>> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema >>>> ? Contact people: Jan Cholasta, Petr Spacek >>>> >>>> >>>>> ACI considerations >>>> >>>> Agent credential is used by FreeIPA web interface, all >>>> authorization is then done on python framework level. We can add >>>> more agents and then switch the used certificate, but I wonder how >>>> to use it in authorization decisions. Apache service will need to >>>> to have access to all these agents anyway. >>> >>> We really need to move to a separate service for agent access, the >>> framework is supposed to not have any more power than the user that >>> connects to it. By giving the framework direct access to >>> credentials we fundamentally change the proposition and erode the >>> security properties of the separation. >>> >>> We have discussed before a proxy process that pass in commands as >>> they come from the framework but assumes agent identity only after >>> checking how the framework authenticated to it (via GSSAPI). >>> >>>> First we need to think how fine grained authorization we want to >>>> do. >>> >>> We need to associate a user to an agent credential via a group, so >>> that we can assign the rights via roles. >>> >>>> I think we will want to be able to for example say that user Foo >>>> can generate certificates in specified subCA. I am not sure it is >>>> a good way to go, it would also make such private key distribution >>>> on IPA replicas + renewal a challenge. >>> >>> I do not think we need to start with very fine grained permissions >>> initially. >>> >>>> Right now, we only have "Virtual Operations" concept to authorize >>>> different operations with Dogtag CA, but it does not distinguish >>>> between different CAs. We could add a new Virtual Operation for >>>> every subCA, but it looks clumsy. But the ACI-based mechanism and >>>> our permission system would still be the easiest way to go, IMHO, >>>> compared to utilizing PKI agents. >>> >>> We need to have a different agent certificate per role, and then in >>> the proxy process associate the right agent certificate based on >>> what the framework asks and internal checking that the user is >>> indeed allowed to do so. >>> >>> The framework will select the 'role' to use based on the operation >>> to be performed. >> >> I totally agree in principle but this will add significant complexity >> to replication and renewal. > > We already have this issue with DNSSEC, so I think we can solve it the > same way (storing keys in LDAP encrypted with a master key). Maybe it is worth mentioning some implementation details from DNSSEC support: - *Every replica has own HSM* with standard PKCS#11 interface. -- By default we install SoftHSM. -- In theory it can be replaced with real HSM because the interface should be the same. This allows users to "easily" get FIPS 140 level 4 certified crypto instead of SoftHSM if they are willing to pay for it. - Every replica has own private-public key pair stored in this HSM. -- Key pair is generated inside HSM. -- Private part will never leave local HSM. -- Public part is stored in LDAP so all replicas can see it. - *All* crypto operations are done inside HSM, no keys ever leave HSM in plain text. - LDAP stores wrapped keys in this was: -- DNS zone keys are wrapped with DNS master key. -- DNS master key is wrapped with replica key. Scenario: If replica 1 wants to use "key2" stored in LDAP by replica 2: - Replica 1 downloads wrapped master key from LDAP. - Replica 1 uses local HSM to unwrap the master key using own private key -> resulting master key is stored in local HSM and never leaves it. - Replica 1 downloads "key2" and uses master key in local HSM to unwrap "key2" -> resulting "key2" is stored in local HSM and never leaves it. Naturally this forces applications to use PKCS#11 for all crypto so the raw key never leaves HSM. Luckily DNSSEC software is built around PKCS#11 so it was a natural choice for us. Personally, I would say that this is the way to go. Petr^2 Spacek >> Each agent cert will need to be tracked by certmonger and renewed >> automatically. The basic framework for that is in place and IIRC >> fairly generalized so this should be relatively simple, but we've had >> a few bumps in the road to renewal. > > Alternatively I think we can avoid this by having the proxy process > store the certs in LDAP (encrypted with the current main agent cert) > and renew them by calling out to certmonger if the certs are close to > expiration. We can make it simpler than it is now. > >> What I think will be more challenging is dealing with distribution of >> additional agent certs to other masters. We handle it now via >> ipa-replica-manage. > > See above :) > >> Given that it is a requirement to be able to generate sub-CAs >> post-install there needs to be some mechanism to share this >> certificate amongst the other IPA masters. >> >> On the bright side Fraser has already considered some of this, at >> least for sub-CA key distribution, but there are no no details >> fleshed out yet. > > This is critical in general, so having this privileged process on the > ipa side is necessary. It can handle access to keys for other uses too. > > For example I would like to use the same mechanism to switch to have > only an encrypted krbMaster key in LDAP and use this privileged process > pull it, unencrypt it with the local cert and then store it in a keytab > for the KDC to use). This is clearly a future development but it is > something we really need to move towards instead of adding "simpler" > workarounds in the current code. From tbordaz at redhat.com Tue Oct 7 14:41:56 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 07 Oct 2014 16:41:56 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141001161606.GA6186@redhat.com> References: <20141001161606.GA6186@redhat.com> Message-ID: <5433FBB4.4070805@redhat.com> On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: > Hi! > > Attached are patches to add support of FreeIPA ID views to Schema > compatibility plugin (slapi-nis). There are two patches for FreeIPA and > a separate patch for slapi-nis. Patches can be applied independently; if > old slapi-nis is installed, it will simply work with new configuration > but do nothing with respect to answering to requests using host-specific > ID views. > > I included documentation on how slapi-nis ID views feature supposed to > work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes > are welcome. There are no additional tests in slapi-nis to cover compat > trees, we have multiple tests in FreeIPA for this purpose, will be run > as part of FreeIPA CI effort. > > FreeIPA patches add ACIs for accessing ID view-applied entries over > compat tree. They also include additional configuration; this > configuration is needed to properly resolve ID view overrides when > creating compat entries. > > A second FreeIPA patch adds support to override login shell. This part > was missing from the original patchset by Tomas. > > For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit > Bose. There is also a regression (fixed by Sumit as well) that prevents > authentication of AD users over PAM which affects authentication over > compat tree. With the patch from Sumit authentication works again, both > with ID view and without it. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hi Alexander, Just a minor remark about idview_get_overrides. It does an internal search of the views and keep the returned views into cbdata->overrides. Later the entries will be freed. Internal search may also return referral arrays (usually freed by slapi_free_search_results_internal). In case cn=views container contains referral entries you may need to free them. Also, I have a concern about performance. My understanding is that for each search, backend_search_cb allocates a new cbdata with uninitialized 'overrides'. So it will trigger the internal search idview_get_overrides. Most of the time those overrides rules have not been updated, so idview_get_overrides will retrieve the same entries. Wouldn't it be possible to 'cache' those entries (to prevent the internal search), and just clear those entries if a mod/add/del happen one them ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Tue Oct 7 14:56:24 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 07 Oct 2014 16:56:24 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Set IPA CA for freeipa certificates Message-ID: <5433FF18.6040103@redhat.com> https://fedorahosted.org/freeipa/ticket/4618 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0020-Set-IPA-CA-for-freeipa-certificates.patch Type: text/x-patch Size: 1141 bytes Desc: not available URL: From abokovoy at redhat.com Tue Oct 7 15:00:46 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 7 Oct 2014 18:00:46 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <5433FBB4.4070805@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433FBB4.4070805@redhat.com> Message-ID: <20141007150046.GF4683@redhat.com> On Tue, 07 Oct 2014, thierry bordaz wrote: >On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: >>Hi! >> >>Attached are patches to add support of FreeIPA ID views to Schema >>compatibility plugin (slapi-nis). There are two patches for FreeIPA and >>a separate patch for slapi-nis. Patches can be applied independently; if >>old slapi-nis is installed, it will simply work with new configuration >>but do nothing with respect to answering to requests using host-specific >>ID views. >> >>I included documentation on how slapi-nis ID views feature supposed to >>work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and fixes >>are welcome. There are no additional tests in slapi-nis to cover compat >>trees, we have multiple tests in FreeIPA for this purpose, will be run >>as part of FreeIPA CI effort. >> >>FreeIPA patches add ACIs for accessing ID view-applied entries over >>compat tree. They also include additional configuration; this >>configuration is needed to properly resolve ID view overrides when >>creating compat entries. >> >>A second FreeIPA patch adds support to override login shell. This part >>was missing from the original patchset by Tomas. >> >>For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit >>Bose. There is also a regression (fixed by Sumit as well) that prevents >>authentication of AD users over PAM which affects authentication over >>compat tree. With the patch from Sumit authentication works again, both >>with ID view and without it. >> >> >> >>_______________________________________________ >>Freeipa-devel mailing list >>Freeipa-devel at redhat.com >>https://www.redhat.com/mailman/listinfo/freeipa-devel >Hi Alexander, > > Just a minor remark about idview_get_overrides. It does an internal > search of the views and keep the returned views into > cbdata->overrides. Later the entries will be freed. Internal search > may also return referral arrays (usually freed by > slapi_free_search_results_internal). In case cn=views container > contains referral entries you may need to free them. What would be a reason to return these referrals in IPA case? This code is IPA-specific and we don't have any referrals for the tree or backend we are dealing with. I agree it would be good to do in general but how that is relevant to the specific use case? > Also, I have a concern about performance. My understanding is that > for each search, backend_search_cb allocates a new cbdata with > uninitialized 'overrides'. So it will trigger the internal search > idview_get_overrides. > Most of the time those overrides rules have not been updated, so > idview_get_overrides will retrieve the same entries. > Wouldn't it be possible to 'cache' those entries (to prevent the > internal search), and just clear those entries if a mod/add/del > happen one them ? I was thinking about using this approach but rejected it for several reasons, primary due to lack of development time. We can do a lot of refactoring on how slapi-nis currently uses RAM to store all compat entries at the same time; the current approach with ID overrides tries to not complicate that logic. We agreed with Simo to do performance optimizations at a later stage. -- / Alexander Bokovoy From tbordaz at redhat.com Tue Oct 7 15:06:58 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 07 Oct 2014 17:06:58 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141007150046.GF4683@redhat.com> References: <20141001161606.GA6186@redhat.com> <5433FBB4.4070805@redhat.com> <20141007150046.GF4683@redhat.com> Message-ID: <54340192.3030806@redhat.com> On 10/07/2014 05:00 PM, Alexander Bokovoy wrote: > On Tue, 07 Oct 2014, thierry bordaz wrote: >> On 10/01/2014 06:16 PM, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached are patches to add support of FreeIPA ID views to Schema >>> compatibility plugin (slapi-nis). There are two patches for FreeIPA and >>> a separate patch for slapi-nis. Patches can be applied >>> independently; if >>> old slapi-nis is installed, it will simply work with new configuration >>> but do nothing with respect to answering to requests using >>> host-specific >>> ID views. >>> >>> I included documentation on how slapi-nis ID views feature supposed to >>> work, available in slapi-nis/doc/ipa/ipa-sch.txt. Any comments and >>> fixes >>> are welcome. There are no additional tests in slapi-nis to cover compat >>> trees, we have multiple tests in FreeIPA for this purpose, will be run >>> as part of FreeIPA CI effort. >>> >>> FreeIPA patches add ACIs for accessing ID view-applied entries over >>> compat tree. They also include additional configuration; this >>> configuration is needed to properly resolve ID view overrides when >>> creating compat entries. >>> >>> A second FreeIPA patch adds support to override login shell. This part >>> was missing from the original patchset by Tomas. >>> >>> For trusted AD users one needs patches to SSSD 1.12.2, made by Sumit >>> Bose. There is also a regression (fixed by Sumit as well) that prevents >>> authentication of AD users over PAM which affects authentication over >>> compat tree. With the patch from Sumit authentication works again, both >>> with ID view and without it. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Hi Alexander, >> >> Just a minor remark about idview_get_overrides. It does an internal >> search of the views and keep the returned views into >> cbdata->overrides. Later the entries will be freed. Internal search >> may also return referral arrays (usually freed by >> slapi_free_search_results_internal). In case cn=views container >> contains referral entries you may need to free them. > What would be a reason to return these referrals in IPA case? This code > is IPA-specific and we don't have any referrals for the tree or backend > we are dealing with. I agree it would be good to do in general but how > that is relevant to the specific use case? You are right, this is IPA-specific and we control the fact that there is no referral entries there. > >> Also, I have a concern about performance. My understanding is that >> for each search, backend_search_cb allocates a new cbdata with >> uninitialized 'overrides'. So it will trigger the internal search >> idview_get_overrides. >> Most of the time those overrides rules have not been updated, so >> idview_get_overrides will retrieve the same entries. >> Wouldn't it be possible to 'cache' those entries (to prevent the >> internal search), and just clear those entries if a mod/add/del >> happen one them ? > I was thinking about using this approach but rejected it for several > reasons, primary due to lack of development time. We can do a lot of > refactoring on how slapi-nis currently uses RAM to store all compat > entries at the same time; the current approach with ID overrides tries > to not complicate that logic. We agreed with Simo to do performance > optimizations at a later stage. Ok. I fully agree. From lkrispen at redhat.com Tue Oct 7 15:12:24 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 07 Oct 2014 17:12:24 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141001161606.GA6186@redhat.com> References: <20141001161606.GA6186@redhat.com> Message-ID: <543402D8.6080801@redhat.com> Hi Alex, I have a question regarding cbdata.target. It is/was a reference to the pblock used to generate a new dn, but now in idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and should be freed, so I think there should be a return code indicating if it was allocated or not. From npmccallum at redhat.com Tue Oct 7 16:00:08 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 07 Oct 2014 12:00:08 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <542EE264.5040308@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> Message-ID: <1412697608.3308.1.camel@redhat.com> Attached is the latest patch. I believe this includes all of our discussions up until this point. However, a few bits of additional information are needed. First, I have renamed the plugin to ipa-otp-counter. I believe all replay prevention work can land inside this plugin, so the name is appropriate. Second, I uncovered a bug in 389 which prevents me from validating the non-replication request in bepre. This is the reason for the additional betxnpre callback. If the upstream 389 bug is fixed, we can merge this check back into bepre. https://fedorahosted.org/389/ticket/47919 Third, I believe we are now handling replication correct. An error is never returned. When a replication would cause the counter to decrease, we remove all counter/watermark related mods from the operation. This will allow the replication to apply without decrementing the value. There is also a new bepost method which check to see if the replication was discarded (via CSN) while having a higher counter value. If so, we apply the higher counter value. Here is the scenario. Server X receives two quick authentications; replications A and B are sent to server Y. Before server Y can process server X's replications, an authentication is performed on server Y; replication C is sent to server X. The following logic holds true: * csnA < csnB < csnC * valueA = valueC, valueB > valueC When server X receives replication C, ipa-otp-counter will strip out all counter mod operations; applying the update but not the lower value. The value of replication B is retained. This is the correct behavior. When server Y processes replications A and B, ipa-otp-counter will detect that a higher value has a lower CSN and will manually set the higher value (in bepost). This initiates replication D, which is sent to server X. Here is the logic: * csnA < csnB < csnC < csnD * valueA = valueC, valueB = valueD, valueD > valueC Server X receives replication D. D has the highest CSN. It has the same value as replication B (server X's current value). Because the values are the same, ipa-otp-counter will strip all counter mod operations. This reduces counter write contention which might become a problem in N-way replication when N>2. On Fri, 2014-10-03 at 19:52 +0200, thierry bordaz wrote: > Hello Nathaniel, > > An additional comment about the patch. > > When the new value is detected to be invalid, it is fixed by a > repair operation (trigger_replication). > I did test it and it is fine to update, with an internal > operation, the same entry that is currently updated. > > Now if you apply the repair operation into a be_preop or a > betxn_preop, when it returns from preop the txn of the current > operation will overwrite the repaired value. > > An option is to register a bepost that checks the value from > the original entry (SLAPI_ENTRY_PRE_OP) and post entry > (SLAPI_ENTRY_POST_OP). Then this postop checks the > orginal/final value and can trigger the repair op. > This time being outside of the main operation txn, the repair > op will be applied. > > thanks > thierry > On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: > > > On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: > > > On Sun, 21 Sep 2014 22:33:47 -0400 > > > Nathaniel McCallum wrote: > > > > > > Comments inline. > > > > > > > + > > > > +#define ch_malloc(type) \ > > > > + (type*) slapi_ch_malloc(sizeof(type)) > > > > +#define ch_calloc(count, type) \ > > > > + (type*) slapi_ch_calloc(count, sizeof(type)) > > > > +#define ch_free(p) \ > > > > + slapi_ch_free((void**) &(p)) > > > please do not redefine slapi functions, it just makes it harder to know > > > what you used. > > > > > > > > > > +typedef struct { > > > > + bool exists; > > > > + long long value; > > > > +} counter; > > > > > > please no typedefs of structures, use "struct counter { ... };" and > > > reference it as "struct counter" in the code. > > > > > > Btw, FWIW you could use a value of -1 to indicate non-existence of the > > > counter value, given counters can only be positive, this would avoid > > > the need for a struct. > > > > > > > +static int > > > > +send_error(Slapi_PBlock *pb, int rc, char *template, ...) > > > > +{ > > > > + va_list ap; > > > > + int res; > > > > + > > > > + va_start(ap, template); > > > > + res = vsnprintf(NULL, 0, template, ap); > > > > + va_end(ap); > > > > + > > > > + if (res > 0) { > > > > + char str[res + 1]; > > > > + > > > > + va_start(ap, template); > > > > + res = vsnprintf(str, sizeof(str), template, ap); > > > > + va_end(ap); > > > > + > > > > + if (res > 0) > > > > + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); > > > > + } > > > > + > > > > + if (res <= 0) > > > > + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); > > > > + > > > > + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); > > > > + return rc; > > > > +} > > > This function seem not really useful, you use send_error() only at the > > > end of one single function where you could have the classic scheme of > > > using a done: label and just use directly slapi_ch_smprintf. This would > > > remove the need to use vsnprintf and all the va_ machinery which is > > > more than 50% of this function. > > > > > > > > > > +static long long > > > > +get_value(const LDAPMod *mod, long long def) > > > > +{ > > > > + const struct berval *bv; > > > > + long long val; > > > > + > > > > + if (mod == NULL) > > > > + return def; > > > > + > > > > + if (mod->mod_vals.modv_bvals == NULL) > > > > + return def; > > > > + > > > > + bv = mod->mod_vals.modv_bvals[0]; > > > > + if (bv == NULL) > > > > + return def; > > > In general (here and elsewhere) I prefer to always use {} in if clauses. > > > I have been bitten enough time by people adding an instruction that > > > should be in the braces but forgot to add braces (defensive programming > > > style). But up to you. > > > > > > > + char buf[bv->bv_len + 1]; > > > > + memcpy(buf, bv->bv_val, bv->bv_len); > > > > + buf[sizeof(buf)-1] = '\0'; > > > > + > > > > + val = strtoll(buf, NULL, 10); > > > > + if (val == LLONG_MIN || val == LLONG_MAX) > > > > + return def; > > > > + > > > > + return val; > > > > +} > > > > + > > > > +static struct berval ** > > > > +make_berval_array(long long value) > > > > +{ > > > > + struct berval **bvs; > > > > + > > > > + bvs = ch_calloc(2, struct berval*); > > > > + bvs[0] = ch_malloc(struct berval); > > > > + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); > > > > + bvs[0]->bv_len = strlen(bvs[0]->bv_val); > > > > + > > > > + return bvs; > > > > +} > > > > + > > > > +static LDAPMod * > > > > +make_ldapmod(int op, const char *attr, long long value) > > > > +{ > > > > + LDAPMod *mod; > > > > + > > > > + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); > > > > + mod->mod_op = op | LDAP_MOD_BVALUES; > > > > + mod->mod_type = slapi_ch_strdup(attr); > > > > + mod->mod_bvalues = make_berval_array(value); > > > > + > > > > + return mod; > > > > +} > > > > + > > > > +static void > > > > +convert_ldapmod_to_bval(LDAPMod *mod) > > > > +{ > > > > + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) > > > > + return; > > > > + > > > > + mod->mod_op |= LDAP_MOD_BVALUES; > > > > + > > > > + if (mod->mod_values == NULL) { > > > > + mod->mod_bvalues = NULL; > > > > + return; > > > > + } > > > > + > > > > + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { > > > > + struct berval *bv = ch_malloc(struct berval); > > > > + bv->bv_val = mod->mod_values[i]; > > > > + bv->bv_len = strlen(bv->bv_val); > > > > + mod->mod_bvalues[i] = bv; > > > > + } > > > > +} > > > > + > > > > +static counter > > > > +get_counter(Slapi_Entry *entry, const char *attr) > > > > +{ > > > > + Slapi_Attr *sattr = NULL; > > > > + > > > > + return (counter) { > > > > + slapi_entry_attr_find(entry, attr, &sattr) == 0, > > > > + slapi_entry_attr_get_longlong(entry, attr) > > > > + }; > > > > +} > > > > + > > > > +static void > > > > +berval_free_array(struct berval ***bvals) > > > > +{ > > > > + for (size_t i = 0; (*bvals)[i] != NULL; i++) { > > > > + ch_free((*bvals)[i]->bv_val); > > > > + ch_free((*bvals)[i]); > > > > + } > > > > + > > > > + slapi_ch_free((void**) bvals); > > > > +} > > > > + > > > > +static bool > > > > +is_replication(Slapi_PBlock *pb) > > > > +{ > > > > + int repl = 0; > > > > + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); > > > > + return repl != 0; > > > > +} > > > > + > > > > +static const char * > > > > +get_attribute(Slapi_Entry *entry) > > > > +{ > > > > + static struct { > > > > + const char *clss; > > > > + const char *attr; > > > > + } table[] = { > > > > + { "ipatokenHOTP", "ipatokenHOTPcounter" }, > > > > + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, > > > > + { NULL, NULL } > > > > + }; > > > > + > > > > + const char *attr = NULL; > > > > + char **clsses = NULL; > > > > + > > > > + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); > > > > + if (clsses == NULL) > > > > + return NULL; > > > > + > > > > + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { > > > > + for (size_t j = 0; attr == NULL && table[j].clss != NULL; > > > > j++) { > > > > + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) > > > > + attr = table[j].attr; > > > > + } > > > > + } > > > > + > > > > + slapi_ch_array_free(clsses); > > > > + return attr; > > > > +} > > > Can you put a comment here that explains what you are going to do in > > > each cases in plain English ? This will help people in future figuring > > > out if/how to modify the code or why something happens a specific way. > > > It will also help the reviewer follow what is going on. > > > > > > > > > > +static int > > > > +preop_mod(Slapi_PBlock *pb) > > > > +{ > > > > + size_t count = 0, attrs = 0, extras = 0; > > > > + Slapi_Entry *entry = NULL; > > > > + const char *attr = NULL; > > > > + LDAPMod **inmods = NULL; > > > > + LDAPMod **mods = NULL; > > > > + counter ctr, orig; > > > > + > > > > + /* Get the input values. */ > > > > + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); > > > > + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); > > > > + if (entry == NULL || inmods == NULL) > > > > + return 0; > > > > + > > > > + /* Get the attribute name. */ > > > > + attr = get_attribute(entry); > > > > + if (attr == NULL) > > > > + return 0; /* Not a token. */ > > > > + > > > > + /* Count items. */ > > > > + while (inmods != NULL && inmods[count] != NULL) { > > > ^^ this one would read much better as: > > > for (count = 0; inmods[count] != NULL; count++) { > > > > > > You do not need to check for insmods != NULL as you already check for > > > it and return 0 a few lines above. > > > > > > > + LDAPMod *mod = inmods[count++]; > > > > + > > > > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > > > > + continue; > > > > + > > > > + attrs++; > > > > + switch (mod->mod_op & LDAP_MOD_OP) { > > > > + case LDAP_MOD_REPLACE: > > > > + case LDAP_MOD_INCREMENT: > > > > + extras++; > > > > + break; > > > > + } > > > > + } > > > > + > > > > + /* Not operating on the counter/watermark. */ > > > > + if (attrs == 0) > > > > + return 0; > > > > + > > > > + /* Get the counter. */ > > > > + orig = ctr = get_counter(entry, attr); > > > > + > > > > + /* Filter the modify operations. */ > > > > + mods = ch_calloc(count + extras + 1, LDAPMod*); > > > > + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; > > > > mods[j++] = inmods[i++]) { > > > Please remove check for insmods != NULL, it is useless, and removing it > > > will bring back the line under 80columns > > > > > > > + LDAPMod *mod = inmods[i]; > > > > + > > > > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > > > > + continue; > > > > + > > > > + convert_ldapmod_to_bval(mod); > > > > + > > > > + switch (mod->mod_op & LDAP_MOD_OP) { > > > > + case LDAP_MOD_DELETE: > > > > + ctr.exists = false; > > > > + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == > > > > NULL) > > > > + berval_free_array(&mod->mod_bvalues); > > > > + > > > > + if (is_replication(pb)) > > > > + berval_free_array(&mod->mod_bvalues); > > > > + > > > > + if (mod->mod_bvalues == NULL) > > > > + mod->mod_bvalues = make_berval_array(ctr.value); > > > > + break; > > > I am not sure I understand this segment, why are you touching the > > > delete operation outside of a replication event ? > > > Doesn't this defeat and admin tool trying to correctly delete/add to > > > avoid races ? > > > > > > > + case LDAP_MOD_INCREMENT: > > > > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > > > > ctr.value); + > > > > + ctr.value += get_value(mod, 1); > > > uhmmm if you had an ADD followed by INCREMENT operation, would this > > > cause the value to become value*2+1 instead of just value+1 ? > > > > > > > + berval_free_array(&mod->mod_bvalues); > > > > + mod->mod_op &= ~LDAP_MOD_OP; > > > > + mod->mod_op |= LDAP_MOD_ADD; > > > > + mod->mod_bvalues = make_berval_array(ctr.value); > > > > + break; > > > uhmm why are you converting mod_increment in all cases ? (including > > > replication) > > > > > > > + case LDAP_MOD_REPLACE: > > > > + if (ctr.exists) > > > > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > > > > ctr.value); + > > > > + mod->mod_op &= ~LDAP_MOD_OP; > > > > + mod->mod_op |= LDAP_MOD_ADD; > > > same question here, why are you converting a replace coming from > > > replication into a delete/add ? > > > > > > > + case LDAP_MOD_ADD: > > > > + ctr.value = get_value(mod, 0); > > > > + ctr.exists = true; > > > > + break; > > > > + } > > > > + } > > > > + > > > > + /* Set the modified operations. */ > > > > + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); > > > > + ch_free(inmods); > > > > + > > > > + /* Ensure we aren't deleting the counter. */ > > > > + if (orig.exists && !ctr.exists) > > > > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > > > > + "Will not delete %s", attr); > > > > + > > > > + /* Ensure we aren't rolling back the counter. */ > > > > + if (orig.value > ctr.value) > > > > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > > > > + "Will not decrement %s", attr); > > > > + > > > > + return 0; > > > > +} > > > > > > see above about send_error(). > > > > > > I think what is needed most is the comment that explains the process > > > at the to of the main function. > > > > > > Simo. > > All of the above are fixed. > > > > Also, I have addressed Thierry's concern about putting the plugin in > > betxnpreoperation by splitting the plugin into two phases: modification > > and validation. Now all modifications occur in bepreoperation and all > > validation occurs in betxnpreoperation. > > > > Additionally, I have new code to trigger a new replication in the case > > where a validation error occurs and we are in a replication transaction. > > Thus, when A attempts to push an old counter value to B, B will now > > replicate the latest value back to A. > > > > Nathaniel > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.5-Create-ipa-otp-counter-389DS-plugin.patch Type: text/x-patch Size: 34222 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 7 16:22:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 07 Oct 2014 18:22:06 +0200 Subject: [Freeipa-devel] [PATCH] 347 Fix CA cert validity check for CA-less and external CA installer options Message-ID: <5434132E.1000304@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-347-Fix-CA-cert-validity-check-for-CA-less-and-external-.patch Type: text/x-patch Size: 1212 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 7 16:48:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 07 Oct 2014 18:48:23 +0200 Subject: [Freeipa-devel] [PATCH] 348 Remove misleading authorization error message in cert-request with --add Message-ID: <54341957.9000004@redhat.com> Hi, the attached patch fixes . The error message is now the generic ACI error message, e.g. "Insufficient access: Insufficient 'add' privilege to add the entry 'krbprincipalname=something/somehost.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com'. " Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-348-Remove-misleading-authorization-error-message-in-cer.patch Type: text/x-patch Size: 1158 bytes Desc: not available URL: From tbordaz at redhat.com Tue Oct 7 16:54:46 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 07 Oct 2014 18:54:46 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412697608.3308.1.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> Message-ID: <54341AD6.8080303@redhat.com> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: > Attached is the latest patch. I believe this includes all of our > discussions up until this point. However, a few bits of additional > information are needed. > > First, I have renamed the plugin to ipa-otp-counter. I believe all > replay prevention work can land inside this plugin, so the name is > appropriate. > > Second, I uncovered a bug in 389 which prevents me from validating the > non-replication request in bepre. This is the reason for the additional > betxnpre callback. If the upstream 389 bug is fixed, we can merge this > check back into bepre. https://fedorahosted.org/389/ticket/47919 Hi Nathaniel, Just a rapid question about that dependency on https://fedorahosted.org/389/ticket/47919. Using txnpreop_mod you manage to workaround the DS issue. Do you need a fix for the DS issue in 1.3.2 or can it be fixed in a later version ? thanks thierry > > Third, I believe we are now handling replication correct. An error is > never returned. When a replication would cause the counter to decrease, > we remove all counter/watermark related mods from the operation. This > will allow the replication to apply without decrementing the value. > There is also a new bepost method which check to see if the replication > was discarded (via CSN) while having a higher counter value. If so, we > apply the higher counter value. > > Here is the scenario. Server X receives two quick authentications; > replications A and B are sent to server Y. Before server Y can process > server X's replications, an authentication is performed on server Y; > replication C is sent to server X. The following logic holds true: > * csnA < csnB < csnC > * valueA = valueC, valueB > valueC > > When server X receives replication C, ipa-otp-counter will strip out all > counter mod operations; applying the update but not the lower value. The > value of replication B is retained. This is the correct behavior. > > When server Y processes replications A and B, ipa-otp-counter will > detect that a higher value has a lower CSN and will manually set the > higher value (in bepost). This initiates replication D, which is sent to > server X. Here is the logic: > * csnA < csnB < csnC < csnD > * valueA = valueC, valueB = valueD, valueD > valueC > > Server X receives replication D. D has the highest CSN. It has the same > value as replication B (server X's current value). Because the values > are the same, ipa-otp-counter will strip all counter mod operations. > This reduces counter write contention which might become a problem in > N-way replication when N>2. > > On Fri, 2014-10-03 at 19:52 +0200, thierry bordaz wrote: >> Hello Nathaniel, >> >> An additional comment about the patch. >> >> When the new value is detected to be invalid, it is fixed by a >> repair operation (trigger_replication). >> I did test it and it is fine to update, with an internal >> operation, the same entry that is currently updated. >> >> Now if you apply the repair operation into a be_preop or a >> betxn_preop, when it returns from preop the txn of the current >> operation will overwrite the repaired value. >> >> An option is to register a bepost that checks the value from >> the original entry (SLAPI_ENTRY_PRE_OP) and post entry >> (SLAPI_ENTRY_POST_OP). Then this postop checks the >> orginal/final value and can trigger the repair op. >> This time being outside of the main operation txn, the repair >> op will be applied. >> >> thanks >> thierry >> On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: >> >>> On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: >>>> On Sun, 21 Sep 2014 22:33:47 -0400 >>>> Nathaniel McCallum wrote: >>>> >>>> Comments inline. >>>> >>>>> + >>>>> +#define ch_malloc(type) \ >>>>> + (type*) slapi_ch_malloc(sizeof(type)) >>>>> +#define ch_calloc(count, type) \ >>>>> + (type*) slapi_ch_calloc(count, sizeof(type)) >>>>> +#define ch_free(p) \ >>>>> + slapi_ch_free((void**) &(p)) >>>> please do not redefine slapi functions, it just makes it harder to know >>>> what you used. >>>> >>>> >>>>> +typedef struct { >>>>> + bool exists; >>>>> + long long value; >>>>> +} counter; >>>> please no typedefs of structures, use "struct counter { ... };" and >>>> reference it as "struct counter" in the code. >>>> >>>> Btw, FWIW you could use a value of -1 to indicate non-existence of the >>>> counter value, given counters can only be positive, this would avoid >>>> the need for a struct. >>>> >>>>> +static int >>>>> +send_error(Slapi_PBlock *pb, int rc, char *template, ...) >>>>> +{ >>>>> + va_list ap; >>>>> + int res; >>>>> + >>>>> + va_start(ap, template); >>>>> + res = vsnprintf(NULL, 0, template, ap); >>>>> + va_end(ap); >>>>> + >>>>> + if (res > 0) { >>>>> + char str[res + 1]; >>>>> + >>>>> + va_start(ap, template); >>>>> + res = vsnprintf(str, sizeof(str), template, ap); >>>>> + va_end(ap); >>>>> + >>>>> + if (res > 0) >>>>> + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); >>>>> + } >>>>> + >>>>> + if (res <= 0) >>>>> + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); >>>>> + >>>>> + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); >>>>> + return rc; >>>>> +} >>>> This function seem not really useful, you use send_error() only at the >>>> end of one single function where you could have the classic scheme of >>>> using a done: label and just use directly slapi_ch_smprintf. This would >>>> remove the need to use vsnprintf and all the va_ machinery which is >>>> more than 50% of this function. >>>> >>>> >>>>> +static long long >>>>> +get_value(const LDAPMod *mod, long long def) >>>>> +{ >>>>> + const struct berval *bv; >>>>> + long long val; >>>>> + >>>>> + if (mod == NULL) >>>>> + return def; >>>>> + >>>>> + if (mod->mod_vals.modv_bvals == NULL) >>>>> + return def; >>>>> + >>>>> + bv = mod->mod_vals.modv_bvals[0]; >>>>> + if (bv == NULL) >>>>> + return def; >>>> In general (here and elsewhere) I prefer to always use {} in if clauses. >>>> I have been bitten enough time by people adding an instruction that >>>> should be in the braces but forgot to add braces (defensive programming >>>> style). But up to you. >>>> >>>>> + char buf[bv->bv_len + 1]; >>>>> + memcpy(buf, bv->bv_val, bv->bv_len); >>>>> + buf[sizeof(buf)-1] = '\0'; >>>>> + >>>>> + val = strtoll(buf, NULL, 10); >>>>> + if (val == LLONG_MIN || val == LLONG_MAX) >>>>> + return def; >>>>> + >>>>> + return val; >>>>> +} >>>>> + >>>>> +static struct berval ** >>>>> +make_berval_array(long long value) >>>>> +{ >>>>> + struct berval **bvs; >>>>> + >>>>> + bvs = ch_calloc(2, struct berval*); >>>>> + bvs[0] = ch_malloc(struct berval); >>>>> + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); >>>>> + bvs[0]->bv_len = strlen(bvs[0]->bv_val); >>>>> + >>>>> + return bvs; >>>>> +} >>>>> + >>>>> +static LDAPMod * >>>>> +make_ldapmod(int op, const char *attr, long long value) >>>>> +{ >>>>> + LDAPMod *mod; >>>>> + >>>>> + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); >>>>> + mod->mod_op = op | LDAP_MOD_BVALUES; >>>>> + mod->mod_type = slapi_ch_strdup(attr); >>>>> + mod->mod_bvalues = make_berval_array(value); >>>>> + >>>>> + return mod; >>>>> +} >>>>> + >>>>> +static void >>>>> +convert_ldapmod_to_bval(LDAPMod *mod) >>>>> +{ >>>>> + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) >>>>> + return; >>>>> + >>>>> + mod->mod_op |= LDAP_MOD_BVALUES; >>>>> + >>>>> + if (mod->mod_values == NULL) { >>>>> + mod->mod_bvalues = NULL; >>>>> + return; >>>>> + } >>>>> + >>>>> + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { >>>>> + struct berval *bv = ch_malloc(struct berval); >>>>> + bv->bv_val = mod->mod_values[i]; >>>>> + bv->bv_len = strlen(bv->bv_val); >>>>> + mod->mod_bvalues[i] = bv; >>>>> + } >>>>> +} >>>>> + >>>>> +static counter >>>>> +get_counter(Slapi_Entry *entry, const char *attr) >>>>> +{ >>>>> + Slapi_Attr *sattr = NULL; >>>>> + >>>>> + return (counter) { >>>>> + slapi_entry_attr_find(entry, attr, &sattr) == 0, >>>>> + slapi_entry_attr_get_longlong(entry, attr) >>>>> + }; >>>>> +} >>>>> + >>>>> +static void >>>>> +berval_free_array(struct berval ***bvals) >>>>> +{ >>>>> + for (size_t i = 0; (*bvals)[i] != NULL; i++) { >>>>> + ch_free((*bvals)[i]->bv_val); >>>>> + ch_free((*bvals)[i]); >>>>> + } >>>>> + >>>>> + slapi_ch_free((void**) bvals); >>>>> +} >>>>> + >>>>> +static bool >>>>> +is_replication(Slapi_PBlock *pb) >>>>> +{ >>>>> + int repl = 0; >>>>> + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); >>>>> + return repl != 0; >>>>> +} >>>>> + >>>>> +static const char * >>>>> +get_attribute(Slapi_Entry *entry) >>>>> +{ >>>>> + static struct { >>>>> + const char *clss; >>>>> + const char *attr; >>>>> + } table[] = { >>>>> + { "ipatokenHOTP", "ipatokenHOTPcounter" }, >>>>> + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, >>>>> + { NULL, NULL } >>>>> + }; >>>>> + >>>>> + const char *attr = NULL; >>>>> + char **clsses = NULL; >>>>> + >>>>> + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); >>>>> + if (clsses == NULL) >>>>> + return NULL; >>>>> + >>>>> + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { >>>>> + for (size_t j = 0; attr == NULL && table[j].clss != NULL; >>>>> j++) { >>>>> + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) >>>>> + attr = table[j].attr; >>>>> + } >>>>> + } >>>>> + >>>>> + slapi_ch_array_free(clsses); >>>>> + return attr; >>>>> +} >>>> Can you put a comment here that explains what you are going to do in >>>> each cases in plain English ? This will help people in future figuring >>>> out if/how to modify the code or why something happens a specific way. >>>> It will also help the reviewer follow what is going on. >>>> >>>> >>>>> +static int >>>>> +preop_mod(Slapi_PBlock *pb) >>>>> +{ >>>>> + size_t count = 0, attrs = 0, extras = 0; >>>>> + Slapi_Entry *entry = NULL; >>>>> + const char *attr = NULL; >>>>> + LDAPMod **inmods = NULL; >>>>> + LDAPMod **mods = NULL; >>>>> + counter ctr, orig; >>>>> + >>>>> + /* Get the input values. */ >>>>> + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); >>>>> + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); >>>>> + if (entry == NULL || inmods == NULL) >>>>> + return 0; >>>>> + >>>>> + /* Get the attribute name. */ >>>>> + attr = get_attribute(entry); >>>>> + if (attr == NULL) >>>>> + return 0; /* Not a token. */ >>>>> + >>>>> + /* Count items. */ >>>>> + while (inmods != NULL && inmods[count] != NULL) { >>>> ^^ this one would read much better as: >>>> for (count = 0; inmods[count] != NULL; count++) { >>>> >>>> You do not need to check for insmods != NULL as you already check for >>>> it and return 0 a few lines above. >>>> >>>>> + LDAPMod *mod = inmods[count++]; >>>>> + >>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>>>> + continue; >>>>> + >>>>> + attrs++; >>>>> + switch (mod->mod_op & LDAP_MOD_OP) { >>>>> + case LDAP_MOD_REPLACE: >>>>> + case LDAP_MOD_INCREMENT: >>>>> + extras++; >>>>> + break; >>>>> + } >>>>> + } >>>>> + >>>>> + /* Not operating on the counter/watermark. */ >>>>> + if (attrs == 0) >>>>> + return 0; >>>>> + >>>>> + /* Get the counter. */ >>>>> + orig = ctr = get_counter(entry, attr); >>>>> + >>>>> + /* Filter the modify operations. */ >>>>> + mods = ch_calloc(count + extras + 1, LDAPMod*); >>>>> + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; >>>>> mods[j++] = inmods[i++]) { >>>> Please remove check for insmods != NULL, it is useless, and removing it >>>> will bring back the line under 80columns >>>> >>>>> + LDAPMod *mod = inmods[i]; >>>>> + >>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>>>> + continue; >>>>> + >>>>> + convert_ldapmod_to_bval(mod); >>>>> + >>>>> + switch (mod->mod_op & LDAP_MOD_OP) { >>>>> + case LDAP_MOD_DELETE: >>>>> + ctr.exists = false; >>>>> + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == >>>>> NULL) >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + >>>>> + if (is_replication(pb)) >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + >>>>> + if (mod->mod_bvalues == NULL) >>>>> + mod->mod_bvalues = make_berval_array(ctr.value); >>>>> + break; >>>> I am not sure I understand this segment, why are you touching the >>>> delete operation outside of a replication event ? >>>> Doesn't this defeat and admin tool trying to correctly delete/add to >>>> avoid races ? >>>> >>>>> + case LDAP_MOD_INCREMENT: >>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>>>> ctr.value); + >>>>> + ctr.value += get_value(mod, 1); >>>> uhmmm if you had an ADD followed by INCREMENT operation, would this >>>> cause the value to become value*2+1 instead of just value+1 ? >>>> >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + mod->mod_op &= ~LDAP_MOD_OP; >>>>> + mod->mod_op |= LDAP_MOD_ADD; >>>>> + mod->mod_bvalues = make_berval_array(ctr.value); >>>>> + break; >>>> uhmm why are you converting mod_increment in all cases ? (including >>>> replication) >>>> >>>>> + case LDAP_MOD_REPLACE: >>>>> + if (ctr.exists) >>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>>>> ctr.value); + >>>>> + mod->mod_op &= ~LDAP_MOD_OP; >>>>> + mod->mod_op |= LDAP_MOD_ADD; >>>> same question here, why are you converting a replace coming from >>>> replication into a delete/add ? >>>> >>>>> + case LDAP_MOD_ADD: >>>>> + ctr.value = get_value(mod, 0); >>>>> + ctr.exists = true; >>>>> + break; >>>>> + } >>>>> + } >>>>> + >>>>> + /* Set the modified operations. */ >>>>> + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); >>>>> + ch_free(inmods); >>>>> + >>>>> + /* Ensure we aren't deleting the counter. */ >>>>> + if (orig.exists && !ctr.exists) >>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>>>> + "Will not delete %s", attr); >>>>> + >>>>> + /* Ensure we aren't rolling back the counter. */ >>>>> + if (orig.value > ctr.value) >>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>>>> + "Will not decrement %s", attr); >>>>> + >>>>> + return 0; >>>>> +} >>>> see above about send_error(). >>>> >>>> I think what is needed most is the comment that explains the process >>>> at the to of the main function. >>>> >>>> Simo. >>> All of the above are fixed. >>> >>> Also, I have addressed Thierry's concern about putting the plugin in >>> betxnpreoperation by splitting the plugin into two phases: modification >>> and validation. Now all modifications occur in bepreoperation and all >>> validation occurs in betxnpreoperation. >>> >>> Additionally, I have new code to trigger a new replication in the case >>> where a validation error occurs and we are in a replication transaction. >>> Thus, when A attempts to push an old counter value to B, B will now >>> replicate the latest value back to A. >>> >>> Nathaniel >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Oct 7 17:26:41 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 07 Oct 2014 19:26:41 +0200 Subject: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns In-Reply-To: References: Message-ID: <54342251.6070304@redhat.com> On 07/10/14 15:58, Gabe Alford wrote: > Forgot to add patch. > > On Tue, Oct 7, 2014 at 7:58 AM, Gabe Alford > wrote: > > Hello, > > Fix for https://fedorahosted.org/freeipa/ticket/4613 > > Thanks, > > Gabe > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Thank you! I prefer to use python-dns >= 1.11.1, there are some DNSSEC fixes which we may use in tests. Could you send updated patch please? -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Tue Oct 7 17:34:04 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 7 Oct 2014 11:34:04 -0600 Subject: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns In-Reply-To: <54342251.6070304@redhat.com> References: <54342251.6070304@redhat.com> Message-ID: Done. Update patch to use python-dns >= 1.11.1 On Tue, Oct 7, 2014 at 11:26 AM, Martin Basti wrote: > On 07/10/14 15:58, Gabe Alford wrote: > > Forgot to add patch. > > On Tue, Oct 7, 2014 at 7:58 AM, Gabe Alford wrote: > >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/4613 >> >> Thanks, >> >> Gabe >> > > > > _______________________________________________ > Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel > > > Thank you! > > I prefer to use python-dns >= 1.11.1, there are some DNSSEC fixes which we > may use in tests. > > Could you send updated patch please? > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0034-2-Missing-requires-on-python-dns-in-spec-file.patch Type: text/x-patch Size: 1358 bytes Desc: not available URL: From npmccallum at redhat.com Tue Oct 7 17:48:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 07 Oct 2014 13:48:34 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <54341AD6.8080303@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <54341AD6.8080303@redhat.com> Message-ID: <1412704114.3308.2.camel@redhat.com> On Tue, 2014-10-07 at 18:54 +0200, thierry bordaz wrote: > On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: > > > Attached is the latest patch. I believe this includes all of our > > discussions up until this point. However, a few bits of additional > > information are needed. > > > > First, I have renamed the plugin to ipa-otp-counter. I believe all > > replay prevention work can land inside this plugin, so the name is > > appropriate. > > > > Second, I uncovered a bug in 389 which prevents me from validating the > > non-replication request in bepre. This is the reason for the additional > > betxnpre callback. If the upstream 389 bug is fixed, we can merge this > > check back into bepre. https://fedorahosted.org/389/ticket/47919 > > Hi Nathaniel, > > Just a rapid question about that dependency on > https://fedorahosted.org/389/ticket/47919. > Using txnpreop_mod you manage to workaround the DS issue. > Do you need a fix for the DS issue in 1.3.2 or can it be fixed > in a later version ? I would strongly prefer a fix ASAP. > thanks > thierry > > > > Third, I believe we are now handling replication correct. An error is > > never returned. When a replication would cause the counter to decrease, > > we remove all counter/watermark related mods from the operation. This > > will allow the replication to apply without decrementing the value. > > There is also a new bepost method which check to see if the replication > > was discarded (via CSN) while having a higher counter value. If so, we > > apply the higher counter value. > > > > Here is the scenario. Server X receives two quick authentications; > > replications A and B are sent to server Y. Before server Y can process > > server X's replications, an authentication is performed on server Y; > > replication C is sent to server X. The following logic holds true: > > * csnA < csnB < csnC > > * valueA = valueC, valueB > valueC > > > > When server X receives replication C, ipa-otp-counter will strip out all > > counter mod operations; applying the update but not the lower value. The > > value of replication B is retained. This is the correct behavior. > > > > When server Y processes replications A and B, ipa-otp-counter will > > detect that a higher value has a lower CSN and will manually set the > > higher value (in bepost). This initiates replication D, which is sent to > > server X. Here is the logic: > > * csnA < csnB < csnC < csnD > > * valueA = valueC, valueB = valueD, valueD > valueC > > > > Server X receives replication D. D has the highest CSN. It has the same > > value as replication B (server X's current value). Because the values > > are the same, ipa-otp-counter will strip all counter mod operations. > > This reduces counter write contention which might become a problem in > > N-way replication when N>2. > > > > On Fri, 2014-10-03 at 19:52 +0200, thierry bordaz wrote: > > > Hello Nathaniel, > > > > > > An additional comment about the patch. > > > > > > When the new value is detected to be invalid, it is fixed by a > > > repair operation (trigger_replication). > > > I did test it and it is fine to update, with an internal > > > operation, the same entry that is currently updated. > > > > > > Now if you apply the repair operation into a be_preop or a > > > betxn_preop, when it returns from preop the txn of the current > > > operation will overwrite the repaired value. > > > > > > An option is to register a bepost that checks the value from > > > the original entry (SLAPI_ENTRY_PRE_OP) and post entry > > > (SLAPI_ENTRY_POST_OP). Then this postop checks the > > > orginal/final value and can trigger the repair op. > > > This time being outside of the main operation txn, the repair > > > op will be applied. > > > > > > thanks > > > thierry > > > On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: > > > > > > > On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: > > > > > On Sun, 21 Sep 2014 22:33:47 -0400 > > > > > Nathaniel McCallum wrote: > > > > > > > > > > Comments inline. > > > > > > > > > > > + > > > > > > +#define ch_malloc(type) \ > > > > > > + (type*) slapi_ch_malloc(sizeof(type)) > > > > > > +#define ch_calloc(count, type) \ > > > > > > + (type*) slapi_ch_calloc(count, sizeof(type)) > > > > > > +#define ch_free(p) \ > > > > > > + slapi_ch_free((void**) &(p)) > > > > > please do not redefine slapi functions, it just makes it harder to know > > > > > what you used. > > > > > > > > > > > > > > > > +typedef struct { > > > > > > + bool exists; > > > > > > + long long value; > > > > > > +} counter; > > > > > please no typedefs of structures, use "struct counter { ... };" and > > > > > reference it as "struct counter" in the code. > > > > > > > > > > Btw, FWIW you could use a value of -1 to indicate non-existence of the > > > > > counter value, given counters can only be positive, this would avoid > > > > > the need for a struct. > > > > > > > > > > > +static int > > > > > > +send_error(Slapi_PBlock *pb, int rc, char *template, ...) > > > > > > +{ > > > > > > + va_list ap; > > > > > > + int res; > > > > > > + > > > > > > + va_start(ap, template); > > > > > > + res = vsnprintf(NULL, 0, template, ap); > > > > > > + va_end(ap); > > > > > > + > > > > > > + if (res > 0) { > > > > > > + char str[res + 1]; > > > > > > + > > > > > > + va_start(ap, template); > > > > > > + res = vsnprintf(str, sizeof(str), template, ap); > > > > > > + va_end(ap); > > > > > > + > > > > > > + if (res > 0) > > > > > > + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); > > > > > > + } > > > > > > + > > > > > > + if (res <= 0) > > > > > > + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); > > > > > > + > > > > > > + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); > > > > > > + return rc; > > > > > > +} > > > > > This function seem not really useful, you use send_error() only at the > > > > > end of one single function where you could have the classic scheme of > > > > > using a done: label and just use directly slapi_ch_smprintf. This would > > > > > remove the need to use vsnprintf and all the va_ machinery which is > > > > > more than 50% of this function. > > > > > > > > > > > > > > > > +static long long > > > > > > +get_value(const LDAPMod *mod, long long def) > > > > > > +{ > > > > > > + const struct berval *bv; > > > > > > + long long val; > > > > > > + > > > > > > + if (mod == NULL) > > > > > > + return def; > > > > > > + > > > > > > + if (mod->mod_vals.modv_bvals == NULL) > > > > > > + return def; > > > > > > + > > > > > > + bv = mod->mod_vals.modv_bvals[0]; > > > > > > + if (bv == NULL) > > > > > > + return def; > > > > > In general (here and elsewhere) I prefer to always use {} in if clauses. > > > > > I have been bitten enough time by people adding an instruction that > > > > > should be in the braces but forgot to add braces (defensive programming > > > > > style). But up to you. > > > > > > > > > > > + char buf[bv->bv_len + 1]; > > > > > > + memcpy(buf, bv->bv_val, bv->bv_len); > > > > > > + buf[sizeof(buf)-1] = '\0'; > > > > > > + > > > > > > + val = strtoll(buf, NULL, 10); > > > > > > + if (val == LLONG_MIN || val == LLONG_MAX) > > > > > > + return def; > > > > > > + > > > > > > + return val; > > > > > > +} > > > > > > + > > > > > > +static struct berval ** > > > > > > +make_berval_array(long long value) > > > > > > +{ > > > > > > + struct berval **bvs; > > > > > > + > > > > > > + bvs = ch_calloc(2, struct berval*); > > > > > > + bvs[0] = ch_malloc(struct berval); > > > > > > + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); > > > > > > + bvs[0]->bv_len = strlen(bvs[0]->bv_val); > > > > > > + > > > > > > + return bvs; > > > > > > +} > > > > > > + > > > > > > +static LDAPMod * > > > > > > +make_ldapmod(int op, const char *attr, long long value) > > > > > > +{ > > > > > > + LDAPMod *mod; > > > > > > + > > > > > > + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); > > > > > > + mod->mod_op = op | LDAP_MOD_BVALUES; > > > > > > + mod->mod_type = slapi_ch_strdup(attr); > > > > > > + mod->mod_bvalues = make_berval_array(value); > > > > > > + > > > > > > + return mod; > > > > > > +} > > > > > > + > > > > > > +static void > > > > > > +convert_ldapmod_to_bval(LDAPMod *mod) > > > > > > +{ > > > > > > + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) > > > > > > + return; > > > > > > + > > > > > > + mod->mod_op |= LDAP_MOD_BVALUES; > > > > > > + > > > > > > + if (mod->mod_values == NULL) { > > > > > > + mod->mod_bvalues = NULL; > > > > > > + return; > > > > > > + } > > > > > > + > > > > > > + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { > > > > > > + struct berval *bv = ch_malloc(struct berval); > > > > > > + bv->bv_val = mod->mod_values[i]; > > > > > > + bv->bv_len = strlen(bv->bv_val); > > > > > > + mod->mod_bvalues[i] = bv; > > > > > > + } > > > > > > +} > > > > > > + > > > > > > +static counter > > > > > > +get_counter(Slapi_Entry *entry, const char *attr) > > > > > > +{ > > > > > > + Slapi_Attr *sattr = NULL; > > > > > > + > > > > > > + return (counter) { > > > > > > + slapi_entry_attr_find(entry, attr, &sattr) == 0, > > > > > > + slapi_entry_attr_get_longlong(entry, attr) > > > > > > + }; > > > > > > +} > > > > > > + > > > > > > +static void > > > > > > +berval_free_array(struct berval ***bvals) > > > > > > +{ > > > > > > + for (size_t i = 0; (*bvals)[i] != NULL; i++) { > > > > > > + ch_free((*bvals)[i]->bv_val); > > > > > > + ch_free((*bvals)[i]); > > > > > > + } > > > > > > + > > > > > > + slapi_ch_free((void**) bvals); > > > > > > +} > > > > > > + > > > > > > +static bool > > > > > > +is_replication(Slapi_PBlock *pb) > > > > > > +{ > > > > > > + int repl = 0; > > > > > > + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); > > > > > > + return repl != 0; > > > > > > +} > > > > > > + > > > > > > +static const char * > > > > > > +get_attribute(Slapi_Entry *entry) > > > > > > +{ > > > > > > + static struct { > > > > > > + const char *clss; > > > > > > + const char *attr; > > > > > > + } table[] = { > > > > > > + { "ipatokenHOTP", "ipatokenHOTPcounter" }, > > > > > > + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, > > > > > > + { NULL, NULL } > > > > > > + }; > > > > > > + > > > > > > + const char *attr = NULL; > > > > > > + char **clsses = NULL; > > > > > > + > > > > > > + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); > > > > > > + if (clsses == NULL) > > > > > > + return NULL; > > > > > > + > > > > > > + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { > > > > > > + for (size_t j = 0; attr == NULL && table[j].clss != NULL; > > > > > > j++) { > > > > > > + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) > > > > > > + attr = table[j].attr; > > > > > > + } > > > > > > + } > > > > > > + > > > > > > + slapi_ch_array_free(clsses); > > > > > > + return attr; > > > > > > +} > > > > > Can you put a comment here that explains what you are going to do in > > > > > each cases in plain English ? This will help people in future figuring > > > > > out if/how to modify the code or why something happens a specific way. > > > > > It will also help the reviewer follow what is going on. > > > > > > > > > > > > > > > > +static int > > > > > > +preop_mod(Slapi_PBlock *pb) > > > > > > +{ > > > > > > + size_t count = 0, attrs = 0, extras = 0; > > > > > > + Slapi_Entry *entry = NULL; > > > > > > + const char *attr = NULL; > > > > > > + LDAPMod **inmods = NULL; > > > > > > + LDAPMod **mods = NULL; > > > > > > + counter ctr, orig; > > > > > > + > > > > > > + /* Get the input values. */ > > > > > > + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); > > > > > > + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); > > > > > > + if (entry == NULL || inmods == NULL) > > > > > > + return 0; > > > > > > + > > > > > > + /* Get the attribute name. */ > > > > > > + attr = get_attribute(entry); > > > > > > + if (attr == NULL) > > > > > > + return 0; /* Not a token. */ > > > > > > + > > > > > > + /* Count items. */ > > > > > > + while (inmods != NULL && inmods[count] != NULL) { > > > > > ^^ this one would read much better as: > > > > > for (count = 0; inmods[count] != NULL; count++) { > > > > > > > > > > You do not need to check for insmods != NULL as you already check for > > > > > it and return 0 a few lines above. > > > > > > > > > > > + LDAPMod *mod = inmods[count++]; > > > > > > + > > > > > > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > > > > > > + continue; > > > > > > + > > > > > > + attrs++; > > > > > > + switch (mod->mod_op & LDAP_MOD_OP) { > > > > > > + case LDAP_MOD_REPLACE: > > > > > > + case LDAP_MOD_INCREMENT: > > > > > > + extras++; > > > > > > + break; > > > > > > + } > > > > > > + } > > > > > > + > > > > > > + /* Not operating on the counter/watermark. */ > > > > > > + if (attrs == 0) > > > > > > + return 0; > > > > > > + > > > > > > + /* Get the counter. */ > > > > > > + orig = ctr = get_counter(entry, attr); > > > > > > + > > > > > > + /* Filter the modify operations. */ > > > > > > + mods = ch_calloc(count + extras + 1, LDAPMod*); > > > > > > + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; > > > > > > mods[j++] = inmods[i++]) { > > > > > Please remove check for insmods != NULL, it is useless, and removing it > > > > > will bring back the line under 80columns > > > > > > > > > > > + LDAPMod *mod = inmods[i]; > > > > > > + > > > > > > + if (PL_strcasecmp(mod->mod_type, attr) != 0) > > > > > > + continue; > > > > > > + > > > > > > + convert_ldapmod_to_bval(mod); > > > > > > + > > > > > > + switch (mod->mod_op & LDAP_MOD_OP) { > > > > > > + case LDAP_MOD_DELETE: > > > > > > + ctr.exists = false; > > > > > > + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == > > > > > > NULL) > > > > > > + berval_free_array(&mod->mod_bvalues); > > > > > > + > > > > > > + if (is_replication(pb)) > > > > > > + berval_free_array(&mod->mod_bvalues); > > > > > > + > > > > > > + if (mod->mod_bvalues == NULL) > > > > > > + mod->mod_bvalues = make_berval_array(ctr.value); > > > > > > + break; > > > > > I am not sure I understand this segment, why are you touching the > > > > > delete operation outside of a replication event ? > > > > > Doesn't this defeat and admin tool trying to correctly delete/add to > > > > > avoid races ? > > > > > > > > > > > + case LDAP_MOD_INCREMENT: > > > > > > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > > > > > > ctr.value); + > > > > > > + ctr.value += get_value(mod, 1); > > > > > uhmmm if you had an ADD followed by INCREMENT operation, would this > > > > > cause the value to become value*2+1 instead of just value+1 ? > > > > > > > > > > > + berval_free_array(&mod->mod_bvalues); > > > > > > + mod->mod_op &= ~LDAP_MOD_OP; > > > > > > + mod->mod_op |= LDAP_MOD_ADD; > > > > > > + mod->mod_bvalues = make_berval_array(ctr.value); > > > > > > + break; > > > > > uhmm why are you converting mod_increment in all cases ? (including > > > > > replication) > > > > > > > > > > > + case LDAP_MOD_REPLACE: > > > > > > + if (ctr.exists) > > > > > > + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > > > > > > ctr.value); + > > > > > > + mod->mod_op &= ~LDAP_MOD_OP; > > > > > > + mod->mod_op |= LDAP_MOD_ADD; > > > > > same question here, why are you converting a replace coming from > > > > > replication into a delete/add ? > > > > > > > > > > > + case LDAP_MOD_ADD: > > > > > > + ctr.value = get_value(mod, 0); > > > > > > + ctr.exists = true; > > > > > > + break; > > > > > > + } > > > > > > + } > > > > > > + > > > > > > + /* Set the modified operations. */ > > > > > > + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); > > > > > > + ch_free(inmods); > > > > > > + > > > > > > + /* Ensure we aren't deleting the counter. */ > > > > > > + if (orig.exists && !ctr.exists) > > > > > > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > > > > > > + "Will not delete %s", attr); > > > > > > + > > > > > > + /* Ensure we aren't rolling back the counter. */ > > > > > > + if (orig.value > ctr.value) > > > > > > + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > > > > > > + "Will not decrement %s", attr); > > > > > > + > > > > > > + return 0; > > > > > > +} > > > > > see above about send_error(). > > > > > > > > > > I think what is needed most is the comment that explains the process > > > > > at the to of the main function. > > > > > > > > > > Simo. > > > > All of the above are fixed. > > > > > > > > Also, I have addressed Thierry's concern about putting the plugin in > > > > betxnpreoperation by splitting the plugin into two phases: modification > > > > and validation. Now all modifications occur in bepreoperation and all > > > > validation occurs in betxnpreoperation. > > > > > > > > Additionally, I have new code to trigger a new replication in the case > > > > where a validation error occurs and we are in a replication transaction. > > > > Thus, when A attempts to push an old counter value to B, B will now > > > > replicate the latest value back to A. > > > > > > > > Nathaniel > > > > > From nhosoi at redhat.com Tue Oct 7 17:52:03 2014 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 07 Oct 2014 10:52:03 -0700 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412704114.3308.2.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <54341AD6.8080303@redhat.com> <1412704114.3308.2.camel@redhat.com> Message-ID: <54342843.8010301@redhat.com> On 2014/10/07 10:48, Nathaniel McCallum wrote: > On Tue, 2014-10-07 at 18:54 +0200, thierry bordaz wrote: >> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: >> >>> Attached is the latest patch. I believe this includes all of our >>> discussions up until this point. However, a few bits of additional >>> information are needed. >>> >>> First, I have renamed the plugin to ipa-otp-counter. I believe all >>> replay prevention work can land inside this plugin, so the name is >>> appropriate. >>> >>> Second, I uncovered a bug in 389 which prevents me from validating the >>> non-replication request in bepre. This is the reason for the additional >>> betxnpre callback. If the upstream 389 bug is fixed, we can merge this >>> check back into bepre. https://fedorahosted.org/389/ticket/47919 >> Hi Nathaniel, >> >> Just a rapid question about that dependency on >> https://fedorahosted.org/389/ticket/47919. >> Using txnpreop_mod you manage to workaround the DS issue. >> Do you need a fix for the DS issue in 1.3.2 or can it be fixed >> in a later version ? > I would strongly prefer a fix ASAP. Thanks, Nathaniel, Do you need the fix just in 389-ds-base-1.3.3.x on F21 and newer? Or any other versions, e.g., 1.3.2 on F20, 1.3.3.1-x on RHEL-7.1, etc... ? --noriko > >> thanks >> thierry >>> Third, I believe we are now handling replication correct. An error is >>> never returned. When a replication would cause the counter to decrease, >>> we remove all counter/watermark related mods from the operation. This >>> will allow the replication to apply without decrementing the value. >>> There is also a new bepost method which check to see if the replication >>> was discarded (via CSN) while having a higher counter value. If so, we >>> apply the higher counter value. >>> >>> Here is the scenario. Server X receives two quick authentications; >>> replications A and B are sent to server Y. Before server Y can process >>> server X's replications, an authentication is performed on server Y; >>> replication C is sent to server X. The following logic holds true: >>> * csnA < csnB < csnC >>> * valueA = valueC, valueB > valueC >>> >>> When server X receives replication C, ipa-otp-counter will strip out all >>> counter mod operations; applying the update but not the lower value. The >>> value of replication B is retained. This is the correct behavior. >>> >>> When server Y processes replications A and B, ipa-otp-counter will >>> detect that a higher value has a lower CSN and will manually set the >>> higher value (in bepost). This initiates replication D, which is sent to >>> server X. Here is the logic: >>> * csnA < csnB < csnC < csnD >>> * valueA = valueC, valueB = valueD, valueD > valueC >>> >>> Server X receives replication D. D has the highest CSN. It has the same >>> value as replication B (server X's current value). Because the values >>> are the same, ipa-otp-counter will strip all counter mod operations. >>> This reduces counter write contention which might become a problem in >>> N-way replication when N>2. >>> >>> On Fri, 2014-10-03 at 19:52 +0200, thierry bordaz wrote: >>>> Hello Nathaniel, >>>> >>>> An additional comment about the patch. >>>> >>>> When the new value is detected to be invalid, it is fixed by a >>>> repair operation (trigger_replication). >>>> I did test it and it is fine to update, with an internal >>>> operation, the same entry that is currently updated. >>>> >>>> Now if you apply the repair operation into a be_preop or a >>>> betxn_preop, when it returns from preop the txn of the current >>>> operation will overwrite the repaired value. >>>> >>>> An option is to register a bepost that checks the value from >>>> the original entry (SLAPI_ENTRY_PRE_OP) and post entry >>>> (SLAPI_ENTRY_POST_OP). Then this postop checks the >>>> orginal/final value and can trigger the repair op. >>>> This time being outside of the main operation txn, the repair >>>> op will be applied. >>>> >>>> thanks >>>> thierry >>>> On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: >>>> >>>>> On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: >>>>>> On Sun, 21 Sep 2014 22:33:47 -0400 >>>>>> Nathaniel McCallum wrote: >>>>>> >>>>>> Comments inline. >>>>>> >>>>>>> + >>>>>>> +#define ch_malloc(type) \ >>>>>>> + (type*) slapi_ch_malloc(sizeof(type)) >>>>>>> +#define ch_calloc(count, type) \ >>>>>>> + (type*) slapi_ch_calloc(count, sizeof(type)) >>>>>>> +#define ch_free(p) \ >>>>>>> + slapi_ch_free((void**) &(p)) >>>>>> please do not redefine slapi functions, it just makes it harder to know >>>>>> what you used. >>>>>> >>>>>> >>>>>>> +typedef struct { >>>>>>> + bool exists; >>>>>>> + long long value; >>>>>>> +} counter; >>>>>> please no typedefs of structures, use "struct counter { ... };" and >>>>>> reference it as "struct counter" in the code. >>>>>> >>>>>> Btw, FWIW you could use a value of -1 to indicate non-existence of the >>>>>> counter value, given counters can only be positive, this would avoid >>>>>> the need for a struct. >>>>>> >>>>>>> +static int >>>>>>> +send_error(Slapi_PBlock *pb, int rc, char *template, ...) >>>>>>> +{ >>>>>>> + va_list ap; >>>>>>> + int res; >>>>>>> + >>>>>>> + va_start(ap, template); >>>>>>> + res = vsnprintf(NULL, 0, template, ap); >>>>>>> + va_end(ap); >>>>>>> + >>>>>>> + if (res > 0) { >>>>>>> + char str[res + 1]; >>>>>>> + >>>>>>> + va_start(ap, template); >>>>>>> + res = vsnprintf(str, sizeof(str), template, ap); >>>>>>> + va_end(ap); >>>>>>> + >>>>>>> + if (res > 0) >>>>>>> + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); >>>>>>> + } >>>>>>> + >>>>>>> + if (res <= 0) >>>>>>> + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); >>>>>>> + >>>>>>> + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); >>>>>>> + return rc; >>>>>>> +} >>>>>> This function seem not really useful, you use send_error() only at the >>>>>> end of one single function where you could have the classic scheme of >>>>>> using a done: label and just use directly slapi_ch_smprintf. This would >>>>>> remove the need to use vsnprintf and all the va_ machinery which is >>>>>> more than 50% of this function. >>>>>> >>>>>> >>>>>>> +static long long >>>>>>> +get_value(const LDAPMod *mod, long long def) >>>>>>> +{ >>>>>>> + const struct berval *bv; >>>>>>> + long long val; >>>>>>> + >>>>>>> + if (mod == NULL) >>>>>>> + return def; >>>>>>> + >>>>>>> + if (mod->mod_vals.modv_bvals == NULL) >>>>>>> + return def; >>>>>>> + >>>>>>> + bv = mod->mod_vals.modv_bvals[0]; >>>>>>> + if (bv == NULL) >>>>>>> + return def; >>>>>> In general (here and elsewhere) I prefer to always use {} in if clauses. >>>>>> I have been bitten enough time by people adding an instruction that >>>>>> should be in the braces but forgot to add braces (defensive programming >>>>>> style). But up to you. >>>>>> >>>>>>> + char buf[bv->bv_len + 1]; >>>>>>> + memcpy(buf, bv->bv_val, bv->bv_len); >>>>>>> + buf[sizeof(buf)-1] = '\0'; >>>>>>> + >>>>>>> + val = strtoll(buf, NULL, 10); >>>>>>> + if (val == LLONG_MIN || val == LLONG_MAX) >>>>>>> + return def; >>>>>>> + >>>>>>> + return val; >>>>>>> +} >>>>>>> + >>>>>>> +static struct berval ** >>>>>>> +make_berval_array(long long value) >>>>>>> +{ >>>>>>> + struct berval **bvs; >>>>>>> + >>>>>>> + bvs = ch_calloc(2, struct berval*); >>>>>>> + bvs[0] = ch_malloc(struct berval); >>>>>>> + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); >>>>>>> + bvs[0]->bv_len = strlen(bvs[0]->bv_val); >>>>>>> + >>>>>>> + return bvs; >>>>>>> +} >>>>>>> + >>>>>>> +static LDAPMod * >>>>>>> +make_ldapmod(int op, const char *attr, long long value) >>>>>>> +{ >>>>>>> + LDAPMod *mod; >>>>>>> + >>>>>>> + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); >>>>>>> + mod->mod_op = op | LDAP_MOD_BVALUES; >>>>>>> + mod->mod_type = slapi_ch_strdup(attr); >>>>>>> + mod->mod_bvalues = make_berval_array(value); >>>>>>> + >>>>>>> + return mod; >>>>>>> +} >>>>>>> + >>>>>>> +static void >>>>>>> +convert_ldapmod_to_bval(LDAPMod *mod) >>>>>>> +{ >>>>>>> + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) >>>>>>> + return; >>>>>>> + >>>>>>> + mod->mod_op |= LDAP_MOD_BVALUES; >>>>>>> + >>>>>>> + if (mod->mod_values == NULL) { >>>>>>> + mod->mod_bvalues = NULL; >>>>>>> + return; >>>>>>> + } >>>>>>> + >>>>>>> + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { >>>>>>> + struct berval *bv = ch_malloc(struct berval); >>>>>>> + bv->bv_val = mod->mod_values[i]; >>>>>>> + bv->bv_len = strlen(bv->bv_val); >>>>>>> + mod->mod_bvalues[i] = bv; >>>>>>> + } >>>>>>> +} >>>>>>> + >>>>>>> +static counter >>>>>>> +get_counter(Slapi_Entry *entry, const char *attr) >>>>>>> +{ >>>>>>> + Slapi_Attr *sattr = NULL; >>>>>>> + >>>>>>> + return (counter) { >>>>>>> + slapi_entry_attr_find(entry, attr, &sattr) == 0, >>>>>>> + slapi_entry_attr_get_longlong(entry, attr) >>>>>>> + }; >>>>>>> +} >>>>>>> + >>>>>>> +static void >>>>>>> +berval_free_array(struct berval ***bvals) >>>>>>> +{ >>>>>>> + for (size_t i = 0; (*bvals)[i] != NULL; i++) { >>>>>>> + ch_free((*bvals)[i]->bv_val); >>>>>>> + ch_free((*bvals)[i]); >>>>>>> + } >>>>>>> + >>>>>>> + slapi_ch_free((void**) bvals); >>>>>>> +} >>>>>>> + >>>>>>> +static bool >>>>>>> +is_replication(Slapi_PBlock *pb) >>>>>>> +{ >>>>>>> + int repl = 0; >>>>>>> + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); >>>>>>> + return repl != 0; >>>>>>> +} >>>>>>> + >>>>>>> +static const char * >>>>>>> +get_attribute(Slapi_Entry *entry) >>>>>>> +{ >>>>>>> + static struct { >>>>>>> + const char *clss; >>>>>>> + const char *attr; >>>>>>> + } table[] = { >>>>>>> + { "ipatokenHOTP", "ipatokenHOTPcounter" }, >>>>>>> + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, >>>>>>> + { NULL, NULL } >>>>>>> + }; >>>>>>> + >>>>>>> + const char *attr = NULL; >>>>>>> + char **clsses = NULL; >>>>>>> + >>>>>>> + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); >>>>>>> + if (clsses == NULL) >>>>>>> + return NULL; >>>>>>> + >>>>>>> + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { >>>>>>> + for (size_t j = 0; attr == NULL && table[j].clss != NULL; >>>>>>> j++) { >>>>>>> + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) >>>>>>> + attr = table[j].attr; >>>>>>> + } >>>>>>> + } >>>>>>> + >>>>>>> + slapi_ch_array_free(clsses); >>>>>>> + return attr; >>>>>>> +} >>>>>> Can you put a comment here that explains what you are going to do in >>>>>> each cases in plain English ? This will help people in future figuring >>>>>> out if/how to modify the code or why something happens a specific way. >>>>>> It will also help the reviewer follow what is going on. >>>>>> >>>>>> >>>>>>> +static int >>>>>>> +preop_mod(Slapi_PBlock *pb) >>>>>>> +{ >>>>>>> + size_t count = 0, attrs = 0, extras = 0; >>>>>>> + Slapi_Entry *entry = NULL; >>>>>>> + const char *attr = NULL; >>>>>>> + LDAPMod **inmods = NULL; >>>>>>> + LDAPMod **mods = NULL; >>>>>>> + counter ctr, orig; >>>>>>> + >>>>>>> + /* Get the input values. */ >>>>>>> + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); >>>>>>> + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); >>>>>>> + if (entry == NULL || inmods == NULL) >>>>>>> + return 0; >>>>>>> + >>>>>>> + /* Get the attribute name. */ >>>>>>> + attr = get_attribute(entry); >>>>>>> + if (attr == NULL) >>>>>>> + return 0; /* Not a token. */ >>>>>>> + >>>>>>> + /* Count items. */ >>>>>>> + while (inmods != NULL && inmods[count] != NULL) { >>>>>> ^^ this one would read much better as: >>>>>> for (count = 0; inmods[count] != NULL; count++) { >>>>>> >>>>>> You do not need to check for insmods != NULL as you already check for >>>>>> it and return 0 a few lines above. >>>>>> >>>>>>> + LDAPMod *mod = inmods[count++]; >>>>>>> + >>>>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>>>>>> + continue; >>>>>>> + >>>>>>> + attrs++; >>>>>>> + switch (mod->mod_op & LDAP_MOD_OP) { >>>>>>> + case LDAP_MOD_REPLACE: >>>>>>> + case LDAP_MOD_INCREMENT: >>>>>>> + extras++; >>>>>>> + break; >>>>>>> + } >>>>>>> + } >>>>>>> + >>>>>>> + /* Not operating on the counter/watermark. */ >>>>>>> + if (attrs == 0) >>>>>>> + return 0; >>>>>>> + >>>>>>> + /* Get the counter. */ >>>>>>> + orig = ctr = get_counter(entry, attr); >>>>>>> + >>>>>>> + /* Filter the modify operations. */ >>>>>>> + mods = ch_calloc(count + extras + 1, LDAPMod*); >>>>>>> + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; >>>>>>> mods[j++] = inmods[i++]) { >>>>>> Please remove check for insmods != NULL, it is useless, and removing it >>>>>> will bring back the line under 80columns >>>>>> >>>>>>> + LDAPMod *mod = inmods[i]; >>>>>>> + >>>>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>>>>>> + continue; >>>>>>> + >>>>>>> + convert_ldapmod_to_bval(mod); >>>>>>> + >>>>>>> + switch (mod->mod_op & LDAP_MOD_OP) { >>>>>>> + case LDAP_MOD_DELETE: >>>>>>> + ctr.exists = false; >>>>>>> + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == >>>>>>> NULL) >>>>>>> + berval_free_array(&mod->mod_bvalues); >>>>>>> + >>>>>>> + if (is_replication(pb)) >>>>>>> + berval_free_array(&mod->mod_bvalues); >>>>>>> + >>>>>>> + if (mod->mod_bvalues == NULL) >>>>>>> + mod->mod_bvalues = make_berval_array(ctr.value); >>>>>>> + break; >>>>>> I am not sure I understand this segment, why are you touching the >>>>>> delete operation outside of a replication event ? >>>>>> Doesn't this defeat and admin tool trying to correctly delete/add to >>>>>> avoid races ? >>>>>> >>>>>>> + case LDAP_MOD_INCREMENT: >>>>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>>>>>> ctr.value); + >>>>>>> + ctr.value += get_value(mod, 1); >>>>>> uhmmm if you had an ADD followed by INCREMENT operation, would this >>>>>> cause the value to become value*2+1 instead of just value+1 ? >>>>>> >>>>>>> + berval_free_array(&mod->mod_bvalues); >>>>>>> + mod->mod_op &= ~LDAP_MOD_OP; >>>>>>> + mod->mod_op |= LDAP_MOD_ADD; >>>>>>> + mod->mod_bvalues = make_berval_array(ctr.value); >>>>>>> + break; >>>>>> uhmm why are you converting mod_increment in all cases ? (including >>>>>> replication) >>>>>> >>>>>>> + case LDAP_MOD_REPLACE: >>>>>>> + if (ctr.exists) >>>>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>>>>>> ctr.value); + >>>>>>> + mod->mod_op &= ~LDAP_MOD_OP; >>>>>>> + mod->mod_op |= LDAP_MOD_ADD; >>>>>> same question here, why are you converting a replace coming from >>>>>> replication into a delete/add ? >>>>>> >>>>>>> + case LDAP_MOD_ADD: >>>>>>> + ctr.value = get_value(mod, 0); >>>>>>> + ctr.exists = true; >>>>>>> + break; >>>>>>> + } >>>>>>> + } >>>>>>> + >>>>>>> + /* Set the modified operations. */ >>>>>>> + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); >>>>>>> + ch_free(inmods); >>>>>>> + >>>>>>> + /* Ensure we aren't deleting the counter. */ >>>>>>> + if (orig.exists && !ctr.exists) >>>>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>>>>>> + "Will not delete %s", attr); >>>>>>> + >>>>>>> + /* Ensure we aren't rolling back the counter. */ >>>>>>> + if (orig.value > ctr.value) >>>>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>>>>>> + "Will not decrement %s", attr); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>> see above about send_error(). >>>>>> >>>>>> I think what is needed most is the comment that explains the process >>>>>> at the to of the main function. >>>>>> >>>>>> Simo. >>>>> All of the above are fixed. >>>>> >>>>> Also, I have addressed Thierry's concern about putting the plugin in >>>>> betxnpreoperation by splitting the plugin into two phases: modification >>>>> and validation. Now all modifications occur in bepreoperation and all >>>>> validation occurs in betxnpreoperation. >>>>> >>>>> Additionally, I have new code to trigger a new replication in the case >>>>> where a validation error occurs and we are in a replication transaction. >>>>> Thus, when A attempts to push an old counter value to B, B will now >>>>> replicate the latest value back to A. >>>>> >>>>> Nathaniel >>>>> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From npmccallum at redhat.com Tue Oct 7 18:48:50 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 07 Oct 2014 14:48:50 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <54342843.8010301@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <54341AD6.8080303@redhat.com> <1412704114.3308.2.camel@redhat.com> <54342843.8010301@redhat.com> Message-ID: <1412707730.3308.3.camel@redhat.com> On Tue, 2014-10-07 at 10:52 -0700, Noriko Hosoi wrote: > On 2014/10/07 10:48, Nathaniel McCallum wrote: > > On Tue, 2014-10-07 at 18:54 +0200, thierry bordaz wrote: > >> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: > >> > >>> Attached is the latest patch. I believe this includes all of our > >>> discussions up until this point. However, a few bits of additional > >>> information are needed. > >>> > >>> First, I have renamed the plugin to ipa-otp-counter. I believe all > >>> replay prevention work can land inside this plugin, so the name is > >>> appropriate. > >>> > >>> Second, I uncovered a bug in 389 which prevents me from validating the > >>> non-replication request in bepre. This is the reason for the additional > >>> betxnpre callback. If the upstream 389 bug is fixed, we can merge this > >>> check back into bepre. https://fedorahosted.org/389/ticket/47919 > >> Hi Nathaniel, > >> > >> Just a rapid question about that dependency on > >> https://fedorahosted.org/389/ticket/47919. > >> Using txnpreop_mod you manage to workaround the DS issue. > >> Do you need a fix for the DS issue in 1.3.2 or can it be fixed > >> in a later version ? > > I would strongly prefer a fix ASAP. > Thanks, Nathaniel, > Do you need the fix just in 389-ds-base-1.3.3.x on F21 and newer? Or any > other versions, e.g., 1.3.2 on F20, 1.3.3.1-x on RHEL-7.1, etc... ? I think we are just shipping 4.1 on F21. Someone please correct me if I'm wrong. > --noriko > > > >> thanks > >> thierry > >>> Third, I believe we are now handling replication correct. An error is > >>> never returned. When a replication would cause the counter to decrease, > >>> we remove all counter/watermark related mods from the operation. This > >>> will allow the replication to apply without decrementing the value. > >>> There is also a new bepost method which check to see if the replication > >>> was discarded (via CSN) while having a higher counter value. If so, we > >>> apply the higher counter value. > >>> > >>> Here is the scenario. Server X receives two quick authentications; > >>> replications A and B are sent to server Y. Before server Y can process > >>> server X's replications, an authentication is performed on server Y; > >>> replication C is sent to server X. The following logic holds true: > >>> * csnA < csnB < csnC > >>> * valueA = valueC, valueB > valueC > >>> > >>> When server X receives replication C, ipa-otp-counter will strip out all > >>> counter mod operations; applying the update but not the lower value. The > >>> value of replication B is retained. This is the correct behavior. > >>> > >>> When server Y processes replications A and B, ipa-otp-counter will > >>> detect that a higher value has a lower CSN and will manually set the > >>> higher value (in bepost). This initiates replication D, which is sent to > >>> server X. Here is the logic: > >>> * csnA < csnB < csnC < csnD > >>> * valueA = valueC, valueB = valueD, valueD > valueC > >>> > >>> Server X receives replication D. D has the highest CSN. It has the same > >>> value as replication B (server X's current value). Because the values > >>> are the same, ipa-otp-counter will strip all counter mod operations. > >>> This reduces counter write contention which might become a problem in > >>> N-way replication when N>2. > >>> > >>> On Fri, 2014-10-03 at 19:52 +0200, thierry bordaz wrote: > >>>> Hello Nathaniel, > >>>> > >>>> An additional comment about the patch. > >>>> > >>>> When the new value is detected to be invalid, it is fixed by a > >>>> repair operation (trigger_replication). > >>>> I did test it and it is fine to update, with an internal > >>>> operation, the same entry that is currently updated. > >>>> > >>>> Now if you apply the repair operation into a be_preop or a > >>>> betxn_preop, when it returns from preop the txn of the current > >>>> operation will overwrite the repaired value. > >>>> > >>>> An option is to register a bepost that checks the value from > >>>> the original entry (SLAPI_ENTRY_PRE_OP) and post entry > >>>> (SLAPI_ENTRY_POST_OP). Then this postop checks the > >>>> orginal/final value and can trigger the repair op. > >>>> This time being outside of the main operation txn, the repair > >>>> op will be applied. > >>>> > >>>> thanks > >>>> thierry > >>>> On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: > >>>> > >>>>> On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: > >>>>>> On Sun, 21 Sep 2014 22:33:47 -0400 > >>>>>> Nathaniel McCallum wrote: > >>>>>> > >>>>>> Comments inline. > >>>>>> > >>>>>>> + > >>>>>>> +#define ch_malloc(type) \ > >>>>>>> + (type*) slapi_ch_malloc(sizeof(type)) > >>>>>>> +#define ch_calloc(count, type) \ > >>>>>>> + (type*) slapi_ch_calloc(count, sizeof(type)) > >>>>>>> +#define ch_free(p) \ > >>>>>>> + slapi_ch_free((void**) &(p)) > >>>>>> please do not redefine slapi functions, it just makes it harder to know > >>>>>> what you used. > >>>>>> > >>>>>> > >>>>>>> +typedef struct { > >>>>>>> + bool exists; > >>>>>>> + long long value; > >>>>>>> +} counter; > >>>>>> please no typedefs of structures, use "struct counter { ... };" and > >>>>>> reference it as "struct counter" in the code. > >>>>>> > >>>>>> Btw, FWIW you could use a value of -1 to indicate non-existence of the > >>>>>> counter value, given counters can only be positive, this would avoid > >>>>>> the need for a struct. > >>>>>> > >>>>>>> +static int > >>>>>>> +send_error(Slapi_PBlock *pb, int rc, char *template, ...) > >>>>>>> +{ > >>>>>>> + va_list ap; > >>>>>>> + int res; > >>>>>>> + > >>>>>>> + va_start(ap, template); > >>>>>>> + res = vsnprintf(NULL, 0, template, ap); > >>>>>>> + va_end(ap); > >>>>>>> + > >>>>>>> + if (res > 0) { > >>>>>>> + char str[res + 1]; > >>>>>>> + > >>>>>>> + va_start(ap, template); > >>>>>>> + res = vsnprintf(str, sizeof(str), template, ap); > >>>>>>> + va_end(ap); > >>>>>>> + > >>>>>>> + if (res > 0) > >>>>>>> + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); > >>>>>>> + } > >>>>>>> + > >>>>>>> + if (res <= 0) > >>>>>>> + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); > >>>>>>> + > >>>>>>> + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); > >>>>>>> + return rc; > >>>>>>> +} > >>>>>> This function seem not really useful, you use send_error() only at the > >>>>>> end of one single function where you could have the classic scheme of > >>>>>> using a done: label and just use directly slapi_ch_smprintf. This would > >>>>>> remove the need to use vsnprintf and all the va_ machinery which is > >>>>>> more than 50% of this function. > >>>>>> > >>>>>> > >>>>>>> +static long long > >>>>>>> +get_value(const LDAPMod *mod, long long def) > >>>>>>> +{ > >>>>>>> + const struct berval *bv; > >>>>>>> + long long val; > >>>>>>> + > >>>>>>> + if (mod == NULL) > >>>>>>> + return def; > >>>>>>> + > >>>>>>> + if (mod->mod_vals.modv_bvals == NULL) > >>>>>>> + return def; > >>>>>>> + > >>>>>>> + bv = mod->mod_vals.modv_bvals[0]; > >>>>>>> + if (bv == NULL) > >>>>>>> + return def; > >>>>>> In general (here and elsewhere) I prefer to always use {} in if clauses. > >>>>>> I have been bitten enough time by people adding an instruction that > >>>>>> should be in the braces but forgot to add braces (defensive programming > >>>>>> style). But up to you. > >>>>>> > >>>>>>> + char buf[bv->bv_len + 1]; > >>>>>>> + memcpy(buf, bv->bv_val, bv->bv_len); > >>>>>>> + buf[sizeof(buf)-1] = '\0'; > >>>>>>> + > >>>>>>> + val = strtoll(buf, NULL, 10); > >>>>>>> + if (val == LLONG_MIN || val == LLONG_MAX) > >>>>>>> + return def; > >>>>>>> + > >>>>>>> + return val; > >>>>>>> +} > >>>>>>> + > >>>>>>> +static struct berval ** > >>>>>>> +make_berval_array(long long value) > >>>>>>> +{ > >>>>>>> + struct berval **bvs; > >>>>>>> + > >>>>>>> + bvs = ch_calloc(2, struct berval*); > >>>>>>> + bvs[0] = ch_malloc(struct berval); > >>>>>>> + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); > >>>>>>> + bvs[0]->bv_len = strlen(bvs[0]->bv_val); > >>>>>>> + > >>>>>>> + return bvs; > >>>>>>> +} > >>>>>>> + > >>>>>>> +static LDAPMod * > >>>>>>> +make_ldapmod(int op, const char *attr, long long value) > >>>>>>> +{ > >>>>>>> + LDAPMod *mod; > >>>>>>> + > >>>>>>> + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); > >>>>>>> + mod->mod_op = op | LDAP_MOD_BVALUES; > >>>>>>> + mod->mod_type = slapi_ch_strdup(attr); > >>>>>>> + mod->mod_bvalues = make_berval_array(value); > >>>>>>> + > >>>>>>> + return mod; > >>>>>>> +} > >>>>>>> + > >>>>>>> +static void > >>>>>>> +convert_ldapmod_to_bval(LDAPMod *mod) > >>>>>>> +{ > >>>>>>> + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) > >>>>>>> + return; > >>>>>>> + > >>>>>>> + mod->mod_op |= LDAP_MOD_BVALUES; > >>>>>>> + > >>>>>>> + if (mod->mod_values == NULL) { > >>>>>>> + mod->mod_bvalues = NULL; > >>>>>>> + return; > >>>>>>> + } > >>>>>>> + > >>>>>>> + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { > >>>>>>> + struct berval *bv = ch_malloc(struct berval); > >>>>>>> + bv->bv_val = mod->mod_values[i]; > >>>>>>> + bv->bv_len = strlen(bv->bv_val); > >>>>>>> + mod->mod_bvalues[i] = bv; > >>>>>>> + } > >>>>>>> +} > >>>>>>> + > >>>>>>> +static counter > >>>>>>> +get_counter(Slapi_Entry *entry, const char *attr) > >>>>>>> +{ > >>>>>>> + Slapi_Attr *sattr = NULL; > >>>>>>> + > >>>>>>> + return (counter) { > >>>>>>> + slapi_entry_attr_find(entry, attr, &sattr) == 0, > >>>>>>> + slapi_entry_attr_get_longlong(entry, attr) > >>>>>>> + }; > >>>>>>> +} > >>>>>>> + > >>>>>>> +static void > >>>>>>> +berval_free_array(struct berval ***bvals) > >>>>>>> +{ > >>>>>>> + for (size_t i = 0; (*bvals)[i] != NULL; i++) { > >>>>>>> + ch_free((*bvals)[i]->bv_val); > >>>>>>> + ch_free((*bvals)[i]); > >>>>>>> + } > >>>>>>> + > >>>>>>> + slapi_ch_free((void**) bvals); > >>>>>>> +} > >>>>>>> + > >>>>>>> +static bool > >>>>>>> +is_replication(Slapi_PBlock *pb) > >>>>>>> +{ > >>>>>>> + int repl = 0; > >>>>>>> + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); > >>>>>>> + return repl != 0; > >>>>>>> +} > >>>>>>> + > >>>>>>> +static const char * > >>>>>>> +get_attribute(Slapi_Entry *entry) > >>>>>>> +{ > >>>>>>> + static struct { > >>>>>>> + const char *clss; > >>>>>>> + const char *attr; > >>>>>>> + } table[] = { > >>>>>>> + { "ipatokenHOTP", "ipatokenHOTPcounter" }, > >>>>>>> + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, > >>>>>>> + { NULL, NULL } > >>>>>>> + }; > >>>>>>> + > >>>>>>> + const char *attr = NULL; > >>>>>>> + char **clsses = NULL; > >>>>>>> + > >>>>>>> + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); > >>>>>>> + if (clsses == NULL) > >>>>>>> + return NULL; > >>>>>>> + > >>>>>>> + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { > >>>>>>> + for (size_t j = 0; attr == NULL && table[j].clss != NULL; > >>>>>>> j++) { > >>>>>>> + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) > >>>>>>> + attr = table[j].attr; > >>>>>>> + } > >>>>>>> + } > >>>>>>> + > >>>>>>> + slapi_ch_array_free(clsses); > >>>>>>> + return attr; > >>>>>>> +} > >>>>>> Can you put a comment here that explains what you are going to do in > >>>>>> each cases in plain English ? This will help people in future figuring > >>>>>> out if/how to modify the code or why something happens a specific way. > >>>>>> It will also help the reviewer follow what is going on. > >>>>>> > >>>>>> > >>>>>>> +static int > >>>>>>> +preop_mod(Slapi_PBlock *pb) > >>>>>>> +{ > >>>>>>> + size_t count = 0, attrs = 0, extras = 0; > >>>>>>> + Slapi_Entry *entry = NULL; > >>>>>>> + const char *attr = NULL; > >>>>>>> + LDAPMod **inmods = NULL; > >>>>>>> + LDAPMod **mods = NULL; > >>>>>>> + counter ctr, orig; > >>>>>>> + > >>>>>>> + /* Get the input values. */ > >>>>>>> + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); > >>>>>>> + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); > >>>>>>> + if (entry == NULL || inmods == NULL) > >>>>>>> + return 0; > >>>>>>> + > >>>>>>> + /* Get the attribute name. */ > >>>>>>> + attr = get_attribute(entry); > >>>>>>> + if (attr == NULL) > >>>>>>> + return 0; /* Not a token. */ > >>>>>>> + > >>>>>>> + /* Count items. */ > >>>>>>> + while (inmods != NULL && inmods[count] != NULL) { > >>>>>> ^^ this one would read much better as: > >>>>>> for (count = 0; inmods[count] != NULL; count++) { > >>>>>> > >>>>>> You do not need to check for insmods != NULL as you already check for > >>>>>> it and return 0 a few lines above. > >>>>>> > >>>>>>> + LDAPMod *mod = inmods[count++]; > >>>>>>> + > >>>>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) > >>>>>>> + continue; > >>>>>>> + > >>>>>>> + attrs++; > >>>>>>> + switch (mod->mod_op & LDAP_MOD_OP) { > >>>>>>> + case LDAP_MOD_REPLACE: > >>>>>>> + case LDAP_MOD_INCREMENT: > >>>>>>> + extras++; > >>>>>>> + break; > >>>>>>> + } > >>>>>>> + } > >>>>>>> + > >>>>>>> + /* Not operating on the counter/watermark. */ > >>>>>>> + if (attrs == 0) > >>>>>>> + return 0; > >>>>>>> + > >>>>>>> + /* Get the counter. */ > >>>>>>> + orig = ctr = get_counter(entry, attr); > >>>>>>> + > >>>>>>> + /* Filter the modify operations. */ > >>>>>>> + mods = ch_calloc(count + extras + 1, LDAPMod*); > >>>>>>> + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; > >>>>>>> mods[j++] = inmods[i++]) { > >>>>>> Please remove check for insmods != NULL, it is useless, and removing it > >>>>>> will bring back the line under 80columns > >>>>>> > >>>>>>> + LDAPMod *mod = inmods[i]; > >>>>>>> + > >>>>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) > >>>>>>> + continue; > >>>>>>> + > >>>>>>> + convert_ldapmod_to_bval(mod); > >>>>>>> + > >>>>>>> + switch (mod->mod_op & LDAP_MOD_OP) { > >>>>>>> + case LDAP_MOD_DELETE: > >>>>>>> + ctr.exists = false; > >>>>>>> + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == > >>>>>>> NULL) > >>>>>>> + berval_free_array(&mod->mod_bvalues); > >>>>>>> + > >>>>>>> + if (is_replication(pb)) > >>>>>>> + berval_free_array(&mod->mod_bvalues); > >>>>>>> + > >>>>>>> + if (mod->mod_bvalues == NULL) > >>>>>>> + mod->mod_bvalues = make_berval_array(ctr.value); > >>>>>>> + break; > >>>>>> I am not sure I understand this segment, why are you touching the > >>>>>> delete operation outside of a replication event ? > >>>>>> Doesn't this defeat and admin tool trying to correctly delete/add to > >>>>>> avoid races ? > >>>>>> > >>>>>>> + case LDAP_MOD_INCREMENT: > >>>>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > >>>>>>> ctr.value); + > >>>>>>> + ctr.value += get_value(mod, 1); > >>>>>> uhmmm if you had an ADD followed by INCREMENT operation, would this > >>>>>> cause the value to become value*2+1 instead of just value+1 ? > >>>>>> > >>>>>>> + berval_free_array(&mod->mod_bvalues); > >>>>>>> + mod->mod_op &= ~LDAP_MOD_OP; > >>>>>>> + mod->mod_op |= LDAP_MOD_ADD; > >>>>>>> + mod->mod_bvalues = make_berval_array(ctr.value); > >>>>>>> + break; > >>>>>> uhmm why are you converting mod_increment in all cases ? (including > >>>>>> replication) > >>>>>> > >>>>>>> + case LDAP_MOD_REPLACE: > >>>>>>> + if (ctr.exists) > >>>>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, > >>>>>>> ctr.value); + > >>>>>>> + mod->mod_op &= ~LDAP_MOD_OP; > >>>>>>> + mod->mod_op |= LDAP_MOD_ADD; > >>>>>> same question here, why are you converting a replace coming from > >>>>>> replication into a delete/add ? > >>>>>> > >>>>>>> + case LDAP_MOD_ADD: > >>>>>>> + ctr.value = get_value(mod, 0); > >>>>>>> + ctr.exists = true; > >>>>>>> + break; > >>>>>>> + } > >>>>>>> + } > >>>>>>> + > >>>>>>> + /* Set the modified operations. */ > >>>>>>> + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); > >>>>>>> + ch_free(inmods); > >>>>>>> + > >>>>>>> + /* Ensure we aren't deleting the counter. */ > >>>>>>> + if (orig.exists && !ctr.exists) > >>>>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > >>>>>>> + "Will not delete %s", attr); > >>>>>>> + > >>>>>>> + /* Ensure we aren't rolling back the counter. */ > >>>>>>> + if (orig.value > ctr.value) > >>>>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, > >>>>>>> + "Will not decrement %s", attr); > >>>>>>> + > >>>>>>> + return 0; > >>>>>>> +} > >>>>>> see above about send_error(). > >>>>>> > >>>>>> I think what is needed most is the comment that explains the process > >>>>>> at the to of the main function. > >>>>>> > >>>>>> Simo. > >>>>> All of the above are fixed. > >>>>> > >>>>> Also, I have addressed Thierry's concern about putting the plugin in > >>>>> betxnpreoperation by splitting the plugin into two phases: modification > >>>>> and validation. Now all modifications occur in bepreoperation and all > >>>>> validation occurs in betxnpreoperation. > >>>>> > >>>>> Additionally, I have new code to trigger a new replication in the case > >>>>> where a validation error occurs and we are in a replication transaction. > >>>>> Thus, when A attempts to push an old counter value to B, B will now > >>>>> replicate the latest value back to A. > >>>>> > >>>>> Nathaniel > >>>>> > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From dkupka at redhat.com Wed Oct 8 05:47:06 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 08 Oct 2014 07:47:06 +0200 Subject: [Freeipa-devel] [PATCH] 0021 Fix example usage in ipa man page. Message-ID: <5434CFDA.8070402@redhat.com> https://fedorahosted.org/freeipa/ticket/4587 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0021-Fix-example-usage-in-ipa-man-page.patch Type: text/x-patch Size: 907 bytes Desc: not available URL: From abokovoy at redhat.com Wed Oct 8 06:02:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 09:02:40 +0300 Subject: [Freeipa-devel] [PATCH] 0021 Fix example usage in ipa man page. In-Reply-To: <5434CFDA.8070402@redhat.com> References: <5434CFDA.8070402@redhat.com> Message-ID: <20141008060240.GB2328@redhat.com> On Wed, 08 Oct 2014, David Kupka wrote: >https://fedorahosted.org/freeipa/ticket/4587 >-- >David Kupka >From 883e90237fbde1075d00990568cde18773e80611 Mon Sep 17 00:00:00 2001 >From: David Kupka >Date: Wed, 8 Oct 2014 01:43:47 -0400 >Subject: [PATCH] Fix example usage in ipa man page. > >https://fedorahosted.org/freeipa/ticket/4587 >--- > ipa.1 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/ipa.1 b/ipa.1 >index fc39fceaae5aa4c614ccaaa7e608f2326d926755..6acfcfd9f7ab580c9b086fa249903cdf10544cdb 100644 >--- a/ipa.1 >+++ b/ipa.1 >@@ -149,7 +149,7 @@ Create a new user with username "foo", first name "foo" and last name "bar". > \fBipa group\-add bar \-\-desc "this is an example group" > Create a new group with name "bar" and description "this is an example group". > .TP >-\fBipa group\-add\-member bar \-\-users=admin,foo\fR >+\fBipa group\-add\-member bar \-\-users={admin,foo}\fR > Add users "admin" and "foo" to the group "bar". > .TP > \fBipa user\-show foo \-\-raw\fR I would like to see a stance about shell expansion use here. May be add a phrase about that right after "Add users ... to the group ..."? It might not be entirely obvious to other people that we rely on a shell expansion features here. -- / Alexander Bokovoy From dkupka at redhat.com Wed Oct 8 06:19:32 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 08 Oct 2014 08:19:32 +0200 Subject: [Freeipa-devel] [PATCH] 0021 Fix example usage in ipa man page. In-Reply-To: <20141008060240.GB2328@redhat.com> References: <5434CFDA.8070402@redhat.com> <20141008060240.GB2328@redhat.com> Message-ID: <5434D774.4070303@redhat.com> On 10/08/2014 08:02 AM, Alexander Bokovoy wrote: > On Wed, 08 Oct 2014, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4587 >> -- >> David Kupka > >> From 883e90237fbde1075d00990568cde18773e80611 Mon Sep 17 00:00:00 2001 >> From: David Kupka >> Date: Wed, 8 Oct 2014 01:43:47 -0400 >> Subject: [PATCH] Fix example usage in ipa man page. >> >> https://fedorahosted.org/freeipa/ticket/4587 >> --- >> ipa.1 | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/ipa.1 b/ipa.1 >> index >> fc39fceaae5aa4c614ccaaa7e608f2326d926755..6acfcfd9f7ab580c9b086fa249903cdf10544cdb >> 100644 >> --- a/ipa.1 >> +++ b/ipa.1 >> @@ -149,7 +149,7 @@ Create a new user with username "foo", first name >> "foo" and last name "bar". >> \fBipa group\-add bar \-\-desc "this is an example group" >> Create a new group with name "bar" and description "this is an example >> group". >> .TP >> -\fBipa group\-add\-member bar \-\-users=admin,foo\fR >> +\fBipa group\-add\-member bar \-\-users={admin,foo}\fR >> Add users "admin" and "foo" to the group "bar". >> .TP >> \fBipa user\-show foo \-\-raw\fR > I would like to see a stance about shell expansion use here. May be add > a phrase about that right after "Add users ... to the group ..."? It > might not be entirely obvious to other people that we rely on a shell > expansion features here. > At first, I wanted to remove one of users mentioned there but '--users=foo' looks confusing to me (using plural and specifying just one value). Personally I would prefer to change all plural parameters to singular form but it is a large change considering the benefit. What about two examples? One '--users=foo' and other using shell expansion. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0021-2-Fix-example-usage-in-ipa-man-page.patch Type: text/x-patch Size: 907 bytes Desc: not available URL: From dkupka at redhat.com Wed Oct 8 06:26:06 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 08 Oct 2014 08:26:06 +0200 Subject: [Freeipa-devel] [PATCH] 0021 Fix example usage in ipa man page. In-Reply-To: <5434D774.4070303@redhat.com> References: <5434CFDA.8070402@redhat.com> <20141008060240.GB2328@redhat.com> <5434D774.4070303@redhat.com> Message-ID: <5434D8FE.6000701@redhat.com> On 10/08/2014 08:19 AM, David Kupka wrote: > On 10/08/2014 08:02 AM, Alexander Bokovoy wrote: >> On Wed, 08 Oct 2014, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4587 >>> -- >>> David Kupka >> >>> From 883e90237fbde1075d00990568cde18773e80611 Mon Sep 17 00:00:00 2001 >>> From: David Kupka >>> Date: Wed, 8 Oct 2014 01:43:47 -0400 >>> Subject: [PATCH] Fix example usage in ipa man page. >>> >>> https://fedorahosted.org/freeipa/ticket/4587 >>> --- >>> ipa.1 | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/ipa.1 b/ipa.1 >>> index >>> fc39fceaae5aa4c614ccaaa7e608f2326d926755..6acfcfd9f7ab580c9b086fa249903cdf10544cdb >>> >>> 100644 >>> --- a/ipa.1 >>> +++ b/ipa.1 >>> @@ -149,7 +149,7 @@ Create a new user with username "foo", first name >>> "foo" and last name "bar". >>> \fBipa group\-add bar \-\-desc "this is an example group" >>> Create a new group with name "bar" and description "this is an example >>> group". >>> .TP >>> -\fBipa group\-add\-member bar \-\-users=admin,foo\fR >>> +\fBipa group\-add\-member bar \-\-users={admin,foo}\fR >>> Add users "admin" and "foo" to the group "bar". >>> .TP >>> \fBipa user\-show foo \-\-raw\fR >> I would like to see a stance about shell expansion use here. May be add >> a phrase about that right after "Add users ... to the group ..."? It >> might not be entirely obvious to other people that we rely on a shell >> expansion features here. >> > > At first, I wanted to remove one of users mentioned there but > '--users=foo' looks confusing to me (using plural and specifying just > one value). > Personally I would prefer to change all plural parameters to singular > form but it is a large change considering the benefit. > What about two examples? One '--users=foo' and other using shell expansion. > > I forget to update the patch, sorry. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0021-3-Fix-example-usage-in-ipa-man-page.patch Type: text/x-patch Size: 1157 bytes Desc: not available URL: From abokovoy at redhat.com Wed Oct 8 06:36:42 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 09:36:42 +0300 Subject: [Freeipa-devel] [PATCH] 0021 Fix example usage in ipa man page. In-Reply-To: <5434D8FE.6000701@redhat.com> References: <5434CFDA.8070402@redhat.com> <20141008060240.GB2328@redhat.com> <5434D774.4070303@redhat.com> <5434D8FE.6000701@redhat.com> Message-ID: <20141008063642.GC2328@redhat.com> On Wed, 08 Oct 2014, David Kupka wrote: >On 10/08/2014 08:19 AM, David Kupka wrote: >>On 10/08/2014 08:02 AM, Alexander Bokovoy wrote: >>>On Wed, 08 Oct 2014, David Kupka wrote: >>>>https://fedorahosted.org/freeipa/ticket/4587 >>>>-- >>>>David Kupka >>> >>>>From 883e90237fbde1075d00990568cde18773e80611 Mon Sep 17 00:00:00 2001 >>>>From: David Kupka >>>>Date: Wed, 8 Oct 2014 01:43:47 -0400 >>>>Subject: [PATCH] Fix example usage in ipa man page. >>>> >>>>https://fedorahosted.org/freeipa/ticket/4587 >>>>--- >>>>ipa.1 | 2 +- >>>>1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>>diff --git a/ipa.1 b/ipa.1 >>>>index >>>>fc39fceaae5aa4c614ccaaa7e608f2326d926755..6acfcfd9f7ab580c9b086fa249903cdf10544cdb >>>> >>>>100644 >>>>--- a/ipa.1 >>>>+++ b/ipa.1 >>>>@@ -149,7 +149,7 @@ Create a new user with username "foo", first name >>>>"foo" and last name "bar". >>>>\fBipa group\-add bar \-\-desc "this is an example group" >>>>Create a new group with name "bar" and description "this is an example >>>>group". >>>>.TP >>>>-\fBipa group\-add\-member bar \-\-users=admin,foo\fR >>>>+\fBipa group\-add\-member bar \-\-users={admin,foo}\fR >>>>Add users "admin" and "foo" to the group "bar". >>>>.TP >>>>\fBipa user\-show foo \-\-raw\fR >>>I would like to see a stance about shell expansion use here. May be add >>>a phrase about that right after "Add users ... to the group ..."? It >>>might not be entirely obvious to other people that we rely on a shell >>>expansion features here. >>> >> >>At first, I wanted to remove one of users mentioned there but >>'--users=foo' looks confusing to me (using plural and specifying just >>one value). >>Personally I would prefer to change all plural parameters to singular >>form but it is a large change considering the benefit. >>What about two examples? One '--users=foo' and other using shell expansion. >> >> > >I forget to update the patch, sorry. > >-- >David Kupka >From 554d9b0f806f6eb7ad8ffc99fbd7ac6cb20c5c4c Mon Sep 17 00:00:00 2001 >From: David Kupka >Date: Wed, 8 Oct 2014 01:43:47 -0400 >Subject: [PATCH] Fix example usage in ipa man page. > >https://fedorahosted.org/freeipa/ticket/4587 >--- > ipa.1 | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > >diff --git a/ipa.1 b/ipa.1 >index fc39fceaae5aa4c614ccaaa7e608f2326d926755..fe2a1aa7bafadd70596b5d95bca49a3f583a3c3d 100644 >--- a/ipa.1 >+++ b/ipa.1 >@@ -149,8 +149,11 @@ Create a new user with username "foo", first name "foo" and last name "bar". > \fBipa group\-add bar \-\-desc "this is an example group" > Create a new group with name "bar" and description "this is an example group". > .TP >-\fBipa group\-add\-member bar \-\-users=admin,foo\fR >-Add users "admin" and "foo" to the group "bar". >+\fBipa group\-add\-member bar \-\-users=foo\fR >+Add user "foo" to the group "bar". >+.TP >+\fBipa group\-add\-member bar \-\-users={admin,foo}\fR >+Add users "admin" and "foo" to the group "bar". This approach depends on shell expansion feature. > .TP > \fBipa user\-show foo \-\-raw\fR > Display user "foo" as (s)he is stored on the server. ACK. -- / Alexander Bokovoy From dkupka at redhat.com Wed Oct 8 07:09:57 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 08 Oct 2014 09:09:57 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig Message-ID: <5434E345.4070402@redhat.com> https://fedorahosted.org/freeipa/ticket/4569 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 16250 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 8 07:24:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 08 Oct 2014 09:24:06 +0200 Subject: [Freeipa-devel] [PATCH] 348 Remove misleading authorization error message in cert-request with --add In-Reply-To: <54341957.9000004@redhat.com> References: <54341957.9000004@redhat.com> Message-ID: <5434E696.8080504@redhat.com> On 10/07/2014 06:48 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > The error message is now the generic ACI error message, e.g. "Insufficient > access: Insufficient 'add' privilege to add the entry > 'krbprincipalname=something/somehost.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com'. > > " > > Honza Yup, simpler is better in this case. The certmonger tracker seems easier to understand to me now: # ipa-getcert list -i 20141008071708 Number of certificates and requests being tracked: 9. Request ID '20141008071708': status: CA_REJECTED ca-error: Server at https://ipa.mkosek-fedora20.test/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'add' privilege to add the entry 'krbprincipalname=test/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test'.). stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes ACK. Pushed to: master: 8e602eaf46b71ad8f713f549d6a823c70567bb22 ipa-4-1: ed5ffbfd75f3f1a62581c50a2c64d9e75fc74081 ipa-4-0: 80da03a2169de3a78edec42c1eab1f87734f49a7 Martin From jcholast at redhat.com Wed Oct 8 07:29:27 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 08 Oct 2014 09:29:27 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <5434E345.4070402@redhat.com> References: <5434E345.4070402@redhat.com> Message-ID: <5434E7D7.3020401@redhat.com> Hi, Dne 8.10.2014 v 09:09 David Kupka napsal(a): > https://fedorahosted.org/freeipa/ticket/4569 In renew_ca_cert and cainstance.py, dogtag should already be stopped in the places you modified, so why the change? Also I don't think it's a good idea to backup CS.cfg when dogtag is still running (in cainstance.py). If the file is being modified by dogtag at the time it is backed up, the backup may be corrupted. Honza -- Jan Cholasta From mkosek at redhat.com Wed Oct 8 07:44:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 08 Oct 2014 09:44:53 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412707730.3308.3.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <54341AD6.8080303@redhat.com> <1412704114.3308.2.camel@redhat.com> <54342843.8010301@redhat.com> <1412707730.3308.3.camel@redhat.com> Message-ID: <5434EB75.7090202@redhat.com> On 10/07/2014 08:48 PM, Nathaniel McCallum wrote: > On Tue, 2014-10-07 at 10:52 -0700, Noriko Hosoi wrote: >> On 2014/10/07 10:48, Nathaniel McCallum wrote: >>> On Tue, 2014-10-07 at 18:54 +0200, thierry bordaz wrote: >>>> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: >>>> >>>>> Attached is the latest patch. I believe this includes all of our >>>>> discussions up until this point. However, a few bits of additional >>>>> information are needed. >>>>> >>>>> First, I have renamed the plugin to ipa-otp-counter. I believe all >>>>> replay prevention work can land inside this plugin, so the name is >>>>> appropriate. >>>>> >>>>> Second, I uncovered a bug in 389 which prevents me from validating the >>>>> non-replication request in bepre. This is the reason for the additional >>>>> betxnpre callback. If the upstream 389 bug is fixed, we can merge this >>>>> check back into bepre. https://fedorahosted.org/389/ticket/47919 >>>> Hi Nathaniel, >>>> >>>> Just a rapid question about that dependency on >>>> https://fedorahosted.org/389/ticket/47919. >>>> Using txnpreop_mod you manage to workaround the DS issue. >>>> Do you need a fix for the DS issue in 1.3.2 or can it be fixed >>>> in a later version ? >>> I would strongly prefer a fix ASAP. >> Thanks, Nathaniel, >> Do you need the fix just in 389-ds-base-1.3.3.x on F21 and newer? Or any >> other versions, e.g., 1.3.2 on F20, 1.3.3.1-x on RHEL-7.1, etc... ? > > I think we are just shipping 4.1 on F21. Someone please correct me if > I'm wrong. FreeIPA 4.x already requires DS 1.3.3.*, so fixing from this version is sufficient for us. We have a Copr repo for Fedora 20 anyway, so we will just rebuild the updated DS there. Martin From pspacek at redhat.com Wed Oct 8 07:46:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 08 Oct 2014 09:46:54 +0200 Subject: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns In-Reply-To: References: <54342251.6070304@redhat.com> Message-ID: <5434EBEE.2000504@redhat.com> Hello, this is going to be a little bit more interesting. RHEL/CentOS version of FreeIPA depends on python-dns >= 1.11.1-2 but Fedora version should depend on >= 1.12.0. RHEL contains Git snapshot which is newer than 1.11.1 but is still not complete 1.12.0. Fedora contains 'proper' 1.11.1 version which is unfortunately too old. Fedora bug for rebase to 1.12.0: https://bugzilla.redhat.com/show_bug.cgi?id=1150396 Petr^2 Spacek On 7.10.2014 19:34, Gabe Alford wrote: > Done. Update patch to use python-dns >= 1.11.1 > > On Tue, Oct 7, 2014 at 11:26 AM, Martin Basti wrote: > >> On 07/10/14 15:58, Gabe Alford wrote: >> >> Forgot to add patch. >> >> On Tue, Oct 7, 2014 at 7:58 AM, Gabe Alford wrote: >> >>> Hello, >>> >>> Fix for https://fedorahosted.org/freeipa/ticket/4613 >>> >>> Thanks, >>> >>> Gabe >>> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> Thank you! >> >> I prefer to use python-dns >= 1.11.1, there are some DNSSEC fixes which we >> may use in tests. >> >> Could you send updated patch please? From mkosek at redhat.com Wed Oct 8 07:55:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 08 Oct 2014 09:55:18 +0200 Subject: [Freeipa-devel] [PATCH] 0021 Fix example usage in ipa man page. In-Reply-To: <20141008063642.GC2328@redhat.com> References: <5434CFDA.8070402@redhat.com> <20141008060240.GB2328@redhat.com> <5434D774.4070303@redhat.com> <5434D8FE.6000701@redhat.com> <20141008063642.GC2328@redhat.com> Message-ID: <5434EDE6.7000407@redhat.com> On 10/08/2014 08:36 AM, Alexander Bokovoy wrote: > On Wed, 08 Oct 2014, David Kupka wrote: >> On 10/08/2014 08:19 AM, David Kupka wrote: >>> On 10/08/2014 08:02 AM, Alexander Bokovoy wrote: >>>> On Wed, 08 Oct 2014, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4587 >>>>> -- >>>>> David Kupka >>>> >>>>> From 883e90237fbde1075d00990568cde18773e80611 Mon Sep 17 00:00:00 2001 >>>>> From: David Kupka >>>>> Date: Wed, 8 Oct 2014 01:43:47 -0400 >>>>> Subject: [PATCH] Fix example usage in ipa man page. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4587 >>>>> --- >>>>> ipa.1 | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/ipa.1 b/ipa.1 >>>>> index >>>>> fc39fceaae5aa4c614ccaaa7e608f2326d926755..6acfcfd9f7ab580c9b086fa249903cdf10544cdb >>>>> >>>>> >>>>> 100644 >>>>> --- a/ipa.1 >>>>> +++ b/ipa.1 >>>>> @@ -149,7 +149,7 @@ Create a new user with username "foo", first name >>>>> "foo" and last name "bar". >>>>> \fBipa group\-add bar \-\-desc "this is an example group" >>>>> Create a new group with name "bar" and description "this is an example >>>>> group". >>>>> .TP >>>>> -\fBipa group\-add\-member bar \-\-users=admin,foo\fR >>>>> +\fBipa group\-add\-member bar \-\-users={admin,foo}\fR >>>>> Add users "admin" and "foo" to the group "bar". >>>>> .TP >>>>> \fBipa user\-show foo \-\-raw\fR >>>> I would like to see a stance about shell expansion use here. May be add >>>> a phrase about that right after "Add users ... to the group ..."? It >>>> might not be entirely obvious to other people that we rely on a shell >>>> expansion features here. >>>> >>> >>> At first, I wanted to remove one of users mentioned there but >>> '--users=foo' looks confusing to me (using plural and specifying just >>> one value). >>> Personally I would prefer to change all plural parameters to singular >>> form but it is a large change considering the benefit. >>> What about two examples? One '--users=foo' and other using shell expansion. >>> >>> >> >> I forget to update the patch, sorry. >> >> -- >> David Kupka > >> From 554d9b0f806f6eb7ad8ffc99fbd7ac6cb20c5c4c Mon Sep 17 00:00:00 2001 >> From: David Kupka >> Date: Wed, 8 Oct 2014 01:43:47 -0400 >> Subject: [PATCH] Fix example usage in ipa man page. >> >> https://fedorahosted.org/freeipa/ticket/4587 >> --- >> ipa.1 | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/ipa.1 b/ipa.1 >> index >> fc39fceaae5aa4c614ccaaa7e608f2326d926755..fe2a1aa7bafadd70596b5d95bca49a3f583a3c3d >> 100644 >> --- a/ipa.1 >> +++ b/ipa.1 >> @@ -149,8 +149,11 @@ Create a new user with username "foo", first name "foo" >> and last name "bar". >> \fBipa group\-add bar \-\-desc "this is an example group" >> Create a new group with name "bar" and description "this is an example group". >> .TP >> -\fBipa group\-add\-member bar \-\-users=admin,foo\fR >> -Add users "admin" and "foo" to the group "bar". >> +\fBipa group\-add\-member bar \-\-users=foo\fR >> +Add user "foo" to the group "bar". >> +.TP >> +\fBipa group\-add\-member bar \-\-users={admin,foo}\fR >> +Add users "admin" and "foo" to the group "bar". This approach depends on >> shell expansion feature. >> .TP >> \fBipa user\-show foo \-\-raw\fR >> Display user "foo" as (s)he is stored on the server. > ACK. Pushed to: master: f36794e8119c6005a6e802b3c4b23e13a3ac0bf5 ipa-4-1: 6e1c7df530fdc76737576c5b1190ac7c5dc59917 ipa-4-0: 9b6145420a7b57e0d0cc152bcd727206651f9b8d Martin From jcholast at redhat.com Wed Oct 8 08:38:47 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 08 Oct 2014 10:38:47 +0200 Subject: [Freeipa-devel] [PATCHES] 349-350 Add ipa-client-install switch --request-cert to request cert for the host Message-ID: <5434F817.4000908@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-349-Fix-certmonger.request_cert.patch Type: text/x-patch Size: 1290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-350-Add-ipa-client-install-switch-request-cert-to-reques.patch Type: text/x-patch Size: 8206 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 8 08:56:45 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 08 Oct 2014 10:56:45 +0200 Subject: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns In-Reply-To: References: <54342251.6070304@redhat.com> Message-ID: <5434FC4D.7010805@redhat.com> On 07/10/14 19:34, Gabe Alford wrote: > Done. Update patch to use python-dns >= 1.11.1 > > On Tue, Oct 7, 2014 at 11:26 AM, Martin Basti > wrote: > > On 07/10/14 15:58, Gabe Alford wrote: >> Forgot to add patch. >> >> On Tue, Oct 7, 2014 at 7:58 AM, Gabe Alford >> > wrote: >> >> Hello, >> >> Fix for https://fedorahosted.org/freeipa/ticket/4613 >> >> Thanks, >> >> Gabe >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Thank you! > > I prefer to use python-dns >= 1.11.1, there are some DNSSEC fixes > which we may use in tests. > > Could you send updated patch please? > > > -- > Martin Basti > > ACK Thank you! -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Oct 8 09:53:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 08 Oct 2014 11:53:26 +0200 Subject: [Freeipa-devel] [PATCH] 351 Support MS CA as the external CA in ipa-server-install and ipa-ca-install Message-ID: <54350996.5010707@redhat.com> Hi, the attached patch fixes . Note that this requires pki-core 10.2.0-3. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-351-Support-MS-CA-as-the-external-CA-in-ipa-server-insta.patch Type: text/x-patch Size: 8979 bytes Desc: not available URL: From jcholast at redhat.com Wed Oct 8 10:27:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 08 Oct 2014 12:27:53 +0200 Subject: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code Message-ID: <543511A9.5050205@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-352-Fix-certmonger-configuration-in-installer-code.patch Type: text/x-patch Size: 14739 bytes Desc: not available URL: From dkupka at redhat.com Wed Oct 8 10:36:35 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 08 Oct 2014 12:36:35 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <5434E7D7.3020401@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> Message-ID: <543513B3.9060808@redhat.com> On 10/08/2014 09:29 AM, Jan Cholasta wrote: > Hi, > > Dne 8.10.2014 v 09:09 David Kupka napsal(a): >> https://fedorahosted.org/freeipa/ticket/4569 > > In renew_ca_cert and cainstance.py, dogtag should already be stopped in > the places you modified, so why the change? I didn't noticed that it is already stopped, fixed. > > Also I don't think it's a good idea to backup CS.cfg when dogtag is > still running (in cainstance.py). If the file is being modified by > dogtag at the time it is backed up, the backup may be corrupted. > Fixed, thanks. > Honza > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-2-ipa4x-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 3210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-2-master-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 3181 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 8 10:49:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 08 Oct 2014 12:49:17 +0200 Subject: [Freeipa-devel] [PATCH] 351 Support MS CA as the external CA in ipa-server-install and ipa-ca-install In-Reply-To: <54350996.5010707@redhat.com> References: <54350996.5010707@redhat.com> Message-ID: <543516AD.6020900@redhat.com> On 10/08/2014 11:53 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Note that this requires pki-core 10.2.0-3. > > Honza The approach looks OK, but I would like to be better in naming documentation: + cert_group.add_option("--external-ca-type", dest="external_ca_type", + type="choice", choices=("generic", "ms"), + help="Type of the external CA") I would name the option either "ad-cs" or "windows-server-ca", i.e. "Active Directory Certificate Services" or "Windows Server CA". "ms" sounds too generic to me in this context. When using trademarks we should be specific about what do we mean. Same for man: +\fB\-\-external\-ca\-type\fR=\fITYPE\fR +Type of the external CA. Possible values are generic, ms. Default value is generic. Use ms to include MS template name extension in the CSR. +.TP I would be more verbose and write ... Use "windows-server-ca" to include Windows Server CA specific template name extension (1.3.6.1.4.1.311.20.2) set in the CSR. From jcholast at redhat.com Wed Oct 8 11:23:57 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 08 Oct 2014 13:23:57 +0200 Subject: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code In-Reply-To: <543511A9.5050205@redhat.com> References: <543511A9.5050205@redhat.com> Message-ID: <54351ECD.1040603@redhat.com> Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a): > Hi, > > the attached patch fixes . > > Honza Forgot to delete a line in dogtaginstance.py (thanks to David for noticing). Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-352.1-Fix-certmonger-configuration-in-installer-code.patch Type: text/x-patch Size: 15038 bytes Desc: not available URL: From jcholast at redhat.com Wed Oct 8 11:35:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 08 Oct 2014 13:35:36 +0200 Subject: [Freeipa-devel] [PATCH] 353 Allow specifying signing algorithm of the IPA CA cert in ipa-ca-install Message-ID: <54352188.4030609@redhat.com> Hi, the attached patch provides an additional fix for . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-353-Allow-specifying-signing-algorithm-of-the-IPA-CA-cer.patch Type: text/x-patch Size: 3586 bytes Desc: not available URL: From jcholast at redhat.com Wed Oct 8 11:46:24 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 08 Oct 2014 13:46:24 +0200 Subject: [Freeipa-devel] [PATCH] 351 Support MS CA as the external CA in ipa-server-install and ipa-ca-install In-Reply-To: <543516AD.6020900@redhat.com> References: <54350996.5010707@redhat.com> <543516AD.6020900@redhat.com> Message-ID: <54352410.2060005@redhat.com> Dne 8.10.2014 v 12:49 Martin Kosek napsal(a): > On 10/08/2014 11:53 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Note that this requires pki-core 10.2.0-3. >> >> Honza > > The approach looks OK, but I would like to be better in naming documentation: > > + cert_group.add_option("--external-ca-type", dest="external_ca_type", > + type="choice", choices=("generic", "ms"), > + help="Type of the external CA") > > I would name the option either "ad-cs" or "windows-server-ca", i.e. "Active > Directory Certificate Services" or "Windows Server CA". "ms" sounds too generic > to me in this context. When using trademarks we should be specific about what > do we mean. Microsoft docs refer to it as "Microsoft Certificate Services" or simply "Certificate Services", so I went with "ms-cs". > > Same for man: > > +\fB\-\-external\-ca\-type\fR=\fITYPE\fR > +Type of the external CA. Possible values are generic, ms. Default value is > generic. Use ms to include MS template name extension in the CSR. > +.TP > > I would be more verbose and write > > ... Use "windows-server-ca" to include Windows Server CA specific template name > extension (1.3.6.1.4.1.311.20.2) set in the CSR. I have reworded the description in man and the commit message a bit. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-351.1-Support-MS-CS-as-the-external-CA-in-ipa-server-insta.patch Type: text/x-patch Size: 9079 bytes Desc: not available URL: From lkrispen at redhat.com Wed Oct 8 14:06:07 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 08 Oct 2014 16:06:07 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Ignore irrelevant subtrees in schema compat plugin Message-ID: <543544CF.1040309@redhat.com> Please review attached patch for ticket: https://fedorahosted.org/freeipa/ticket/4586 This reduces the number of internal searches and contention for database locks. Together with DS fix for https://fedorahosted.org/389/ticket/47918 the issues reported in 4586 did no longer occur. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0002-Ignore-irrelevant-subtrees-in-schema-compat-plugin.patch Type: text/x-patch Size: 4137 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 8 14:41:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 08 Oct 2014 16:41:21 +0200 Subject: [Freeipa-devel] [PATCH] 0655 Add additional backup & restore checks Message-ID: <54354D11.4080501@redhat.com> This adds basic checks that PAM, DNS, and Kerberos are working before & after the backup&restore (in addition to DS, CA & IPA CLI that were there before). -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0655-Add-additional-backup-restore-tests.patch Type: text/x-patch Size: 2601 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 8 14:59:07 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 08 Oct 2014 16:59:07 +0200 Subject: [Freeipa-devel] [PATCH 0133] Fix ipactl service ordering Message-ID: <5435513B.8090904@redhat.com> IPA sorts service order alphabetically, this patch modify ipactl to use integers. How to reproduce: set attribute ipaConfigString: startOrder 150 DN: cn=HTTP,cn=ipa.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com then run #ipactl restart httpd service should start as last service, but it starts almost first. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0133-Fix-ipactl-service-ordering.patch Type: text/x-patch Size: 1178 bytes Desc: not available URL: From tbordaz at redhat.com Wed Oct 8 15:30:36 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 08 Oct 2014 17:30:36 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412697608.3308.1.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> Message-ID: <5435589C.8040701@redhat.com> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: > Attached is the latest patch. I believe this includes all of our > discussions up until this point. However, a few bits of additional > information are needed. > > First, I have renamed the plugin to ipa-otp-counter. I believe all > replay prevention work can land inside this plugin, so the name is > appropriate. > > Second, I uncovered a bug in 389 which prevents me from validating the > non-replication request in bepre. This is the reason for the additional > betxnpre callback. If the upstream 389 bug is fixed, we can merge this > check back into bepre. https://fedorahosted.org/389/ticket/47919 > > Third, I believe we are now handling replication correct. An error is > never returned. When a replication would cause the counter to decrease, > we remove all counter/watermark related mods from the operation. This > will allow the replication to apply without decrementing the value. > There is also a new bepost method which check to see if the replication > was discarded (via CSN) while having a higher counter value. If so, we > apply the higher counter value. For me the code is good. It took me some time to understand the benefit of removing mods in preop. In fact I think it is a good idea, as it prevents extra repair ops and also make more easy the computation of the value to set in repair mod. > > Here is the scenario. Server X receives two quick authentications; > replications A and B are sent to server Y. Before server Y can process > server X's replications, an authentication is performed on server Y; > replication C is sent to server X. The following logic holds true: > * csnA < csnB < csnC > * valueA = valueC, valueB > valueC > > When server X receives replication C, ipa-otp-counter will strip out all > counter mod operations; applying the update but not the lower value. The > value of replication B is retained. This is the correct behavior. > > When server Y processes replications A and B, ipa-otp-counter will > detect that a higher value has a lower CSN and will manually set the > higher value (in bepost). This initiates replication D, which is sent to > server X. Here is the logic: > * csnA < csnB < csnC < csnD > * valueA = valueC, valueB = valueD, valueD > valueC > > Server X receives replication D. D has the highest CSN. It has the same > value as replication B (server X's current value). Because the values > are the same, ipa-otp-counter will strip all counter mod operations. > This reduces counter write contention which might become a problem in > N-way replication when N>2. I think we should rather let the mods going on. So that the full topology will have valueD (or valueB)/csnD rather having a set of servers having valueD/csnB and an other set valueD/csnD. thanks thierry > > On Fri, 2014-10-03 at 19:52 +0200, thierry bordaz wrote: >> Hello Nathaniel, >> >> An additional comment about the patch. >> >> When the new value is detected to be invalid, it is fixed by a >> repair operation (trigger_replication). >> I did test it and it is fine to update, with an internal >> operation, the same entry that is currently updated. >> >> Now if you apply the repair operation into a be_preop or a >> betxn_preop, when it returns from preop the txn of the current >> operation will overwrite the repaired value. >> >> An option is to register a bepost that checks the value from >> the original entry (SLAPI_ENTRY_PRE_OP) and post entry >> (SLAPI_ENTRY_POST_OP). Then this postop checks the >> orginal/final value and can trigger the repair op. >> This time being outside of the main operation txn, the repair >> op will be applied. >> >> thanks >> thierry >> On 09/29/2014 08:30 PM, Nathaniel McCallum wrote: >> >>> On Mon, 2014-09-22 at 09:32 -0400, Simo Sorce wrote: >>>> On Sun, 21 Sep 2014 22:33:47 -0400 >>>> Nathaniel McCallum wrote: >>>> >>>> Comments inline. >>>> >>>>> + >>>>> +#define ch_malloc(type) \ >>>>> + (type*) slapi_ch_malloc(sizeof(type)) >>>>> +#define ch_calloc(count, type) \ >>>>> + (type*) slapi_ch_calloc(count, sizeof(type)) >>>>> +#define ch_free(p) \ >>>>> + slapi_ch_free((void**) &(p)) >>>> please do not redefine slapi functions, it just makes it harder to know >>>> what you used. >>>> >>>> >>>>> +typedef struct { >>>>> + bool exists; >>>>> + long long value; >>>>> +} counter; >>>> please no typedefs of structures, use "struct counter { ... };" and >>>> reference it as "struct counter" in the code. >>>> >>>> Btw, FWIW you could use a value of -1 to indicate non-existence of the >>>> counter value, given counters can only be positive, this would avoid >>>> the need for a struct. >>>> >>>>> +static int >>>>> +send_error(Slapi_PBlock *pb, int rc, char *template, ...) >>>>> +{ >>>>> + va_list ap; >>>>> + int res; >>>>> + >>>>> + va_start(ap, template); >>>>> + res = vsnprintf(NULL, 0, template, ap); >>>>> + va_end(ap); >>>>> + >>>>> + if (res > 0) { >>>>> + char str[res + 1]; >>>>> + >>>>> + va_start(ap, template); >>>>> + res = vsnprintf(str, sizeof(str), template, ap); >>>>> + va_end(ap); >>>>> + >>>>> + if (res > 0) >>>>> + slapi_send_ldap_result(pb, rc, NULL, str, 0, NULL); >>>>> + } >>>>> + >>>>> + if (res <= 0) >>>>> + slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); >>>>> + >>>>> + slapi_pblock_set(pb, SLAPI_RESULT_CODE, &rc); >>>>> + return rc; >>>>> +} >>>> This function seem not really useful, you use send_error() only at the >>>> end of one single function where you could have the classic scheme of >>>> using a done: label and just use directly slapi_ch_smprintf. This would >>>> remove the need to use vsnprintf and all the va_ machinery which is >>>> more than 50% of this function. >>>> >>>> >>>>> +static long long >>>>> +get_value(const LDAPMod *mod, long long def) >>>>> +{ >>>>> + const struct berval *bv; >>>>> + long long val; >>>>> + >>>>> + if (mod == NULL) >>>>> + return def; >>>>> + >>>>> + if (mod->mod_vals.modv_bvals == NULL) >>>>> + return def; >>>>> + >>>>> + bv = mod->mod_vals.modv_bvals[0]; >>>>> + if (bv == NULL) >>>>> + return def; >>>> In general (here and elsewhere) I prefer to always use {} in if clauses. >>>> I have been bitten enough time by people adding an instruction that >>>> should be in the braces but forgot to add braces (defensive programming >>>> style). But up to you. >>>> >>>>> + char buf[bv->bv_len + 1]; >>>>> + memcpy(buf, bv->bv_val, bv->bv_len); >>>>> + buf[sizeof(buf)-1] = '\0'; >>>>> + >>>>> + val = strtoll(buf, NULL, 10); >>>>> + if (val == LLONG_MIN || val == LLONG_MAX) >>>>> + return def; >>>>> + >>>>> + return val; >>>>> +} >>>>> + >>>>> +static struct berval ** >>>>> +make_berval_array(long long value) >>>>> +{ >>>>> + struct berval **bvs; >>>>> + >>>>> + bvs = ch_calloc(2, struct berval*); >>>>> + bvs[0] = ch_malloc(struct berval); >>>>> + bvs[0]->bv_val = slapi_ch_smprintf("%lld", value); >>>>> + bvs[0]->bv_len = strlen(bvs[0]->bv_val); >>>>> + >>>>> + return bvs; >>>>> +} >>>>> + >>>>> +static LDAPMod * >>>>> +make_ldapmod(int op, const char *attr, long long value) >>>>> +{ >>>>> + LDAPMod *mod; >>>>> + >>>>> + mod = (LDAPMod*) slapi_ch_calloc(1, sizeof(LDAPMod)); >>>>> + mod->mod_op = op | LDAP_MOD_BVALUES; >>>>> + mod->mod_type = slapi_ch_strdup(attr); >>>>> + mod->mod_bvalues = make_berval_array(value); >>>>> + >>>>> + return mod; >>>>> +} >>>>> + >>>>> +static void >>>>> +convert_ldapmod_to_bval(LDAPMod *mod) >>>>> +{ >>>>> + if (mod == NULL || (mod->mod_op & LDAP_MOD_BVALUES)) >>>>> + return; >>>>> + >>>>> + mod->mod_op |= LDAP_MOD_BVALUES; >>>>> + >>>>> + if (mod->mod_values == NULL) { >>>>> + mod->mod_bvalues = NULL; >>>>> + return; >>>>> + } >>>>> + >>>>> + for (size_t i = 0; mod->mod_values[i] != NULL; i++) { >>>>> + struct berval *bv = ch_malloc(struct berval); >>>>> + bv->bv_val = mod->mod_values[i]; >>>>> + bv->bv_len = strlen(bv->bv_val); >>>>> + mod->mod_bvalues[i] = bv; >>>>> + } >>>>> +} >>>>> + >>>>> +static counter >>>>> +get_counter(Slapi_Entry *entry, const char *attr) >>>>> +{ >>>>> + Slapi_Attr *sattr = NULL; >>>>> + >>>>> + return (counter) { >>>>> + slapi_entry_attr_find(entry, attr, &sattr) == 0, >>>>> + slapi_entry_attr_get_longlong(entry, attr) >>>>> + }; >>>>> +} >>>>> + >>>>> +static void >>>>> +berval_free_array(struct berval ***bvals) >>>>> +{ >>>>> + for (size_t i = 0; (*bvals)[i] != NULL; i++) { >>>>> + ch_free((*bvals)[i]->bv_val); >>>>> + ch_free((*bvals)[i]); >>>>> + } >>>>> + >>>>> + slapi_ch_free((void**) bvals); >>>>> +} >>>>> + >>>>> +static bool >>>>> +is_replication(Slapi_PBlock *pb) >>>>> +{ >>>>> + int repl = 0; >>>>> + slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &repl); >>>>> + return repl != 0; >>>>> +} >>>>> + >>>>> +static const char * >>>>> +get_attribute(Slapi_Entry *entry) >>>>> +{ >>>>> + static struct { >>>>> + const char *clss; >>>>> + const char *attr; >>>>> + } table[] = { >>>>> + { "ipatokenHOTP", "ipatokenHOTPcounter" }, >>>>> + { "ipatokenTOTP", "ipatokenTOTPwatermark" }, >>>>> + { NULL, NULL } >>>>> + }; >>>>> + >>>>> + const char *attr = NULL; >>>>> + char **clsses = NULL; >>>>> + >>>>> + clsses = slapi_entry_attr_get_charray(entry, "objectClass"); >>>>> + if (clsses == NULL) >>>>> + return NULL; >>>>> + >>>>> + for (size_t i = 0; attr == NULL && clsses[i] != NULL; i++) { >>>>> + for (size_t j = 0; attr == NULL && table[j].clss != NULL; >>>>> j++) { >>>>> + if (PL_strcasecmp(table[j].clss, clsses[i]) == 0) >>>>> + attr = table[j].attr; >>>>> + } >>>>> + } >>>>> + >>>>> + slapi_ch_array_free(clsses); >>>>> + return attr; >>>>> +} >>>> Can you put a comment here that explains what you are going to do in >>>> each cases in plain English ? This will help people in future figuring >>>> out if/how to modify the code or why something happens a specific way. >>>> It will also help the reviewer follow what is going on. >>>> >>>> >>>>> +static int >>>>> +preop_mod(Slapi_PBlock *pb) >>>>> +{ >>>>> + size_t count = 0, attrs = 0, extras = 0; >>>>> + Slapi_Entry *entry = NULL; >>>>> + const char *attr = NULL; >>>>> + LDAPMod **inmods = NULL; >>>>> + LDAPMod **mods = NULL; >>>>> + counter ctr, orig; >>>>> + >>>>> + /* Get the input values. */ >>>>> + slapi_pblock_get(pb, SLAPI_ENTRY_PRE_OP, &entry); >>>>> + slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &inmods); >>>>> + if (entry == NULL || inmods == NULL) >>>>> + return 0; >>>>> + >>>>> + /* Get the attribute name. */ >>>>> + attr = get_attribute(entry); >>>>> + if (attr == NULL) >>>>> + return 0; /* Not a token. */ >>>>> + >>>>> + /* Count items. */ >>>>> + while (inmods != NULL && inmods[count] != NULL) { >>>> ^^ this one would read much better as: >>>> for (count = 0; inmods[count] != NULL; count++) { >>>> >>>> You do not need to check for insmods != NULL as you already check for >>>> it and return 0 a few lines above. >>>> >>>>> + LDAPMod *mod = inmods[count++]; >>>>> + >>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>>>> + continue; >>>>> + >>>>> + attrs++; >>>>> + switch (mod->mod_op & LDAP_MOD_OP) { >>>>> + case LDAP_MOD_REPLACE: >>>>> + case LDAP_MOD_INCREMENT: >>>>> + extras++; >>>>> + break; >>>>> + } >>>>> + } >>>>> + >>>>> + /* Not operating on the counter/watermark. */ >>>>> + if (attrs == 0) >>>>> + return 0; >>>>> + >>>>> + /* Get the counter. */ >>>>> + orig = ctr = get_counter(entry, attr); >>>>> + >>>>> + /* Filter the modify operations. */ >>>>> + mods = ch_calloc(count + extras + 1, LDAPMod*); >>>>> + for (size_t i = 0, j = 0; inmods != NULL && inmods[i] != NULL; >>>>> mods[j++] = inmods[i++]) { >>>> Please remove check for insmods != NULL, it is useless, and removing it >>>> will bring back the line under 80columns >>>> >>>>> + LDAPMod *mod = inmods[i]; >>>>> + >>>>> + if (PL_strcasecmp(mod->mod_type, attr) != 0) >>>>> + continue; >>>>> + >>>>> + convert_ldapmod_to_bval(mod); >>>>> + >>>>> + switch (mod->mod_op & LDAP_MOD_OP) { >>>>> + case LDAP_MOD_DELETE: >>>>> + ctr.exists = false; >>>>> + if (mod->mod_bvalues != NULL && mod->mod_bvalues[0] == >>>>> NULL) >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + >>>>> + if (is_replication(pb)) >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + >>>>> + if (mod->mod_bvalues == NULL) >>>>> + mod->mod_bvalues = make_berval_array(ctr.value); >>>>> + break; >>>> I am not sure I understand this segment, why are you touching the >>>> delete operation outside of a replication event ? >>>> Doesn't this defeat and admin tool trying to correctly delete/add to >>>> avoid races ? >>>> >>>>> + case LDAP_MOD_INCREMENT: >>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>>>> ctr.value); + >>>>> + ctr.value += get_value(mod, 1); >>>> uhmmm if you had an ADD followed by INCREMENT operation, would this >>>> cause the value to become value*2+1 instead of just value+1 ? >>>> >>>>> + berval_free_array(&mod->mod_bvalues); >>>>> + mod->mod_op &= ~LDAP_MOD_OP; >>>>> + mod->mod_op |= LDAP_MOD_ADD; >>>>> + mod->mod_bvalues = make_berval_array(ctr.value); >>>>> + break; >>>> uhmm why are you converting mod_increment in all cases ? (including >>>> replication) >>>> >>>>> + case LDAP_MOD_REPLACE: >>>>> + if (ctr.exists) >>>>> + mods[j++] = make_ldapmod(LDAP_MOD_DELETE, attr, >>>>> ctr.value); + >>>>> + mod->mod_op &= ~LDAP_MOD_OP; >>>>> + mod->mod_op |= LDAP_MOD_ADD; >>>> same question here, why are you converting a replace coming from >>>> replication into a delete/add ? >>>> >>>>> + case LDAP_MOD_ADD: >>>>> + ctr.value = get_value(mod, 0); >>>>> + ctr.exists = true; >>>>> + break; >>>>> + } >>>>> + } >>>>> + >>>>> + /* Set the modified operations. */ >>>>> + slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods); >>>>> + ch_free(inmods); >>>>> + >>>>> + /* Ensure we aren't deleting the counter. */ >>>>> + if (orig.exists && !ctr.exists) >>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>>>> + "Will not delete %s", attr); >>>>> + >>>>> + /* Ensure we aren't rolling back the counter. */ >>>>> + if (orig.value > ctr.value) >>>>> + return send_error(pb, LDAP_UNWILLING_TO_PERFORM, >>>>> + "Will not decrement %s", attr); >>>>> + >>>>> + return 0; >>>>> +} >>>> see above about send_error(). >>>> >>>> I think what is needed most is the comment that explains the process >>>> at the to of the main function. >>>> >>>> Simo. >>> All of the above are fixed. >>> >>> Also, I have addressed Thierry's concern about putting the plugin in >>> betxnpreoperation by splitting the plugin into two phases: modification >>> and validation. Now all modifications occur in bepreoperation and all >>> validation occurs in betxnpreoperation. >>> >>> Additionally, I have new code to trigger a new replication in the case >>> where a validation error occurs and we are in a replication transaction. >>> Thus, when A attempts to push an old counter value to B, B will now >>> replicate the latest value back to A. >>> >>> Nathaniel >>> From pvoborni at redhat.com Wed Oct 8 16:51:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 08 Oct 2014 18:51:13 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <542C289A.6040301@redhat.com> References: <542C289A.6040301@redhat.com> Message-ID: <54356B81.4020505@redhat.com> On 1.10.2014 18:15, Petr Vobornik wrote: > Hello list, > > Patch for: https://fedorahosted.org/freeipa/ticket/4419 > New revisions of 761 and 763 with updated API and ACIs: ipa host-allow-operation HOSTNAME retrieve-keytab --users=STR --groups STR ipa host-disallow-operation HOSTNAME retrieve-keytab --users=STR --groups STR ipa host-allow-operation HOSTNAME create-keytab --users=STR --groups STR ipa host-disallow-operation HOSTNAME create-keytab --users=STR --groups STR ipa service-allow-operation PRINCIPAL retrieve-keytab --users=STR --groups STR ipa service-disallow-operation PRINCIPAL retrieve-keytab --users=STR --groups STR ipa service-allow-operation PRINCIPAL create-keytab --users=STR --groups STR ipa service-disallow-operation PRINCIPAL create-keytab --users=STR --groups STR ACIs are targeted to specific operations by including subtypes. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0761-2-keytab-manipulation-permission-management.patch Type: text/x-patch Size: 27257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0763-1-tests-management-of-keytab-permissions.patch Type: text/x-patch Size: 30836 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 8 16:53:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 08 Oct 2014 18:53:03 +0200 Subject: [Freeipa-devel] [PATCH] 764 webui: management of keytab permissions In-Reply-To: <542EAECA.4050104@redhat.com> References: <542C289A.6040301@redhat.com> <542EAECA.4050104@redhat.com> Message-ID: <54356BEF.2080600@redhat.com> On 3.10.2014 16:12, Petr Vobornik wrote: > On 1.10.2014 18:15, Petr Vobornik wrote: >> Hello list, >> >> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >> > > Web UI for 4419. Depends on patch 761 (parent thread). > New version which works with 761-2. The content was moved to details facet (based on UXD feedback). -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0764-1-webui-management-of-keytab-permissions.patch Type: text/x-patch Size: 15876 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 8 17:30:53 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 08 Oct 2014 13:30:53 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <5435589C.8040701@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> Message-ID: <1412789453.9441.1.camel@redhat.com> On Wed, 2014-10-08 at 17:30 +0200, thierry bordaz wrote: > On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: > > Attached is the latest patch. I believe this includes all of our > > discussions up until this point. However, a few bits of additional > > information are needed. > > > > First, I have renamed the plugin to ipa-otp-counter. I believe all > > replay prevention work can land inside this plugin, so the name is > > appropriate. > > > > Second, I uncovered a bug in 389 which prevents me from validating the > > non-replication request in bepre. This is the reason for the additional > > betxnpre callback. If the upstream 389 bug is fixed, we can merge this > > check back into bepre. https://fedorahosted.org/389/ticket/47919 > > > > Third, I believe we are now handling replication correct. An error is > > never returned. When a replication would cause the counter to decrease, > > we remove all counter/watermark related mods from the operation. This > > will allow the replication to apply without decrementing the value. > > There is also a new bepost method which check to see if the replication > > was discarded (via CSN) while having a higher counter value. If so, we > > apply the higher counter value. > > For me the code is good. It took me some time to understand the benefit > of removing mods in preop. > In fact I think it is a good idea, as it prevents extra repair ops and > also make more easy the computation of the value to set in repair mod. > > > > Here is the scenario. Server X receives two quick authentications; > > replications A and B are sent to server Y. Before server Y can process > > server X's replications, an authentication is performed on server Y; > > replication C is sent to server X. The following logic holds true: > > * csnA < csnB < csnC > > * valueA = valueC, valueB > valueC > > > > When server X receives replication C, ipa-otp-counter will strip out all > > counter mod operations; applying the update but not the lower value. The > > value of replication B is retained. This is the correct behavior. > > > > When server Y processes replications A and B, ipa-otp-counter will > > detect that a higher value has a lower CSN and will manually set the > > higher value (in bepost). This initiates replication D, which is sent to > > server X. Here is the logic: > > * csnA < csnB < csnC < csnD > > * valueA = valueC, valueB = valueD, valueD > valueC > > > > Server X receives replication D. D has the highest CSN. It has the same > > value as replication B (server X's current value). Because the values > > are the same, ipa-otp-counter will strip all counter mod operations. > > This reduces counter write contention which might become a problem in > > N-way replication when N>2. > > I think we should rather let the mods going on. So that the full > topology will have > valueD (or valueB)/csnD rather having a set of servers having > valueD/csnB and an other set valueD/csnD. I think you misunderstand. The value for csnD is only discarded when the server already has valueB (valueB == valueD). Only the value is discarded, so csnD is still applied. The full topology will have either valueB w/ csnD or valueD w/ csnD. Since, valueB always equals valueD, by substitution, all servers have valueD w/ csnD. Nathaniel From abokovoy at redhat.com Wed Oct 8 17:50:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 8 Oct 2014 20:50:55 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <543402D8.6080801@redhat.com> References: <20141001161606.GA6186@redhat.com> <543402D8.6080801@redhat.com> Message-ID: <20141008175055.GJ2328@redhat.com> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >Hi Alex, > >I have a question regarding cbdata.target. It is/was a reference to >the pblock used to generate a new dn, but now in >idview_replace_target_dn(&cbdata.target,...) it can be newly allocated >and should be freed, so I think there should be a return code >indicating if it was allocated or not. Yes, good catch. I've fixed this and other issues raised in the review. I also fixed an issue with an initial lookup by an override. If someone does a search by an override, we would replace uid|cn= by uid= if it exists and by otherwise -- for groups we don't have ipaOriginalUid as they don't have uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if there is no entry in the map cache, the search will return nothing, the entry will be staged for lookup through SSSD. In the original version lookup in SSSD didn't take ipaAnchorUUID into account, so the entry would not be found at all. I did add a call to do sid2name first and then use the name to perform actual SSSD lookup. Works nicely now. New patch for slapi-nis is attached. -- / Alexander Bokovoy -------------- next part -------------- From 1c2e7caa3e1c11cc0bc0d8477a0c27308ca8506b Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 29 Jul 2014 12:04:34 +0300 Subject: [PATCH] Add support for FreeIPA ID views FreeIPA ID views allow to override POSIX attributes for certain users and groups. A support is added to allow using specific ID view when serving compatibility tree. Each user or group entry which has an override in the view is amended with the overridden values from the view before served out to the LDAP client. A view to use is specified as a part of base DN: cn=,cn=views,cn=compat,$SUFFIX where cn=compat,$SUFFIX is the original compatibility tree base DN. Each entry, when served through the view, gets new DN rewritten to specify the view. Additionally, if override in the view changes uid (for users) or cn (for groups) attribute, the entry's RDN is changed accordingly. For groups memberUid attribute is modified as well in case there is an override in the view that changes uid value of that member. FreeIPA ID views support overrides for users of trusted Active Directory domains. In case of a trusted AD domain's user or group is returned via compatibility tree, view overrides are applied in two stages: 1. SSSD applies default view for AD users 2. slapi-nis applies explicitly specified (host-specific) view on top of the entry returned by SSSD Thus, slapi-nis does not need to apply default view for AD users and if there are no host-specific views in use, there is no need to specify a view in the base DN, making overhead of a default view for AD users lower. --- configure.ac | 14 ++ doc/ipa/sch-ipa.txt | 93 ++++++++++++ src/Makefile.am | 4 + src/back-sch-idview.c | 392 ++++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch-nss.c | 111 +++++++++++--- src/back-sch.c | 71 +++++++-- src/back-sch.h | 38 +++++ 7 files changed, 692 insertions(+), 31 deletions(-) create mode 100644 src/back-sch-idview.c diff --git a/configure.ac b/configure.ac index 84b84d1..71dbdc7 100644 --- a/configure.ac +++ b/configure.ac @@ -383,6 +383,20 @@ if test "x$use_nsswitch" != xno ; then AC_DEFINE(USE_NSSWITCH,1,[Use nsswitch API to lookup users and groups not found in the LDAP tree]) fi +use_idviews=true +AC_ARG_WITH(idviews, + AS_HELP_STRING([--with-idviews], [Use FreeIPA ID views to override POSIX IDs of users and groups]), + use_idviews=$withval,use_idviews=yes) +if test "x$use_idviews" = xyes ; then + AC_MSG_RESULT([FreeIPA ID views support is enabled]) + AC_DEFINE(USE_IPA_IDVIEWS,1,[Use FreeIPA ID views to override POSIX attributes of users and groups per view.]) + AC_DEFINE(IPA_IDVIEWS_ATTR_ANCHORUUID, ["ipaAnchorUUID"],[FreeIPA attr unique pointer for id overrides]) + AC_DEFINE(IPA_IDVIEWS_ATTR_ORIGINALUID, ["ipaOriginalUid"],[FreeIPA attr original uid value for user id overrides]) +else + AC_MSG_RESULT([FreeIPA ID views support is disabled]) +fi +AM_CONDITIONAL([USE_IPA_IDVIEWS], [test "x$use_idviews" != xno]) + mylibdir=`eval echo "$libdir" | sed "s,NONE,${ac_default_prefix},g"` mylibdir=`eval echo "$mylibdir" | sed "s,NONE,${ac_prefix},g"` case "$server" in diff --git a/doc/ipa/sch-ipa.txt b/doc/ipa/sch-ipa.txt index b5a585b..f560580 100644 --- a/doc/ipa/sch-ipa.txt +++ b/doc/ipa/sch-ipa.txt @@ -87,3 +87,96 @@ on IPA masters. As 'system-auth' PAM service is not used directly by any other application, it is safe to use it for trusted domain users via compatibility path. + +== Support for ID views == + +When FreeIPA 4.1 is in use, Schema compatibility plugin can be configured to +override POSIX attributes according to an identity view (ID View) which +contains overrides for users and groups. + +The overrides are managed by FreeIPA separately for users and groups: + +* management of ID views: + ipa idview-add 'my view' + +* management of an override for a user: + ipa idoverrideuser-add 'my view' auser --login=foo --shell=/bin/ksh \ + --homedir=/home/foo --uid=12345 + +* management of an override for a group: + ipa idoverridegroup-add 'my view' agroup --group-name=bgroup --gid=54321 + +FreeIPA transparently supports overrides for users and groups from trusted AD +domains. This means that for trusted domains, IPA doesn't require to place +POSIX attributes in Active Directory. Instead, a global ID view named 'Default +Trust View' is used to contain POSIX attributes for existing AD users. +Additionally, specialized ID views can be added on top of the 'Default Trust +View' and then assigned to specific hosts. + +Schema compatibility plugin does support ID overrides from a single view. The +feature is designed to allow host-specific ID view, where the view is specified +through the search base. + +For native IPA users default POSIX attributes are stored natively, thus only a +host-specific ID view is applied, if any. For trusted AD users 'Default Trust +View' ID view is applied automatically by SSSD running on the IPA master, thus +Schema compatibility plugin only applies a host-specific ID view, if specified. + +In FreeIPA Schema compatibility is configured to serve entries through the +host-specific ID view with base DN of cn=,cn=views,cn=compat,$SUFFIX. + +=== ID views implementation === +Detailed design of ID views in FreeIPA can be seen here: +http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust + +In Schema compatibility plugin support for ID views is done on top of existing +map cache. It is expected that there are less overrides than non-overridden +entries for IPA users and groups. For trusted AD users POSIX attributes from +'Default Trust View' are applied by SSSD on IPA master. Thus, if there are no +host-specific overrides, trusted AD users treated by Schema compatibility +plugin as before -- as entries which content comes from nssswitch API. + +This approach allows to only keep original entry in the memory and apply +host-specific override only at the time when entry with explicitly requested ID +view is returned as part of a search result. + +In order to map original entry to an override, FreeIPA configuration for Schema +compatibility plugin adds ipaAnchorUUID attribute and ipaOverrideTarget object +class to every generated entry. ipaAnchorUUID is based on ipaUniqueID for IPA +objects and on SID for trusted AD objects: + +* ipaAnchorUUID=:IPA:: for IPA object (user, group)_ + +* ipaAnchorUUID=:SID: for trusted AD user or group + +For ID overrides FreeIPA maintains ipaAnchorUUID with the same value so that an +override can be found by simple matching of the ipaAnchorUUID attribute's +value. FreeIPA also stores original uid value for user objects in ID override +as ipaOriginalUid attribute, to allow mapping back memberUid values for groups. + +When a query request comes, the view in the base DN is detected and remembered. +Base DN is rewritten to exclude the cn=,cn=views so that a normal +search can be performed against cached entries. Additionally, search filter is +analyzed to replace references to rewritten uid (for user) and cn (for group) +attributes by references to the original objects. The references come from the +ID view overrides, if they exist. + +Once search results are gathered for the map, they are processed in order to +apply an override. For users entry attributes overridden with the values from +an override. For groups additional processing is performed on values of +memberUid attribute. + +As opposed to member attribute, memberUid attribute contains only values of uid +attribute of the original member entry. Given that an ID override may redefine +uid value, corresponding memberUid value of a group needs to be rewritten to +include redefined uid value. In order to do that, original memberUid value is +compared with ipaOriginalUid attribute's value to find an override +corresponding to the original user object. If such override is detected, memberUid +value is replaced by the uid value of the override. + +When attributes of the entry are processed and optionally amended with overridden +values, DN of the entry is rewritten as well, to reflect the fact that entry is +served through the view. + +For all returned entries ipaAnchorUUID attribute and ipaOverrideTarget objectclass +are removed. Resulting entry is sent to the client. diff --git a/src/Makefile.am b/src/Makefile.am index e4fe1a9..6f4926e 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -78,6 +78,10 @@ schemacompat_plugin_la_SOURCES += back-sch-pam.c schemacompat_plugin_la_LIBADD += $(PAM_LIBS) endif +if USE_IPA_IDVIEWS +schemacompat_plugin_la_SOURCES += back-sch-idview.c +endif + noinst_LTLIBRARIES = dummy-nis-plugin.la dummy_nis_plugin_la_SOURCES = \ disp-nis.c \ diff --git a/src/back-sch-idview.c b/src/back-sch-idview.c new file mode 100644 index 0000000..e1c053d --- /dev/null +++ b/src/back-sch-idview.c @@ -0,0 +1,392 @@ +/* + * Copyright 2014 Red Hat, Inc. + * + * 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; version 2 of the License. + * + * 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 PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + +#include +#include "../yp/yp.h" + +#ifdef HAVE_TCPD_H +#include +#endif + +#include "backend.h" +#include "back-shr.h" +#include "format.h" +#include "plugin.h" +#include "map.h" +#include "back-sch.h" + +void +idview_get_overrides(struct backend_search_cbdata *cbdata) +{ + char *dn = NULL; + int ret = 0, result = 0; + const Slapi_DN *suffix = NULL; + Slapi_PBlock *pb; + + if (cbdata->idview == NULL) + return; + + pb = wrap_pblock_new(cbdata->pb); + if (pb == NULL) + return; + + wrap_inc_call_level(); + + suffix = slapi_get_suffix_by_dn(cbdata->target_dn); + dn = slapi_ch_smprintf("cn=%s,cn=views,cn=accounts,%s", cbdata->idview, slapi_sdn_get_dn(suffix)); + /* Fetch all attributes; there is a bug in 389-ds: it gives out all attributes for the entry anyway + * when search returns Slapi_Entry* objects. Instead, we'll do removal later */ + slapi_search_internal_set_pb(pb, dn, LDAP_SCOPE_SUBTREE, + "(objectclass=ipaOverrideAnchor)", NULL, 0, + NULL, NULL, cbdata->state->plugin_identity, 0); + ret = slapi_search_internal_pb(pb); + slapi_ch_free_string(&dn); + slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_RESULT, &result); + + if (result == 0) { + /* Steal search result entries to avoid re-allocating them */ + slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, &(cbdata->overrides)); + slapi_pblock_set(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, NULL); + } + + wrap_dec_call_level(); + slapi_pblock_destroy(pb); +} + +void +idview_free_overrides(struct backend_search_cbdata *cbdata) +{ + int i = 0; + if (cbdata->overrides != NULL) { + for(i=0; cbdata->overrides[i] != NULL; i++) { + slapi_entry_free(cbdata->overrides[i]); + } + slapi_ch_free((void**)&(cbdata->overrides)); + } +} + +void +idview_process_overrides(struct backend_search_cbdata *cbdata, + const char *key, const char *map, const char *domain, + Slapi_Entry *entry) +{ +#define VIEW_TEMPLATE_KEY_MAP_DOMAIN 0 +#define VIEW_TEMPLATE_KEY_MAP_DOMAIN_NEWKEY 3 +#define VIEW_TEMPLATE_MAP_DOMAIN 1 +#define VIEW_TEMPLATE_DOMAIN 2 + /* After view was applied, entry's DN needs to reflect the view */ + const char *dn_template[] = {"%s,%s,cn=%s,cn=views,%s", /* an entry for user or group */ + "%s,cn=%s,cn=views,%s", /* an entry for a map (container for users or groups) */ + "cn=%s,cn=views,%s", /* an entry is a base of the compat tree */ + "%s=%s,%s,cn=%s,cn=views,%s", /* an entry for user or group which RDN was overridden with new value */ + }; + const char *filterout_attrs[] = {"objectclass", "creatorsname", "modifiersname", + "createtimestamp", "modifytimestamp", "parentid", + "entryusn", "entryid", "entrydn", "ipaoriginaluid", + "ipaanchoruuid", "nsuniqueid", NULL }; + char *new_dn = NULL, *new_key = NULL, *sep = NULL, *new_val = NULL; + char *override_type = NULL; + Slapi_Entry *override_entry = NULL; + Slapi_Attr *anchor = NULL, *id_attr = NULL; + Slapi_Value *anchor_value = NULL, *id_value = NULL; + int i, result, dn_template_id; + + if (cbdata->overrides == NULL) { + /* Only retrieve overrides for the view first time when neccessary */ + idview_get_overrides(cbdata); + if (cbdata->overrides == NULL) + return; + } + + /* 1. See if the entry has ipaAnchorUUID and selected idview has an override for it */ + /* The code below intentionally uses Slapi_Value instead of comparing string values to + * avoid allocating additional memory */ + result = slapi_entry_attr_find(entry, IPA_IDVIEWS_ATTR_ANCHORUUID, &anchor); + if ((result == 0) && (anchor != NULL) && (cbdata->overrides != NULL)) { + result = slapi_attr_first_value(anchor, &anchor_value); + for(i = 0; cbdata->overrides[i] != NULL; i++) { + result = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ANCHORUUID, &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + result = slapi_value_compare(id_attr, anchor_value, id_value); + if (result == 0) { + override_entry = cbdata->overrides[i]; + break; + } + } + } + } + + /* 2. If there is indeed an override, replace attribute values except for the ones that should be ignored */ + if (override_entry != NULL) { + Slapi_Attr *override_attr = NULL; + + result = slapi_entry_first_attr(override_entry, &override_attr); + while (result == 0) { + Slapi_ValueSet *override_valueset = NULL; + + /* Filter out override attributes that we don't care about */ + result = slapi_attr_get_type(override_attr, &override_type); + for (i = 0; filterout_attrs[i] != NULL; i++) { + if (strcasecmp(override_type, filterout_attrs[i]) == 0) { + break; + } + } + + if (filterout_attrs[i] == NULL) { + /* Replace the attribute's value with the override or + * add an override value if the attribute didn't exist */ + result = slapi_entry_attr_exists(entry, override_type); + if (result == 1) { + result = slapi_entry_attr_delete(entry, override_type); + } + result = slapi_attr_get_valueset(override_attr, &override_valueset); + result = slapi_entry_add_valueset(entry, override_type, override_valueset); + } + result = slapi_entry_next_attr(override_entry, override_attr, &override_attr); + } + } + + /* 3. If entry has memberUid, we need to replace memberUid values too, if they were overridden */ + override_type = "memberUid"; + result = slapi_entry_attr_find(entry, override_type, &anchor); + if ((result == 0) && (anchor != NULL) && (cbdata->overrides != NULL)) { + int value_idx = 0; + Slapi_ValueSet *new_valueset = slapi_valueset_new(); + + if (new_valueset != NULL) { + /* For each memberUid value, find an override with ipaOriginalUid attribute of the same value */ + value_idx = slapi_attr_first_value(anchor, &anchor_value); + while (value_idx != -1) { + bool_t value_found = FALSE; + for(i = 0; cbdata->overrides[i] != NULL; i++) { + result = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ORIGINALUID, &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + result = slapi_value_compare(id_attr, anchor_value, id_value); + if (result == 0) { + /* If there is an override with ipaOriginalUid: , use its 'uid' value to override */ + result = slapi_entry_attr_find(cbdata->overrides[i], "uid", &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + if (result == 0) { + /* finally: we have an override with ipaOriginalUid: _and_ + * this override is changing the 'uid' attribute so we have something to replace */ + slapi_valueset_add_value(new_valueset, id_value); + value_found = TRUE; + break; + } + } + } + } + } + + if (value_found == FALSE) { + slapi_valueset_add_value(new_valueset, anchor_value); + } + value_idx = slapi_attr_next_value(anchor, value_idx, &anchor_value); + } + + result = slapi_entry_attr_delete(entry, override_type); + result = slapi_entry_add_valueset(entry, override_type, new_valueset); + slapi_valueset_free(new_valueset); + } + } + + /* 4. Even if there were no overrides, since we are serving throught the view, replace DN value */ + dn_template_id = (key == NULL ? 1 : 0) + (map == NULL ? 1 : 0); + switch (dn_template_id) { + case VIEW_TEMPLATE_KEY_MAP_DOMAIN: + /* update RDN with proper value from the entry after overrides were applied */ + sep = strchr(key, '='); + if (sep != NULL) { + sep[0] = '\0'; + new_val = slapi_entry_attr_get_charptr(entry, key); + new_dn = slapi_ch_smprintf(dn_template[VIEW_TEMPLATE_KEY_MAP_DOMAIN_NEWKEY], key, new_val, map, cbdata->idview, domain); + slapi_ch_free_string(&new_val); + sep[0] = '='; + } else { + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], key, map, cbdata->idview, domain); + } + break; + case VIEW_TEMPLATE_MAP_DOMAIN: + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], map, cbdata->idview, domain); + break; + case VIEW_TEMPLATE_DOMAIN: + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], cbdata->idview, domain); + break; + }; + slapi_entry_set_dn(entry, new_dn); +} + +void +idview_replace_target_dn(char **target, char **idview) +{ + char *idview_p = NULL; + char *cnviews = NULL; + char *new_target = NULL; + + cnviews = strstr(*target, ",cn=views,"); + if (cnviews != NULL && cnviews != *target) { + cnviews[0] = '\0'; + idview_p = strrchr(*target, ','); + if (idview_p == NULL) { + idview_p = *target; + } else { + idview_p++; + } + if (strstr(idview_p, "cn=") != idview_p) { + cnviews[0] = ','; + return; + } + *idview = slapi_ch_strdup(&idview_p[3]); + if (idview_p != *target) { + idview_p[0] = '\0'; + new_target = slapi_ch_smprintf("%s%s", *target, cnviews+10); + idview_p--; + idview_p[0] = ','; + } else { + new_target = slapi_ch_smprintf("%s", cnviews+10); + } + cnviews[0] = ','; + *target = new_target; + } +} + +static int +idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct berval *bval, struct backend_search_filter_config *config) +{ + int res, i; + Slapi_Value *filter_val, *value, *anchor_val; + Slapi_Attr *anchor, *attr = NULL; + struct backend_search_cbdata *cbdata = (struct backend_search_cbdata *) config->callback_data; + + if (cbdata == NULL || cbdata->idview == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + if (filter_type == NULL || config->name == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + if (cbdata->overrides == NULL) { + /* Only retrieve overrides for the view first time when neccessary */ + idview_get_overrides(cbdata); + } + + if (cbdata->overrides == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + filter_val = slapi_value_new_berval(bval); + + /* If filter contains an attribute name which is overridden in the view and filter value + * corresponds to the override, replace the filter by (ipaAnchorUUID=...) from the override + * to point to the original because otherwise an entry will not be found in the slapi-nis map */ + for(i=0; cbdata->overrides[i] != NULL; i++) { + res = slapi_entry_attr_find(cbdata->overrides[i], filter_type, &attr); + if ((res == 0) && (attr != NULL)) { + res = slapi_attr_first_value(attr, &value); + res = slapi_value_compare(attr, value, filter_val); + if (res == 0) { + /* For uid overrides we should have ipaOriginalUID in the override */ + if (strcasecmp(filter_type, "uid") == 0) { + res = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ORIGINALUID, &anchor); + if (res == 0) { + res = slapi_attr_first_value(anchor, &anchor_val); + slapi_ber_bvdone(bval); + slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); + config->override_found = TRUE; + break; + } + } + + /* otherwise, use ipaAnchorUUID value */ + res = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ANCHORUUID, &anchor); + if (res == 0) { + res = slapi_attr_first_value(anchor, &anchor_val); + slapi_filter_changetype(filter, IPA_IDVIEWS_ATTR_ANCHORUUID); + slapi_ber_bvdone(bval); + slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); + config->override_found = TRUE; + break; + } + + } + } + } + + slapi_value_free(&filter_val); + + return SLAPI_FILTER_SCAN_CONTINUE; + +} + +/* Traverse through the filter and replace overridden attribute/value pairs with references to the original + * entries. This allows to properly handle overrides of uid and cn attributes where searches look like + * (&(objectclass=posixAccount)(uid=foobar)) -- if uid=foobar is part of an override for uid=admin, we need + * to point back to uid=admin to be able to find original entry in the slapi-nis cache. + * + * Note that in reality we don't use original value of the uid/cn attribue. Instead, we use ipaAnchorUUID + * to refer to the original entry. */ +extern char * +slapi_filter_to_string( const struct slapi_filter *f, char *buf, size_t bufsize ); +void +idview_replace_filter(struct backend_search_cbdata *cbdata) +{ + struct backend_search_filter_config config = + {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL, NULL, NULL}; + int res = 0; + + if (cbdata->idview == NULL) { + return; + } + + config.callback = idview_process_filter_cb; + config.callback_data = cbdata; + + /* Ignore the return code as it will always be SLAPI_FILTER_SCAN_NO_MORE */ + res = backend_analyze_search_filter(cbdata->filter, &config); + + if (config.name != NULL) { + slapi_ch_free_string(&config.name); + } + +} diff --git a/src/back-sch-nss.c b/src/back-sch-nss.c index f192bb9..26d4b8c 100644 --- a/src/back-sch-nss.c +++ b/src/back-sch-nss.c @@ -52,16 +52,20 @@ #include "back-sch.h" #include "format.h" -struct backend_search_filter_config { - bool_t search_user; - bool_t search_group; - bool_t search_uid; - bool_t search_gid; - bool_t search_members; - bool_t name_set; - bool_t wrong_search; - char *name; -}; +static int +bvstrprefix(const struct berval *bval, const char *s) +{ + size_t len; + int c; + + len = strlen(s); + if (len < bval->bv_len) { + return strncasecmp(bval->bv_val, s, len) != 0; + } + + return 1; + +} static int bvstrcasecmp(const struct berval *bval, const char *s) @@ -115,6 +119,14 @@ backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) } else if ((0 == strcasecmp(filter_type, "objectClass")) && (0 == bvstrcasecmp(bval, "shadowAccount"))) { config->wrong_search = TRUE; +#ifdef HAVE_SSS_NSS_IDMAP +#ifdef USE_IPA_IDVIEWS + } else if ((0 == strcasecmp(filter_type, "ipaAnchorUUID")) && + (0 == bvstrprefix(bval, ":SID:S-"))) { + config->search_sid = TRUE; + config->name_set = TRUE; +#endif +#endif } if ((NULL == config->name) && config->name_set) { @@ -127,10 +139,15 @@ backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) } } + if (config->callback != NULL) { + return config->callback(filter, filter_type, bval, config); + } + if ((config->search_uid || config->search_gid || config->search_user || - config->search_group) && (config->name != NULL)) { + config->search_group || + config->search_sid) && (config->name != NULL)) { return SLAPI_FILTER_SCAN_STOP; } return SLAPI_FILTER_SCAN_CONTINUE; @@ -211,21 +228,21 @@ backend_make_user_entry_from_nsswitch_passwd(struct passwd *pwd, slapi_entry_add_string(entry, "objectClass", "posixAccount"); slapi_entry_add_string(entry, - "objectClass", "extensibleObject"); - slapi_entry_add_string(entry, "uid", pwd->pw_name); slapi_entry_attr_set_uint(entry, "uidNumber", pwd->pw_uid); slapi_entry_attr_set_uint(entry, "gidNumber", pwd->pw_gid); - slapi_entry_add_string(entry, - "gecos", pwd->pw_gecos); if (strlen(pwd->pw_gecos) > 0) { slapi_entry_add_string(entry, "cn", pwd->pw_gecos); + slapi_entry_add_string(entry, + "gecos", pwd->pw_gecos); } else { slapi_entry_add_string(entry, "cn", pwd->pw_name); + slapi_entry_add_string(entry, + "gecos", pwd->pw_name); } slapi_entry_add_string(entry, @@ -240,7 +257,20 @@ backend_make_user_entry_from_nsswitch_passwd(struct passwd *pwd, #ifdef HAVE_SSS_NSS_IDMAP rc = sss_nss_getsidbyid(pwd->pw_uid, &sid_str, &id_type); if ((rc == 0) && (sid_str != NULL)) { +#ifdef USE_IPA_IDVIEWS + char *anchor = NULL; + /* For overrides of AD users to work correctly, we need to generate + * ipaAnchorUUID value so that idviews can be properly searched for the override */ + anchor = slapi_ch_smprintf(":SID:%s", sid_str); + if (anchor != NULL) { + slapi_entry_add_string(entry, "objectClass", "ipaOverrideTarget"); + slapi_entry_add_string(entry, "ipaAnchorUUID", anchor); + slapi_ch_free_string(&anchor); + } +#else + slapi_entry_add_string(entry, "objectClass", "extensibleObject"); slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); +#endif free(sid_str); } #endif @@ -335,8 +365,6 @@ backend_make_group_entry_from_nsswitch_group(struct group *grp, slapi_entry_add_string(entry, "objectClass", "posixGroup"); slapi_entry_add_string(entry, - "objectClass", "extensibleObject"); - slapi_entry_add_string(entry, "cn", grp->gr_name); slapi_entry_attr_set_uint(entry, "gidNumber", grp->gr_gid); @@ -352,7 +380,20 @@ backend_make_group_entry_from_nsswitch_group(struct group *grp, #ifdef HAVE_SSS_NSS_IDMAP rc = sss_nss_getsidbyid(grp->gr_gid, &sid_str, &id_type); if ((rc == 0) && (sid_str != NULL)) { +#ifdef USE_IPA_IDVIEWS + char *anchor = NULL; + /* For overrides of AD users to work correctly, we need to generate + * ipaAnchorUUID value so that idviews can be properly searched for the override */ + anchor = slapi_ch_smprintf(":SID:%s", sid_str); + if (anchor != NULL) { + slapi_entry_add_string(entry, "objectClass", "ipaOverrideTarget"); + slapi_entry_add_string(entry, "ipaAnchorUUID", anchor); + slapi_ch_free_string(&anchor); + } +#else + slapi_entry_add_string(entry, "objectClass", "extensibleObject"); slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); +#endif free(sid_str); } #endif @@ -558,6 +599,16 @@ nsswitch_type_to_name(enum sch_search_nsswitch_t type) return "(unknown)"; } +int +backend_analyze_search_filter(Slapi_Filter *filter, struct backend_search_filter_config *config) +{ + int result, rc; + result = slapi_filter_apply(filter, + backend_search_filter_has_cn_uid, + config, &rc); + return (result != SLAPI_FILTER_SCAN_STOP) ? 1 : 0; +} + /* Check if the filter is one (like uid=) that should trigger an * nsswitch lookup, and if it is, make a note that we should perform such a * lookup. */ @@ -566,15 +617,15 @@ backend_search_nsswitch(struct backend_set_data *set_data, struct backend_search_cbdata *cbdata) { int result, rc; - struct backend_search_filter_config config = {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL}; + struct backend_search_filter_config config = + {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL, NULL, NULL}; struct backend_staged_search *staged = NULL; char *idptr = NULL; unsigned long id; /* First, we search the filter to see if it includes a cn|uid= test. */ - result = slapi_filter_apply(cbdata->filter, - backend_search_filter_has_cn_uid, &config, &rc); - if ((result != SLAPI_FILTER_SCAN_STOP)) { + result = backend_analyze_search_filter(cbdata->filter, &config); + if (result != 0) { return; } @@ -624,6 +675,7 @@ backend_search_nsswitch(struct backend_set_data *set_data, staged->type = cbdata->check_nsswitch; staged->name = config.name; /* takes ownership */ staged->is_id = config.search_gid || config.search_uid; + staged->is_sid = config.search_sid; staged->search_members = config.search_members; staged->next = cbdata->staged; @@ -649,6 +701,23 @@ backend_retrieve_from_nsswitch(struct backend_staged_search *staged, { Slapi_Entry **entries; +#ifdef HAVE_SSS_NSS_IDMAP + if (staged->is_sid) { + char *name = NULL; + enum sss_id_type id_type; + /* we expect name to be a SID prefixed with :SID: */ + int result = sss_nss_getnamebysid(staged->name+5, &name, &id_type); + if (result == 0) { + staged->is_sid = FALSE; + staged->is_id = FALSE; + + slapi_ch_free_string(&staged->name); + staged->name = slapi_ch_strdup(name); + free(name); + } + } +#endif + if (((staged->type == SCH_NSSWITCH_GROUP) && staged->search_members) && (NULL != staged->name)) { entries = backend_retrieve_group_list_from_nsswitch(staged->name, staged->container_sdn, diff --git a/src/back-sch.c b/src/back-sch.c index 78f2627..27d5101 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -259,15 +259,6 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, free(nsswitch_min_id); } - if (ret.check_nsswitch != SCH_NSSWITCH_NONE) { - /* If we're adding nsswitch-based entries to this map, make - * sure that we copy the schema-compat-origin and SID - * attributes, so that we can read the former during the BIND - * callback. */ - backend_shr_add_strlist(&ret.attribute_format, "objectClass=%ifeq(\"%{ipaNTSecurityIdentifier}\",\"\",\"\",\"extensibleObject\")"); - backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); - } - *pret = backend_copy_set_config(&ret); if (*pret == NULL) { if (strlen(container) > 0) { @@ -1005,6 +996,7 @@ backend_search_entry_cb(const char *domain, const char *map, bool_t secure, void *backend_data, void *cb_data) { Slapi_DN *sdn; + Slapi_Entry *entry; struct backend_search_cbdata *cbdata; struct backend_entry_data *entry_data; int result; @@ -1043,9 +1035,25 @@ backend_search_entry_cb(const char *domain, const char *map, bool_t secure, cbdata->state->plugin_desc->spd_id, "search matched %s\n", slapi_sdn_get_ndn(sdn)); - slapi_send_ldap_search_entry(cbdata->pb, entry_data->e, NULL, + entry = entry_data->e; +#ifdef USE_IPA_IDVIEWS + entry = slapi_entry_dup(entry_data->e); + if (cbdata->idview != NULL) { + idview_process_overrides(cbdata, key, map, domain, entry); + } + + if (slapi_entry_attr_exists(entry, IPA_IDVIEWS_ATTR_ANCHORUUID) == 1) { + slapi_entry_attr_delete(entry, IPA_IDVIEWS_ATTR_ANCHORUUID); + slapi_entry_delete_string(entry, "objectClass", "ipaOverrideTarget"); + } +#endif + slapi_send_ldap_search_entry(cbdata->pb, entry, NULL, cbdata->attrs, cbdata->attrsonly); cbdata->n_entries++; + + if (entry != entry_data->e) { + slapi_entry_free(entry); + } break; } @@ -1104,6 +1112,13 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, "search matched %s\n", ndn); +#ifdef USE_IPA_IDVIEWS + if (cbdata->idview != NULL) { + idview_process_overrides(cbdata, NULL, + set_data->common.set, + set_data->common.group, set_entry); + } +#endif slapi_send_ldap_search_entry(cbdata->pb, set_entry, NULL, cbdata->attrs, cbdata->attrsonly); @@ -1216,6 +1231,11 @@ backend_search_group_cb(const char *group, void *cb_data) slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, "search matched %s\n", group); +#ifdef USE_IPA_IDVIEWS + if (cbdata->idview != NULL) { + idview_process_overrides(cbdata, NULL, NULL, group, group_entry); + } +#endif slapi_send_ldap_search_entry(cbdata->pb, group_entry, NULL, cbdata->attrs, cbdata->attrsonly); @@ -1313,11 +1333,16 @@ backend_search_cb(Slapi_PBlock *pb) cbdata.n_entries = 0; cbdata.staged = NULL; cbdata.cur_staged = NULL; + cbdata.idview = NULL; + cbdata.overrides = NULL; /* Okay, we can search. */ slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, "searching from \"%s\" for \"%s\" with scope %d%s\n", cbdata.target, cbdata.strfilter, cbdata.scope, backend_sch_scope_as_string(cbdata.scope)); +#ifdef USE_IPA_IDVIEWS + idview_replace_target_dn(&cbdata.target, &cbdata.idview); +#endif cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); /* Check if there's a backend handling this search. */ if (!slapi_be_exist(cbdata.target_dn)) { @@ -1326,10 +1351,21 @@ backend_search_cb(Slapi_PBlock *pb) "slapi_be_exists(\"%s\") = 0, " "ignoring search\n", cbdata.target); slapi_sdn_free(&cbdata.target_dn); + if (cbdata.idview != NULL) { + slapi_ch_free_string(&cbdata.target); + } + slapi_ch_free_string(&cbdata.idview); +#ifdef USE_IPA_IDVIEWS + idview_free_overrides(&cbdata); +#endif return 0; } + /* Walk the list of groups. */ wrap_inc_call_level(); +#ifdef USE_IPA_IDVIEWS + idview_replace_filter(&cbdata); +#endif if (map_rdlock() == 0) { map_data_foreach_domain(cbdata.state, backend_search_group_cb, &cbdata); @@ -1468,6 +1504,13 @@ backend_search_cb(Slapi_PBlock *pb) cbdata.n_entries, NULL); } slapi_sdn_free(&cbdata.target_dn); + if (cbdata.idview != NULL) { + slapi_ch_free_string(&cbdata.target); + } + slapi_ch_free_string(&cbdata.idview); +#ifdef USE_IPA_IDVIEWS + idview_free_overrides(&cbdata); +#endif free(cbdata.closest_match); free(cbdata.text); return cbdata.answer ? -1 : 0; @@ -1525,6 +1568,7 @@ static void backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char **group, const char**set) { struct backend_locate_cbdata cbdata; + char *idview = NULL; slapi_pblock_get(pb, SLAPI_PLUGIN_PRIVATE, &cbdata.state); if (cbdata.state->plugin_base == NULL) { @@ -1533,6 +1577,9 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** return; } slapi_pblock_get(pb, SLAPI_TARGET_DN, &cbdata.target); +#ifdef USE_IPA_IDVIEWS + idview_replace_target_dn(&cbdata.target, &idview); +#endif cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); cbdata.entry_data = NULL; cbdata.entry_group = NULL; @@ -1542,6 +1589,10 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** *group = cbdata.entry_group; *set = cbdata.entry_set; slapi_sdn_free(&cbdata.target_dn); + if (idview != NULL) { + slapi_ch_free_string(&cbdata.target); + } + slapi_ch_free_string(&idview); } /* Check if the target DN is part of this group's tree. If it is, return an diff --git a/src/back-sch.h b/src/back-sch.h index 2f4a3df..9f0b201 100644 --- a/src/back-sch.h +++ b/src/back-sch.h @@ -55,6 +55,7 @@ struct backend_staged_search { struct backend_set_data *set_data; enum sch_search_nsswitch_t type; bool_t is_id; + bool_t is_sid; /* if search is by ipaAnchorUUID beginning with :SID:S-... */ bool_t search_members; char *name; char *container_sdn; @@ -69,6 +70,8 @@ struct backend_search_cbdata { Slapi_PBlock *pb; struct plugin_state *state; char *target, *strfilter, **attrs; + char *idview; + Slapi_Entry **overrides; int scope, sizelimit, timelimit, attrsonly; bool_t check_access; enum sch_search_nsswitch_t check_nsswitch; @@ -87,6 +90,31 @@ struct backend_search_cbdata { struct backend_staged_search *cur_staged; }; +struct backend_search_filter_config { + bool_t search_user; + bool_t search_group; + bool_t search_uid; + bool_t search_gid; + bool_t search_sid; + bool_t search_members; + bool_t name_set; + bool_t wrong_search; + bool_t override_found; + char *name; + /* If callback is defined, it is called on each filter after analyzing it. + * Return code of the callback is directly returned to slapi_filter_apply() */ + int (*callback)(Slapi_Filter *filter, const char *filter_type, struct berval *bval, struct backend_search_filter_config *config); + void *callback_data; +}; + +/* Analyzes the filter to decide what kind of NSS search is it + * Returns 0 on success, 1 on failure + * struct backend_search_filter_config is populated with information about the filter + * config.name should be freed with slapi_ch_free_string() + */ + +int backend_analyze_search_filter(Slapi_Filter *filter, struct backend_search_filter_config *config); + void backend_search_nsswitch(struct backend_set_data *set_data, struct backend_search_cbdata *cbdata); @@ -95,4 +123,14 @@ bool_t backend_retrieve_from_nsswitch(struct backend_staged_search *staged, int backend_sch_do_pam_auth(Slapi_PBlock *pb, const char *username); +#ifdef USE_IPA_IDVIEWS +void idview_get_overrides(struct backend_search_cbdata *cbdata); +void idview_free_overrides(struct backend_search_cbdata *cbdata); +void idview_process_overrides(struct backend_search_cbdata *cbdata, + const char *key, const char *map, const char *domain, + Slapi_Entry *entry); +void idview_replace_target_dn(char **target, char **idview); +void idview_replace_filter(struct backend_search_cbdata *cbdata); +#endif + #endif -- 2.1.0 From mbasti at redhat.com Wed Oct 8 18:08:24 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 08 Oct 2014 20:08:24 +0200 Subject: [Freeipa-devel] [PATCH 0133] Fix ipactl service ordering In-Reply-To: <5435513B.8090904@redhat.com> References: <5435513B.8090904@redhat.com> Message-ID: <54357D98.4060608@redhat.com> On 08/10/14 16:59, Martin Basti wrote: > IPA sorts service order alphabetically, this patch modify ipactl to > use integers. > > How to reproduce: > set attribute ipaConfigString: startOrder 150 > DN: cn=HTTP,cn=ipa.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > > then run > #ipactl restart > > httpd service should start as last service, but it starts almost first. > > Patch attached. > selfNACK -- Martin Basti From tbordaz at redhat.com Wed Oct 8 19:45:38 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 08 Oct 2014 21:45:38 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412789453.9441.1.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> Message-ID: <54359462.5080409@redhat.com> On 10/08/2014 07:30 PM, Nathaniel McCallum wrote: > On Wed, 2014-10-08 at 17:30 +0200, thierry bordaz wrote: >> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: >>> Attached is the latest patch. I believe this includes all of our >>> discussions up until this point. However, a few bits of additional >>> information are needed. >>> >>> First, I have renamed the plugin to ipa-otp-counter. I believe all >>> replay prevention work can land inside this plugin, so the name is >>> appropriate. >>> >>> Second, I uncovered a bug in 389 which prevents me from validating the >>> non-replication request in bepre. This is the reason for the additional >>> betxnpre callback. If the upstream 389 bug is fixed, we can merge this >>> check back into bepre. https://fedorahosted.org/389/ticket/47919 >>> >>> Third, I believe we are now handling replication correct. An error is >>> never returned. When a replication would cause the counter to decrease, >>> we remove all counter/watermark related mods from the operation. This >>> will allow the replication to apply without decrementing the value. >>> There is also a new bepost method which check to see if the replication >>> was discarded (via CSN) while having a higher counter value. If so, we >>> apply the higher counter value. >> For me the code is good. It took me some time to understand the benefit >> of removing mods in preop. >> In fact I think it is a good idea, as it prevents extra repair ops and >> also make more easy the computation of the value to set in repair mod. >>> Here is the scenario. Server X receives two quick authentications; >>> replications A and B are sent to server Y. Before server Y can process >>> server X's replications, an authentication is performed on server Y; >>> replication C is sent to server X. The following logic holds true: >>> * csnA < csnB < csnC >>> * valueA = valueC, valueB > valueC >>> >>> When server X receives replication C, ipa-otp-counter will strip out all >>> counter mod operations; applying the update but not the lower value. The >>> value of replication B is retained. This is the correct behavior. >>> >>> When server Y processes replications A and B, ipa-otp-counter will >>> detect that a higher value has a lower CSN and will manually set the >>> higher value (in bepost). This initiates replication D, which is sent to >>> server X. Here is the logic: >>> * csnA < csnB < csnC < csnD >>> * valueA = valueC, valueB = valueD, valueD > valueC >>> >>> Server X receives replication D. D has the highest CSN. It has the same >>> value as replication B (server X's current value). Because the values >>> are the same, ipa-otp-counter will strip all counter mod operations. >>> This reduces counter write contention which might become a problem in >>> N-way replication when N>2. >> I think we should rather let the mods going on. So that the full >> topology will have >> valueD (or valueB)/csnD rather having a set of servers having >> valueD/csnB and an other set valueD/csnD. > I think you misunderstand. The value for csnD is only discarded when the > server already has valueB (valueB == valueD). Only the value is > discarded, so csnD is still applied. The full topology will have either > valueB w/ csnD or valueD w/ csnD. Since, valueB always equals valueD, by > substitution, all servers have valueD w/ csnD. > > Nathaniel > There are several parts where the CSN are stored. One is used to allow replication protocol to send the approriate updates. This part is stored into a dedicated entry: RUV. In fact when the update valudD/CSND will be received and applied, the RUV will be updated with csnD. An other part is the attribute/attribute values. An attribute value contains the actual value and the CSN associated to that value. This CSN is updated by entry_apply_mod_wsi when it decides which value to keep and which CSN is associated to this value. In the example above, on the server X, the counter attribute has valueB/csnB. Then it receives the update ValueD/csnD it discard this update because valueD=ValueB. That means that on serverX we will have valueB/csnB. Now if on an other server we receive the updates in the reverse order: valueD/csnD first then valueB/csnB. This server will apply and valueD/csnD then will discard valueB/csnB. ValueD and ValueB being identical it is not a big issue. But we will have some server with csnD and others with csnB. thanks thierry From rmeggins at redhat.com Wed Oct 8 19:53:00 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 08 Oct 2014 13:53:00 -0600 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <54359462.5080409@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> Message-ID: <5435961C.9050501@redhat.com> On 10/08/2014 01:45 PM, thierry bordaz wrote: > On 10/08/2014 07:30 PM, Nathaniel McCallum wrote: >> On Wed, 2014-10-08 at 17:30 +0200, thierry bordaz wrote: >>> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: >>>> Attached is the latest patch. I believe this includes all of our >>>> discussions up until this point. However, a few bits of additional >>>> information are needed. >>>> >>>> First, I have renamed the plugin to ipa-otp-counter. I believe all >>>> replay prevention work can land inside this plugin, so the name is >>>> appropriate. >>>> >>>> Second, I uncovered a bug in 389 which prevents me from validating the >>>> non-replication request in bepre. This is the reason for the >>>> additional >>>> betxnpre callback. If the upstream 389 bug is fixed, we can merge this >>>> check back into bepre. https://fedorahosted.org/389/ticket/47919 >>>> >>>> Third, I believe we are now handling replication correct. An error is >>>> never returned. When a replication would cause the counter to >>>> decrease, >>>> we remove all counter/watermark related mods from the operation. This >>>> will allow the replication to apply without decrementing the value. >>>> There is also a new bepost method which check to see if the >>>> replication >>>> was discarded (via CSN) while having a higher counter value. If so, we >>>> apply the higher counter value. >>> For me the code is good. It took me some time to understand the benefit >>> of removing mods in preop. >>> In fact I think it is a good idea, as it prevents extra repair ops and >>> also make more easy the computation of the value to set in repair mod. >>>> Here is the scenario. Server X receives two quick authentications; >>>> replications A and B are sent to server Y. Before server Y can process >>>> server X's replications, an authentication is performed on server Y; >>>> replication C is sent to server X. The following logic holds true: >>>> * csnA < csnB < csnC >>>> * valueA = valueC, valueB > valueC >>>> >>>> When server X receives replication C, ipa-otp-counter will strip >>>> out all >>>> counter mod operations; applying the update but not the lower >>>> value. The >>>> value of replication B is retained. This is the correct behavior. >>>> >>>> When server Y processes replications A and B, ipa-otp-counter will >>>> detect that a higher value has a lower CSN and will manually set the >>>> higher value (in bepost). This initiates replication D, which is >>>> sent to >>>> server X. Here is the logic: >>>> * csnA < csnB < csnC < csnD >>>> * valueA = valueC, valueB = valueD, valueD > valueC >>>> >>>> Server X receives replication D. D has the highest CSN. It has the >>>> same >>>> value as replication B (server X's current value). Because the values >>>> are the same, ipa-otp-counter will strip all counter mod operations. >>>> This reduces counter write contention which might become a problem in >>>> N-way replication when N>2. >>> I think we should rather let the mods going on. So that the full >>> topology will have >>> valueD (or valueB)/csnD rather having a set of servers having >>> valueD/csnB and an other set valueD/csnD. >> I think you misunderstand. The value for csnD is only discarded when the >> server already has valueB (valueB == valueD). Only the value is >> discarded, so csnD is still applied. The full topology will have either >> valueB w/ csnD or valueD w/ csnD. Since, valueB always equals valueD, by >> substitution, all servers have valueD w/ csnD. >> >> Nathaniel >> > > There are several parts where the CSN are stored. > One is used to allow replication protocol to send the approriate > updates. This part is stored into a dedicated entry: RUV. > In fact when the update valudD/CSND will be received and applied, the > RUV will be updated with csnD. > > An other part is the attribute/attribute values. An attribute value > contains the actual value and the CSN associated to that value. > This CSN is updated by entry_apply_mod_wsi when it decides which value > to keep and which CSN is associated to this value. > > In the example above, on the server X, the counter attribute has > valueB/csnB. Then it receives the update ValueD/csnD it discard this > update because valueD=ValueB. That means that on serverX we will have > valueB/csnB. > > Now if on an other server we receive the updates in the reverse order: > valueD/csnD first then valueB/csnB. > This server will apply and valueD/csnD then will discard valueB/csnB. > > ValueD and ValueB being identical it is not a big issue. But we will > have some server with csnD and others with csnB. The CSN is also the key in the changelog database. > > thanks > thierry > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From npmccallum at redhat.com Wed Oct 8 19:53:39 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 08 Oct 2014 15:53:39 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <54359462.5080409@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> Message-ID: <1412798019.9441.8.camel@redhat.com> On Wed, 2014-10-08 at 21:45 +0200, thierry bordaz wrote: > On 10/08/2014 07:30 PM, Nathaniel McCallum wrote: > > On Wed, 2014-10-08 at 17:30 +0200, thierry bordaz wrote: > >> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: > >>> Attached is the latest patch. I believe this includes all of our > >>> discussions up until this point. However, a few bits of additional > >>> information are needed. > >>> > >>> First, I have renamed the plugin to ipa-otp-counter. I believe all > >>> replay prevention work can land inside this plugin, so the name is > >>> appropriate. > >>> > >>> Second, I uncovered a bug in 389 which prevents me from validating the > >>> non-replication request in bepre. This is the reason for the additional > >>> betxnpre callback. If the upstream 389 bug is fixed, we can merge this > >>> check back into bepre. https://fedorahosted.org/389/ticket/47919 > >>> > >>> Third, I believe we are now handling replication correct. An error is > >>> never returned. When a replication would cause the counter to decrease, > >>> we remove all counter/watermark related mods from the operation. This > >>> will allow the replication to apply without decrementing the value. > >>> There is also a new bepost method which check to see if the replication > >>> was discarded (via CSN) while having a higher counter value. If so, we > >>> apply the higher counter value. > >> For me the code is good. It took me some time to understand the benefit > >> of removing mods in preop. > >> In fact I think it is a good idea, as it prevents extra repair ops and > >> also make more easy the computation of the value to set in repair mod. > >>> Here is the scenario. Server X receives two quick authentications; > >>> replications A and B are sent to server Y. Before server Y can process > >>> server X's replications, an authentication is performed on server Y; > >>> replication C is sent to server X. The following logic holds true: > >>> * csnA < csnB < csnC > >>> * valueA = valueC, valueB > valueC > >>> > >>> When server X receives replication C, ipa-otp-counter will strip out all > >>> counter mod operations; applying the update but not the lower value. The > >>> value of replication B is retained. This is the correct behavior. > >>> > >>> When server Y processes replications A and B, ipa-otp-counter will > >>> detect that a higher value has a lower CSN and will manually set the > >>> higher value (in bepost). This initiates replication D, which is sent to > >>> server X. Here is the logic: > >>> * csnA < csnB < csnC < csnD > >>> * valueA = valueC, valueB = valueD, valueD > valueC > >>> > >>> Server X receives replication D. D has the highest CSN. It has the same > >>> value as replication B (server X's current value). Because the values > >>> are the same, ipa-otp-counter will strip all counter mod operations. > >>> This reduces counter write contention which might become a problem in > >>> N-way replication when N>2. > >> I think we should rather let the mods going on. So that the full > >> topology will have > >> valueD (or valueB)/csnD rather having a set of servers having > >> valueD/csnB and an other set valueD/csnD. > > I think you misunderstand. The value for csnD is only discarded when the > > server already has valueB (valueB == valueD). Only the value is > > discarded, so csnD is still applied. The full topology will have either > > valueB w/ csnD or valueD w/ csnD. Since, valueB always equals valueD, by > > substitution, all servers have valueD w/ csnD. > > > > Nathaniel > > > > There are several parts where the CSN are stored. > One is used to allow replication protocol to send the approriate > updates. This part is stored into a dedicated entry: RUV. > In fact when the update valudD/CSND will be received and applied, the > RUV will be updated with csnD. > > An other part is the attribute/attribute values. An attribute value > contains the actual value and the CSN associated to that value. > This CSN is updated by entry_apply_mod_wsi when it decides which value > to keep and which CSN is associated to this value. > > In the example above, on the server X, the counter attribute has > valueB/csnB. Then it receives the update ValueD/csnD it discard this > update because valueD=ValueB. That means that on serverX we will have > valueB/csnB. It does not discard the update (CSN). It discards the value because valueD == valueB. So csnD will be applied, it just won't touch the counter values; valueB will be retained. > Now if on an other server we receive the updates in the reverse order: > valueD/csnD first then valueB/csnB. > This server will apply and valueD/csnD then will discard valueB/csnB. This server will apply valueD/csnD AND csnB, but not valueB. This is because valueB == valueD. > ValueD and ValueB being identical it is not a big issue. But we will > have some server with csnD and others with csnB. As I understand my code, all servers will have csnD. Some servers will have valueB and others will have valueD, but valueB == valueD. We *never* discard a CSN. We only discard the counter/watermark mods in the replication operation. Nathaniel From npmccallum at redhat.com Wed Oct 8 21:08:45 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 08 Oct 2014 17:08:45 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <5435961C.9050501@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <5435961C.9050501@redhat.com> Message-ID: <1412802525.9441.10.camel@redhat.com> On Wed, 2014-10-08 at 13:53 -0600, Rich Megginson wrote: > On 10/08/2014 01:45 PM, thierry bordaz wrote: > > On 10/08/2014 07:30 PM, Nathaniel McCallum wrote: > >> On Wed, 2014-10-08 at 17:30 +0200, thierry bordaz wrote: > >>> On 10/07/2014 06:00 PM, Nathaniel McCallum wrote: > >>>> Attached is the latest patch. I believe this includes all of our > >>>> discussions up until this point. However, a few bits of additional > >>>> information are needed. > >>>> > >>>> First, I have renamed the plugin to ipa-otp-counter. I believe all > >>>> replay prevention work can land inside this plugin, so the name is > >>>> appropriate. > >>>> > >>>> Second, I uncovered a bug in 389 which prevents me from validating the > >>>> non-replication request in bepre. This is the reason for the > >>>> additional > >>>> betxnpre callback. If the upstream 389 bug is fixed, we can merge this > >>>> check back into bepre. https://fedorahosted.org/389/ticket/47919 > >>>> > >>>> Third, I believe we are now handling replication correct. An error is > >>>> never returned. When a replication would cause the counter to > >>>> decrease, > >>>> we remove all counter/watermark related mods from the operation. This > >>>> will allow the replication to apply without decrementing the value. > >>>> There is also a new bepost method which check to see if the > >>>> replication > >>>> was discarded (via CSN) while having a higher counter value. If so, we > >>>> apply the higher counter value. > >>> For me the code is good. It took me some time to understand the benefit > >>> of removing mods in preop. > >>> In fact I think it is a good idea, as it prevents extra repair ops and > >>> also make more easy the computation of the value to set in repair mod. > >>>> Here is the scenario. Server X receives two quick authentications; > >>>> replications A and B are sent to server Y. Before server Y can process > >>>> server X's replications, an authentication is performed on server Y; > >>>> replication C is sent to server X. The following logic holds true: > >>>> * csnA < csnB < csnC > >>>> * valueA = valueC, valueB > valueC > >>>> > >>>> When server X receives replication C, ipa-otp-counter will strip > >>>> out all > >>>> counter mod operations; applying the update but not the lower > >>>> value. The > >>>> value of replication B is retained. This is the correct behavior. > >>>> > >>>> When server Y processes replications A and B, ipa-otp-counter will > >>>> detect that a higher value has a lower CSN and will manually set the > >>>> higher value (in bepost). This initiates replication D, which is > >>>> sent to > >>>> server X. Here is the logic: > >>>> * csnA < csnB < csnC < csnD > >>>> * valueA = valueC, valueB = valueD, valueD > valueC > >>>> > >>>> Server X receives replication D. D has the highest CSN. It has the > >>>> same > >>>> value as replication B (server X's current value). Because the values > >>>> are the same, ipa-otp-counter will strip all counter mod operations. > >>>> This reduces counter write contention which might become a problem in > >>>> N-way replication when N>2. > >>> I think we should rather let the mods going on. So that the full > >>> topology will have > >>> valueD (or valueB)/csnD rather having a set of servers having > >>> valueD/csnB and an other set valueD/csnD. > >> I think you misunderstand. The value for csnD is only discarded when the > >> server already has valueB (valueB == valueD). Only the value is > >> discarded, so csnD is still applied. The full topology will have either > >> valueB w/ csnD or valueD w/ csnD. Since, valueB always equals valueD, by > >> substitution, all servers have valueD w/ csnD. > >> > >> Nathaniel > >> > > > > There are several parts where the CSN are stored. > > One is used to allow replication protocol to send the approriate > > updates. This part is stored into a dedicated entry: RUV. > > In fact when the update valudD/CSND will be received and applied, the > > RUV will be updated with csnD. > > > > An other part is the attribute/attribute values. An attribute value > > contains the actual value and the CSN associated to that value. > > This CSN is updated by entry_apply_mod_wsi when it decides which value > > to keep and which CSN is associated to this value. > > > > In the example above, on the server X, the counter attribute has > > valueB/csnB. Then it receives the update ValueD/csnD it discard this > > update because valueD=ValueB. That means that on serverX we will have > > valueB/csnB. > > > > Now if on an other server we receive the updates in the reverse order: > > valueD/csnD first then valueB/csnB. > > This server will apply and valueD/csnD then will discard valueB/csnB. > > > > ValueD and ValueB being identical it is not a big issue. But we will > > have some server with csnD and others with csnB. > > The CSN is also the key in the changelog database. Right. We *never* discard a replication operation. We only discard some of its mods if and only if those mods would result in either no change at all or an illegal change. If an illegal change would occur, we also issue a new fixup replication request so that everyone quickly gets consistency. Nathaniel From simo at redhat.com Wed Oct 8 21:19:23 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 8 Oct 2014 17:19:23 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412798019.9441.8.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> Message-ID: <20141008171923.6cf5eb65@willson.usersys.redhat.com> On Wed, 08 Oct 2014 15:53:39 -0400 Nathaniel McCallum wrote: > As I understand my code, all servers will have csnD. Some servers will > have valueB and others will have valueD, but valueB == valueD. > > We *never* discard a CSN. We only discard the counter/watermark mods > in the replication operation. What Thierry is saying is that the individual attributes in the entry have associate the last CSN that modified them. Because you remove the mods when ValueD == ValueB the counter attribute will not have the associated CSN changed. But it doesn't really matter because the plugin will always keep things consistent. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Wed Oct 8 21:46:01 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 08 Oct 2014 17:46:01 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name Message-ID: <1412804761.9441.12.camel@redhat.com> The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "Users can create self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) To this: aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "Users can create self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Use-UUID-plugin-to-generate-ipaTokenUniqueIDs.patch Type: text/x-patch Size: 10997 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-post-read-control-to-get-new-DN-after-add.patch Type: text/x-patch Size: 2447 bytes Desc: not available URL: -------------- next part -------------- [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(objectClass) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPalgorithm) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPdigits) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPkey) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenHOTPcounter) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOwner) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:40 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:40 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenUniqueID) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" From npmccallum at redhat.com Wed Oct 8 21:50:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 08 Oct 2014 17:50:35 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <20141008171923.6cf5eb65@willson.usersys.redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> Message-ID: <1412805035.9441.14.camel@redhat.com> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: > On Wed, 08 Oct 2014 15:53:39 -0400 > Nathaniel McCallum wrote: > > > As I understand my code, all servers will have csnD. Some servers will > > have valueB and others will have valueD, but valueB == valueD. > > > > We *never* discard a CSN. We only discard the counter/watermark mods > > in the replication operation. > > What Thierry is saying is that the individual attributes in the entry > have associate the last CSN that modified them. Because you remove the > mods when ValueD == ValueB the counter attribute will not have the > associated CSN changed. But it doesn't really matter because the plugin > will always keep things consistent. Oh, I thought this was only being tracked on a per-entry basis. If it really matters, I can undo this optimization (it is a single character change). It will just be some extra writes. Nathaniel From npmccallum at redhat.com Wed Oct 8 22:15:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 08 Oct 2014 18:15:35 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <20141008171923.6cf5eb65@willson.usersys.redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> Message-ID: <1412806535.9441.18.camel@redhat.com> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: > On Wed, 08 Oct 2014 15:53:39 -0400 > Nathaniel McCallum wrote: > > > As I understand my code, all servers will have csnD. Some servers will > > have valueB and others will have valueD, but valueB == valueD. > > > > We *never* discard a CSN. We only discard the counter/watermark mods > > in the replication operation. > > What Thierry is saying is that the individual attributes in the entry > have associate the last CSN that modified them. Because you remove the > mods when ValueD == ValueB the counter attribute will not have the > associated CSN changed. But it doesn't really matter because the plugin > will always keep things consistent. Attached is a new version. It removes this optimization. If server X has valueB/csnB and receives valueD/csnD and valueB == valueD, the replication will be applied without any modification. However, if valueB > valueD and csnD > csnB, the counter mods will still be stripped. It also collapses the error check from betxnpre to bepre now that we have a fix for https://fedorahosted.org/389/ticket/47919 committed. The betxnpre functions are completely removed. Also, a dependency on 389 1.3.3.4 (not yet released) is added. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.6-Create-ipa-otp-counter-389DS-plugin.patch Type: text/x-patch Size: 34185 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 9 06:44:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 08:44:25 +0200 Subject: [Freeipa-devel] [PATCH] 351 Support MS CA as the external CA in ipa-server-install and ipa-ca-install In-Reply-To: <54352410.2060005@redhat.com> References: <54350996.5010707@redhat.com> <543516AD.6020900@redhat.com> <54352410.2060005@redhat.com> Message-ID: <54362EC9.1090005@redhat.com> On 10/08/2014 01:46 PM, Jan Cholasta wrote: > Dne 8.10.2014 v 12:49 Martin Kosek napsal(a): >> On 10/08/2014 11:53 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Note that this requires pki-core 10.2.0-3. >>> >>> Honza >> >> The approach looks OK, but I would like to be better in naming documentation: >> >> + cert_group.add_option("--external-ca-type", dest="external_ca_type", >> + type="choice", choices=("generic", "ms"), >> + help="Type of the external CA") >> >> I would name the option either "ad-cs" or "windows-server-ca", i.e. "Active >> Directory Certificate Services" or "Windows Server CA". "ms" sounds too generic >> to me in this context. When using trademarks we should be specific about what >> do we mean. > > Microsoft docs refer to it as "Microsoft Certificate Services" or simply > "Certificate Services", so I went with "ms-cs". Works for me. Just please update the man and refer to this type as "Microsoft Certificate Services (MS CS)" just in case MS CS alone does not ring a bell of a user. But that's just a minor issue, what is more concerning is that IPA installation crashed with the signed CA certificate (this part worked smoothly btw): ... [17/27]: setting audit signing renewal to 2 years [18/27]: configuring certificate server to start on boot [19/27]: restarting certificate server [20/27]: requesting RA certificate from CA [error] IndexError: list index out of range Unexpected error - see /var/log/ipaserver-install.log for details: IndexError: list index out of range See https://mkosek.fedorapeople.org/ticket-4496.tgz for related logs. Martin From dkupka at redhat.com Thu Oct 9 07:00:04 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 09 Oct 2014 09:00:04 +0200 Subject: [Freeipa-devel] [PATCH 130] Missing DNS tests In-Reply-To: <542BE898.6070004@redhat.com> References: <542BE898.6070004@redhat.com> Message-ID: <54363274.5030804@redhat.com> On 10/01/2014 01:42 PM, Martin Basti wrote: > This patch adds 2 missing DNS tests: > * removing non-existent permission > * removing idnssoamname value using dnszone-mod --name-server= > > Patch attached, belongs to ipa-4-1 and master branches. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. -- David Kupka From lkrispen at redhat.com Thu Oct 9 07:33:57 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 09 Oct 2014 09:33:57 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141008175055.GJ2328@redhat.com> References: <20141001161606.GA6186@redhat.com> <543402D8.6080801@redhat.com> <20141008175055.GJ2328@redhat.com> Message-ID: <54363A65.2060609@redhat.com> all the issues I found are fixed, for me it's ACK On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: > On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >> Hi Alex, >> >> I have a question regarding cbdata.target. It is/was a reference to >> the pblock used to generate a new dn, but now in >> idview_replace_target_dn(&cbdata.target,...) it can be newly >> allocated and should be freed, so I think there should be a return >> code indicating if it was allocated or not. > Yes, good catch. > > I've fixed this and other issues raised in the review. > > I also fixed an issue with an initial lookup by an override. If someone > does a search by an override, we would replace uid|cn= by > uid= if it exists and by > otherwise -- for groups we don't have ipaOriginalUid as they don't have > uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if > there is no entry in the map cache, the search will return nothing, the > entry will be staged for lookup through SSSD. > > In the original version lookup in SSSD didn't take ipaAnchorUUID into > account, so the entry would not be found at all. I did add a call to > do sid2name first and then use the name to perform actual SSSD lookup. > > Works nicely now. > > New patch for slapi-nis is attached. From mkosek at redhat.com Thu Oct 9 08:02:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 10:02:53 +0200 Subject: [Freeipa-devel] [PATCH 130] Missing DNS tests In-Reply-To: <542BE898.6070004@redhat.com> References: <542BE898.6070004@redhat.com> Message-ID: <5436412D.5050800@redhat.com> On 10/01/2014 01:42 PM, Martin Basti wrote: > This patch adds 2 missing DNS tests: > * removing non-existent permission > * removing idnssoamname value using dnszone-mod --name-server= > > Patch attached, belongs to ipa-4-1 and master branches. Pushed to: master: 41015e6c9c5232a741314ba77df082ba7db55620 ipa-4-1: 6d10f98c6b1adae1687738e8240ae78991f48ba3 Martin From mkosek at redhat.com Thu Oct 9 08:05:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 10:05:51 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <54363A65.2060609@redhat.com> References: <20141001161606.GA6186@redhat.com> <543402D8.6080801@redhat.com> <20141008175055.GJ2328@redhat.com> <54363A65.2060609@redhat.com> Message-ID: <543641DF.6020302@redhat.com> On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: > all the issues I found are fixed, for me it's ACK > > On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: >> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>> Hi Alex, >>> >>> I have a question regarding cbdata.target. It is/was a reference to the >>> pblock used to generate a new dn, but now in >>> idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and >>> should be freed, so I think there should be a return code indicating if it >>> was allocated or not. >> Yes, good catch. >> >> I've fixed this and other issues raised in the review. >> >> I also fixed an issue with an initial lookup by an override. If someone >> does a search by an override, we would replace uid|cn= by >> uid= if it exists and by >> otherwise -- for groups we don't have ipaOriginalUid as they don't have >> uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if >> there is no entry in the map cache, the search will return nothing, the >> entry will be staged for lookup through SSSD. >> >> In the original version lookup in SSSD didn't take ipaAnchorUUID into >> account, so the entry would not be found at all. I did add a call to >> do sid2name first and then use the name to perform actual SSSD lookup. >> >> Works nicely now. >> >> New patch for slapi-nis is attached. Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes as well, it would be great to have that pushed there. Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA 4.1? When the changes are ready, it would be nice to get slapi-nis released so that we can bump FreeIPA slapi-nis requires. Martin From mkosek at redhat.com Thu Oct 9 08:06:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 10:06:47 +0200 Subject: [Freeipa-devel] [PATCH 130] Missing DNS tests In-Reply-To: <54363274.5030804@redhat.com> References: <542BE898.6070004@redhat.com> <54363274.5030804@redhat.com> Message-ID: <54364217.1030305@redhat.com> On 10/09/2014 09:00 AM, David Kupka wrote: > On 10/01/2014 01:42 PM, Martin Basti wrote: >> This patch adds 2 missing DNS tests: >> * removing non-existent permission >> * removing idnssoamname value using dnszone-mod --name-server= >> >> Patch attached, belongs to ipa-4-1 and master branches. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Works for me, ACK. > I see I replied to wrong part of the thread :-) So just to repeat: Pushed to: master: 41015e6c9c5232a741314ba77df082ba7db55620 ipa-4-1: 6d10f98c6b1adae1687738e8240ae78991f48ba3 Martin From mkosek at redhat.com Thu Oct 9 08:12:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 10:12:35 +0200 Subject: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns In-Reply-To: <5434FC4D.7010805@redhat.com> References: <54342251.6070304@redhat.com> <5434FC4D.7010805@redhat.com> Message-ID: <54364373.2000007@redhat.com> On 10/08/2014 10:56 AM, Martin Basti wrote: > On 07/10/14 19:34, Gabe Alford wrote: >> Done. Update patch to use python-dns >= 1.11.1 >> >> On Tue, Oct 7, 2014 at 11:26 AM, Martin Basti > > wrote: >> >> On 07/10/14 15:58, Gabe Alford wrote: >>> Forgot to add patch. >>> >>> On Tue, Oct 7, 2014 at 7:58 AM, Gabe Alford >>> > wrote: >>> >>> Hello, >>> >>> Fix for https://fedorahosted.org/freeipa/ticket/4613 >>> >>> Thanks, >>> >>> Gabe >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Thank you! >> >> I prefer to use python-dns >= 1.11.1, there are some DNSSEC fixes >> which we may use in tests. >> >> Could you send updated patch please? >> >> >> -- Martin Basti >> >> > ACK > Thank you! Pushed to: master: 7b7567aabfb4954ef6df30f375800e6e93fa5f6a ipa-4-1: 19f5ec840ebcbea5ce270a2a9c8e8a1654c4195d ipa-4-0: f336bcbd9be139ff825433c055465e26f98b4f18 Martin From pspacek at redhat.com Thu Oct 9 08:42:59 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 Oct 2014 10:42:59 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC check for DNS forwarders Message-ID: <54364A93.3020307@redhat.com> Hello, bad things will happen (i.e. external DNS resolution will not work) if configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC support is not enabled. For this reason I'm proposing to add explicit check to IPA installer and possibly even to dnsconfig-mod/dnszone-mod commands so forwarders can be tested before putting them in effect. This check should detect failures soon and prevent surprises where IPA installs itself but DNS resolution doesn't work for some domains etc. Please voice your concerns ASAP. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: dnssec_test.py Type: text/x-python Size: 1342 bytes Desc: not available URL: From pspacek at redhat.com Thu Oct 9 08:50:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 Oct 2014 10:50:57 +0200 Subject: [Freeipa-devel] [WIP] DNSSEC check for DNS forwarders Message-ID: <54364C71.90703@redhat.com> Hello, bad things will happen (i.e. external DNS resolution will not work) if configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC support is not enabled. For this reason I'm proposing to add explicit check to IPA installer and possibly even to dnsconfig-mod/dnszone-mod commands so forwarders are be tested before putting them in effect. This check should detect failures soon and prevent surprises where IPA installs itself but DNS resolution doesn't work for some domains etc. Instructions for attached patch/script: # ./dnssec_test.py 127.127.127.127 -> Will (likely) time-out, print a warning and return None - This should be a reason to abort installation because forwarder doesn't work at all. # ./dnssec_test.py 10.1.2.3 - Result depends on your local resolver. - In RH's network it will print a scary warning message and return False because internal forwarder doesn't support DNSSEC. - Should be a reason to abort installation. (This could be overridden by --force switch but then "dnssec-validation" option in /etc/named.conf has to be set to "no" otherwise IPA DNS will not work properly.) (I would rather force people to flip the switch in named.conf on forwarder so this could be a hidden option.) # ./dnssec_test.py 199.7.83.42 -> Should return True - forwarder works and DNSSEC is supported - Installation should continue. Please voice your concerns ASAP. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: dnssec_test.py Type: text/x-python Size: 1342 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 9 09:04:41 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 09 Oct 2014 11:04:41 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC check for DNS forwarders In-Reply-To: <54364A93.3020307@redhat.com> References: <54364A93.3020307@redhat.com> Message-ID: <54364FA9.2080900@redhat.com> On 09/10/14 10:42, Petr Spacek wrote: > Hello, > > bad things will happen (i.e. external DNS resolution will not work) if > configured DNS forwarders are not standard compliant, i.e. EDNS or > DNSSEC support is not enabled. > > For this reason I'm proposing to add explicit check to IPA installer > and possibly even to dnsconfig-mod/dnszone-mod commands so forwarders > can be tested before putting them in effect. > > This check should detect failures soon and prevent surprises where IPA > installs itself but DNS resolution doesn't work for some domains etc. > > Please voice your concerns ASAP. > > This is related to named option "dnssec-validate yes;" right? What is expected if this test failed: 1) during DNS installation 2) during dnsconfig-mod --forwarders 3) during dnszone-mod --forwarders Will we force users to use standard compliant DNS forwarder or will we disable DNSSEC validation? What if user doesn't want use DNSSEC? Martin^2 -- Martin Basti From abokovoy at redhat.com Thu Oct 9 09:04:44 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Oct 2014 12:04:44 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <543641DF.6020302@redhat.com> References: <20141001161606.GA6186@redhat.com> <543402D8.6080801@redhat.com> <20141008175055.GJ2328@redhat.com> <54363A65.2060609@redhat.com> <543641DF.6020302@redhat.com> Message-ID: <20141009090444.GO2328@redhat.com> On Thu, 09 Oct 2014, Martin Kosek wrote: >On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: >> all the issues I found are fixed, for me it's ACK >> >> On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: >>> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>> Hi Alex, >>>> >>>> I have a question regarding cbdata.target. It is/was a reference to the >>>> pblock used to generate a new dn, but now in >>>> idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and >>>> should be freed, so I think there should be a return code indicating if it >>>> was allocated or not. >>> Yes, good catch. >>> >>> I've fixed this and other issues raised in the review. >>> >>> I also fixed an issue with an initial lookup by an override. If someone >>> does a search by an override, we would replace uid|cn= by >>> uid= if it exists and by >>> otherwise -- for groups we don't have ipaOriginalUid as they don't have >>> uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if >>> there is no entry in the map cache, the search will return nothing, the >>> entry will be staged for lookup through SSSD. >>> >>> In the original version lookup in SSSD didn't take ipaAnchorUUID into >>> account, so the entry would not be found at all. I did add a call to >>> do sid2name first and then use the name to perform actual SSSD lookup. >>> >>> Works nicely now. >>> >>> New patch for slapi-nis is attached. > >Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes >as well, it would be great to have that pushed there. > >Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA >4.1? When the changes are ready, it would be nice to get slapi-nis released so >that we can bump FreeIPA slapi-nis requires. No more changes are planned right now. If Nalin would grant me write access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora already. -- / Alexander Bokovoy From tbordaz at redhat.com Thu Oct 9 09:44:04 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 09 Oct 2014 11:44:04 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412806535.9441.18.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> Message-ID: <543658E4.3010103@redhat.com> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: > On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: >> On Wed, 08 Oct 2014 15:53:39 -0400 >> Nathaniel McCallum wrote: >> >>> As I understand my code, all servers will have csnD. Some servers will >>> have valueB and others will have valueD, but valueB == valueD. >>> >>> We *never* discard a CSN. We only discard the counter/watermark mods >>> in the replication operation. >> What Thierry is saying is that the individual attributes in the entry >> have associate the last CSN that modified them. Because you remove the >> mods when ValueD == ValueB the counter attribute will not have the >> associated CSN changed. But it doesn't really matter because the plugin >> will always keep things consistent. > Attached is a new version. It removes this optimization. If server X has > valueB/csnB and receives valueD/csnD and valueB == valueD, the > replication will be applied without any modification. However, if valueB >> valueD and csnD > csnB, the counter mods will still be stripped. > It also collapses the error check from betxnpre to bepre now that we > have a fix for https://fedorahosted.org/389/ticket/47919 committed. The > betxnpre functions are completely removed. Also, a dependency on 389 > 1.3.3.4 (not yet released) is added. > > Nathaniel Hello Nathaniel, For me the code is fine. Ack. I have two minor comments: * in preop_mod, when a direct update moves the counter backward you send UNWILLING to perform with a message. The message is allocated with slapi_ch_smprintf, you may free it with slapi_ch_free_string (rather than 'free'). * About this message, for example when you have these MODS (I admit they make no sens): changetype: modify ipatokenHOTPcounter: MOD_DELETE - ipatokenHOTPcounter: MOD_INCREMENT The returned message will be "Will not decrement ipatokenHOTPcounter", because 'simulate' will return 'COUNTER_UNSET+1'. Is it the message you expected ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Oct 9 10:43:46 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 Oct 2014 12:43:46 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC check for DNS forwarders In-Reply-To: <54364FA9.2080900@redhat.com> References: <54364A93.3020307@redhat.com> <54364FA9.2080900@redhat.com> Message-ID: <543666E2.4090708@redhat.com> On 9.10.2014 11:04, Martin Basti wrote: > On 09/10/14 10:42, Petr Spacek wrote: >> Hello, >> >> bad things will happen (i.e. external DNS resolution will not work) if >> configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC >> support is not enabled. >> >> For this reason I'm proposing to add explicit check to IPA installer and >> possibly even to dnsconfig-mod/dnszone-mod commands so forwarders can be >> tested before putting them in effect. >> >> This check should detect failures soon and prevent surprises where IPA >> installs itself but DNS resolution doesn't work for some domains etc. >> >> Please voice your concerns ASAP. We have discussed this in person once again, here is refined idea: > This is related to named option "dnssec-validate yes;" right? Yes. > What is expected if this test failed: > 1) during DNS installation Fail installation with error and scream loudly. User can use new option --no-dnssec-validation to change error to loud warning. This option will put "dnssec-validate no;" into /etc/named.conf. > 2) during dnsconfig-mod --forwarders Print a warning. This will not affect named.conf validation settings in any way. > 3) during dnszone-mod --forwarders This check doesn't make sense because zone-forwarder doesn't necessarily has access to DNS root zone and the forwarded zone doesn't need to be signed. > Will we force users to use standard compliant DNS forwarder or will we disable > DNSSEC validation? We decided to enable validation by default but user can use the new option if he really insists on an insecure mode. > What if user doesn't want use DNSSEC? There are three levels of 'use': Highest level signing own DNS zones: IPA will not force users to sign any DNS zone. It always has to be explicitly enabled per-zone. Mid level is DNSSEC validation on results from signed domains: I would like to enable it by default because it improves security. Lowest level is the ability to get signatures (even if validation is not enabled at the moment): This is about EDNS & DNSSEC standard compliance and IMHO this should be required. That is why installer and dnsconfig-mod should scream. -- Petr^2 Spacek From mbasti at redhat.com Thu Oct 9 10:44:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 09 Oct 2014 12:44:54 +0200 Subject: [Freeipa-devel] [PATCH 0133] Fix ipactl service ordering In-Reply-To: <54357D98.4060608@redhat.com> References: <5435513B.8090904@redhat.com> <54357D98.4060608@redhat.com> Message-ID: <54366726.7070800@redhat.com> On 08/10/14 20:08, Martin Basti wrote: > On 08/10/14 16:59, Martin Basti wrote: >> IPA sorts service order alphabetically, this patch modify ipactl to >> use integers. >> >> How to reproduce: >> set attribute ipaConfigString: startOrder 150 >> DN: >> cn=HTTP,cn=ipa.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >> >> then run >> #ipactl restart >> >> httpd service should start as last service, but it starts almost first. >> >> Patch attached. >> > > selfNACK > NACKing my SelfNACK, I accidentally installed wrong RPM and I though I haven't fixed it correctly. Patch is OK. -- Martin Basti From pspacek at redhat.com Thu Oct 9 10:45:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 Oct 2014 12:45:00 +0200 Subject: [Freeipa-devel] [WIP] DNSSEC check for DNS forwarders In-Reply-To: <54364C71.90703@redhat.com> References: <54364C71.90703@redhat.com> Message-ID: <5436672C.1050201@redhat.com> I have accidentally sent the e-mail twice. Please reply to thread with additional [PATCH] keyword in subject and let this thread to die. On 9.10.2014 10:50, Petr Spacek wrote: > Hello, > > bad things will happen (i.e. external DNS resolution will not work) if > configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC > support is not enabled. > > For this reason I'm proposing to add explicit check to IPA installer and > possibly even to dnsconfig-mod/dnszone-mod commands so forwarders are be > tested before putting them in effect. > > This check should detect failures soon and prevent surprises where IPA > installs itself but DNS resolution doesn't work for some domains etc. > > > Instructions for attached patch/script: > # ./dnssec_test.py 127.127.127.127 > -> Will (likely) time-out, print a warning and return None > - This should be a reason to abort installation because forwarder doesn't work > at all. > > # ./dnssec_test.py 10.1.2.3 > - Result depends on your local resolver. > - In RH's network it will print a scary warning message and return False > because internal forwarder doesn't support DNSSEC. > - Should be a reason to abort installation. (This could be overridden by > --force switch but then "dnssec-validation" option in /etc/named.conf has to > be set to "no" otherwise IPA DNS will not work properly.) > (I would rather force people to flip the switch in named.conf on forwarder so > this could be a hidden option.) > > # ./dnssec_test.py 199.7.83.42 > -> Should return True - forwarder works and DNSSEC is supported > - Installation should continue. > > Please voice your concerns ASAP. -- Petr^2 Spacek From dkupka at redhat.com Thu Oct 9 10:51:12 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 09 Oct 2014 12:51:12 +0200 Subject: [Freeipa-devel] [PATCH 0133] Fix ipactl service ordering In-Reply-To: <54366726.7070800@redhat.com> References: <5435513B.8090904@redhat.com> <54357D98.4060608@redhat.com> <54366726.7070800@redhat.com> Message-ID: <543668A0.1030009@redhat.com> On 10/09/2014 12:44 PM, Martin Basti wrote: > On 08/10/14 20:08, Martin Basti wrote: >> On 08/10/14 16:59, Martin Basti wrote: >>> IPA sorts service order alphabetically, this patch modify ipactl to >>> use integers. >>> >>> How to reproduce: >>> set attribute ipaConfigString: startOrder 150 >>> DN: >>> cn=HTTP,cn=ipa.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>> >>> then run >>> #ipactl restart >>> >>> httpd service should start as last service, but it starts almost first. >>> >>> Patch attached. >>> >> >> selfNACK >> > NACKing my SelfNACK, I accidentally installed wrong RPM and I though I > haven't fixed it correctly. > Patch is OK. > Works for me, ACK. -- David Kupka From mkosek at redhat.com Thu Oct 9 10:52:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 12:52:56 +0200 Subject: [Freeipa-devel] [PATCH 0133] Fix ipactl service ordering In-Reply-To: <543668A0.1030009@redhat.com> References: <5435513B.8090904@redhat.com> <54357D98.4060608@redhat.com> <54366726.7070800@redhat.com> <543668A0.1030009@redhat.com> Message-ID: <54366908.1080205@redhat.com> On 10/09/2014 12:51 PM, David Kupka wrote: > On 10/09/2014 12:44 PM, Martin Basti wrote: >> On 08/10/14 20:08, Martin Basti wrote: >>> On 08/10/14 16:59, Martin Basti wrote: >>>> IPA sorts service order alphabetically, this patch modify ipactl to >>>> use integers. >>>> >>>> How to reproduce: >>>> set attribute ipaConfigString: startOrder 150 >>>> DN: >>>> cn=HTTP,cn=ipa.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com >>>> >>>> then run >>>> #ipactl restart >>>> >>>> httpd service should start as last service, but it starts almost first. >>>> >>>> Patch attached. >>>> >>> >>> selfNACK >>> >> NACKing my SelfNACK, I accidentally installed wrong RPM and I though I >> haven't fixed it correctly. >> Patch is OK. >> > Works for me, ACK. > Pushed to: master: 57c510dcc7a08d908fd55856a735b8dca6684571 ipa-4-1: f74213877a81553bc16c8e050956e742b0b9a5f4 ipa-4-0: 56a146a66627e71fcd927ede7608ed3358cd904c Martin From mbasti at redhat.com Thu Oct 9 10:56:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 09 Oct 2014 12:56:15 +0200 Subject: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd? In-Reply-To: <541FD546.9080505@redhat.com> References: <541C187D.3010903@redhat.com> <541C4A81.4050108@redhat.com> <541FD546.9080505@redhat.com> Message-ID: <543669CF.2070306@redhat.com> On 22/09/14 09:52, Jan Cholasta wrote: > Dne 19.9.2014 v 17:23 Rob Crittenden napsal(a): >> Martin Basti wrote: >>> Hello list, >>> >>> I need to use systemd mask/unmask in ipa service. >>> >>> But as Honza wrote: >>> "IMO masking/unmasking should be part of disabling/enabling a >>> service in >>> systemd. AFAIK in most other init systems when you disable a >>> service, it >>> has the same effect as masking the service in systemd - it will >>> never be >>> started until it is enabled/unmasked again. " >>> >>> So my questions is, should be masking part of disabling service in >>> systemd, to be platform independent? >>> Or should we add mask/unmask methods to >>> ipaplatform.base.services.PlatformService where mask is alias for >>> disable? >>> >>> Martin^2 >>> >> >> After reading http://0pointer.de/blog/projects/three-levels-of-off I >> disagree that disabling in SysV is the same as masking in systemd, >> though I guess it depends on the meaning of disable. According to that >> page chkconfig off is equivalent to systemctl disable >> .service, which is what we do now AFAIR. > > I don't think that's entirely correct. They are equivalent > mechanically (a symlink is added/removed when a service is > enabled/disabled), but effectively they are different. AFAIK in SysV, > services can be started either manually or automatically on boot and > if you disable a service the only way it will start is when you do it > manually. In systemd, there are more ways services can be started > automatically (socket, D-Bus, etc.) and disabling a service will only > disable automatic start *on boot*, but it can still be started > automatically, which contrasts with what SysV does. > >> >> Why do you need to mask a service, e.g. render it completely >> unstartable? >> >> rob >> > > Let's continue with discussion, 1) should we add general method mask/unmask to ipaplatform, or 2) make mask/unmask part of enabling/disabling in systemd Martin^2 -- Martin Basti From abokovoy at redhat.com Thu Oct 9 11:01:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Oct 2014 14:01:16 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis: normalize memberUid search filter term for AD users Message-ID: <20141009110116.GP2328@redhat.com> Hi, memberUid attribute has case-sensitive comparison defined but when we construct memberUid for AD users (coming through SSSD), they are normalized to lower case. Interestingly enough, 'uid' attribute has case-insensitive comparison. Work around the issue by low-casing the memberUid search term value when it is a fully-qualified name (user at domain), meaning we do ask for a SSSD user. This is the patch on top of my ID views support patch. https://bugzilla.redhat.com/show_bug.cgi?id=1130131 -- / Alexander Bokovoy -------------- next part -------------- From e90135b7a477d15c4349e7d46e4cbf2730a66d71 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 9 Oct 2014 13:52:38 +0300 Subject: [PATCH 2/2] slapi-nis: normalize memberUid search filter when searching AD users memberUid attribute uses IA5 String comparison which is case-sensitive. At the same time, uid attribute uses case-insensitive comparison. When memberUid is constructed for groups from AD, SSSD normalizes names to a lower case. slapi-nis records these entries as they produced by SSSD. However, the search filter is not modified, thus case-sensitive comparison of memberUid attribute may fail match of the original term. Workaround the issue by low-casing memberUid term in the search filter if it includes '@' sign, meaning we are searching on fully-qualified user name provided by SSSD. https://bugzilla.redhat.com/show_bug.cgi?id=1130131 --- src/back-sch-nss.c | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) diff --git a/src/back-sch-nss.c b/src/back-sch-nss.c index 26d4b8c..12ae589 100644 --- a/src/back-sch-nss.c +++ b/src/back-sch-nss.c @@ -60,7 +60,7 @@ bvstrprefix(const struct berval *bval, const char *s) len = strlen(s); if (len < bval->bv_len) { - return strncasecmp(bval->bv_val, s, len) != 0; + return slapi_utf8ncasecmp((unsigned char *) bval->bv_val, (unsigned char *) s, len) != 0; } return 1; @@ -75,9 +75,9 @@ bvstrcasecmp(const struct berval *bval, const char *s) len = strlen(s); if (len == bval->bv_len) { - return strncasecmp(bval->bv_val, s, len); + return slapi_utf8ncasecmp((unsigned char *) bval->bv_val, (unsigned char *) s, len); } - c = strncasecmp(bval->bv_val, s, MIN(bval->bv_len, len)); + c = slapi_utf8ncasecmp((unsigned char *) bval->bv_val, (unsigned char *) s, MIN(bval->bv_len, len)); if (c != 0) { return c; } @@ -111,6 +111,35 @@ backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) } else if (0 == strcasecmp(filter_type, "cn")) { config->name_set = TRUE; } else if (0 == strcasecmp(filter_type, "memberUid")) { + /* memberUid is case-sensitive in RFC 2307 but uid is case-insensitive + * When memberUid is generated for SSSD-provided entries, it is low-cased, + * we need to low case the filter value to actually match it. + * However, we will do it only for fully qualified names as they are coming from SSSD. */ + char *memberUid = NULL; + char *lwMemberUid = NULL; + unsigned int i = 0; + + for (i=0; i < bval->bv_len ; i++) { + if (bval->bv_val[i] == '@') + break; + } + + if (i < bval->bv_len) { + memberUid = slapi_ch_malloc(bval->bv_len + 1); + if (memberUid != NULL) { + memcpy(memberUid, bval->bv_val, bval->bv_len); + memberUid[bval->bv_len] = '\0'; + lwMemberUid = (char *) slapi_utf8StrToLower((unsigned char*) memberUid); + if (lwMemberUid != NULL) { + struct berval bval_lw = {0, NULL}; + bval_lw.bv_len = strlen((const char *) lwMemberUid); + bval_lw.bv_val = lwMemberUid; + slapi_ber_bvdone(bval); + slapi_ber_bvcpy(bval, &bval_lw); + } + slapi_ch_free_string(&memberUid); + } + } config->name_set = TRUE; config->search_members = TRUE; } else if ((0 == strcasecmp(filter_type, "objectClass")) && -- 2.1.0 From abokovoy at redhat.com Thu Oct 9 11:02:53 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Oct 2014 14:02:53 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141009090444.GO2328@redhat.com> References: <20141001161606.GA6186@redhat.com> <543402D8.6080801@redhat.com> <20141008175055.GJ2328@redhat.com> <54363A65.2060609@redhat.com> <543641DF.6020302@redhat.com> <20141009090444.GO2328@redhat.com> Message-ID: <20141009110253.GQ2328@redhat.com> On Thu, 09 Oct 2014, Alexander Bokovoy wrote: >On Thu, 09 Oct 2014, Martin Kosek wrote: >>On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: >>>all the issues I found are fixed, for me it's ACK >>> >>>On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: >>>>On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>>>Hi Alex, >>>>> >>>>>I have a question regarding cbdata.target. It is/was a reference to the >>>>>pblock used to generate a new dn, but now in >>>>>idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and >>>>>should be freed, so I think there should be a return code indicating if it >>>>>was allocated or not. >>>>Yes, good catch. >>>> >>>>I've fixed this and other issues raised in the review. >>>> >>>>I also fixed an issue with an initial lookup by an override. If someone >>>>does a search by an override, we would replace uid|cn= by >>>>uid= if it exists and by >>>>otherwise -- for groups we don't have ipaOriginalUid as they don't have >>>>uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if >>>>there is no entry in the map cache, the search will return nothing, the >>>>entry will be staged for lookup through SSSD. >>>> >>>>In the original version lookup in SSSD didn't take ipaAnchorUUID into >>>>account, so the entry would not be found at all. I did add a call to >>>>do sid2name first and then use the name to perform actual SSSD lookup. >>>> >>>>Works nicely now. >>>> >>>>New patch for slapi-nis is attached. >> >>Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes >>as well, it would be great to have that pushed there. >> >>Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA >>4.1? When the changes are ready, it would be nice to get slapi-nis released so >>that we can bump FreeIPA slapi-nis requires. >No more changes are planned right now. If Nalin would grant me write >access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora already. Never say never. The moment I've sent this email, I've realized I need to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131 The patch is sent in a separate email. -- / Alexander Bokovoy From mkosek at redhat.com Thu Oct 9 11:06:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 13:06:35 +0200 Subject: [Freeipa-devel] [PATCHES] 344-346 Support building RPMs for RHEL/CentOS 7.0 In-Reply-To: <54326F99.50301@redhat.com> References: <54326F99.50301@redhat.com> Message-ID: <54366C3B.7090600@redhat.com> On 10/06/2014 12:31 PM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Honza 346 looks OK, but I still have couple points to previous 2 patches. 1) I do not like much the "Red Hat-like systems" classification. While it is probably OK to use "redhat" as a folder/package name, the description should say something better (as Red Hat by itself is a company name, not OS name). I did a little research what my colleagues think, Rich M. was suggesting following what Puppet does with "osFamily" and go with "Red Hat OS family". Alexander's suggestion was to do something like "Fedora/RHEL 7.x/CentOS 7.x/... distributions". Up to you, though I like the "family" approach more. 2) You changed the hierarchy. Previously we had base -> fedora -> rhel Now we have base -> redhat -> fedora \-> rhel I wonder if this will be flexible enough. Fedora goes before RHEL, so we will soon need to add a support for something that works in Fedora but does not work in RHEL. Would we then add the new function only to fedora platform to not break rhel platform? Or would be add it to base redhat platform and update rhel platform to workaround the function with what is available in rhel? I just want to make sure we are clear on this one. Thanks, Martin From pviktori at redhat.com Thu Oct 9 11:12:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 09 Oct 2014 13:12:39 +0200 Subject: [Freeipa-devel] [PATCH] 0656-0660 Make most tests runnable under py.test Message-ID: <54366DA7.20204@redhat.com> This makes all tests except - integration - xmlrpc - doctest to be runnable under py.test. The last patch does touch Declarative, but keeps compatibility with Nose. How to test: - have a ticket - do NOT have integration tests configured (using $MASTER or $IPATEST_*_CONFIG) # yum install pytest $ IPA_UNIT_TEST_MODE=cli_test py.test (note: the command is `py.test`, for historical reasons in the pytest project) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0656-tests-Use-PEP8-compliant-setup-teardown-method-names.patch Type: text/x-patch Size: 20207 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0657-tests-Add-configuration-for-pytest.patch Type: text/x-patch Size: 735 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0658-ipatests.util.ClassChecker-Raise-AttributeError-in-g.patch Type: text/x-patch Size: 832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0659-test_automount_plugin-Fix-test-ordering.patch Type: text/x-patch Size: 1559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0660-Use-setup_class-teardown_class-in-Declarative-tests.patch Type: text/x-patch Size: 5018 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 9 11:13:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 13:13:45 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <20141009110253.GQ2328@redhat.com> References: <20141001161606.GA6186@redhat.com> <543402D8.6080801@redhat.com> <20141008175055.GJ2328@redhat.com> <54363A65.2060609@redhat.com> <543641DF.6020302@redhat.com> <20141009090444.GO2328@redhat.com> <20141009110253.GQ2328@redhat.com> Message-ID: <54366DE9.2040500@redhat.com> On 10/09/2014 01:02 PM, Alexander Bokovoy wrote: > On Thu, 09 Oct 2014, Alexander Bokovoy wrote: >> On Thu, 09 Oct 2014, Martin Kosek wrote: >>> On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: >>>> all the issues I found are fixed, for me it's ACK >>>> >>>> On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: >>>>> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>>>> Hi Alex, >>>>>> >>>>>> I have a question regarding cbdata.target. It is/was a reference to the >>>>>> pblock used to generate a new dn, but now in >>>>>> idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and >>>>>> should be freed, so I think there should be a return code indicating if it >>>>>> was allocated or not. >>>>> Yes, good catch. >>>>> >>>>> I've fixed this and other issues raised in the review. >>>>> >>>>> I also fixed an issue with an initial lookup by an override. If someone >>>>> does a search by an override, we would replace uid|cn= by >>>>> uid= if it exists and by >>>>> otherwise -- for groups we don't have ipaOriginalUid as they don't have >>>>> uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if >>>>> there is no entry in the map cache, the search will return nothing, the >>>>> entry will be staged for lookup through SSSD. >>>>> >>>>> In the original version lookup in SSSD didn't take ipaAnchorUUID into >>>>> account, so the entry would not be found at all. I did add a call to >>>>> do sid2name first and then use the name to perform actual SSSD lookup. >>>>> >>>>> Works nicely now. >>>>> >>>>> New patch for slapi-nis is attached. >>> >>> Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes >>> as well, it would be great to have that pushed there. >>> >>> Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA >>> 4.1? When the changes are ready, it would be nice to get slapi-nis released so >>> that we can bump FreeIPA slapi-nis requires. >> No more changes are planned right now. If Nalin would grant me write >> access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora >> already. > Never say never. The moment I've sent this email, I've realized I need > to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131 > > The patch is sent in a separate email. Seen that, thanks! BTW what about #4435 Trusted AD users are not resovable in netgroups #4403 [RFE] compat tree: show AD members of IPA groups do you see this also as something that would fit in slapi-nis in 4.1? Martin From abokovoy at redhat.com Thu Oct 9 11:27:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Oct 2014 14:27:20 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree In-Reply-To: <54366DE9.2040500@redhat.com> References: <20141001161606.GA6186@redhat.com> <543402D8.6080801@redhat.com> <20141008175055.GJ2328@redhat.com> <54363A65.2060609@redhat.com> <543641DF.6020302@redhat.com> <20141009090444.GO2328@redhat.com> <20141009110253.GQ2328@redhat.com> <54366DE9.2040500@redhat.com> Message-ID: <20141009112720.GS2328@redhat.com> On Thu, 09 Oct 2014, Martin Kosek wrote: >On 10/09/2014 01:02 PM, Alexander Bokovoy wrote: >> On Thu, 09 Oct 2014, Alexander Bokovoy wrote: >>> On Thu, 09 Oct 2014, Martin Kosek wrote: >>>> On 10/09/2014 09:33 AM, Ludwig Krispenz wrote: >>>>> all the issues I found are fixed, for me it's ACK >>>>> >>>>> On 10/08/2014 07:50 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 07 Oct 2014, Ludwig Krispenz wrote: >>>>>>> Hi Alex, >>>>>>> >>>>>>> I have a question regarding cbdata.target. It is/was a reference to the >>>>>>> pblock used to generate a new dn, but now in >>>>>>> idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and >>>>>>> should be freed, so I think there should be a return code indicating if it >>>>>>> was allocated or not. >>>>>> Yes, good catch. >>>>>> >>>>>> I've fixed this and other issues raised in the review. >>>>>> >>>>>> I also fixed an issue with an initial lookup by an override. If someone >>>>>> does a search by an override, we would replace uid|cn= by >>>>>> uid= if it exists and by >>>>>> otherwise -- for groups we don't have ipaOriginalUid as they don't have >>>>>> uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if >>>>>> there is no entry in the map cache, the search will return nothing, the >>>>>> entry will be staged for lookup through SSSD. >>>>>> >>>>>> In the original version lookup in SSSD didn't take ipaAnchorUUID into >>>>>> account, so the entry would not be found at all. I did add a call to >>>>>> do sid2name first and then use the name to perform actual SSSD lookup. >>>>>> >>>>>> Works nicely now. >>>>>> >>>>>> New patch for slapi-nis is attached. >>>> >>>> Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes >>>> as well, it would be great to have that pushed there. >>>> >>>> Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA >>>> 4.1? When the changes are ready, it would be nice to get slapi-nis released so >>>> that we can bump FreeIPA slapi-nis requires. >>> No more changes are planned right now. If Nalin would grant me write >>> access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora >>> already. >> Never say never. The moment I've sent this email, I've realized I need >> to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131 >> >> The patch is sent in a separate email. > >Seen that, thanks! BTW what about > >#4435 Trusted AD users are not resovable in netgroups >#4403 [RFE] compat tree: show AD members of IPA groups > >do you see this also as something that would fit in slapi-nis in 4.1? I don't think I'll be able to fix them before 4.1. Netgroups support requires to create additional configuration and in theory could be simple but needs a lot of care (escaping of embedded string delimiters). Additionally, netgroups will not yet work with views properly, this is something that requires more time. AD members of IPA groups needs more work too as we have no means yet to pick up and resolve ipaExternalMember in slapi-nis. -- / Alexander Bokovoy From tbordaz at redhat.com Thu Oct 9 12:11:09 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 09 Oct 2014 14:11:09 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412804761.9441.12.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> Message-ID: <54367B5D.6050900@redhat.com> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: > The background of this email is this bug: > https://fedorahosted.org/freeipa/ticket/4456 > > Attached are two patches which solve this issue for admin users (not > very helpful, I know). They depend on this fix in 389: > https://fedorahosted.org/389/ticket/47920 > > There are two outstanding issues: > > 1. 389 does not send the post read control for normal users. The > operation itself succeeds, but no control is sent. > > The relevant sections from the log are attached. 389 is denying access > to the following attributes (* = valid, ! = invalid): > ! objectClass > ! ipatokenOTPalgorithm > ! ipatokenOTPdigits > * ipatokenOTPkey > * ipatokenHOTPcounter > ! ipatokenOwner > ! managedBy > ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". The only ACI I found that match this target is: |aci: (targetfilter= "(objectClass=ipaToken)") (targetattrs= "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") (version3.0; acl"Users/managers can read basic token info"; allow(read, search, compare) userattr= "ipatokenOwner#USERDN" or userattr= "managedBy#USERDN";)| Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? > The ACIs allowing access to most of these attributes are here: > https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > > Note that I am able to query the entry just fine (including all the > above invalidly restricted attributes). Hence, I know the ACIs are > working just fine. > > Part of the strange thing is that in the post read control request, I > haven't indicated that I want *any* attributes returned (i.e. I want > just the DN). So I'm not sure why it is querying all the attributes. I > would suspect that the proper behavior would be to only check the ACIs > on attributes that will actually be returned. It may not querying all attributes, but just search the first one it can read. As it finds none of them you get the message for all attributes. thanks thierry > > 2. The second patch (0002) modifies the ACI for normal user token > addition from this: > > aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > userattr = "managedBy#SELFDN";) > > To this: > > aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > "Users can create self-managed tokens"; allow (add) userattr = > "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > > The idea is to allow users to create tokens which will be expanded by > the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are > checked. Since the expanded UUID no longer matches the ACI, the addition > is denied. Is this truly the correct behavior? I would think that the > ACIs would be checked before the UUID plugin, not after. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Thu Oct 9 13:02:47 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 09 Oct 2014 15:02:47 +0200 Subject: [Freeipa-devel] [PATCHES] 344-346 Support building RPMs for RHEL/CentOS 7.0 In-Reply-To: <54366C3B.7090600@redhat.com> References: <54326F99.50301@redhat.com> <54366C3B.7090600@redhat.com> Message-ID: <54368777.7080404@redhat.com> Dne 9.10.2014 v 13:06 Martin Kosek napsal(a): > On 10/06/2014 12:31 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Honza > > 346 looks OK, but I still have couple points to previous 2 patches. > > 1) I do not like much the "Red Hat-like systems" classification. While it is > probably OK to use "redhat" as a folder/package name, the description should > say something better (as Red Hat by itself is a company name, not OS name). > > I did a little research what my colleagues think, Rich M. was suggesting > following what Puppet does with "osFamily" and go with "Red Hat OS family". > > Alexander's suggestion was to do something like "Fedora/RHEL 7.x/CentOS 7.x/... > distributions". Up to you, though I like the "family" approach more. I like this more as well, fixed. > > 2) You changed the hierarchy. Previously we had > > base -> fedora -> rhel > > Now we have > > base -> redhat -> fedora > \-> rhel > > I wonder if this will be flexible enough. Fedora goes before RHEL, so we will > soon need to add a support for something that works in Fedora but does not work > in RHEL. Well, it's more flexible than what we had before. > > Would we then add the new function only to fedora platform to not break rhel > platform? Or would be add it to base redhat platform and update rhel platform > to workaround the function with what is available in rhel? If you want to do a Fedora-only change, you do it in the fedora module, if you want to do a Fedora & RHEL change, you do it in the redhat module. To make a Fedora-only change a Fedora & RHEL change, you move it from the fedora module to the redhat module. Same for RHEL-only vs. Fedora & RHEL changes. Think of the redhat module as a super-class and the fedora and rhel module as sub-classes. > > I just want to make sure we are clear on this one. > > Thanks, > Martin > Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-344.1-Split-off-generic-Red-Hat-like-platform-code-from-Fe.patch Type: text/x-patch Size: 60656 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-344.1-Split-off-generic-Red-Hat-like-platform-code-from-Fe-ipa-4-0.patch Type: text/x-patch Size: 51323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-344.1-Split-off-generic-Red-Hat-like-platform-code-from-Fe-ipa-4-1.patch Type: text/x-patch Size: 61413 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-345.1-Add-RHEL-platform-module.patch Type: text/x-patch Size: 7057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-345.1-Add-RHEL-platform-module-ipa-4-0.patch Type: text/x-patch Size: 7057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-345.1-Add-RHEL-platform-module-ipa-4-1.patch Type: text/x-patch Size: 7057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-346.1-Support-building-RPMs-for-RHEL-CentOS-7.0.patch Type: text/x-patch Size: 3556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-346.1-Support-building-RPMs-for-RHEL-CentOS-7.0-ipa-4-0.patch Type: text/x-patch Size: 3556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-346.1-Support-building-RPMs-for-RHEL-CentOS-7.0-ipa-4-1.patch Type: text/x-patch Size: 3556 bytes Desc: not available URL: From simo at redhat.com Thu Oct 9 13:06:47 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 9 Oct 2014 09:06:47 -0400 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design In-Reply-To: <5433F978.2070704@redhat.com> References: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> <5433D2B9.7080209@redhat.com> <20141007090629.5135145e@willson.usersys.redhat.com> <5433EABD.5090103@redhat.com> <20141007094012.184c3812@willson.usersys.redhat.com> <5433F978.2070704@redhat.com> Message-ID: <20141009090647.2a5fac47@willson.usersys.redhat.com> On Tue, 07 Oct 2014 16:32:24 +0200 Petr Spacek wrote: > Naturally this forces applications to use PKCS#11 for all crypto so > the raw key never leaves HSM. Luckily DNSSEC software is built around > PKCS#11 so it was a natural choice for us. > > Personally, I would say that this is the way to go. I think this should be a goal indeed. However I'd be content if the proxy process I described would use SoftHSM to retrieve the secrets to hand them out (or proxy the calls by using them to authenticate) for now. But yes the idea is that we store them encrypted in LDAP and the only thing we do is to add ipa servers public keys to LDAP as a way to distribute access to master keys. The CA stuff is slightly different though. We really have only 2 ways here: 1. keep using certificates and build a proxy service that uses GSSAPI for authenticating received requests, then turn around and fetch a corresponding cert only the proxy has access to and reply the same command to the CA using this cert for auth. 2. Teach dogtag to use GSSAPI for authenticating these requests and then just tell it which principals (or groups of principals) are allowed to perform operations instead of using certs. Of course 2 would be much simpler. Fraser, how hard do you think it would be to add #2 ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Oct 9 13:13:43 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 9 Oct 2014 09:13:43 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412804761.9441.12.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> Message-ID: <20141009091343.7d2d9c20@willson.usersys.redhat.com> On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum wrote: > The background of this email is this bug: > https://fedorahosted.org/freeipa/ticket/4456 > > Attached are two patches which solve this issue for admin users (not > very helpful, I know). They depend on this fix in 389: > https://fedorahosted.org/389/ticket/47920 > > There are two outstanding issues: > > 1. 389 does not send the post read control for normal users. The > operation itself succeeds, but no control is sent. > > The relevant sections from the log are attached. 389 is denying access > to the following attributes (* = valid, ! = invalid): > ! objectClass > ! ipatokenOTPalgorithm > ! ipatokenOTPdigits > * ipatokenOTPkey > * ipatokenHOTPcounter > ! ipatokenOwner > ! managedBy > ! ipatokenUniqueID > > The ACIs allowing access to most of these attributes are here: > https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > > Note that I am able to query the entry just fine (including all the > above invalidly restricted attributes). Hence, I know the ACIs are > working just fine. > > Part of the strange thing is that in the post read control request, I > haven't indicated that I want *any* attributes returned (i.e. I want > just the DN). So I'm not sure why it is querying all the attributes. I > would suspect that the proper behavior would be to only check the ACIs > on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? > 2. The second patch (0002) modifies the ACI for normal user token > addition from this: > > aci: (target = > "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = > "(objectClass=ipaToken)")(version 3.0; acl "Users can create > self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" > and userattr = "managedBy#SELFDN";) > > To this: > > aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > "Users can create self-managed tokens"; allow (add) userattr = > "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > > The idea is to allow users to create tokens which will be expanded by > the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs > are checked. Since the expanded UUID no longer matches the ACI, the > addition is denied. Is this truly the correct behavior? I would think > that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Oct 9 13:40:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 09 Oct 2014 15:40:33 +0200 Subject: [Freeipa-devel] [PATCHES] 344-346 Support building RPMs for RHEL/CentOS 7.0 In-Reply-To: <54368777.7080404@redhat.com> References: <54326F99.50301@redhat.com> <54366C3B.7090600@redhat.com> <54368777.7080404@redhat.com> Message-ID: <54369051.9050208@redhat.com> On 10/09/2014 03:02 PM, Jan Cholasta wrote: > Dne 9.10.2014 v 13:06 Martin Kosek napsal(a): >> On 10/06/2014 12:31 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix . >>> >>> Honza >> >> 346 looks OK, but I still have couple points to previous 2 patches. >> >> 1) I do not like much the "Red Hat-like systems" classification. While it is >> probably OK to use "redhat" as a folder/package name, the description should >> say something better (as Red Hat by itself is a company name, not OS name). >> >> I did a little research what my colleagues think, Rich M. was suggesting >> following what Puppet does with "osFamily" and go with "Red Hat OS family". >> >> Alexander's suggestion was to do something like "Fedora/RHEL 7.x/CentOS 7.x/... >> distributions". Up to you, though I like the "family" approach more. > > I like this more as well, fixed. > >> >> 2) You changed the hierarchy. Previously we had >> >> base -> fedora -> rhel >> >> Now we have >> >> base -> redhat -> fedora >> \-> rhel >> >> I wonder if this will be flexible enough. Fedora goes before RHEL, so we will >> soon need to add a support for something that works in Fedora but does not work >> in RHEL. > > Well, it's more flexible than what we had before. > >> >> Would we then add the new function only to fedora platform to not break rhel >> platform? Or would be add it to base redhat platform and update rhel platform >> to workaround the function with what is available in rhel? > > If you want to do a Fedora-only change, you do it in the fedora module, if you > want to do a Fedora & RHEL change, you do it in the redhat module. To make a > Fedora-only change a Fedora & RHEL change, you move it from the fedora module > to the redhat module. Same for RHEL-only vs. Fedora & RHEL changes. > > Think of the redhat module as a super-class and the fedora and rhel module as > sub-classes. Ok, works for me, ACK! Pushed to master, ipa-4-1, ipa-4-0. Martin From dkupka at redhat.com Thu Oct 9 13:56:31 2014 From: dkupka at redhat.com (David Kupka) Date: Thu, 09 Oct 2014 15:56:31 +0200 Subject: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code In-Reply-To: <54351ECD.1040603@redhat.com> References: <543511A9.5050205@redhat.com> <54351ECD.1040603@redhat.com> Message-ID: <5436940F.6010800@redhat.com> On 10/08/2014 01:23 PM, Jan Cholasta wrote: > Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a): >> Hi, >> >> the attached patch fixes . >> >> Honza > > Forgot to delete a line in dogtaginstance.py (thanks to David for > noticing). Updated patch attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. -- David Kupka From pspacek at redhat.com Thu Oct 9 13:57:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 09 Oct 2014 15:57:26 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview Message-ID: <54369446.6000207@redhat.com> Hello, it would be great if people could look at current state of DNSSEC patches for FreeIPA. It consist of several relatively independent parts: - python-pkcs#11 interface written by Martin Basti: https://github.com/spacekpe/freeipa-pkcs11 - DNSSEC daemons written by me: https://github.com/spacekpe/ipadnssecd - FreeIPA integration written by Martin Basti: https://github.com/bastiak/freeipa/tree/dnssec For now brief visual inspection is good enough :-) Current state ============= - It works only on single DNSSEC "master" server because we still do not have the key wrapping machinery. - The "master" server has to be configured manually using ipa-dnssec-setmaster utility. - DNSSEC keys are generated on the fly when DNSSEC is enabled for particular zone. - Metadata for BIND are generated on the fly. - BIND automatically signs the zone. It depends on latest softhsm, opendnssec and bind-pkcs11-util & bind-pkcs11 packages which are not in Fedora 21 yet. Thank you for your time! -- Petr^2 Spacek From thozza at redhat.com Thu Oct 9 13:59:16 2014 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 09 Oct 2014 15:59:16 +0200 Subject: [Freeipa-devel] [WIP] DNSSEC check for DNS forwarders In-Reply-To: <54364C71.90703@redhat.com> References: <54364C71.90703@redhat.com> Message-ID: <543694B4.6010506@redhat.com> On 10/09/2014 10:50 AM, Petr Spacek wrote: > Hello, > > bad things will happen (i.e. external DNS resolution will not work) if > configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC > support is not enabled. > > For this reason I'm proposing to add explicit check to IPA installer and > possibly even to dnsconfig-mod/dnszone-mod commands so forwarders are be tested > before putting them in effect. > > This check should detect failures soon and prevent surprises where IPA installs > itself but DNS resolution doesn't work for some domains etc. > > > Instructions for attached patch/script: > # ./dnssec_test.py 127.127.127.127 > -> Will (likely) time-out, print a warning and return None > - This should be a reason to abort installation because forwarder doesn't work > at all. > > # ./dnssec_test.py 10.1.2.3 > - Result depends on your local resolver. > - In RH's network it will print a scary warning message and return False because > internal forwarder doesn't support DNSSEC. > - Should be a reason to abort installation. (This could be overridden by --force > switch but then "dnssec-validation" option in /etc/named.conf has to be set to > "no" otherwise IPA DNS will not work properly.) > (I would rather force people to flip the switch in named.conf on forwarder so > this could be a hidden option.) > > # ./dnssec_test.py 199.7.83.42 > -> Should return True - forwarder works and DNSSEC is supported > - Installation should continue. > > Please voice your concerns ASAP. > I must confirm that if using DNSSEC, it is essential to probe the forwarder for proper DNSSEC support before using it. If the forwarder is not able to provide all the necessary information, the validation will not work. This is basically the same we are already doing on the client side where dnssec-trigger tries to determine if network-provided DNS forwarders are DNSSEC enabled before configuring unbound server. Therefore I agree with the idea, however it is up to IPA developers how they end up implementing the probing. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From lkrispen at redhat.com Thu Oct 9 14:06:06 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 09 Oct 2014 16:06:06 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <20141009091343.7d2d9c20@willson.usersys.redhat.com> References: <1412804761.9441.12.camel@redhat.com> <20141009091343.7d2d9c20@willson.usersys.redhat.com> Message-ID: <5436964E.5030504@redhat.com> On 10/09/2014 03:13 PM, Simo Sorce wrote: > On Wed, 08 Oct 2014 17:46:01 -0400 > Nathaniel McCallum wrote: > >> The background of this email is this bug: >> https://fedorahosted.org/freeipa/ticket/4456 >> >> Attached are two patches which solve this issue for admin users (not >> very helpful, I know). They depend on this fix in 389: >> https://fedorahosted.org/389/ticket/47920 >> >> There are two outstanding issues: >> >> 1. 389 does not send the post read control for normal users. The >> operation itself succeeds, but no control is sent. >> >> The relevant sections from the log are attached. 389 is denying access >> to the following attributes (* = valid, ! = invalid): >> ! objectClass >> ! ipatokenOTPalgorithm >> ! ipatokenOTPdigits >> * ipatokenOTPkey >> * ipatokenHOTPcounter >> ! ipatokenOwner >> ! managedBy >> ! ipatokenUniqueID >> >> The ACIs allowing access to most of these attributes are here: >> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >> >> Note that I am able to query the entry just fine (including all the >> above invalidly restricted attributes). Hence, I know the ACIs are >> working just fine. >> >> Part of the strange thing is that in the post read control request, I >> haven't indicated that I want *any* attributes returned (i.e. I want >> just the DN). So I'm not sure why it is querying all the attributes. I >> would suspect that the proper behavior would be to only check the ACIs >> on attributes that will actually be returned. > Can you show an example ldif ? > I wonder if you are setting the owner ? > >> 2. The second patch (0002) modifies the ACI for normal user token >> addition from this: >> >> aci: (target = >> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = >> "(objectClass=ipaToken)")(version 3.0; acl "Users can create >> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" >> and userattr = "managedBy#SELFDN";) >> >> To this: >> >> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, >> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >> "Users can create self-managed tokens"; allow (add) userattr = >> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) >> >> The idea is to allow users to create tokens which will be expanded by >> the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs >> are checked. Since the expanded UUID no longer matches the ACI, the >> addition is denied. Is this truly the correct behavior? I would think >> that the ACIs would be checked before the UUID plugin, not after. > I would expect the same, can someone on the DS team comment ? acis are always applied before the entry is sent to the client. the control is added when the result is sent and for the postop control it gets the POST_OP entry and checks read access to teh entry > > Simo. > From simo at redhat.com Thu Oct 9 14:27:34 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 9 Oct 2014 10:27:34 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5436964E.5030504@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <20141009091343.7d2d9c20@willson.usersys.redhat.com> <5436964E.5030504@redhat.com> Message-ID: <20141009102734.142d033c@willson.usersys.redhat.com> On Thu, 09 Oct 2014 16:06:06 +0200 Ludwig Krispenz wrote: > > On 10/09/2014 03:13 PM, Simo Sorce wrote: > > On Wed, 08 Oct 2014 17:46:01 -0400 > > Nathaniel McCallum wrote: > > > >> The background of this email is this bug: > >> https://fedorahosted.org/freeipa/ticket/4456 > >> > >> Attached are two patches which solve this issue for admin users > >> (not very helpful, I know). They depend on this fix in 389: > >> https://fedorahosted.org/389/ticket/47920 > >> > >> There are two outstanding issues: > >> > >> 1. 389 does not send the post read control for normal users. The > >> operation itself succeeds, but no control is sent. > >> > >> The relevant sections from the log are attached. 389 is denying > >> access to the following attributes (* = valid, ! = invalid): > >> ! objectClass > >> ! ipatokenOTPalgorithm > >> ! ipatokenOTPdigits > >> * ipatokenOTPkey > >> * ipatokenHOTPcounter > >> ! ipatokenOwner > >> ! managedBy > >> ! ipatokenUniqueID > >> > >> The ACIs allowing access to most of these attributes are here: > >> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > >> > >> Note that I am able to query the entry just fine (including all the > >> above invalidly restricted attributes). Hence, I know the ACIs are > >> working just fine. > >> > >> Part of the strange thing is that in the post read control > >> request, I haven't indicated that I want *any* attributes returned > >> (i.e. I want just the DN). So I'm not sure why it is querying all > >> the attributes. I would suspect that the proper behavior would be > >> to only check the ACIs on attributes that will actually be > >> returned. > > Can you show an example ldif ? > > I wonder if you are setting the owner ? > > > >> 2. The second patch (0002) modifies the ACI for normal user token > >> addition from this: > >> > >> aci: (target = > >> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = > >> "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" > >> and userattr = "managedBy#SELFDN";) > >> > >> To this: > >> > >> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > >> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > >> "Users can create self-managed tokens"; allow (add) userattr = > >> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > >> > >> The idea is to allow users to create tokens which will be expanded > >> by the UUID plugin. Unfortunately, after the UUID is expanded, the > >> ACIs are checked. Since the expanded UUID no longer matches the > >> ACI, the addition is denied. Is this truly the correct behavior? I > >> would think that the ACIs would be checked before the UUID plugin, > >> not after. > > I would expect the same, can someone on the DS team comment ? > acis are always applied before the entry is sent to the client. the > control is added when the result is sent and for the postop control > it gets the POST_OP entry and checks read access to teh entry So you think the whole add was denied because the post-read couldn't read back the entry ? Then fixing the read-related issue is all we need ? Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Thu Oct 9 14:33:20 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 09 Oct 2014 16:33:20 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <20141009102734.142d033c@willson.usersys.redhat.com> References: <1412804761.9441.12.camel@redhat.com> <20141009091343.7d2d9c20@willson.usersys.redhat.com> <5436964E.5030504@redhat.com> <20141009102734.142d033c@willson.usersys.redhat.com> Message-ID: <54369CB0.2080909@redhat.com> On 10/09/2014 04:27 PM, Simo Sorce wrote: > On Thu, 09 Oct 2014 16:06:06 +0200 > Ludwig Krispenz wrote: > >> On 10/09/2014 03:13 PM, Simo Sorce wrote: >>> On Wed, 08 Oct 2014 17:46:01 -0400 >>> Nathaniel McCallum wrote: >>> >>>> The background of this email is this bug: >>>> https://fedorahosted.org/freeipa/ticket/4456 >>>> >>>> Attached are two patches which solve this issue for admin users >>>> (not very helpful, I know). They depend on this fix in 389: >>>> https://fedorahosted.org/389/ticket/47920 >>>> >>>> There are two outstanding issues: >>>> >>>> 1. 389 does not send the post read control for normal users. The >>>> operation itself succeeds, but no control is sent. >>>> >>>> The relevant sections from the log are attached. 389 is denying >>>> access to the following attributes (* = valid, ! = invalid): >>>> ! objectClass >>>> ! ipatokenOTPalgorithm >>>> ! ipatokenOTPdigits >>>> * ipatokenOTPkey >>>> * ipatokenHOTPcounter >>>> ! ipatokenOwner >>>> ! managedBy >>>> ! ipatokenUniqueID >>>> >>>> The ACIs allowing access to most of these attributes are here: >>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >>>> >>>> Note that I am able to query the entry just fine (including all the >>>> above invalidly restricted attributes). Hence, I know the ACIs are >>>> working just fine. >>>> >>>> Part of the strange thing is that in the post read control >>>> request, I haven't indicated that I want *any* attributes returned >>>> (i.e. I want just the DN). So I'm not sure why it is querying all >>>> the attributes. I would suspect that the proper behavior would be >>>> to only check the ACIs on attributes that will actually be >>>> returned. >>> Can you show an example ldif ? >>> I wonder if you are setting the owner ? >>> >>>> 2. The second patch (0002) modifies the ACI for normal user token >>>> addition from this: >>>> >>>> aci: (target = >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = >>>> "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" >>>> and userattr = "managedBy#SELFDN";) >>>> >>>> To this: >>>> >>>> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, >>>> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>> "Users can create self-managed tokens"; allow (add) userattr = >>>> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) >>>> >>>> The idea is to allow users to create tokens which will be expanded >>>> by the UUID plugin. Unfortunately, after the UUID is expanded, the >>>> ACIs are checked. Since the expanded UUID no longer matches the >>>> ACI, the addition is denied. Is this truly the correct behavior? I >>>> would think that the ACIs would be checked before the UUID plugin, >>>> not after. >>> I would expect the same, can someone on the DS team comment ? >> acis are always applied before the entry is sent to the client. the >> control is added when the result is sent and for the postop control >> it gets the POST_OP entry and checks read access to teh entry > So you think the whole add was denied because the post-read couldn't > read back the entry ? as far as I understood Nathaniel, the add succeeded, only the control was not returned > Then fixing the read-related issue is all we need ? you need an aci allowing to read the postop entry > > Simo. > > From simo at redhat.com Thu Oct 9 14:47:36 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 9 Oct 2014 10:47:36 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <54369CB0.2080909@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <20141009091343.7d2d9c20@willson.usersys.redhat.com> <5436964E.5030504@redhat.com> <20141009102734.142d033c@willson.usersys.redhat.com> <54369CB0.2080909@redhat.com> Message-ID: <20141009104736.457af069@willson.usersys.redhat.com> On Thu, 09 Oct 2014 16:33:20 +0200 Ludwig Krispenz wrote: > > On 10/09/2014 04:27 PM, Simo Sorce wrote: > > On Thu, 09 Oct 2014 16:06:06 +0200 > > Ludwig Krispenz wrote: > > > >> On 10/09/2014 03:13 PM, Simo Sorce wrote: > >>> On Wed, 08 Oct 2014 17:46:01 -0400 > >>> Nathaniel McCallum wrote: > >>> > >>>> The background of this email is this bug: > >>>> https://fedorahosted.org/freeipa/ticket/4456 > >>>> > >>>> Attached are two patches which solve this issue for admin users > >>>> (not very helpful, I know). They depend on this fix in 389: > >>>> https://fedorahosted.org/389/ticket/47920 > >>>> > >>>> There are two outstanding issues: > >>>> > >>>> 1. 389 does not send the post read control for normal users. The > >>>> operation itself succeeds, but no control is sent. > >>>> > >>>> The relevant sections from the log are attached. 389 is denying > >>>> access to the following attributes (* = valid, ! = invalid): > >>>> ! objectClass > >>>> ! ipatokenOTPalgorithm > >>>> ! ipatokenOTPdigits > >>>> * ipatokenOTPkey > >>>> * ipatokenHOTPcounter > >>>> ! ipatokenOwner > >>>> ! managedBy > >>>> ! ipatokenUniqueID > >>>> > >>>> The ACIs allowing access to most of these attributes are here: > >>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > >>>> > >>>> Note that I am able to query the entry just fine (including all > >>>> the above invalidly restricted attributes). Hence, I know the > >>>> ACIs are working just fine. > >>>> > >>>> Part of the strange thing is that in the post read control > >>>> request, I haven't indicated that I want *any* attributes > >>>> returned (i.e. I want just the DN). So I'm not sure why it is > >>>> querying all the attributes. I would suspect that the proper > >>>> behavior would be to only check the ACIs on attributes that will > >>>> actually be returned. > >>> Can you show an example ldif ? > >>> I wonder if you are setting the owner ? > >>> > >>>> 2. The second patch (0002) modifies the ACI for normal user token > >>>> addition from this: > >>>> > >>>> aci: (target = > >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = > >>>> "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >>>> self-managed tokens"; allow (add) userattr = > >>>> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > >>>> > >>>> To this: > >>>> > >>>> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > >>>> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; > >>>> acl "Users can create self-managed tokens"; allow (add) userattr > >>>> = "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > >>>> > >>>> The idea is to allow users to create tokens which will be > >>>> expanded by the UUID plugin. Unfortunately, after the UUID is > >>>> expanded, the ACIs are checked. Since the expanded UUID no > >>>> longer matches the ACI, the addition is denied. Is this truly > >>>> the correct behavior? I would think that the ACIs would be > >>>> checked before the UUID plugin, not after. > >>> I would expect the same, can someone on the DS team comment ? > >> acis are always applied before the entry is sent to the client. the > >> control is added when the result is sent and for the postop control > >> it gets the POST_OP entry and checks read access to teh entry > > So you think the whole add was denied because the post-read couldn't > > read back the entry ? > as far as I understood Nathaniel, the add succeeded, only the control > was not returned > > Then fixing the read-related issue is all we need ? > you need an aci allowing to read the postop entry Btw we could add userattr = creatorsName#SELFDN" to the read ACI so that ipatokenOwner/managedby are not strictly needed for post-read ? Does it make sense to do ? Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Thu Oct 9 15:29:45 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 09 Oct 2014 17:29:45 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <20141009104736.457af069@willson.usersys.redhat.com> References: <1412804761.9441.12.camel@redhat.com> <20141009091343.7d2d9c20@willson.usersys.redhat.com> <5436964E.5030504@redhat.com> <20141009102734.142d033c@willson.usersys.redhat.com> <54369CB0.2080909@redhat.com> <20141009104736.457af069@willson.usersys.redhat.com> Message-ID: <5436A9E9.3070205@redhat.com> On 10/09/2014 04:47 PM, Simo Sorce wrote: > On Thu, 09 Oct 2014 16:33:20 +0200 > Ludwig Krispenz wrote: > >> On 10/09/2014 04:27 PM, Simo Sorce wrote: >>> On Thu, 09 Oct 2014 16:06:06 +0200 >>> Ludwig Krispenz wrote: >>> >>>> On 10/09/2014 03:13 PM, Simo Sorce wrote: >>>>> On Wed, 08 Oct 2014 17:46:01 -0400 >>>>> Nathaniel McCallum wrote: >>>>> >>>>>> The background of this email is this bug: >>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>> >>>>>> Attached are two patches which solve this issue for admin users >>>>>> (not very helpful, I know). They depend on this fix in 389: >>>>>> https://fedorahosted.org/389/ticket/47920 >>>>>> >>>>>> There are two outstanding issues: >>>>>> >>>>>> 1. 389 does not send the post read control for normal users. The >>>>>> operation itself succeeds, but no control is sent. >>>>>> >>>>>> The relevant sections from the log are attached. 389 is denying >>>>>> access to the following attributes (* = valid, ! = invalid): >>>>>> ! objectClass >>>>>> ! ipatokenOTPalgorithm >>>>>> ! ipatokenOTPdigits >>>>>> * ipatokenOTPkey >>>>>> * ipatokenHOTPcounter >>>>>> ! ipatokenOwner >>>>>> ! managedBy >>>>>> ! ipatokenUniqueID >>>>>> >>>>>> The ACIs allowing access to most of these attributes are here: >>>>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >>>>>> >>>>>> Note that I am able to query the entry just fine (including all >>>>>> the above invalidly restricted attributes). Hence, I know the >>>>>> ACIs are working just fine. >>>>>> >>>>>> Part of the strange thing is that in the post read control >>>>>> request, I haven't indicated that I want *any* attributes >>>>>> returned (i.e. I want just the DN). So I'm not sure why it is >>>>>> querying all the attributes. I would suspect that the proper >>>>>> behavior would be to only check the ACIs on attributes that will >>>>>> actually be returned. >>>>> Can you show an example ldif ? >>>>> I wonder if you are setting the owner ? >>>>> >>>>>> 2. The second patch (0002) modifies the ACI for normal user token >>>>>> addition from this: >>>>>> >>>>>> aci: (target = >>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = >>>>>> "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>>> self-managed tokens"; allow (add) userattr = >>>>>> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) >>>>>> >>>>>> To this: >>>>>> >>>>>> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, >>>>>> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; >>>>>> acl "Users can create self-managed tokens"; allow (add) userattr >>>>>> = "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) >>>>>> >>>>>> The idea is to allow users to create tokens which will be >>>>>> expanded by the UUID plugin. Unfortunately, after the UUID is >>>>>> expanded, the ACIs are checked. Since the expanded UUID no >>>>>> longer matches the ACI, the addition is denied. Is this truly >>>>>> the correct behavior? I would think that the ACIs would be >>>>>> checked before the UUID plugin, not after. >>>>> I would expect the same, can someone on the DS team comment ? >>>> acis are always applied before the entry is sent to the client. the >>>> control is added when the result is sent and for the postop control >>>> it gets the POST_OP entry and checks read access to teh entry >>> So you think the whole add was denied because the post-read couldn't >>> read back the entry ? >> as far as I understood Nathaniel, the add succeeded, only the control >> was not returned >>> Then fixing the read-related issue is all we need ? >> you need an aci allowing to read the postop entry > Btw we could add userattr = creatorsName#SELFDN" to the read ACI so that > ipatokenOwner/managedby are not strictly needed for post-read ? > Does it make sense to do ? I'm not sure, are there cases when tokenOwner is not set or different from selfdn ? Could anyone else create the token for another user (an admin )? I don't see what the entry really looked like when trying to create the control, and who was "self" in that scenario. In Nathaniel's post access was denied to uid=otp,.... is this the tokenwoner ? > > Simo. > From npmccallum at redhat.com Thu Oct 9 15:51:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Oct 2014 11:51:14 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <543658E4.3010103@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> Message-ID: <1412869874.3262.2.camel@redhat.com> On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: > On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: > > > On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: > > > On Wed, 08 Oct 2014 15:53:39 -0400 > > > Nathaniel McCallum wrote: > > > > > > > As I understand my code, all servers will have csnD. Some servers will > > > > have valueB and others will have valueD, but valueB == valueD. > > > > > > > > We *never* discard a CSN. We only discard the counter/watermark mods > > > > in the replication operation. > > > What Thierry is saying is that the individual attributes in the entry > > > have associate the last CSN that modified them. Because you remove the > > > mods when ValueD == ValueB the counter attribute will not have the > > > associated CSN changed. But it doesn't really matter because the plugin > > > will always keep things consistent. > > Attached is a new version. It removes this optimization. If server X has > > valueB/csnB and receives valueD/csnD and valueB == valueD, the > > replication will be applied without any modification. However, if valueB > > > valueD and csnD > csnB, the counter mods will still be stripped. > > It also collapses the error check from betxnpre to bepre now that we > > have a fix for https://fedorahosted.org/389/ticket/47919 committed. The > > betxnpre functions are completely removed. Also, a dependency on 389 > > 1.3.3.4 (not yet released) is added. > > > > Nathaniel > Hello Nathaniel, > > For me the code is fine. Ack. New attached patch. > I have two minor comments: > * in preop_mod, when a direct update moves the counter > backward you send UNWILLING to perform with a message. > The message is allocated with slapi_ch_smprintf, you > may free it with slapi_ch_free_string (rather than > 'free'). Fixed. > * About this message, for example when you have these > MODS (I admit they make no sens): > > changetype: modify > ipatokenHOTPcounter: MOD_DELETE > - > ipatokenHOTPcounter: MOD_INCREMENT > > The returned message will be "Will not decrement > ipatokenHOTPcounter", because 'simulate' will return > 'COUNTER_UNSET+1'. > Is it the message you expected ? I changed the logic in simulate(). Please review it. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.7-Create-ipa-otp-counter-389DS-plugin.patch Type: text/x-patch Size: 34626 bytes Desc: not available URL: From npmccallum at redhat.com Thu Oct 9 15:51:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Oct 2014 11:51:28 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <54369CB0.2080909@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <20141009091343.7d2d9c20@willson.usersys.redhat.com> <5436964E.5030504@redhat.com> <20141009102734.142d033c@willson.usersys.redhat.com> <54369CB0.2080909@redhat.com> Message-ID: <1412869888.3262.3.camel@redhat.com> On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote: > On 10/09/2014 04:27 PM, Simo Sorce wrote: > > On Thu, 09 Oct 2014 16:06:06 +0200 > > Ludwig Krispenz wrote: > > > >> On 10/09/2014 03:13 PM, Simo Sorce wrote: > >>> On Wed, 08 Oct 2014 17:46:01 -0400 > >>> Nathaniel McCallum wrote: > >>> > >>>> The background of this email is this bug: > >>>> https://fedorahosted.org/freeipa/ticket/4456 > >>>> > >>>> Attached are two patches which solve this issue for admin users > >>>> (not very helpful, I know). They depend on this fix in 389: > >>>> https://fedorahosted.org/389/ticket/47920 > >>>> > >>>> There are two outstanding issues: > >>>> > >>>> 1. 389 does not send the post read control for normal users. The > >>>> operation itself succeeds, but no control is sent. > >>>> > >>>> The relevant sections from the log are attached. 389 is denying > >>>> access to the following attributes (* = valid, ! = invalid): > >>>> ! objectClass > >>>> ! ipatokenOTPalgorithm > >>>> ! ipatokenOTPdigits > >>>> * ipatokenOTPkey > >>>> * ipatokenHOTPcounter > >>>> ! ipatokenOwner > >>>> ! managedBy > >>>> ! ipatokenUniqueID > >>>> > >>>> The ACIs allowing access to most of these attributes are here: > >>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > >>>> > >>>> Note that I am able to query the entry just fine (including all the > >>>> above invalidly restricted attributes). Hence, I know the ACIs are > >>>> working just fine. > >>>> > >>>> Part of the strange thing is that in the post read control > >>>> request, I haven't indicated that I want *any* attributes returned > >>>> (i.e. I want just the DN). So I'm not sure why it is querying all > >>>> the attributes. I would suspect that the proper behavior would be > >>>> to only check the ACIs on attributes that will actually be > >>>> returned. > >>> Can you show an example ldif ? > >>> I wonder if you are setting the owner ? This is the ldif I used: dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com changetype: add objectClass: top objectClass: ipaToken objectClass: ipaTokenHOTP ipatokenUniqueID: autogenerate ipatokenOTPalgorithm: sha1 ipatokenOTPdigits: 6 ipatokenOTPkey: 00000000 ipatokenHOTPcounter: 0 ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com > >>>> 2. The second patch (0002) modifies the ACI for normal user token > >>>> addition from this: > >>>> > >>>> aci: (target = > >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = > >>>> "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" > >>>> and userattr = "managedBy#SELFDN";) > >>>> > >>>> To this: > >>>> > >>>> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > >>>> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > >>>> "Users can create self-managed tokens"; allow (add) userattr = > >>>> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > >>>> > >>>> The idea is to allow users to create tokens which will be expanded > >>>> by the UUID plugin. Unfortunately, after the UUID is expanded, the > >>>> ACIs are checked. Since the expanded UUID no longer matches the > >>>> ACI, the addition is denied. Is this truly the correct behavior? I > >>>> would think that the ACIs would be checked before the UUID plugin, > >>>> not after. > >>> I would expect the same, can someone on the DS team comment ? > >> acis are always applied before the entry is sent to the client. the > >> control is added when the result is sent and for the postop control > >> it gets the POST_OP entry and checks read access to teh entry > > So you think the whole add was denied because the post-read couldn't > > read back the entry ? > as far as I understood Nathaniel, the add succeeded, only the control > was not returned > > Then fixing the read-related issue is all we need ? > you need an aci allowing to read the postop entry No. Issue #2 is unrelated to issue #1. In issue #2, the add itself fails. From lkrispen at redhat.com Thu Oct 9 16:01:54 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 09 Oct 2014 18:01:54 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412869888.3262.3.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <20141009091343.7d2d9c20@willson.usersys.redhat.com> <5436964E.5030504@redhat.com> <20141009102734.142d033c@willson.usersys.redhat.com> <54369CB0.2080909@redhat.com> <1412869888.3262.3.camel@redhat.com> Message-ID: <5436B172.7010301@redhat.com> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote: >> On 10/09/2014 04:27 PM, Simo Sorce wrote: >>> On Thu, 09 Oct 2014 16:06:06 +0200 >>> Ludwig Krispenz wrote: >>> >>>> On 10/09/2014 03:13 PM, Simo Sorce wrote: >>>>> On Wed, 08 Oct 2014 17:46:01 -0400 >>>>> Nathaniel McCallum wrote: >>>>> >>>>>> The background of this email is this bug: >>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>> >>>>>> Attached are two patches which solve this issue for admin users >>>>>> (not very helpful, I know). They depend on this fix in 389: >>>>>> https://fedorahosted.org/389/ticket/47920 >>>>>> >>>>>> There are two outstanding issues: >>>>>> >>>>>> 1. 389 does not send the post read control for normal users. The >>>>>> operation itself succeeds, but no control is sent. >>>>>> >>>>>> The relevant sections from the log are attached. 389 is denying >>>>>> access to the following attributes (* = valid, ! = invalid): >>>>>> ! objectClass >>>>>> ! ipatokenOTPalgorithm >>>>>> ! ipatokenOTPdigits >>>>>> * ipatokenOTPkey >>>>>> * ipatokenHOTPcounter >>>>>> ! ipatokenOwner >>>>>> ! managedBy >>>>>> ! ipatokenUniqueID >>>>>> >>>>>> The ACIs allowing access to most of these attributes are here: >>>>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >>>>>> >>>>>> Note that I am able to query the entry just fine (including all the >>>>>> above invalidly restricted attributes). Hence, I know the ACIs are >>>>>> working just fine. >>>>>> >>>>>> Part of the strange thing is that in the post read control >>>>>> request, I haven't indicated that I want *any* attributes returned >>>>>> (i.e. I want just the DN). So I'm not sure why it is querying all >>>>>> the attributes. I would suspect that the proper behavior would be >>>>>> to only check the ACIs on attributes that will actually be >>>>>> returned. >>>>> Can you show an example ldif ? >>>>> I wonder if you are setting the owner ? > This is the ldif I used: > dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com > changetype: add > objectClass: top > objectClass: ipaToken > objectClass: ipaTokenHOTP > ipatokenUniqueID: autogenerate > ipatokenOTPalgorithm: sha1 > ipatokenOTPdigits: 6 > ipatokenOTPkey: 00000000 > ipatokenHOTPcounter: 0 > ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com > managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com > >>>>>> 2. The second patch (0002) modifies the ACI for normal user token >>>>>> addition from this: >>>>>> >>>>>> aci: (target = >>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = >>>>>> "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" >>>>>> and userattr = "managedBy#SELFDN";) >>>>>> >>>>>> To this: >>>>>> >>>>>> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, >>>>>> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>>>> "Users can create self-managed tokens"; allow (add) userattr = >>>>>> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) >>>>>> >>>>>> The idea is to allow users to create tokens which will be expanded >>>>>> by the UUID plugin. Unfortunately, after the UUID is expanded, the >>>>>> ACIs are checked. Since the expanded UUID no longer matches the >>>>>> ACI, the addition is denied. Is this truly the correct behavior? I >>>>>> would think that the ACIs would be checked before the UUID plugin, >>>>>> not after. >>>>> I would expect the same, can someone on the DS team comment ? >>>> acis are always applied before the entry is sent to the client. the >>>> control is added when the result is sent and for the postop control >>>> it gets the POST_OP entry and checks read access to teh entry >>> So you think the whole add was denied because the post-read couldn't >>> read back the entry ? >> as far as I understood Nathaniel, the add succeeded, only the control >> was not returned >>> Then fixing the read-related issue is all we need ? >> you need an aci allowing to read the postop entry > No. Issue #2 is unrelated to issue #1. In issue #2, the add itself > fails. is this because of the change from tokenuiqieid=* to tokenuniqueid=autogenerate in the aci, why not stick to* > From npmccallum at redhat.com Thu Oct 9 16:02:15 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Oct 2014 12:02:15 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5436B172.7010301@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <20141009091343.7d2d9c20@willson.usersys.redhat.com> <5436964E.5030504@redhat.com> <20141009102734.142d033c@willson.usersys.redhat.com> <54369CB0.2080909@redhat.com> <1412869888.3262.3.camel@redhat.com> <5436B172.7010301@redhat.com> Message-ID: <1412870535.3262.7.camel@redhat.com> On Thu, 2014-10-09 at 18:01 +0200, Ludwig Krispenz wrote: > On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: > > On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote: > >> On 10/09/2014 04:27 PM, Simo Sorce wrote: > >>> On Thu, 09 Oct 2014 16:06:06 +0200 > >>> Ludwig Krispenz wrote: > >>> > >>>> On 10/09/2014 03:13 PM, Simo Sorce wrote: > >>>>> On Wed, 08 Oct 2014 17:46:01 -0400 > >>>>> Nathaniel McCallum wrote: > >>>>> > >>>>>> The background of this email is this bug: > >>>>>> https://fedorahosted.org/freeipa/ticket/4456 > >>>>>> > >>>>>> Attached are two patches which solve this issue for admin users > >>>>>> (not very helpful, I know). They depend on this fix in 389: > >>>>>> https://fedorahosted.org/389/ticket/47920 > >>>>>> > >>>>>> There are two outstanding issues: > >>>>>> > >>>>>> 1. 389 does not send the post read control for normal users. The > >>>>>> operation itself succeeds, but no control is sent. > >>>>>> > >>>>>> The relevant sections from the log are attached. 389 is denying > >>>>>> access to the following attributes (* = valid, ! = invalid): > >>>>>> ! objectClass > >>>>>> ! ipatokenOTPalgorithm > >>>>>> ! ipatokenOTPdigits > >>>>>> * ipatokenOTPkey > >>>>>> * ipatokenHOTPcounter > >>>>>> ! ipatokenOwner > >>>>>> ! managedBy > >>>>>> ! ipatokenUniqueID > >>>>>> > >>>>>> The ACIs allowing access to most of these attributes are here: > >>>>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > >>>>>> > >>>>>> Note that I am able to query the entry just fine (including all the > >>>>>> above invalidly restricted attributes). Hence, I know the ACIs are > >>>>>> working just fine. > >>>>>> > >>>>>> Part of the strange thing is that in the post read control > >>>>>> request, I haven't indicated that I want *any* attributes returned > >>>>>> (i.e. I want just the DN). So I'm not sure why it is querying all > >>>>>> the attributes. I would suspect that the proper behavior would be > >>>>>> to only check the ACIs on attributes that will actually be > >>>>>> returned. > >>>>> Can you show an example ldif ? > >>>>> I wonder if you are setting the owner ? > > This is the ldif I used: > > dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com > > changetype: add > > objectClass: top > > objectClass: ipaToken > > objectClass: ipaTokenHOTP > > ipatokenUniqueID: autogenerate > > ipatokenOTPalgorithm: sha1 > > ipatokenOTPdigits: 6 > > ipatokenOTPkey: 00000000 > > ipatokenHOTPcounter: 0 > > ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com > > managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com > > > >>>>>> 2. The second patch (0002) modifies the ACI for normal user token > >>>>>> addition from this: > >>>>>> > >>>>>> aci: (target = > >>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = > >>>>>> "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" > >>>>>> and userattr = "managedBy#SELFDN";) > >>>>>> > >>>>>> To this: > >>>>>> > >>>>>> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > >>>>>> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > >>>>>> "Users can create self-managed tokens"; allow (add) userattr = > >>>>>> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > >>>>>> > >>>>>> The idea is to allow users to create tokens which will be expanded > >>>>>> by the UUID plugin. Unfortunately, after the UUID is expanded, the > >>>>>> ACIs are checked. Since the expanded UUID no longer matches the > >>>>>> ACI, the addition is denied. Is this truly the correct behavior? I > >>>>>> would think that the ACIs would be checked before the UUID plugin, > >>>>>> not after. > >>>>> I would expect the same, can someone on the DS team comment ? > >>>> acis are always applied before the entry is sent to the client. the > >>>> control is added when the result is sent and for the postop control > >>>> it gets the POST_OP entry and checks read access to teh entry > >>> So you think the whole add was denied because the post-read couldn't > >>> read back the entry ? > >> as far as I understood Nathaniel, the add succeeded, only the control > >> was not returned > >>> Then fixing the read-related issue is all we need ? > >> you need an aci allowing to read the postop entry > > No. Issue #2 is unrelated to issue #1. In issue #2, the add itself > > fails. > is this because of the change from tokenuiqieid=* to > tokenuniqueid=autogenerate in the aci? Yes. > why not stick to* Because all of this work is done precisely to change from * to autogenerate. The goal is to make it so that ordinary users can only create autogenerated token IDs while admins can specify their own custom token IDs. Nathaniel From npmccallum at redhat.com Thu Oct 9 16:27:55 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Oct 2014 12:27:55 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <54367B5D.6050900@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> Message-ID: <1412872075.3262.9.camel@redhat.com> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: > On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: > > > The background of this email is this bug: > > https://fedorahosted.org/freeipa/ticket/4456 > > > > Attached are two patches which solve this issue for admin users (not > > very helpful, I know). They depend on this fix in 389: > > https://fedorahosted.org/389/ticket/47920 > > > > There are two outstanding issues: > > > > 1. 389 does not send the post read control for normal users. The > > operation itself succeeds, but no control is sent. > > > > The relevant sections from the log are attached. 389 is denying access > > to the following attributes (* = valid, ! = invalid): > > ! objectClass > > ! ipatokenOTPalgorithm > > ! ipatokenOTPdigits > > * ipatokenOTPkey > > * ipatokenHOTPcounter > > ! ipatokenOwner > > ! managedBy > > ! ipatokenUniqueID > Hello Nathaniel, > > The post read control needs access to the modified entry to > return it. > This access is granted at the condition, the binddn can access > attributes. Agreed and understood. > My understanding is that the target entry is > ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". Correct. > The only ACI I found that match this target is: > aci: (targetfilter = "(objectClass=ipaToken)") > (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled > || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") > (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) Correct. > Do you know if the target entry has 'ipatokenOwner' or > 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? > > The ACIs allowing access to most of these attributes are here: > > https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > > > > Note that I am able to query the entry just fine (including all the > > above invalidly restricted attributes). Hence, I know the ACIs are > > working just fine. > > > > Part of the strange thing is that in the post read control request, I > > haven't indicated that I want *any* attributes returned (i.e. I want > > just the DN). So I'm not sure why it is querying all the attributes. I > > would suspect that the proper behavior would be to only check the ACIs > > on attributes that will actually be returned. > It may not querying all attributes, but just search the first > one it can read. > As it finds none of them you get the message for all > attributes. Right, but why iterate through all possible attributes? It should only iterate through the attributes requested. Whether the user can read a non-requested attribute or not is irrelevant because the attribute was not requested. From tbordaz at redhat.com Thu Oct 9 16:32:01 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 09 Oct 2014 18:32:01 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412872075.3262.9.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> Message-ID: <5436B881.3070002@redhat.com> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >> >>> The background of this email is this bug: >>> https://fedorahosted.org/freeipa/ticket/4456 >>> >>> Attached are two patches which solve this issue for admin users (not >>> very helpful, I know). They depend on this fix in 389: >>> https://fedorahosted.org/389/ticket/47920 >>> >>> There are two outstanding issues: >>> >>> 1. 389 does not send the post read control for normal users. The >>> operation itself succeeds, but no control is sent. >>> >>> The relevant sections from the log are attached. 389 is denying access >>> to the following attributes (* = valid, ! = invalid): >>> ! objectClass >>> ! ipatokenOTPalgorithm >>> ! ipatokenOTPdigits >>> * ipatokenOTPkey >>> * ipatokenHOTPcounter >>> ! ipatokenOwner >>> ! managedBy >>> ! ipatokenUniqueID >> Hello Nathaniel, >> >> The post read control needs access to the modified entry to >> return it. >> This access is granted at the condition, the binddn can access >> attributes. > Agreed and understood. > >> My understanding is that the target entry is >> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". > Correct. > >> The only ACI I found that match this target is: >> aci: (targetfilter = "(objectClass=ipaToken)") >> (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled >> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") >> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > Correct. > >> Do you know if the target entry has 'ipatokenOwner' or >> 'managedBy' with the binddn value ? > Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce > >>> The ACIs allowing access to most of these attributes are here: >>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >>> >>> Note that I am able to query the entry just fine (including all the >>> above invalidly restricted attributes). Hence, I know the ACIs are >>> working just fine. >>> >>> Part of the strange thing is that in the post read control request, I >>> haven't indicated that I want *any* attributes returned (i.e. I want >>> just the DN). So I'm not sure why it is querying all the attributes. I >>> would suspect that the proper behavior would be to only check the ACIs >>> on attributes that will actually be returned. >> It may not querying all attributes, but just search the first >> one it can read. >> As it finds none of them you get the message for all >> attributes. > Right, but why iterate through all possible attributes? It should only > iterate through the attributes requested. Whether the user can read a > non-requested attribute or not is irrelevant because the attribute was > not requested. I think it is iterating from the attributes in the entry. Searching the first one that the authenticated subject is allowed to read. thanks thierry From lkrispen at redhat.com Thu Oct 9 16:38:14 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 09 Oct 2014 18:38:14 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5436B881.3070002@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> Message-ID: <5436B9F6.8010607@redhat.com> On 10/09/2014 06:32 PM, thierry bordaz wrote: > On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: >> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >>> >>>> The background of this email is this bug: >>>> https://fedorahosted.org/freeipa/ticket/4456 >>>> >>>> Attached are two patches which solve this issue for admin users (not >>>> very helpful, I know). They depend on this fix in 389: >>>> https://fedorahosted.org/389/ticket/47920 >>>> >>>> There are two outstanding issues: >>>> >>>> 1. 389 does not send the post read control for normal users. The >>>> operation itself succeeds, but no control is sent. >>>> >>>> The relevant sections from the log are attached. 389 is denying access >>>> to the following attributes (* = valid, ! = invalid): >>>> ! objectClass >>>> ! ipatokenOTPalgorithm >>>> ! ipatokenOTPdigits >>>> * ipatokenOTPkey >>>> * ipatokenHOTPcounter >>>> ! ipatokenOwner >>>> ! managedBy >>>> ! ipatokenUniqueID >>> Hello Nathaniel, >>> >>> The post read control needs access to the modified entry to >>> return it. >>> This access is granted at the condition, the binddn can access >>> attributes. >> Agreed and understood. >> >>> My understanding is that the target entry is >>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com >>> and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". >> Correct. >> >>> The only ACI I found that match this target is: >>> aci: (targetfilter = "(objectClass=ipaToken)") >>> (targetattrs = "objectclass || description || managedBy || >>> ipatokenUniqueID || ipatokenDisabled >>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor >>> || ipatokenModel || ipatokenSerial || ipatokenOwner") >>> (version 3.0; acl "Users/managers can read basic token >>> info"; allow (read, search, compare) userattr = >>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >> Correct. >> >>> Do you know if the target entry has 'ipatokenOwner' or >>> 'managedBy' with the binddn value ? >> Yes, both. So why is access to objectClass (et cetera) being denied? > Good question... +1 could you post the full aci logging not only the summary for the access to the attributes ? > I will try to reproduce >> >>>> The ACIs allowing access to most of these attributes are here: >>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >>>> >>>> >>>> Note that I am able to query the entry just fine (including all the >>>> above invalidly restricted attributes). Hence, I know the ACIs are >>>> working just fine. >>>> >>>> Part of the strange thing is that in the post read control request, I >>>> haven't indicated that I want *any* attributes returned (i.e. I want >>>> just the DN). So I'm not sure why it is querying all the attributes. I >>>> would suspect that the proper behavior would be to only check the ACIs >>>> on attributes that will actually be returned. >>> It may not querying all attributes, but just search the first >>> one it can read. >>> As it finds none of them you get the message for all >>> attributes. >> Right, but why iterate through all possible attributes? It should only >> iterate through the attributes requested. Whether the user can read a >> non-requested attribute or not is irrelevant because the attribute was >> not requested. > I think it is iterating from the attributes in the entry. Searching > the first one that the authenticated subject is allowed to read. > > thanks > thierry > From npmccallum at redhat.com Thu Oct 9 16:40:07 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Oct 2014 12:40:07 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5436B881.3070002@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> Message-ID: <1412872807.3262.10.camel@redhat.com> On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: > On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: > > On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: > >> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: > >> > >>> The background of this email is this bug: > >>> https://fedorahosted.org/freeipa/ticket/4456 > >>> > >>> Attached are two patches which solve this issue for admin users (not > >>> very helpful, I know). They depend on this fix in 389: > >>> https://fedorahosted.org/389/ticket/47920 > >>> > >>> There are two outstanding issues: > >>> > >>> 1. 389 does not send the post read control for normal users. The > >>> operation itself succeeds, but no control is sent. > >>> > >>> The relevant sections from the log are attached. 389 is denying access > >>> to the following attributes (* = valid, ! = invalid): > >>> ! objectClass > >>> ! ipatokenOTPalgorithm > >>> ! ipatokenOTPdigits > >>> * ipatokenOTPkey > >>> * ipatokenHOTPcounter > >>> ! ipatokenOwner > >>> ! managedBy > >>> ! ipatokenUniqueID > >> Hello Nathaniel, > >> > >> The post read control needs access to the modified entry to > >> return it. > >> This access is granted at the condition, the binddn can access > >> attributes. > > Agreed and understood. > > > >> My understanding is that the target entry is > >> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". > > Correct. > > > >> The only ACI I found that match this target is: > >> aci: (targetfilter = "(objectClass=ipaToken)") > >> (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled > >> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") > >> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > Correct. > > > >> Do you know if the target entry has 'ipatokenOwner' or > >> 'managedBy' with the binddn value ? > > Yes, both. So why is access to objectClass (et cetera) being denied? > Good question... I will try to reproduce Thanks! > >>> The ACIs allowing access to most of these attributes are here: > >>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > >>> > >>> Note that I am able to query the entry just fine (including all the > >>> above invalidly restricted attributes). Hence, I know the ACIs are > >>> working just fine. > >>> > >>> Part of the strange thing is that in the post read control request, I > >>> haven't indicated that I want *any* attributes returned (i.e. I want > >>> just the DN). So I'm not sure why it is querying all the attributes. I > >>> would suspect that the proper behavior would be to only check the ACIs > >>> on attributes that will actually be returned. > >> It may not querying all attributes, but just search the first > >> one it can read. > >> As it finds none of them you get the message for all > >> attributes. > > Right, but why iterate through all possible attributes? It should only > > iterate through the attributes requested. Whether the user can read a > > non-requested attribute or not is irrelevant because the attribute was > > not requested. > I think it is iterating from the attributes in the entry. Searching the > first one that the authenticated subject is allowed to read. I agree. The question is: why? Nathaniel From tbordaz at redhat.com Thu Oct 9 16:48:25 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 09 Oct 2014 18:48:25 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1412869874.3262.2.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> Message-ID: <5436BC59.2090008@redhat.com> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: >> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: >> >>> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: >>>> On Wed, 08 Oct 2014 15:53:39 -0400 >>>> Nathaniel McCallum wrote: >>>> >>>>> As I understand my code, all servers will have csnD. Some servers will >>>>> have valueB and others will have valueD, but valueB == valueD. >>>>> >>>>> We *never* discard a CSN. We only discard the counter/watermark mods >>>>> in the replication operation. >>>> What Thierry is saying is that the individual attributes in the entry >>>> have associate the last CSN that modified them. Because you remove the >>>> mods when ValueD == ValueB the counter attribute will not have the >>>> associated CSN changed. But it doesn't really matter because the plugin >>>> will always keep things consistent. >>> Attached is a new version. It removes this optimization. If server X has >>> valueB/csnB and receives valueD/csnD and valueB == valueD, the >>> replication will be applied without any modification. However, if valueB >>>> valueD and csnD > csnB, the counter mods will still be stripped. >>> It also collapses the error check from betxnpre to bepre now that we >>> have a fix for https://fedorahosted.org/389/ticket/47919 committed. The >>> betxnpre functions are completely removed. Also, a dependency on 389 >>> 1.3.3.4 (not yet released) is added. >>> >>> Nathaniel >> Hello Nathaniel, >> >> For me the code is fine. Ack. > New attached patch. > >> I have two minor comments: >> * in preop_mod, when a direct update moves the counter >> backward you send UNWILLING to perform with a message. >> The message is allocated with slapi_ch_smprintf, you >> may free it with slapi_ch_free_string (rather than >> 'free'). > Fixed. > >> * About this message, for example when you have these >> MODS (I admit they make no sens): >> >> changetype: modify >> ipatokenHOTPcounter: MOD_DELETE >> - >> ipatokenHOTPcounter: MOD_INCREMENT >> >> The returned message will be "Will not decrement >> ipatokenHOTPcounter", because 'simulate' will return >> 'COUNTER_UNSET+1'. >> Is it the message you expected ? > I changed the logic in simulate(). Please review it. > > Nathaniel > Hello Nathaniel, The patch is ok for me. Ack. Thank you thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Thu Oct 9 16:53:34 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Oct 2014 12:53:34 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5436B9F6.8010607@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <5436B9F6.8010607@redhat.com> Message-ID: <1412873614.3262.11.camel@redhat.com> On Thu, 2014-10-09 at 18:38 +0200, Ludwig Krispenz wrote: > On 10/09/2014 06:32 PM, thierry bordaz wrote: > > On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: > >> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: > >>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: > >>> > >>>> The background of this email is this bug: > >>>> https://fedorahosted.org/freeipa/ticket/4456 > >>>> > >>>> Attached are two patches which solve this issue for admin users (not > >>>> very helpful, I know). They depend on this fix in 389: > >>>> https://fedorahosted.org/389/ticket/47920 > >>>> > >>>> There are two outstanding issues: > >>>> > >>>> 1. 389 does not send the post read control for normal users. The > >>>> operation itself succeeds, but no control is sent. > >>>> > >>>> The relevant sections from the log are attached. 389 is denying access > >>>> to the following attributes (* = valid, ! = invalid): > >>>> ! objectClass > >>>> ! ipatokenOTPalgorithm > >>>> ! ipatokenOTPdigits > >>>> * ipatokenOTPkey > >>>> * ipatokenHOTPcounter > >>>> ! ipatokenOwner > >>>> ! managedBy > >>>> ! ipatokenUniqueID > >>> Hello Nathaniel, > >>> > >>> The post read control needs access to the modified entry to > >>> return it. > >>> This access is granted at the condition, the binddn can access > >>> attributes. > >> Agreed and understood. > >> > >>> My understanding is that the target entry is > >>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com > >>> and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". > >> Correct. > >> > >>> The only ACI I found that match this target is: > >>> aci: (targetfilter = "(objectClass=ipaToken)") > >>> (targetattrs = "objectclass || description || managedBy || > >>> ipatokenUniqueID || ipatokenDisabled > >>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor > >>> || ipatokenModel || ipatokenSerial || ipatokenOwner") > >>> (version 3.0; acl "Users/managers can read basic token > >>> info"; allow (read, search, compare) userattr = > >>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > >> Correct. > >> > >>> Do you know if the target entry has 'ipatokenOwner' or > >>> 'managedBy' with the binddn value ? > >> Yes, both. So why is access to objectClass (et cetera) being denied? > > Good question... > +1 > could you post the full aci logging not only the summary for the access > to the attributes ? Attached. -------------- next part -------------- [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=anonymous-limits,cn=etc,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "uid=otp,cn=users,cn=accounts,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of service reference [08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of service reference [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] ipa-lockout-plugin - preop returning 0: success [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "uid=otp,cn=users,cn=accounts,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] ipa-pwd-extop - Attempting OTP authentication for 'uid=otp,cn=users,cn=accounts,dc=example,dc=com'. [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "dc=example,dc=com" for "(&(|(objectClass=ipaTokenTOTP)(objectClass=ipaTokenHOTP))(ipatokenOwner=uid=otp,cn=users,cn=accounts,dc=example,dc=com)(|(ipatokenNotBefore<=20141008205439Z)(!(ipatokenNotBefore=*)))(|(ipatokenNotAfter>=20141008205439Z)(!(ipatokenNotAfter=*)))(|(ipatokenDisabled=FALSE)(!(ipatokenDisabled=*))))" with scope 2 (sub) [08/Oct/2014:16:54:39 -0400] ipa-pwd-extop - kerberos key already present in user entry: uid=otp,cn=users,cn=accounts,dc=example,dc=com [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "uid=otp,cn=users,cn=accounts,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "uid=otp,cn=users,cn=accounts,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=anonymous-limits,cn=etc,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of service reference [08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of service reference [08/Oct/2014:16:54:39 -0400] ipa-range-check - Not an ID range object, nothing to do. [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD begin [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD target=ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD begin [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD target=ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD begin [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD target=ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD begin [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD target=ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD begin [08/Oct/2014:16:54:39 -0400] NSUniqueAttr - ADD target=ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "uid=otp,cn=users,cn=accounts,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] NSACLPlugin - #### conn=24 op=1 binddn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Allow add on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(NULL) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: allowed by aci(38): aciname= "Users can create self-managed tokens", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NS7bitAttr - ADD begin [08/Oct/2014:16:54:39 -0400] NS7bitAttr - ADD target=ipaTokenUniqueID=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com [08/Oct/2014:16:54:39 -0400] DSRetroclPlugin - write_replog_db: write change record 11118 for dn: "ipaTokenUniqueID=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] DSRetroclPlugin - write_replog_db: add targetUniqueId: "32102902-4f2d11e4-a8c0ee17-25642a64" [08/Oct/2014:16:54:39 -0400] NS7bitAttr - ADD begin [08/Oct/2014:16:54:39 -0400] NS7bitAttr - ADD target=changenumber=11118,cn=changelog [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - added "changenumber=11118,cn=changelog" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11118,cn=changelog" does not belong in "cn=compat,dc=example,dc=com"/"cn=computers" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11118,cn=changelog" does not belong in "cn=compat,dc=example,dc=com"/"cn=groups" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11118,cn=changelog" does not belong in "cn=compat,dc=example,dc=com"/"cn=ng" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11118,cn=changelog" does not belong in "cn=compat,dc=example,dc=com"/"cn=users" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11118,cn=changelog" does not belong in "ou=sudoers,dc=example,dc=com"/"" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=computers" made in ("changenumber=11118,cn=changelog") ("" in list "" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=groups" made in ("changenumber=11118,cn=changelog") ("" in list "cn,gidNumber,member,uid,memberUid" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - updating deref_r[0] references for "changenumber=11118,cn=changelog" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching for references to "changenumber=11118,cn=changelog" (link=1, attributes="","member") [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=groups,cn=accounts,dc=example,dc=com" for "(member=changenumber=11118,cn=changelog)" with scope 1 [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=users,cn=accounts,dc=example,dc=com" for "(member=changenumber=11118,cn=changelog)" with scope 1 [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - no more references to chase (link=1, attributes="","member") [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=ng" made in ("changenumber=11118,cn=changelog") ("" in list "" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=users" made in ("changenumber=11118,cn=changelog") ("" in list "uid,cn,gidNumber,uidNumber,loginShell,homeDirectory" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "ou=sudoers,dc=example,dc=com"/"" made in ("changenumber=11118,cn=changelog") ("" in list "" or list empty) [08/Oct/2014:16:54:39 -0400] roles-plugin - --> roles_post_op [08/Oct/2014:16:54:39 -0400] roles-plugin - --> roles_cache_change_notify [08/Oct/2014:16:54:39 -0400] roles-plugin - <-- roles_cache_change_notify: not a role entry [08/Oct/2014:16:54:39 -0400] roles-plugin - <-- roles_post_op [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - added "ipaTokenUniqueID=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" does not belong in "cn=compat,dc=example,dc=com"/"cn=computers" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" does not belong in "cn=compat,dc=example,dc=com"/"cn=groups" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" does not belong in "cn=compat,dc=example,dc=com"/"cn=ng" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" does not belong in "cn=compat,dc=example,dc=com"/"cn=users" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" does not belong in "ou=sudoers,dc=example,dc=com"/"" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=computers" made in ("ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com") ("" in list "" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=groups" made in ("ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com") ("" in list "cn,gidNumber,member,uid,memberUid" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - updating deref_r[0] references for "ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching for references to "ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com" (link=1, attributes="","member") [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=groups,cn=accounts,dc=example,dc=com" for "(member=ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com)" with scope 1 [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=users,cn=accounts,dc=example,dc=com" for "(member=ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com)" with scope 1 [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - no more references to chase (link=1, attributes="","member") [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=ng" made in ("ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com") ("" in list "" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=users" made in ("ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com") ("" in list "uid,cn,gidNumber,uidNumber,loginShell,homeDirectory" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "ou=sudoers,dc=example,dc=com"/"" made in ("ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com") ("" in list "" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com" for "objectclass=*" with scope 1 (one) [08/Oct/2014:16:54:39 -0400] roles-plugin - --> roles_post_op [08/Oct/2014:16:54:39 -0400] roles-plugin - --> roles_cache_change_notify [08/Oct/2014:16:54:39 -0400] roles-plugin - <-- roles_cache_change_notify: not a role entry [08/Oct/2014:16:54:39 -0400] roles-plugin - <-- roles_post_op [08/Oct/2014:16:54:39 -0400] NSACLPlugin - #### conn=24 op=1 binddn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NS7bitAttr - MODIFY begin [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(objectClass) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "uid=otp,cn=users,cn=accounts,dc=example,dc=com" for "(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base) [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPalgorithm) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] DSRetroclPlugin - write_replog_db: write change record 11119 for dn: "uid=otp,cn=users,cn=accounts,dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] DSRetroclPlugin - write_replog_db: add targetUniqueId: "a93a1d8f-3dc411e4-aaddee17-25642a64" [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPdigits) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NS7bitAttr - ADD begin [08/Oct/2014:16:54:39 -0400] NS7bitAttr - ADD target=changenumber=11119,cn=changelog [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOTPkey) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenHOTPcounter) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - added "changenumber=11119,cn=changelog" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11119,cn=changelog" does not belong in "cn=compat,dc=example,dc=com"/"cn=computers" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11119,cn=changelog" does not belong in "cn=compat,dc=example,dc=com"/"cn=groups" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11119,cn=changelog" does not belong in "cn=compat,dc=example,dc=com"/"cn=ng" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11119,cn=changelog" does not belong in "cn=compat,dc=example,dc=com"/"cn=users" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - entry "changenumber=11119,cn=changelog" does not belong in "ou=sudoers,dc=example,dc=com"/"" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=computers" made in ("changenumber=11119,cn=changelog") ("" in list "" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=groups" made in ("changenumber=11119,cn=changelog") ("" in list "cn,gidNumber,member,uid,memberUid" or list empty) [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - updating deref_r[0] references for "changenumber=11119,cn=changelog" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching for references to "changenumber=11119,cn=changelog" (link=1, attributes="","member") [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=groups,cn=accounts,dc=example,dc=com" for "(member=changenumber=11119,cn=changelog)" with scope 1 [08/Oct/2014:16:54:39 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenOwner) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from "cn=users,cn=accounts,dc=example,dc=com" for "(member=changenumber=11119,cn=changelog)" with scope 1 [08/Oct/2014:16:54:40 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - no more references to chase (link=1, attributes="","member") [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=ng" made in ("changenumber=11119,cn=changelog") ("" in list "" or list empty) [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=users" made in ("changenumber=11119,cn=changelog") ("" in list "uid,cn,gidNumber,uidNumber,loginShell,homeDirectory" or list empty) [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "ou=sudoers,dc=example,dc=com"/"" made in ("changenumber=11119,cn=changelog") ("" in list "" or list empty) [08/Oct/2014:16:54:40 -0400] NSACLPlugin - conn=24 op=1 (main): Deny read on entry(ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com).attr(ipatokenUniqueID) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [08/Oct/2014:16:54:40 -0400] roles-plugin - --> roles_post_op [08/Oct/2014:16:54:40 -0400] roles-plugin - --> roles_cache_change_notify [08/Oct/2014:16:54:40 -0400] roles-plugin - <-- roles_cache_change_notify: not a role entry [08/Oct/2014:16:54:40 -0400] roles-plugin - <-- roles_post_op [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - modified "uid=otp,cn=users,cn=accounts,dc=example,dc=com" [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - "uid=otp,cn=users,cn=accounts,dc=example,dc=com" not in "cn=compat,dc=example,dc=com"/"cn=computers", before or after modify [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - "uid=otp,cn=users,cn=accounts,dc=example,dc=com" not in "cn=compat,dc=example,dc=com"/"cn=groups", before or after modify [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - "uid=otp,cn=users,cn=accounts,dc=example,dc=com" not in "cn=compat,dc=example,dc=com"/"cn=ng", before or after modify [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - no interesting changes for "cn=compat,dc=example,dc=com"/"cn=users" made in ("uid=otp,cn=users,cn=accounts,dc=example,dc=com") (replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn not in uid,cn,gidNumber,uidNumber,loginShell,homeDirectory) [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - "uid=otp,cn=users,cn=accounts,dc=example,dc=com" not in "ou=sudoers,dc=example,dc=com"/"", before or after modify [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=computers" made in ("uid=otp,cn=users,cn=accounts,dc=example,dc=com") ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" in list "" or list empty) [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - no interesting reference-based changes for "cn=compat,dc=example,dc=com"/"cn=groups" made in "uid=otp,cn=users,cn=accounts,dc=example,dc=com" ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" not in "cn,gidNumber,member,uid,memberUid") [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=ng" made in ("uid=otp,cn=users,cn=accounts,dc=example,dc=com") ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" in list "" or list empty) [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - no interesting reference-based changes for "cn=compat,dc=example,dc=com"/"cn=users" made in "uid=otp,cn=users,cn=accounts,dc=example,dc=com" ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" not in "uid,cn,gidNumber,uidNumber,loginShell,homeDirectory") [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "ou=sudoers,dc=example,dc=com"/"" made in ("uid=otp,cn=users,cn=accounts,dc=example,dc=com") ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" in list "" or list empty) [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=computers" made in ("uid=otp,cn=users,cn=accounts,dc=example,dc=com") ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" in list "" or list empty) [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - no interesting reference-based changes for "cn=compat,dc=example,dc=com"/"cn=groups" made in "uid=otp,cn=users,cn=accounts,dc=example,dc=com" ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" not in "cn,gidNumber,member,uid,memberUid") [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "cn=compat,dc=example,dc=com"/"cn=ng" made in ("uid=otp,cn=users,cn=accounts,dc=example,dc=com") ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" in list "" or list empty) [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - no interesting reference-based changes for "cn=compat,dc=example,dc=com"/"cn=users" made in "uid=otp,cn=users,cn=accounts,dc=example,dc=com" ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" not in "uid,cn,gidNumber,uidNumber,loginShell,homeDirectory") [08/Oct/2014:16:54:40 -0400] schema-compat-plugin - reference-based changes for "ou=sudoers,dc=example,dc=com"/"" made in ("uid=otp,cn=users,cn=accounts,dc=example,dc=com") ("replace:krbLastSuccessfulAuth,replace:modifytimestamp,replace:entryusn" in list "" or list empty) [08/Oct/2014:16:54:40 -0400] roles-plugin - --> roles_post_op [08/Oct/2014:16:54:40 -0400] roles-plugin - --> roles_cache_change_notify [08/Oct/2014:16:54:40 -0400] roles-plugin - <-- roles_cache_change_notify: not a role entry [08/Oct/2014:16:54:40 -0400] roles-plugin - <-- roles_post_op [08/Oct/2014:16:54:40 -0400] ipa-lockout-plugin - postop returning 0: success From lkrispen at redhat.com Thu Oct 9 17:40:38 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 09 Oct 2014 19:40:38 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412873614.3262.11.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <5436B9F6.8010607@redhat.com> <1412873614.3262.11.camel@redhat.com> Message-ID: <5436C896.804@redhat.com> On 10/09/2014 06:53 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-09 at 18:38 +0200, Ludwig Krispenz wrote: >> On 10/09/2014 06:32 PM, thierry bordaz wrote: >>> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: >>>> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >>>>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >>>>> >>>>>> The background of this email is this bug: >>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>> >>>>>> Attached are two patches which solve this issue for admin users (not >>>>>> very helpful, I know). They depend on this fix in 389: >>>>>> https://fedorahosted.org/389/ticket/47920 >>>>>> >>>>>> There are two outstanding issues: >>>>>> >>>>>> 1. 389 does not send the post read control for normal users. The >>>>>> operation itself succeeds, but no control is sent. >>>>>> >>>>>> The relevant sections from the log are attached. 389 is denying access >>>>>> to the following attributes (* = valid, ! = invalid): >>>>>> ! objectClass >>>>>> ! ipatokenOTPalgorithm >>>>>> ! ipatokenOTPdigits >>>>>> * ipatokenOTPkey >>>>>> * ipatokenHOTPcounter >>>>>> ! ipatokenOwner >>>>>> ! managedBy >>>>>> ! ipatokenUniqueID >>>>> Hello Nathaniel, >>>>> >>>>> The post read control needs access to the modified entry to >>>>> return it. >>>>> This access is granted at the condition, the binddn can access >>>>> attributes. >>>> Agreed and understood. >>>> >>>>> My understanding is that the target entry is >>>>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com >>>>> and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". >>>> Correct. >>>> >>>>> The only ACI I found that match this target is: >>>>> aci: (targetfilter = "(objectClass=ipaToken)") >>>>> (targetattrs = "objectclass || description || managedBy || >>>>> ipatokenUniqueID || ipatokenDisabled >>>>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor >>>>> || ipatokenModel || ipatokenSerial || ipatokenOwner") >>>>> (version 3.0; acl "Users/managers can read basic token >>>>> info"; allow (read, search, compare) userattr = >>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>> Correct. >>>> >>>>> Do you know if the target entry has 'ipatokenOwner' or >>>>> 'managedBy' with the binddn value ? >>>> Yes, both. So why is access to objectClass (et cetera) being denied? >>> Good question... >> +1 >> could you post the full aci logging not only the summary for the access >> to the attributes ? > Attached. this doesn't look like full acl logging, did you set errorlog-level to include 128 ? From tbordaz at redhat.com Thu Oct 9 20:22:13 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 09 Oct 2014 22:22:13 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412872807.3262.10.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> Message-ID: <5436EE75.5080608@redhat.com> On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: >> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >>>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >>>> >>>>> The background of this email is this bug: >>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>> >>>>> Attached are two patches which solve this issue for admin users (not >>>>> very helpful, I know). They depend on this fix in 389: >>>>> https://fedorahosted.org/389/ticket/47920 >>>>> >>>>> There are two outstanding issues: >>>>> >>>>> 1. 389 does not send the post read control for normal users. The >>>>> operation itself succeeds, but no control is sent. >>>>> >>>>> The relevant sections from the log are attached. 389 is denying access >>>>> to the following attributes (* = valid, ! = invalid): >>>>> ! objectClass >>>>> ! ipatokenOTPalgorithm >>>>> ! ipatokenOTPdigits >>>>> * ipatokenOTPkey >>>>> * ipatokenHOTPcounter >>>>> ! ipatokenOwner >>>>> ! managedBy >>>>> ! ipatokenUniqueID >>>> Hello Nathaniel, >>>> >>>> The post read control needs access to the modified entry to >>>> return it. >>>> This access is granted at the condition, the binddn can access >>>> attributes. >>> Agreed and understood. >>> >>>> My understanding is that the target entry is >>>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". >>> Correct. >>> >>>> The only ACI I found that match this target is: >>>> aci: (targetfilter = "(objectClass=ipaToken)") >>>> (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled >>>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") >>>> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>> Correct. >>> >>>> Do you know if the target entry has 'ipatokenOwner' or >>>> 'managedBy' with the binddn value ? >>> Yes, both. So why is access to objectClass (et cetera) being denied? >> Good question... I will try to reproduce > Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as "cn=active guy,cn=accounts,dc=example,dc=com" and to do a modify on "cn=active otp,cn=otp,dc=example,dc=com". The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = "(objectclass=organizationalPerson)")(target = "ldap:///c n=*,cn=otp,dc=example,dc=com")(targetattr = "objectclass || description || se eAlso")(version 3.0; acl "Active user modify otp entry"; allow (write) userdn = "ldap:///cn=active guy,cn=accounts,dc=example,dc=com";) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) " "Active user modify otp entry"" [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= "Active user modify otp entry", acidn="cn=otp,dc=example,dc=com" The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = "(objectclass=organizationalPerson)") (targetattr = "obje ctclass || description || seeAlso || cn")(version 3.0; acl "Active user can r ead his entries"; allow (read, search, compare) userattr = "seeAlso#USERDN";) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) " "Active user can read his entries"" [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that you are testing, I will try on that branch thanks thierry > >>>>> The ACIs allowing access to most of these attributes are here: >>>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >>>>> >>>>> Note that I am able to query the entry just fine (including all the >>>>> above invalidly restricted attributes). Hence, I know the ACIs are >>>>> working just fine. >>>>> >>>>> Part of the strange thing is that in the post read control request, I >>>>> haven't indicated that I want *any* attributes returned (i.e. I want >>>>> just the DN). So I'm not sure why it is querying all the attributes. I >>>>> would suspect that the proper behavior would be to only check the ACIs >>>>> on attributes that will actually be returned. >>>> It may not querying all attributes, but just search the first >>>> one it can read. >>>> As it finds none of them you get the message for all >>>> attributes. >>> Right, but why iterate through all possible attributes? It should only >>> iterate through the attributes requested. Whether the user can read a >>> non-requested attribute or not is irrelevant because the attribute was >>> not requested. >> I think it is iterating from the attributes in the entry. Searching the >> first one that the authenticated subject is allowed to read. > I agree. The question is: why? > > Nathaniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ctrl.ldif Type: text/x-ldif Size: 6643 bytes Desc: not available URL: From npmccallum at redhat.com Thu Oct 9 20:51:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 09 Oct 2014 16:51:43 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5436EE75.5080608@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> Message-ID: <1412887903.3262.14.camel@redhat.com> On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: > On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: > > > On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: > > > On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: > > > > On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: > > > > > On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: > > > > > > > > > > > The background of this email is this bug: > > > > > > https://fedorahosted.org/freeipa/ticket/4456 > > > > > > > > > > > > Attached are two patches which solve this issue for admin users (not > > > > > > very helpful, I know). They depend on this fix in 389: > > > > > > https://fedorahosted.org/389/ticket/47920 > > > > > > > > > > > > There are two outstanding issues: > > > > > > > > > > > > 1. 389 does not send the post read control for normal users. The > > > > > > operation itself succeeds, but no control is sent. > > > > > > > > > > > > The relevant sections from the log are attached. 389 is denying access > > > > > > to the following attributes (* = valid, ! = invalid): > > > > > > ! objectClass > > > > > > ! ipatokenOTPalgorithm > > > > > > ! ipatokenOTPdigits > > > > > > * ipatokenOTPkey > > > > > > * ipatokenHOTPcounter > > > > > > ! ipatokenOwner > > > > > > ! managedBy > > > > > > ! ipatokenUniqueID > > > > > Hello Nathaniel, > > > > > > > > > > The post read control needs access to the modified entry to > > > > > return it. > > > > > This access is granted at the condition, the binddn can access > > > > > attributes. > > > > Agreed and understood. > > > > > > > > > My understanding is that the target entry is > > > > > ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". > > > > Correct. > > > > > > > > > The only ACI I found that match this target is: > > > > > aci: (targetfilter = "(objectClass=ipaToken)") > > > > > (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled > > > > > || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") > > > > > (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > > > Correct. > > > > > > > > > Do you know if the target entry has 'ipatokenOwner' or > > > > > 'managedBy' with the binddn value ? > > > > Yes, both. So why is access to objectClass (et cetera) being denied? > > > Good question... I will try to reproduce > > Thanks! > > Hello, > > I tried to reproduce and it seems to work on *master*. > I am using the attached ldif file. > The test case is to bind as "cn=active > guy,cn=accounts,dc=example,dc=com" and to do a modify on > "cn=active otp,cn=otp,dc=example,dc=com". > > The modify updates the 'description' attribute and do a > postread (description, cn). > > The write 'description' is allowed by : > dn: cn=otp,dc=example,dc=com > aci: (targetfilter = > "(objectclass=organizationalPerson)")(target = > "ldap:///c > n=*,cn=otp,dc=example,dc=com")(targetattr = > "objectclass || description || se > eAlso")(version 3.0; acl "Active user modify otp > entry"; allow (write) userdn > = "ldap:///cn=active > guy,cn=accounts,dc=example,dc=com";) > > [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. > Evaluating ALLOW aci(19) " "Active user modify otp > entry"" > [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 > op=16 (main): Allow write on entry(cn=active > otp,cn=otp,dc=example,dc=com).attr(description) to > cn=active guy,cn=accounts,dc=example,dc=com: allowed > by aci(19): aciname= "Active user modify otp entry", > acidn="cn=otp,dc=example,dc=com" > > > The postread is allowed by: > dn: cn=otp,dc=example,dc=com > aci: (targetfilter = > "(objectclass=organizationalPerson)") (targetattr = > "obje > ctclass || description || seeAlso || cn")(version > 3.0; acl "Active user can r > ead his entries"; allow (read, search, compare) > userattr = "seeAlso#USERDN";) > > [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. > Evaluating ALLOW aci(21) " "Active user can read his > entries"" > [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ > ALLOW in cache > [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 > op=16 (main): Allow read on entry(cn=active > otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active > guy,cn=accounts,dc=example,dc=com: cached allow by > aci(21) > > The postread works if I use USERDN or SELFDN. > > Please let me know the version of 389-ds that you are testing, > I will try on that branch That is not really the same test at all. 1. Install FreeIPA from F21 @ example.com 2. Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com -W -e postread=* < References: <542E7E48.2020900@redhat.com> Message-ID: <54377745.4000204@redhat.com> On 10/03/2014 12:45 PM, Martin Basti wrote: > Hello! > > Patch 131: > https://fedorahosted.org/freeipa/ticket/3801#comment:31 > > Patch 132: > I modified named.conf in 131, so I change the rest of paths to be > ipaplatform specified. > > Patches attached > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Hi! The upgrade processes looks fine to me. And I didn't find any surprise in the code. So it's A and C/2 from me. For the rest go to Petr^2. -- David Kupka From mkosek at redhat.com Fri Oct 10 06:50:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Oct 2014 08:50:50 +0200 Subject: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code In-Reply-To: <5436940F.6010800@redhat.com> References: <543511A9.5050205@redhat.com> <54351ECD.1040603@redhat.com> <5436940F.6010800@redhat.com> Message-ID: <543781CA.3070509@redhat.com> On 10/09/2014 03:56 PM, David Kupka wrote: > On 10/08/2014 01:23 PM, Jan Cholasta wrote: >> Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a): >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Forgot to delete a line in dogtaginstance.py (thanks to David for >> noticing). Updated patch attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Works for me, ACK. > Thanks, pushed to master. Just to double check - no parts of the fixes should be applied to 4.1 or 4.0 branches, is that correct? Martin From dkupka at redhat.com Fri Oct 10 06:55:27 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 10 Oct 2014 08:55:27 +0200 Subject: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code In-Reply-To: <543781CA.3070509@redhat.com> References: <543511A9.5050205@redhat.com> <54351ECD.1040603@redhat.com> <5436940F.6010800@redhat.com> <543781CA.3070509@redhat.com> Message-ID: <543782DF.7080409@redhat.com> On 10/10/2014 08:50 AM, Martin Kosek wrote: > On 10/09/2014 03:56 PM, David Kupka wrote: >> On 10/08/2014 01:23 PM, Jan Cholasta wrote: >>> Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a): >>>> Hi, >>>> >>>> the attached patch fixes >>>> . >>>> >>>> Honza >>> >>> Forgot to delete a line in dogtaginstance.py (thanks to David for >>> noticing). Updated patch attached. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Works for me, ACK. >> > > Thanks, pushed to master. > > Just to double check - no parts of the fixes should be applied to 4.1 or > 4.0 branches, is that correct? > > Martin I've never seen or been able to reproduce this bug other than on master branch. AFAIK, the issue was caused by KRA patches that are only in master. -- David Kupka From mkosek at redhat.com Fri Oct 10 07:17:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Oct 2014 09:17:34 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <54369446.6000207@redhat.com> References: <54369446.6000207@redhat.com> Message-ID: <5437880E.5010002@redhat.com> On 10/09/2014 03:57 PM, Petr Spacek wrote: > Hello, > > it would be great if people could look at current state of DNSSEC patches for > FreeIPA. > > It consist of several relatively independent parts: > - python-pkcs#11 interface written by Martin Basti: > https://github.com/spacekpe/freeipa-pkcs11 > > - DNSSEC daemons written by me: > https://github.com/spacekpe/ipadnssecd > > - FreeIPA integration written by Martin Basti: > https://github.com/bastiak/freeipa/tree/dnssec > > For now brief visual inspection is good enough :-) > > Current state > ============= > - It works only on single DNSSEC "master" server because we still do not have > the key wrapping machinery. > - The "master" server has to be configured manually using ipa-dnssec-setmaster > utility. > - DNSSEC keys are generated on the fly when DNSSEC is enabled for particular zone. > - Metadata for BIND are generated on the fly. > - BIND automatically signs the zone. > > It depends on latest softhsm, opendnssec and bind-pkcs11-util & bind-pkcs11 > packages which are not in Fedora 21 yet. > > Thank you for your time! > Good! I am glad to see a progress. I am also CCing Simo and Rob to be in the loop. It would be especially useful if you also show Simo your special file permissions (setfacl) and sharing config files between daemons. I rather nervous about this part. To comment on FreeIPA integration - I saw you are adding a new config file: - install/tools/ipa-dnssec-setmaster I wonder how consistent and future proof that is. Setting master is currently being done in "ipa-*replica-manage", check for example "ipa-csreplica-manage". We want to have these operations on a sensible place as we will be refactoring them in 4.2. As for the service installation code itself, I would rather see it in # ipa-dns-install which could have new --dnssec-master and --no-dnssec flag. Martin From mkosek at redhat.com Fri Oct 10 07:23:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Oct 2014 09:23:03 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <5436BC59.2090008@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> <5436BC59.2090008@redhat.com> Message-ID: <54378957.1020201@redhat.com> On 10/09/2014 06:48 PM, thierry bordaz wrote: > On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: >> On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: >>> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: >>> >>>> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: >>>>> On Wed, 08 Oct 2014 15:53:39 -0400 >>>>> Nathaniel McCallum wrote: >>>>> >>>>>> As I understand my code, all servers will have csnD. Some servers will >>>>>> have valueB and others will have valueD, but valueB == valueD. >>>>>> >>>>>> We *never* discard a CSN. We only discard the counter/watermark mods >>>>>> in the replication operation. >>>>> What Thierry is saying is that the individual attributes in the entry >>>>> have associate the last CSN that modified them. Because you remove the >>>>> mods when ValueD == ValueB the counter attribute will not have the >>>>> associated CSN changed. But it doesn't really matter because the plugin >>>>> will always keep things consistent. >>>> Attached is a new version. It removes this optimization. If server X has >>>> valueB/csnB and receives valueD/csnD and valueB == valueD, the >>>> replication will be applied without any modification. However, if valueB >>>>> valueD and csnD > csnB, the counter mods will still be stripped. >>>> It also collapses the error check from betxnpre to bepre now that we >>>> have a fix forhttps://fedorahosted.org/389/ticket/47919 committed. The >>>> betxnpre functions are completely removed. Also, a dependency on 389 >>>> 1.3.3.4 (not yet released) is added. >>>> >>>> Nathaniel >>> Hello Nathaniel, >>> >>> For me the code is fine. Ack. >> New attached patch. >> >>> I have two minor comments: >>> * in preop_mod, when a direct update moves the counter >>> backward you send UNWILLING to perform with a message. >>> The message is allocated with slapi_ch_smprintf, you >>> may free it with slapi_ch_free_string (rather than >>> 'free'). >> Fixed. >> >>> * About this message, for example when you have these >>> MODS (I admit they make no sens): >>> >>> changetype: modify >>> ipatokenHOTPcounter: MOD_DELETE >>> - >>> ipatokenHOTPcounter: MOD_INCREMENT >>> >>> The returned message will be "Will not decrement >>> ipatokenHOTPcounter", because 'simulate' will return >>> 'COUNTER_UNSET+1'. >>> Is it the message you expected ? >> I changed the logic in simulate(). Please review it. >> >> Nathaniel >> > Hello Nathaniel, > > > The patch is ok for me. Ack. > > Thank you > thierry Great! Thanks for tough review. However, we will still need to wait for 389 to release so that we can add the new required DS version at least to FreeIPA Copr. Otherwise all development/CI would break. Martin From mbasti at redhat.com Fri Oct 10 07:53:28 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 10 Oct 2014 09:53:28 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <5437880E.5010002@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> Message-ID: <54379078.4080407@redhat.com> On 10/10/14 09:17, Martin Kosek wrote: > On 10/09/2014 03:57 PM, Petr Spacek wrote: >> Hello, >> >> it would be great if people could look at current state of DNSSEC >> patches for >> FreeIPA. >> >> It consist of several relatively independent parts: >> - python-pkcs#11 interface written by Martin Basti: >> https://github.com/spacekpe/freeipa-pkcs11 >> >> - DNSSEC daemons written by me: >> https://github.com/spacekpe/ipadnssecd >> >> - FreeIPA integration written by Martin Basti: >> https://github.com/bastiak/freeipa/tree/dnssec >> >> For now brief visual inspection is good enough :-) >> >> Current state >> ============= >> - It works only on single DNSSEC "master" server because we still do >> not have >> the key wrapping machinery. >> - The "master" server has to be configured manually using >> ipa-dnssec-setmaster >> utility. >> - DNSSEC keys are generated on the fly when DNSSEC is enabled for >> particular zone. >> - Metadata for BIND are generated on the fly. >> - BIND automatically signs the zone. >> >> It depends on latest softhsm, opendnssec and bind-pkcs11-util & >> bind-pkcs11 >> packages which are not in Fedora 21 yet. >> >> Thank you for your time! >> > > Good! I am glad to see a progress. I am also CCing Simo and Rob to be > in the loop. It would be especially useful if you also show Simo your > special file permissions (setfacl) and sharing config files between > daemons. I rather nervous about this part. We will *not* use setfacl, there were some issues with softhsm, which Petr^2 found yesterday. > > To comment on FreeIPA integration - I saw you are adding a new config > file: > - install/tools/ipa-dnssec-setmaster > > I wonder how consistent and future proof that is. Setting master is > currently being done in "ipa-*replica-manage", check for example > "ipa-csreplica-manage". We want to have these operations on a sensible > place as we will be refactoring them in 4.2. > > As for the service installation code itself, I would rather see it in > > # ipa-dns-install > > which could have new --dnssec-master and --no-dnssec flag. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin Basti From abokovoy at redhat.com Fri Oct 10 08:39:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Oct 2014 11:39:36 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys Message-ID: <20141010083936.GZ2328@redhat.com> Hi! I'm resending patches 0159 and 0160, and adding two more: 0161 -- support user SSH public keys in ID view user overrides 0162 -- support gidNumber in ID view user override SSH public keys to work require support from SSSD and that one is currently missing. At least, one add/remove the keys to/from the override objects. Compat tree does not support exporting SSH keys. When accessing the tree anonymously, the entry will be filtered out by ACIs but for authenticated users we need to explicitly ignore ipaSshPubKey attribute in the override, so I'm resending updated slapi-nis patch that only adds one more attribute to filter out. -- / Alexander Bokovoy -------------- next part -------------- From f28587d5c736600682f4b7dcf3e1158940fd5797 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Sep 2014 14:54:50 +0300 Subject: [PATCH 2/6] Support idviews in compat tree --- ACI.txt | 6 ++++++ install/share/71idviews.ldif | 1 + install/share/schema_compat.uldif | 8 ++++++++ install/updates/10-schema_compat.update | 12 ++++++++++++ ipalib/plugins/group.py | 10 ++++++++++ ipalib/plugins/user.py | 11 +++++++++++ ipaserver/install/plugins/update_managed_permissions.py | 11 +++++++++++ 7 files changed, 59 insertions(+) diff --git a/ACI.txt b/ACI.txt index cebdc2c..87c057e 100644 --- a/ACI.txt +++ b/ACI.txt @@ -54,6 +54,8 @@ dn: dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=groups,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "member || memberhost || memberof || memberuid || memberuser")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Group Membership";allow (compare,read,search) userdn = "ldap:///all";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=groups,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "businesscategory || cn || createtimestamp || description || entryusn || gidnumber || ipaexternalmember || ipantsecurityidentifier || ipauniqueid || mepmanagedby || modifytimestamp || o || objectclass || ou || owner || seealso")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Groups";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example @@ -256,6 +258,8 @@ dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "memberof")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Membership";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || displayname || entryusn || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || modifytimestamp || objectclass || sn || title || uid || uidnumber")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Standard Attributes";allow (compare,read,search) userdn = "ldap:///anyone";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gecos || gidnumber || homedirectory || loginshell || modifytimestamp || objectclass || uid || uidnumber")(target = "ldap:///cn=users,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read User Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Remove Users";allow (delete) groupdn = "ldap:///cn=System: Remove Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example @@ -264,6 +268,8 @@ dn: cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example aci: (target = "ldap:///cn=caSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example")(targetfilter = "(objectclass=pkiuser)")(version 3.0;acl "permission:System: Add CA Certificate For Renewal";allow (add) groupdn = "ldap:///cn=System: Add CA Certificate For Renewal,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetfilter = "(objectclass=ipacertificate)")(version 3.0;acl "permission:System: Add Certificate Store Entry";allow (add) groupdn = "ldap:///cn=System: Add Certificate Store Entry,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: dc=ipa,dc=example +aci: (targetattr = "ipaanchoruuid")(target = "ldap:///cn=*,cn=compat,dc=ipa,dc=example")(targetfilter = "(objectclass=ipaOverrideTarget)")(version 3.0;acl "permission:System: Compat Tree ID View targets";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=CAcert,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetattr = "cacertificate")(targetfilter = "(objectclass=pkica)")(version 3.0;acl "permission:System: Modify CA Certificate";allow (write) groupdn = "ldap:///cn=System: Modify CA Certificate,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example diff --git a/install/share/71idviews.ldif b/install/share/71idviews.ldif index 3f8df2e..caa5cff 100644 --- a/install/share/71idviews.ldif +++ b/install/share/71idviews.ldif @@ -5,3 +5,4 @@ objectClasses: (2.16.840.1.113730.3.8.12.29 NAME 'ipaIDView' SUP nsContainer STR objectClasses: (2.16.840.1.113730.3.8.12.30 NAME 'ipaOverrideAnchor' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) MAY ( description ) X-ORIGIN 'IPA v4' ) objectClasses: (2.16.840.1.113730.3.8.12.31 NAME 'ipaUserOverride' DESC 'Override for User Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( uid $ uidNumber $ gidNumber $ homeDirectory $ loginShell $ gecos $ ipaOriginalUid ) X-ORIGIN 'IPA v4' ) objectClasses: (2.16.840.1.113730.3.8.12.32 NAME 'ipaGroupOverride' DESC 'Override for Group Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( gidNumber $ cn ) X-ORIGIN 'IPA v4' ) +objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) diff --git a/install/share/schema_compat.uldif b/install/share/schema_compat.uldif index 6de812f..6769fd1 100644 --- a/install/share/schema_compat.uldif +++ b/install/share/schema_compat.uldif @@ -38,6 +38,10 @@ default:schema-compat-entry-attribute: uidNumber=%{uidNumber} default:schema-compat-entry-attribute: gidNumber=%{gidNumber} default:schema-compat-entry-attribute: loginShell=%{loginShell} default:schema-compat-entry-attribute: homeDirectory=%{homeDirectory} +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","") +default:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} +default:schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") dn: cn=groups, cn=Schema Compatibility, cn=plugins, cn=config default:objectClass: top @@ -52,6 +56,10 @@ default:schema-compat-entry-attribute: objectclass=posixGroup default:schema-compat-entry-attribute: gidNumber=%{gidNumber} default:schema-compat-entry-attribute: memberUid=%{memberUid} default:schema-compat-entry-attribute: memberUid=%deref_r("member","uid") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","") +default:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} +default:schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config add:objectClass: top diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update index aeddadb..e88b492 100644 --- a/install/updates/10-schema_compat.update +++ b/install/updates/10-schema_compat.update @@ -47,3 +47,15 @@ dn: cn=Schema Compatibility,cn=plugins,cn=config # rewritten to the original entry if needed add:nsslapd-pluginprecedence: 49 +dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","")' +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","")' +add:schema-compat-entry-attribute: 'ipaanchoruuid=%{ipaanchoruuid}' +add:schema-compat-entry-attribute: '%ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","")' + +dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","")' +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","")' +add:schema-compat-entry-attribute: 'ipaanchoruuid=%{ipaanchoruuid}' +add:schema-compat-entry-attribute: '%ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","")' + diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index 9c2e308..03e6893 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -212,6 +212,16 @@ class group(LDAPObject): 'objectclass', 'cn', 'memberuid', 'gidnumber', }, }, + 'System: Read Group Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=groups', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'cn', 'memberuid', 'gidnumber', + }, + }, } label = _('User Groups') diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index f95b4fd..e206289 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -435,6 +435,17 @@ class user(LDAPObject): 'homedirectory', 'loginshell', }, }, + 'System: Read User Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=users', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'uid', 'cn', 'gecos', 'gidnumber', 'uidnumber', + 'homedirectory', 'loginshell', + }, + }, } label = _('Users') diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py index df49d5d..032485a 100644 --- a/ipaserver/install/plugins/update_managed_permissions.py +++ b/ipaserver/install/plugins/update_managed_permissions.py @@ -117,6 +117,17 @@ NONOBJECT_PERMISSIONS = { }, 'default_privileges': {'IPA Masters Readers'}, }, + 'System: Compat Tree ID View targets': { + 'replaces_global_anonymous_aci': True, + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=*,cn=compat', api.env.basedn), + 'ipapermtargetfilter': {'(objectclass=ipaOverrideTarget)'}, + 'ipapermbindruletype': 'anonymous', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'ipaAnchorUUID', + }, + }, 'System: Read DNA Configuration': { 'replaces_global_anonymous_aci': True, 'ipapermlocation': DN('cn=dna,cn=ipa,cn=etc', api.env.basedn), -- 2.1.0 -------------- next part -------------- From 6855012f03490188a3d4d188f028b1e54fc37858 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Sep 2014 15:44:31 +0300 Subject: [PATCH 3/6] Support overridding user shell in ID views --- ACI.txt | 2 +- API.txt | 9 ++++++--- ipalib/plugins/idviews.py | 8 ++++++-- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/ACI.txt b/ACI.txt index 87c057e..b2192ce 100644 --- a/ACI.txt +++ b/ACI.txt @@ -123,7 +123,7 @@ aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:S dn: cn=views,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || entryusn || gidnumber || ipaanchoruuid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System: Read Group ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "createtimestamp || description || entryusn || homedirectory || ipaanchoruuid || ipaoriginaluid || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "createtimestamp || description || entryusn || homedirectory || ipaanchoruuid || ipaoriginaluid || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ranges,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipabaseid || ipabaserid || ipaidrangesize || ipanttrusteddomainsid || iparangetype || ipasecondarybaserid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaidrange)")(version 3.0;acl "permission:System: Read ID Ranges";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index c5e76c7..41b852b 100644 --- a/API.txt +++ b/API.txt @@ -2104,7 +2104,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,10,3 +args: 2,11,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2112,6 +2112,7 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') option: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', required=False) @@ -2130,7 +2131,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: idoverrideuser_find -args: 2,12,4 +args: 2,13,4 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -2138,6 +2139,7 @@ option: Str('description', attribute=True, autofill=False, cli_name='desc', mult option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, query=True, required=False) option: Str('ipaanchoruuid', attribute=True, autofill=False, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, query=True, required=False) +option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Int('sizelimit?', autofill=False, minvalue=0) @@ -2150,7 +2152,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,13,3 +args: 2,14,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2159,6 +2161,7 @@ option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) option: Flag('rights', autofill=True, default=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index 3b0df02..afaa6f9 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -650,14 +650,14 @@ class idoverrideuser(baseidoverride): 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { 'objectClass', 'ipaAnchorUUID', 'uidNumber', 'description', - 'homeDirectory', 'uid', 'ipaOriginalUid', + 'homeDirectory', 'uid', 'ipaOriginalUid', 'loginShell', }, }, } object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ - 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', + 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', ] takes_params = baseidoverride.takes_params + ( @@ -679,6 +679,10 @@ class idoverrideuser(baseidoverride): cli_name='homedir', label=_('Home directory'), ), + Str('loginshell?', + cli_name='shell', + label=_('Login shell'), + ), Str('ipaoriginaluid?', flags=['no_option', 'no_output'] ), -- 2.1.0 -------------- next part -------------- From 231459b7dba299dc19d2c7afaab0228bbe738f49 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 10 Oct 2014 09:26:13 +0300 Subject: [PATCH 4/6] Allow user overrides to specify SSH public keys Overrides for users can have SSH public keys. This, however, will not enable SSH public keys from overrides to be actually used until SSSD gets fixed to pull them in. SSSD ticket for SSH public keys in overrides: https://fedorahosted.org/sssd/ticket/2454 Resolves https://fedorahosted.org/freeipa/ticket/4509 --- API.txt | 6 ++++-- ipalib/plugins/idviews.py | 25 +++++++++++++++++++++++++ 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/API.txt b/API.txt index 41b852b..5316ac2 100644 --- a/API.txt +++ b/API.txt @@ -2104,7 +2104,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,11,3 +args: 2,12,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2112,6 +2112,7 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('ipasshpubkey', attribute=True, cli_name='sshpubkey', csv=True, multivalue=True, required=False) option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') @@ -2152,7 +2153,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,14,3 +args: 2,15,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2161,6 +2162,7 @@ option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('ipasshpubkey', attribute=True, autofill=False, cli_name='sshpubkey', csv=True, multivalue=True, required=False) option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index afaa6f9..fb71c93 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -25,6 +25,8 @@ from ipalib.plugins.hostgroup import get_complete_hostgroup_member_list from ipalib import api, Str, Int, Flag, _, ngettext, errors, output from ipalib.constants import IPA_ANCHOR_PREFIX, SID_ANCHOR_PREFIX from ipalib.plugable import Registry +from ipalib.util import (normalize_sshpubkey, validate_sshpubkey, + convert_sshpubkey_post) from ipapython.dn import DN @@ -658,6 +660,7 @@ class idoverrideuser(baseidoverride): object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', + 'ipaSshPubkey', ] takes_params = baseidoverride.takes_params + ( @@ -686,6 +689,13 @@ class idoverrideuser(baseidoverride): Str('ipaoriginaluid?', flags=['no_option', 'no_output'] ), + Str('ipasshpubkey*', validate_sshpubkey, + cli_name='sshpubkey', + label=_('SSH public key'), + normalizer=normalize_sshpubkey, + csv=True, + flags=['no_search'], + ), ) override_object = 'user' @@ -757,6 +767,10 @@ class idoverrideuser_add(baseidoverride_add): # Update the ipaOriginalUid self.obj.update_original_uid_reference(entry_attrs) return dn + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + convert_sshpubkey_post(ldap, dn, entry_attrs) + return dn + @register() @@ -777,6 +791,17 @@ class idoverrideuser_mod(baseidoverride_mod): # Update the ipaOriginalUid self.obj.set_anchoruuid_from_dn(dn, entry_attrs) self.obj.update_original_uid_reference(entry_attrs) + if 'objectclass' in entry_attrs: + obj_classes = entry_attrs['objectclass'] + else: + _entry_attrs = ldap.get_entry(dn, ['objectclass']) + obj_classes = entry_attrs['objectclass'] = _entry_attrs['objectclass'] + + if 'ipasshpubkey' in entry_attrs and 'ipasshuser' not in obj_classes: + obj_classes.append('ipasshuser') + return dn + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + convert_sshpubkey_post(ldap, dn, entry_attrs) return dn -- 2.1.0 -------------- next part -------------- From 99ee88c7a84fd5a689a44eb7d666585063e5798a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 10 Oct 2014 09:30:51 +0300 Subject: [PATCH 5/6] Allow user overrides to specify GID of the user Resolves https://fedorahosted.org/freeipa/ticket/4617 --- API.txt | 9 ++++++--- ipalib/plugins/idviews.py | 8 +++++++- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index 5316ac2..19f1a56 100644 --- a/API.txt +++ b/API.txt @@ -2104,12 +2104,13 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,12,3 +args: 2,13,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Int('gidnumber', attribute=True, cli_name='gid', minvalue=1, multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) option: Str('ipasshpubkey', attribute=True, cli_name='sshpubkey', csv=True, multivalue=True, required=False) @@ -2132,11 +2133,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: idoverrideuser_find -args: 2,13,4 +args: 2,14,4 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Int('gidnumber', attribute=True, autofill=False, cli_name='gid', minvalue=1, multivalue=False, query=True, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, query=True, required=False) option: Str('ipaanchoruuid', attribute=True, autofill=False, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, query=True, required=False) @@ -2153,13 +2155,14 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,15,3 +args: 2,16,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Int('gidnumber', attribute=True, autofill=False, cli_name='gid', minvalue=1, multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) option: Str('ipasshpubkey', attribute=True, autofill=False, cli_name='sshpubkey', csv=True, multivalue=True, required=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index fb71c93..c78abf2 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -660,7 +660,7 @@ class idoverrideuser(baseidoverride): object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', - 'ipaSshPubkey', + 'ipaSshPubkey', 'gidNumber', ] takes_params = baseidoverride.takes_params + ( @@ -678,6 +678,12 @@ class idoverrideuser(baseidoverride): doc=_('User ID Number'), minvalue=1, ), + Int('gidnumber?', + cli_name='gid', + label=_('GID'), + doc=_('Group ID Number'), + minvalue=1, + ), Str('homedirectory?', cli_name='homedir', label=_('Home directory'), -- 2.1.0 -------------- next part -------------- From ba752818b04070396d068ba004505fce696149d5 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 29 Jul 2014 12:04:34 +0300 Subject: [PATCH 1/2] Add support for FreeIPA ID views FreeIPA ID views allow to override POSIX attributes for certain users and groups. A support is added to allow using specific ID view when serving compatibility tree. Each user or group entry which has an override in the view is amended with the overridden values from the view before served out to the LDAP client. A view to use is specified as a part of base DN: cn=,cn=views,cn=compat,$SUFFIX where cn=compat,$SUFFIX is the original compatibility tree base DN. Each entry, when served through the view, gets new DN rewritten to specify the view. Additionally, if override in the view changes uid (for users) or cn (for groups) attribute, the entry's RDN is changed accordingly. For groups memberUid attribute is modified as well in case there is an override in the view that changes uid value of that member. FreeIPA ID views support overrides for users of trusted Active Directory domains. In case of a trusted AD domain's user or group is returned via compatibility tree, view overrides are applied in two stages: 1. SSSD applies default view for AD users 2. slapi-nis applies explicitly specified (host-specific) view on top of the entry returned by SSSD Thus, slapi-nis does not need to apply default view for AD users and if there are no host-specific views in use, there is no need to specify a view in the base DN, making overhead of a default view for AD users lower. --- configure.ac | 14 ++ doc/ipa/sch-ipa.txt | 93 ++++++++++++ src/Makefile.am | 4 + src/back-sch-idview.c | 392 ++++++++++++++++++++++++++++++++++++++++++++++++++ src/back-sch-nss.c | 111 +++++++++++--- src/back-sch.c | 71 +++++++-- src/back-sch.h | 38 +++++ 7 files changed, 692 insertions(+), 31 deletions(-) create mode 100644 src/back-sch-idview.c diff --git a/configure.ac b/configure.ac index 84b84d1..71dbdc7 100644 --- a/configure.ac +++ b/configure.ac @@ -383,6 +383,20 @@ if test "x$use_nsswitch" != xno ; then AC_DEFINE(USE_NSSWITCH,1,[Use nsswitch API to lookup users and groups not found in the LDAP tree]) fi +use_idviews=true +AC_ARG_WITH(idviews, + AS_HELP_STRING([--with-idviews], [Use FreeIPA ID views to override POSIX IDs of users and groups]), + use_idviews=$withval,use_idviews=yes) +if test "x$use_idviews" = xyes ; then + AC_MSG_RESULT([FreeIPA ID views support is enabled]) + AC_DEFINE(USE_IPA_IDVIEWS,1,[Use FreeIPA ID views to override POSIX attributes of users and groups per view.]) + AC_DEFINE(IPA_IDVIEWS_ATTR_ANCHORUUID, ["ipaAnchorUUID"],[FreeIPA attr unique pointer for id overrides]) + AC_DEFINE(IPA_IDVIEWS_ATTR_ORIGINALUID, ["ipaOriginalUid"],[FreeIPA attr original uid value for user id overrides]) +else + AC_MSG_RESULT([FreeIPA ID views support is disabled]) +fi +AM_CONDITIONAL([USE_IPA_IDVIEWS], [test "x$use_idviews" != xno]) + mylibdir=`eval echo "$libdir" | sed "s,NONE,${ac_default_prefix},g"` mylibdir=`eval echo "$mylibdir" | sed "s,NONE,${ac_prefix},g"` case "$server" in diff --git a/doc/ipa/sch-ipa.txt b/doc/ipa/sch-ipa.txt index b5a585b..f560580 100644 --- a/doc/ipa/sch-ipa.txt +++ b/doc/ipa/sch-ipa.txt @@ -87,3 +87,96 @@ on IPA masters. As 'system-auth' PAM service is not used directly by any other application, it is safe to use it for trusted domain users via compatibility path. + +== Support for ID views == + +When FreeIPA 4.1 is in use, Schema compatibility plugin can be configured to +override POSIX attributes according to an identity view (ID View) which +contains overrides for users and groups. + +The overrides are managed by FreeIPA separately for users and groups: + +* management of ID views: + ipa idview-add 'my view' + +* management of an override for a user: + ipa idoverrideuser-add 'my view' auser --login=foo --shell=/bin/ksh \ + --homedir=/home/foo --uid=12345 + +* management of an override for a group: + ipa idoverridegroup-add 'my view' agroup --group-name=bgroup --gid=54321 + +FreeIPA transparently supports overrides for users and groups from trusted AD +domains. This means that for trusted domains, IPA doesn't require to place +POSIX attributes in Active Directory. Instead, a global ID view named 'Default +Trust View' is used to contain POSIX attributes for existing AD users. +Additionally, specialized ID views can be added on top of the 'Default Trust +View' and then assigned to specific hosts. + +Schema compatibility plugin does support ID overrides from a single view. The +feature is designed to allow host-specific ID view, where the view is specified +through the search base. + +For native IPA users default POSIX attributes are stored natively, thus only a +host-specific ID view is applied, if any. For trusted AD users 'Default Trust +View' ID view is applied automatically by SSSD running on the IPA master, thus +Schema compatibility plugin only applies a host-specific ID view, if specified. + +In FreeIPA Schema compatibility is configured to serve entries through the +host-specific ID view with base DN of cn=,cn=views,cn=compat,$SUFFIX. + +=== ID views implementation === +Detailed design of ID views in FreeIPA can be seen here: +http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust + +In Schema compatibility plugin support for ID views is done on top of existing +map cache. It is expected that there are less overrides than non-overridden +entries for IPA users and groups. For trusted AD users POSIX attributes from +'Default Trust View' are applied by SSSD on IPA master. Thus, if there are no +host-specific overrides, trusted AD users treated by Schema compatibility +plugin as before -- as entries which content comes from nssswitch API. + +This approach allows to only keep original entry in the memory and apply +host-specific override only at the time when entry with explicitly requested ID +view is returned as part of a search result. + +In order to map original entry to an override, FreeIPA configuration for Schema +compatibility plugin adds ipaAnchorUUID attribute and ipaOverrideTarget object +class to every generated entry. ipaAnchorUUID is based on ipaUniqueID for IPA +objects and on SID for trusted AD objects: + +* ipaAnchorUUID=:IPA:: for IPA object (user, group)_ + +* ipaAnchorUUID=:SID: for trusted AD user or group + +For ID overrides FreeIPA maintains ipaAnchorUUID with the same value so that an +override can be found by simple matching of the ipaAnchorUUID attribute's +value. FreeIPA also stores original uid value for user objects in ID override +as ipaOriginalUid attribute, to allow mapping back memberUid values for groups. + +When a query request comes, the view in the base DN is detected and remembered. +Base DN is rewritten to exclude the cn=,cn=views so that a normal +search can be performed against cached entries. Additionally, search filter is +analyzed to replace references to rewritten uid (for user) and cn (for group) +attributes by references to the original objects. The references come from the +ID view overrides, if they exist. + +Once search results are gathered for the map, they are processed in order to +apply an override. For users entry attributes overridden with the values from +an override. For groups additional processing is performed on values of +memberUid attribute. + +As opposed to member attribute, memberUid attribute contains only values of uid +attribute of the original member entry. Given that an ID override may redefine +uid value, corresponding memberUid value of a group needs to be rewritten to +include redefined uid value. In order to do that, original memberUid value is +compared with ipaOriginalUid attribute's value to find an override +corresponding to the original user object. If such override is detected, memberUid +value is replaced by the uid value of the override. + +When attributes of the entry are processed and optionally amended with overridden +values, DN of the entry is rewritten as well, to reflect the fact that entry is +served through the view. + +For all returned entries ipaAnchorUUID attribute and ipaOverrideTarget objectclass +are removed. Resulting entry is sent to the client. diff --git a/src/Makefile.am b/src/Makefile.am index e4fe1a9..6f4926e 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -78,6 +78,10 @@ schemacompat_plugin_la_SOURCES += back-sch-pam.c schemacompat_plugin_la_LIBADD += $(PAM_LIBS) endif +if USE_IPA_IDVIEWS +schemacompat_plugin_la_SOURCES += back-sch-idview.c +endif + noinst_LTLIBRARIES = dummy-nis-plugin.la dummy_nis_plugin_la_SOURCES = \ disp-nis.c \ diff --git a/src/back-sch-idview.c b/src/back-sch-idview.c new file mode 100644 index 0000000..5a2b450 --- /dev/null +++ b/src/back-sch-idview.c @@ -0,0 +1,392 @@ +/* + * Copyright 2014 Red Hat, Inc. + * + * 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; version 2 of the License. + * + * 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 PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this Program; if not, write to the + * + * Free Software Foundation, Inc. + * 59 Temple Place, Suite 330 + * Boston, MA 02111-1307 USA + * + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include +#include + +#ifdef HAVE_DIRSRV_SLAPI_PLUGIN_H +#include +#include +#include +#else +#include +#endif + +#include +#include "../yp/yp.h" + +#ifdef HAVE_TCPD_H +#include +#endif + +#include "backend.h" +#include "back-shr.h" +#include "format.h" +#include "plugin.h" +#include "map.h" +#include "back-sch.h" + +void +idview_get_overrides(struct backend_search_cbdata *cbdata) +{ + char *dn = NULL; + int ret = 0, result = 0; + const Slapi_DN *suffix = NULL; + Slapi_PBlock *pb; + + if (cbdata->idview == NULL) + return; + + pb = wrap_pblock_new(cbdata->pb); + if (pb == NULL) + return; + + wrap_inc_call_level(); + + suffix = slapi_get_suffix_by_dn(cbdata->target_dn); + dn = slapi_ch_smprintf("cn=%s,cn=views,cn=accounts,%s", cbdata->idview, slapi_sdn_get_dn(suffix)); + /* Fetch all attributes; there is a bug in 389-ds: it gives out all attributes for the entry anyway + * when search returns Slapi_Entry* objects. Instead, we'll do removal later */ + slapi_search_internal_set_pb(pb, dn, LDAP_SCOPE_SUBTREE, + "(objectclass=ipaOverrideAnchor)", NULL, 0, + NULL, NULL, cbdata->state->plugin_identity, 0); + ret = slapi_search_internal_pb(pb); + slapi_ch_free_string(&dn); + slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_RESULT, &result); + + if (result == 0) { + /* Steal search result entries to avoid re-allocating them */ + slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, &(cbdata->overrides)); + slapi_pblock_set(pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, NULL); + } + + wrap_dec_call_level(); + slapi_pblock_destroy(pb); +} + +void +idview_free_overrides(struct backend_search_cbdata *cbdata) +{ + int i = 0; + if (cbdata->overrides != NULL) { + for(i=0; cbdata->overrides[i] != NULL; i++) { + slapi_entry_free(cbdata->overrides[i]); + } + slapi_ch_free((void**)&(cbdata->overrides)); + } +} + +void +idview_process_overrides(struct backend_search_cbdata *cbdata, + const char *key, const char *map, const char *domain, + Slapi_Entry *entry) +{ +#define VIEW_TEMPLATE_KEY_MAP_DOMAIN 0 +#define VIEW_TEMPLATE_KEY_MAP_DOMAIN_NEWKEY 3 +#define VIEW_TEMPLATE_MAP_DOMAIN 1 +#define VIEW_TEMPLATE_DOMAIN 2 + /* After view was applied, entry's DN needs to reflect the view */ + const char *dn_template[] = {"%s,%s,cn=%s,cn=views,%s", /* an entry for user or group */ + "%s,cn=%s,cn=views,%s", /* an entry for a map (container for users or groups) */ + "cn=%s,cn=views,%s", /* an entry is a base of the compat tree */ + "%s=%s,%s,cn=%s,cn=views,%s", /* an entry for user or group which RDN was overridden with new value */ + }; + const char *filterout_attrs[] = {"objectclass", "creatorsname", "modifiersname", + "createtimestamp", "modifytimestamp", "parentid", + "entryusn", "entryid", "entrydn", "ipaoriginaluid", + "ipaanchoruuid", "nsuniqueid", "ipasshpubkey", NULL }; + char *new_dn = NULL, *new_key = NULL, *sep = NULL, *new_val = NULL; + char *override_type = NULL; + Slapi_Entry *override_entry = NULL; + Slapi_Attr *anchor = NULL, *id_attr = NULL; + Slapi_Value *anchor_value = NULL, *id_value = NULL; + int i, result, dn_template_id; + + if (cbdata->overrides == NULL) { + /* Only retrieve overrides for the view first time when neccessary */ + idview_get_overrides(cbdata); + if (cbdata->overrides == NULL) + return; + } + + /* 1. See if the entry has ipaAnchorUUID and selected idview has an override for it */ + /* The code below intentionally uses Slapi_Value instead of comparing string values to + * avoid allocating additional memory */ + result = slapi_entry_attr_find(entry, IPA_IDVIEWS_ATTR_ANCHORUUID, &anchor); + if ((result == 0) && (anchor != NULL) && (cbdata->overrides != NULL)) { + result = slapi_attr_first_value(anchor, &anchor_value); + for(i = 0; cbdata->overrides[i] != NULL; i++) { + result = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ANCHORUUID, &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + result = slapi_value_compare(id_attr, anchor_value, id_value); + if (result == 0) { + override_entry = cbdata->overrides[i]; + break; + } + } + } + } + + /* 2. If there is indeed an override, replace attribute values except for the ones that should be ignored */ + if (override_entry != NULL) { + Slapi_Attr *override_attr = NULL; + + result = slapi_entry_first_attr(override_entry, &override_attr); + while (result == 0) { + Slapi_ValueSet *override_valueset = NULL; + + /* Filter out override attributes that we don't care about */ + result = slapi_attr_get_type(override_attr, &override_type); + for (i = 0; filterout_attrs[i] != NULL; i++) { + if (strcasecmp(override_type, filterout_attrs[i]) == 0) { + break; + } + } + + if (filterout_attrs[i] == NULL) { + /* Replace the attribute's value with the override or + * add an override value if the attribute didn't exist */ + result = slapi_entry_attr_exists(entry, override_type); + if (result == 1) { + result = slapi_entry_attr_delete(entry, override_type); + } + result = slapi_attr_get_valueset(override_attr, &override_valueset); + result = slapi_entry_add_valueset(entry, override_type, override_valueset); + } + result = slapi_entry_next_attr(override_entry, override_attr, &override_attr); + } + } + + /* 3. If entry has memberUid, we need to replace memberUid values too, if they were overridden */ + override_type = "memberUid"; + result = slapi_entry_attr_find(entry, override_type, &anchor); + if ((result == 0) && (anchor != NULL) && (cbdata->overrides != NULL)) { + int value_idx = 0; + Slapi_ValueSet *new_valueset = slapi_valueset_new(); + + if (new_valueset != NULL) { + /* For each memberUid value, find an override with ipaOriginalUid attribute of the same value */ + value_idx = slapi_attr_first_value(anchor, &anchor_value); + while (value_idx != -1) { + bool_t value_found = FALSE; + for(i = 0; cbdata->overrides[i] != NULL; i++) { + result = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ORIGINALUID, &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + result = slapi_value_compare(id_attr, anchor_value, id_value); + if (result == 0) { + /* If there is an override with ipaOriginalUid: , use its 'uid' value to override */ + result = slapi_entry_attr_find(cbdata->overrides[i], "uid", &id_attr); + if ((result == 0) && (id_attr != NULL)) { + result = slapi_attr_first_value(id_attr, &id_value); + if (result == 0) { + /* finally: we have an override with ipaOriginalUid: _and_ + * this override is changing the 'uid' attribute so we have something to replace */ + slapi_valueset_add_value(new_valueset, id_value); + value_found = TRUE; + break; + } + } + } + } + } + + if (value_found == FALSE) { + slapi_valueset_add_value(new_valueset, anchor_value); + } + value_idx = slapi_attr_next_value(anchor, value_idx, &anchor_value); + } + + result = slapi_entry_attr_delete(entry, override_type); + result = slapi_entry_add_valueset(entry, override_type, new_valueset); + slapi_valueset_free(new_valueset); + } + } + + /* 4. Even if there were no overrides, since we are serving throught the view, replace DN value */ + dn_template_id = (key == NULL ? 1 : 0) + (map == NULL ? 1 : 0); + switch (dn_template_id) { + case VIEW_TEMPLATE_KEY_MAP_DOMAIN: + /* update RDN with proper value from the entry after overrides were applied */ + sep = strchr(key, '='); + if (sep != NULL) { + sep[0] = '\0'; + new_val = slapi_entry_attr_get_charptr(entry, key); + new_dn = slapi_ch_smprintf(dn_template[VIEW_TEMPLATE_KEY_MAP_DOMAIN_NEWKEY], key, new_val, map, cbdata->idview, domain); + slapi_ch_free_string(&new_val); + sep[0] = '='; + } else { + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], key, map, cbdata->idview, domain); + } + break; + case VIEW_TEMPLATE_MAP_DOMAIN: + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], map, cbdata->idview, domain); + break; + case VIEW_TEMPLATE_DOMAIN: + new_dn = slapi_ch_smprintf(dn_template[dn_template_id], cbdata->idview, domain); + break; + }; + slapi_entry_set_dn(entry, new_dn); +} + +void +idview_replace_target_dn(char **target, char **idview) +{ + char *idview_p = NULL; + char *cnviews = NULL; + char *new_target = NULL; + + cnviews = strstr(*target, ",cn=views,"); + if (cnviews != NULL && cnviews != *target) { + cnviews[0] = '\0'; + idview_p = strrchr(*target, ','); + if (idview_p == NULL) { + idview_p = *target; + } else { + idview_p++; + } + if (strstr(idview_p, "cn=") != idview_p) { + cnviews[0] = ','; + return; + } + *idview = slapi_ch_strdup(&idview_p[3]); + if (idview_p != *target) { + idview_p[0] = '\0'; + new_target = slapi_ch_smprintf("%s%s", *target, cnviews+10); + idview_p--; + idview_p[0] = ','; + } else { + new_target = slapi_ch_smprintf("%s", cnviews+10); + } + cnviews[0] = ','; + *target = new_target; + } +} + +static int +idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct berval *bval, struct backend_search_filter_config *config) +{ + int res, i; + Slapi_Value *filter_val, *value, *anchor_val; + Slapi_Attr *anchor, *attr = NULL; + struct backend_search_cbdata *cbdata = (struct backend_search_cbdata *) config->callback_data; + + if (cbdata == NULL || cbdata->idview == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + if (filter_type == NULL || config->name == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + if (cbdata->overrides == NULL) { + /* Only retrieve overrides for the view first time when neccessary */ + idview_get_overrides(cbdata); + } + + if (cbdata->overrides == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + filter_val = slapi_value_new_berval(bval); + + /* If filter contains an attribute name which is overridden in the view and filter value + * corresponds to the override, replace the filter by (ipaAnchorUUID=...) from the override + * to point to the original because otherwise an entry will not be found in the slapi-nis map */ + for(i=0; cbdata->overrides[i] != NULL; i++) { + res = slapi_entry_attr_find(cbdata->overrides[i], filter_type, &attr); + if ((res == 0) && (attr != NULL)) { + res = slapi_attr_first_value(attr, &value); + res = slapi_value_compare(attr, value, filter_val); + if (res == 0) { + /* For uid overrides we should have ipaOriginalUID in the override */ + if (strcasecmp(filter_type, "uid") == 0) { + res = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ORIGINALUID, &anchor); + if (res == 0) { + res = slapi_attr_first_value(anchor, &anchor_val); + slapi_ber_bvdone(bval); + slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); + config->override_found = TRUE; + break; + } + } + + /* otherwise, use ipaAnchorUUID value */ + res = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ANCHORUUID, &anchor); + if (res == 0) { + res = slapi_attr_first_value(anchor, &anchor_val); + slapi_filter_changetype(filter, IPA_IDVIEWS_ATTR_ANCHORUUID); + slapi_ber_bvdone(bval); + slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); + config->override_found = TRUE; + break; + } + + } + } + } + + slapi_value_free(&filter_val); + + return SLAPI_FILTER_SCAN_CONTINUE; + +} + +/* Traverse through the filter and replace overridden attribute/value pairs with references to the original + * entries. This allows to properly handle overrides of uid and cn attributes where searches look like + * (&(objectclass=posixAccount)(uid=foobar)) -- if uid=foobar is part of an override for uid=admin, we need + * to point back to uid=admin to be able to find original entry in the slapi-nis cache. + * + * Note that in reality we don't use original value of the uid/cn attribue. Instead, we use ipaAnchorUUID + * to refer to the original entry. */ +extern char * +slapi_filter_to_string( const struct slapi_filter *f, char *buf, size_t bufsize ); +void +idview_replace_filter(struct backend_search_cbdata *cbdata) +{ + struct backend_search_filter_config config = + {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL, NULL, NULL}; + int res = 0; + + if (cbdata->idview == NULL) { + return; + } + + config.callback = idview_process_filter_cb; + config.callback_data = cbdata; + + /* Ignore the return code as it will always be SLAPI_FILTER_SCAN_NO_MORE */ + res = backend_analyze_search_filter(cbdata->filter, &config); + + if (config.name != NULL) { + slapi_ch_free_string(&config.name); + } + +} diff --git a/src/back-sch-nss.c b/src/back-sch-nss.c index f192bb9..26d4b8c 100644 --- a/src/back-sch-nss.c +++ b/src/back-sch-nss.c @@ -52,16 +52,20 @@ #include "back-sch.h" #include "format.h" -struct backend_search_filter_config { - bool_t search_user; - bool_t search_group; - bool_t search_uid; - bool_t search_gid; - bool_t search_members; - bool_t name_set; - bool_t wrong_search; - char *name; -}; +static int +bvstrprefix(const struct berval *bval, const char *s) +{ + size_t len; + int c; + + len = strlen(s); + if (len < bval->bv_len) { + return strncasecmp(bval->bv_val, s, len) != 0; + } + + return 1; + +} static int bvstrcasecmp(const struct berval *bval, const char *s) @@ -115,6 +119,14 @@ backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) } else if ((0 == strcasecmp(filter_type, "objectClass")) && (0 == bvstrcasecmp(bval, "shadowAccount"))) { config->wrong_search = TRUE; +#ifdef HAVE_SSS_NSS_IDMAP +#ifdef USE_IPA_IDVIEWS + } else if ((0 == strcasecmp(filter_type, "ipaAnchorUUID")) && + (0 == bvstrprefix(bval, ":SID:S-"))) { + config->search_sid = TRUE; + config->name_set = TRUE; +#endif +#endif } if ((NULL == config->name) && config->name_set) { @@ -127,10 +139,15 @@ backend_search_filter_has_cn_uid(Slapi_Filter *filter, void *arg) } } + if (config->callback != NULL) { + return config->callback(filter, filter_type, bval, config); + } + if ((config->search_uid || config->search_gid || config->search_user || - config->search_group) && (config->name != NULL)) { + config->search_group || + config->search_sid) && (config->name != NULL)) { return SLAPI_FILTER_SCAN_STOP; } return SLAPI_FILTER_SCAN_CONTINUE; @@ -211,21 +228,21 @@ backend_make_user_entry_from_nsswitch_passwd(struct passwd *pwd, slapi_entry_add_string(entry, "objectClass", "posixAccount"); slapi_entry_add_string(entry, - "objectClass", "extensibleObject"); - slapi_entry_add_string(entry, "uid", pwd->pw_name); slapi_entry_attr_set_uint(entry, "uidNumber", pwd->pw_uid); slapi_entry_attr_set_uint(entry, "gidNumber", pwd->pw_gid); - slapi_entry_add_string(entry, - "gecos", pwd->pw_gecos); if (strlen(pwd->pw_gecos) > 0) { slapi_entry_add_string(entry, "cn", pwd->pw_gecos); + slapi_entry_add_string(entry, + "gecos", pwd->pw_gecos); } else { slapi_entry_add_string(entry, "cn", pwd->pw_name); + slapi_entry_add_string(entry, + "gecos", pwd->pw_name); } slapi_entry_add_string(entry, @@ -240,7 +257,20 @@ backend_make_user_entry_from_nsswitch_passwd(struct passwd *pwd, #ifdef HAVE_SSS_NSS_IDMAP rc = sss_nss_getsidbyid(pwd->pw_uid, &sid_str, &id_type); if ((rc == 0) && (sid_str != NULL)) { +#ifdef USE_IPA_IDVIEWS + char *anchor = NULL; + /* For overrides of AD users to work correctly, we need to generate + * ipaAnchorUUID value so that idviews can be properly searched for the override */ + anchor = slapi_ch_smprintf(":SID:%s", sid_str); + if (anchor != NULL) { + slapi_entry_add_string(entry, "objectClass", "ipaOverrideTarget"); + slapi_entry_add_string(entry, "ipaAnchorUUID", anchor); + slapi_ch_free_string(&anchor); + } +#else + slapi_entry_add_string(entry, "objectClass", "extensibleObject"); slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); +#endif free(sid_str); } #endif @@ -335,8 +365,6 @@ backend_make_group_entry_from_nsswitch_group(struct group *grp, slapi_entry_add_string(entry, "objectClass", "posixGroup"); slapi_entry_add_string(entry, - "objectClass", "extensibleObject"); - slapi_entry_add_string(entry, "cn", grp->gr_name); slapi_entry_attr_set_uint(entry, "gidNumber", grp->gr_gid); @@ -352,7 +380,20 @@ backend_make_group_entry_from_nsswitch_group(struct group *grp, #ifdef HAVE_SSS_NSS_IDMAP rc = sss_nss_getsidbyid(grp->gr_gid, &sid_str, &id_type); if ((rc == 0) && (sid_str != NULL)) { +#ifdef USE_IPA_IDVIEWS + char *anchor = NULL; + /* For overrides of AD users to work correctly, we need to generate + * ipaAnchorUUID value so that idviews can be properly searched for the override */ + anchor = slapi_ch_smprintf(":SID:%s", sid_str); + if (anchor != NULL) { + slapi_entry_add_string(entry, "objectClass", "ipaOverrideTarget"); + slapi_entry_add_string(entry, "ipaAnchorUUID", anchor); + slapi_ch_free_string(&anchor); + } +#else + slapi_entry_add_string(entry, "objectClass", "extensibleObject"); slapi_entry_add_string(entry, "ipaNTSecurityIdentifier", sid_str); +#endif free(sid_str); } #endif @@ -558,6 +599,16 @@ nsswitch_type_to_name(enum sch_search_nsswitch_t type) return "(unknown)"; } +int +backend_analyze_search_filter(Slapi_Filter *filter, struct backend_search_filter_config *config) +{ + int result, rc; + result = slapi_filter_apply(filter, + backend_search_filter_has_cn_uid, + config, &rc); + return (result != SLAPI_FILTER_SCAN_STOP) ? 1 : 0; +} + /* Check if the filter is one (like uid=) that should trigger an * nsswitch lookup, and if it is, make a note that we should perform such a * lookup. */ @@ -566,15 +617,15 @@ backend_search_nsswitch(struct backend_set_data *set_data, struct backend_search_cbdata *cbdata) { int result, rc; - struct backend_search_filter_config config = {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL}; + struct backend_search_filter_config config = + {FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, NULL, NULL, NULL}; struct backend_staged_search *staged = NULL; char *idptr = NULL; unsigned long id; /* First, we search the filter to see if it includes a cn|uid= test. */ - result = slapi_filter_apply(cbdata->filter, - backend_search_filter_has_cn_uid, &config, &rc); - if ((result != SLAPI_FILTER_SCAN_STOP)) { + result = backend_analyze_search_filter(cbdata->filter, &config); + if (result != 0) { return; } @@ -624,6 +675,7 @@ backend_search_nsswitch(struct backend_set_data *set_data, staged->type = cbdata->check_nsswitch; staged->name = config.name; /* takes ownership */ staged->is_id = config.search_gid || config.search_uid; + staged->is_sid = config.search_sid; staged->search_members = config.search_members; staged->next = cbdata->staged; @@ -649,6 +701,23 @@ backend_retrieve_from_nsswitch(struct backend_staged_search *staged, { Slapi_Entry **entries; +#ifdef HAVE_SSS_NSS_IDMAP + if (staged->is_sid) { + char *name = NULL; + enum sss_id_type id_type; + /* we expect name to be a SID prefixed with :SID: */ + int result = sss_nss_getnamebysid(staged->name+5, &name, &id_type); + if (result == 0) { + staged->is_sid = FALSE; + staged->is_id = FALSE; + + slapi_ch_free_string(&staged->name); + staged->name = slapi_ch_strdup(name); + free(name); + } + } +#endif + if (((staged->type == SCH_NSSWITCH_GROUP) && staged->search_members) && (NULL != staged->name)) { entries = backend_retrieve_group_list_from_nsswitch(staged->name, staged->container_sdn, diff --git a/src/back-sch.c b/src/back-sch.c index 78f2627..27d5101 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -259,15 +259,6 @@ backend_set_config_read_config(struct plugin_state *state, Slapi_Entry *e, free(nsswitch_min_id); } - if (ret.check_nsswitch != SCH_NSSWITCH_NONE) { - /* If we're adding nsswitch-based entries to this map, make - * sure that we copy the schema-compat-origin and SID - * attributes, so that we can read the former during the BIND - * callback. */ - backend_shr_add_strlist(&ret.attribute_format, "objectClass=%ifeq(\"%{ipaNTSecurityIdentifier}\",\"\",\"\",\"extensibleObject\")"); - backend_shr_add_strlist(&ret.attribute_format, "ipaNTSecurityIdentifier=%{ipaNTSecurityIdentifier}"); - } - *pret = backend_copy_set_config(&ret); if (*pret == NULL) { if (strlen(container) > 0) { @@ -1005,6 +996,7 @@ backend_search_entry_cb(const char *domain, const char *map, bool_t secure, void *backend_data, void *cb_data) { Slapi_DN *sdn; + Slapi_Entry *entry; struct backend_search_cbdata *cbdata; struct backend_entry_data *entry_data; int result; @@ -1043,9 +1035,25 @@ backend_search_entry_cb(const char *domain, const char *map, bool_t secure, cbdata->state->plugin_desc->spd_id, "search matched %s\n", slapi_sdn_get_ndn(sdn)); - slapi_send_ldap_search_entry(cbdata->pb, entry_data->e, NULL, + entry = entry_data->e; +#ifdef USE_IPA_IDVIEWS + entry = slapi_entry_dup(entry_data->e); + if (cbdata->idview != NULL) { + idview_process_overrides(cbdata, key, map, domain, entry); + } + + if (slapi_entry_attr_exists(entry, IPA_IDVIEWS_ATTR_ANCHORUUID) == 1) { + slapi_entry_attr_delete(entry, IPA_IDVIEWS_ATTR_ANCHORUUID); + slapi_entry_delete_string(entry, "objectClass", "ipaOverrideTarget"); + } +#endif + slapi_send_ldap_search_entry(cbdata->pb, entry, NULL, cbdata->attrs, cbdata->attrsonly); cbdata->n_entries++; + + if (entry != entry_data->e) { + slapi_entry_free(entry); + } break; } @@ -1104,6 +1112,13 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, "search matched %s\n", ndn); +#ifdef USE_IPA_IDVIEWS + if (cbdata->idview != NULL) { + idview_process_overrides(cbdata, NULL, + set_data->common.set, + set_data->common.group, set_entry); + } +#endif slapi_send_ldap_search_entry(cbdata->pb, set_entry, NULL, cbdata->attrs, cbdata->attrsonly); @@ -1216,6 +1231,11 @@ backend_search_group_cb(const char *group, void *cb_data) slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, "search matched %s\n", group); +#ifdef USE_IPA_IDVIEWS + if (cbdata->idview != NULL) { + idview_process_overrides(cbdata, NULL, NULL, group, group_entry); + } +#endif slapi_send_ldap_search_entry(cbdata->pb, group_entry, NULL, cbdata->attrs, cbdata->attrsonly); @@ -1313,11 +1333,16 @@ backend_search_cb(Slapi_PBlock *pb) cbdata.n_entries = 0; cbdata.staged = NULL; cbdata.cur_staged = NULL; + cbdata.idview = NULL; + cbdata.overrides = NULL; /* Okay, we can search. */ slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, "searching from \"%s\" for \"%s\" with scope %d%s\n", cbdata.target, cbdata.strfilter, cbdata.scope, backend_sch_scope_as_string(cbdata.scope)); +#ifdef USE_IPA_IDVIEWS + idview_replace_target_dn(&cbdata.target, &cbdata.idview); +#endif cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); /* Check if there's a backend handling this search. */ if (!slapi_be_exist(cbdata.target_dn)) { @@ -1326,10 +1351,21 @@ backend_search_cb(Slapi_PBlock *pb) "slapi_be_exists(\"%s\") = 0, " "ignoring search\n", cbdata.target); slapi_sdn_free(&cbdata.target_dn); + if (cbdata.idview != NULL) { + slapi_ch_free_string(&cbdata.target); + } + slapi_ch_free_string(&cbdata.idview); +#ifdef USE_IPA_IDVIEWS + idview_free_overrides(&cbdata); +#endif return 0; } + /* Walk the list of groups. */ wrap_inc_call_level(); +#ifdef USE_IPA_IDVIEWS + idview_replace_filter(&cbdata); +#endif if (map_rdlock() == 0) { map_data_foreach_domain(cbdata.state, backend_search_group_cb, &cbdata); @@ -1468,6 +1504,13 @@ backend_search_cb(Slapi_PBlock *pb) cbdata.n_entries, NULL); } slapi_sdn_free(&cbdata.target_dn); + if (cbdata.idview != NULL) { + slapi_ch_free_string(&cbdata.target); + } + slapi_ch_free_string(&cbdata.idview); +#ifdef USE_IPA_IDVIEWS + idview_free_overrides(&cbdata); +#endif free(cbdata.closest_match); free(cbdata.text); return cbdata.answer ? -1 : 0; @@ -1525,6 +1568,7 @@ static void backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char **group, const char**set) { struct backend_locate_cbdata cbdata; + char *idview = NULL; slapi_pblock_get(pb, SLAPI_PLUGIN_PRIVATE, &cbdata.state); if (cbdata.state->plugin_base == NULL) { @@ -1533,6 +1577,9 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** return; } slapi_pblock_get(pb, SLAPI_TARGET_DN, &cbdata.target); +#ifdef USE_IPA_IDVIEWS + idview_replace_target_dn(&cbdata.target, &idview); +#endif cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); cbdata.entry_data = NULL; cbdata.entry_group = NULL; @@ -1542,6 +1589,10 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** *group = cbdata.entry_group; *set = cbdata.entry_set; slapi_sdn_free(&cbdata.target_dn); + if (idview != NULL) { + slapi_ch_free_string(&cbdata.target); + } + slapi_ch_free_string(&idview); } /* Check if the target DN is part of this group's tree. If it is, return an diff --git a/src/back-sch.h b/src/back-sch.h index 2f4a3df..9f0b201 100644 --- a/src/back-sch.h +++ b/src/back-sch.h @@ -55,6 +55,7 @@ struct backend_staged_search { struct backend_set_data *set_data; enum sch_search_nsswitch_t type; bool_t is_id; + bool_t is_sid; /* if search is by ipaAnchorUUID beginning with :SID:S-... */ bool_t search_members; char *name; char *container_sdn; @@ -69,6 +70,8 @@ struct backend_search_cbdata { Slapi_PBlock *pb; struct plugin_state *state; char *target, *strfilter, **attrs; + char *idview; + Slapi_Entry **overrides; int scope, sizelimit, timelimit, attrsonly; bool_t check_access; enum sch_search_nsswitch_t check_nsswitch; @@ -87,6 +90,31 @@ struct backend_search_cbdata { struct backend_staged_search *cur_staged; }; +struct backend_search_filter_config { + bool_t search_user; + bool_t search_group; + bool_t search_uid; + bool_t search_gid; + bool_t search_sid; + bool_t search_members; + bool_t name_set; + bool_t wrong_search; + bool_t override_found; + char *name; + /* If callback is defined, it is called on each filter after analyzing it. + * Return code of the callback is directly returned to slapi_filter_apply() */ + int (*callback)(Slapi_Filter *filter, const char *filter_type, struct berval *bval, struct backend_search_filter_config *config); + void *callback_data; +}; + +/* Analyzes the filter to decide what kind of NSS search is it + * Returns 0 on success, 1 on failure + * struct backend_search_filter_config is populated with information about the filter + * config.name should be freed with slapi_ch_free_string() + */ + +int backend_analyze_search_filter(Slapi_Filter *filter, struct backend_search_filter_config *config); + void backend_search_nsswitch(struct backend_set_data *set_data, struct backend_search_cbdata *cbdata); @@ -95,4 +123,14 @@ bool_t backend_retrieve_from_nsswitch(struct backend_staged_search *staged, int backend_sch_do_pam_auth(Slapi_PBlock *pb, const char *username); +#ifdef USE_IPA_IDVIEWS +void idview_get_overrides(struct backend_search_cbdata *cbdata); +void idview_free_overrides(struct backend_search_cbdata *cbdata); +void idview_process_overrides(struct backend_search_cbdata *cbdata, + const char *key, const char *map, const char *domain, + Slapi_Entry *entry); +void idview_replace_target_dn(char **target, char **idview); +void idview_replace_filter(struct backend_search_cbdata *cbdata); +#endif + #endif -- 2.1.0 From jcholast at redhat.com Fri Oct 10 09:50:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 10 Oct 2014 11:50:30 +0200 Subject: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code In-Reply-To: <543782DF.7080409@redhat.com> References: <543511A9.5050205@redhat.com> <54351ECD.1040603@redhat.com> <5436940F.6010800@redhat.com> <543781CA.3070509@redhat.com> <543782DF.7080409@redhat.com> Message-ID: <5437ABE6.7060107@redhat.com> Dne 10.10.2014 v 08:55 David Kupka napsal(a): > On 10/10/2014 08:50 AM, Martin Kosek wrote: >> On 10/09/2014 03:56 PM, David Kupka wrote: >>> On 10/08/2014 01:23 PM, Jan Cholasta wrote: >>>> Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a): >>>>> Hi, >>>>> >>>>> the attached patch fixes >>>>> . >>>>> >>>>> Honza >>>> >>>> Forgot to delete a line in dogtaginstance.py (thanks to David for >>>> noticing). Updated patch attached. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> >>> Works for me, ACK. >>> >> >> Thanks, pushed to master. >> >> Just to double check - no parts of the fixes should be applied to 4.1 or >> 4.0 branches, is that correct? >> >> Martin > > I've never seen or been able to reproduce this bug other than on master > branch. AFAIK, the issue was caused by KRA patches that are only in master. The patch is master only and applies on top of the KRA changes. -- Jan Cholasta From mkosek at redhat.com Fri Oct 10 10:17:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Oct 2014 12:17:48 +0200 Subject: [Freeipa-devel] [PATCH] 0018 Check that port 8443 is available when installing PKI. In-Reply-To: <542E7810.7090906@redhat.com> References: <54297123.4040901@redhat.com> <542D2C0A.20903@redhat.com> <542E7810.7090906@redhat.com> Message-ID: <5437B24C.5070804@redhat.com> On 10/03/2014 12:18 PM, David Kupka wrote: > > > On 10/02/2014 12:42 PM, Martin Kosek wrote: >> On 09/29/2014 04:48 PM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4564 >> >> Looks and works OK. The port checking should be ideally refactored in 4.2 and >> *instance.py should use some common hooks to define which ports should be >> checked, but your way be enough for now. >> >> What about ipa-replica-install? It could be also run with --setup-ca option. > > I missed that one. git grep I used did not return it. Thanks. Ok, ACK. Pushed to master, ipa-4-1, ipa-4-0 (with little merge). Martin From pvoborni at redhat.com Fri Oct 10 11:44:16 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Oct 2014 13:44:16 +0200 Subject: [Freeipa-devel] [PATCH] 766 idviews: error out if appling Default Trust View on hosts Message-ID: <5437C690.50308@redhat.com> CLI part of: https://fedorahosted.org/freeipa/ticket/4615 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0766-idviews-error-out-if-appling-Default-Trust-View-on-h.patch Type: text/x-patch Size: 1006 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 10 11:44:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Oct 2014 13:44:59 +0200 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View Message-ID: <5437C6BB.7030109@redhat.com> Web UI part of: https://fedorahosted.org/freeipa/ticket/4615 Patch 767 is a little refactoring needed for $pre_op(as plain object) work as intended even with instantiated objects + fixes a bug where Evented objects were not considered a framework object. Patch 768 switches tabs so we can hide it later Patch 769 hides the tab PAtch 770 is not really needed(would like to hear options whether to include it). It's in effect only if user somehow manages to open 'Applies to hosts' facet for 'Default trust view'. Maybe redirection would be better - if we need to act. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0770-webui-hide-un-apply-buttons-for-Default-Trust-View.patch Type: text/x-patch Size: 1463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0769-webui-hide-applied-to-hosts-tab-for-Default-Trust-Vi.patch Type: text/x-patch Size: 3333 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0768-webui-change-order-of-idview-s-facet-groups.patch Type: text/x-patch Size: 1142 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0767-webui-make-Evented-a-part-of-base-IPA.object.patch Type: text/x-patch Size: 6672 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 10 11:45:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Oct 2014 13:45:05 +0200 Subject: [Freeipa-devel] [PATCH] 771 webui: do not offer ipa users to Default Trust View Message-ID: <5437C6C1.9070007@redhat.com> https://fedorahosted.org/freeipa/ticket/4616 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0771-webui-do-not-offer-ipa-users-to-Default-Trust-View.patch Type: text/x-patch Size: 7516 bytes Desc: not available URL: From abokovoy at redhat.com Fri Oct 10 12:32:10 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Oct 2014 15:32:10 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <20141010083936.GZ2328@redhat.com> References: <20141010083936.GZ2328@redhat.com> Message-ID: <20141010123210.GA2328@redhat.com> On Fri, 10 Oct 2014, Alexander Bokovoy wrote: > Hi! > > I'm resending patches 0159 and 0160, and adding two more: > > 0161 -- support user SSH public keys in ID view user overrides > 0162 -- support gidNumber in ID view user override > > SSH public keys to work require support from SSSD and that one is > currently missing. At least, one add/remove the keys to/from the > override objects. > > Compat tree does not support exporting SSH keys. When accessing the tree > anonymously, the entry will be filtered out by ACIs but for > authenticated users we need to explicitly ignore ipaSshPubKey attribute > in the override, so I'm resending updated slapi-nis patch that only > adds one more attribute to filter out. slapi-nis patches now committed to slapi-nis git repository, version 0.54 is released. Packages for rawhide are built. Fedora 21 update is https://admin.fedoraproject.org/updates/slapi-nis-0.54-1.fc21 -- / Alexander Bokovoy From ssorce at redhat.com Fri Oct 10 12:51:01 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 10 Oct 2014 08:51:01 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <5437880E.5010002@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> Message-ID: <20141010085101.32a683ad@willson.usersys.redhat.com> On Fri, 10 Oct 2014 09:17:34 +0200 Martin Kosek wrote: > On 10/09/2014 03:57 PM, Petr Spacek wrote: > > Hello, > > > > it would be great if people could look at current state of DNSSEC > > patches for FreeIPA. > > > > It consist of several relatively independent parts: > > - python-pkcs#11 interface written by Martin Basti: > > https://github.com/spacekpe/freeipa-pkcs11 > > > > - DNSSEC daemons written by me: > > https://github.com/spacekpe/ipadnssecd Well I have to be honest, it would be easier if commit messages were in English :-) Simo. > > - FreeIPA integration written by Martin Basti: > > https://github.com/bastiak/freeipa/tree/dnssec > > > > For now brief visual inspection is good enough :-) > > > > Current state > > ============= > > - It works only on single DNSSEC "master" server because we still > > do not have the key wrapping machinery. > > - The "master" server has to be configured manually using > > ipa-dnssec-setmaster utility. > > - DNSSEC keys are generated on the fly when DNSSEC is enabled for > > particular zone. > > - Metadata for BIND are generated on the fly. > > - BIND automatically signs the zone. > > > > It depends on latest softhsm, opendnssec and bind-pkcs11-util & > > bind-pkcs11 packages which are not in Fedora 21 yet. > > > > Thank you for your time! > > > > Good! I am glad to see a progress. I am also CCing Simo and Rob to be > in the loop. It would be especially useful if you also show Simo your > special file permissions (setfacl) and sharing config files between > daemons. I rather nervous about this part. > > To comment on FreeIPA integration - I saw you are adding a new config > file: > - install/tools/ipa-dnssec-setmaster > > I wonder how consistent and future proof that is. Setting master is > currently being done in "ipa-*replica-manage", check for example > "ipa-csreplica-manage". We want to have these operations on a > sensible place as we will be refactoring them in 4.2. > > As for the service installation code itself, I would rather see it in > > # ipa-dns-install > > which could have new --dnssec-master and --no-dnssec flag. > > Martin -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Oct 10 13:12:17 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 10 Oct 2014 15:12:17 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <20141010085101.32a683ad@willson.usersys.redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <20141010085101.32a683ad@willson.usersys.redhat.com> Message-ID: <5437DB31.40304@redhat.com> On 10/10/14 14:51, Simo Sorce wrote: > On Fri, 10 Oct 2014 09:17:34 +0200 > Martin Kosek wrote: > >> On 10/09/2014 03:57 PM, Petr Spacek wrote: >>> Hello, >>> >>> it would be great if people could look at current state of DNSSEC >>> patches for FreeIPA. >>> >>> It consist of several relatively independent parts: >>> - python-pkcs#11 interface written by Martin Basti: >>> https://github.com/spacekpe/freeipa-pkcs11 >>> >>> - DNSSEC daemons written by me: >>> https://github.com/spacekpe/ipadnssecd > Well I have to be honest, it would be easier if commit messages were in > English :-) > > Simo. Honestly, those commit messages are not helpful, we plan to merge it into one IPA commit, so we don't use nice commit messages. > >>> - FreeIPA integration written by Martin Basti: >>> https://github.com/bastiak/freeipa/tree/dnssec >>> >>> For now brief visual inspection is good enough :-) >>> >>> Current state >>> ============= >>> - It works only on single DNSSEC "master" server because we still >>> do not have the key wrapping machinery. >>> - The "master" server has to be configured manually using >>> ipa-dnssec-setmaster utility. >>> - DNSSEC keys are generated on the fly when DNSSEC is enabled for >>> particular zone. >>> - Metadata for BIND are generated on the fly. >>> - BIND automatically signs the zone. >>> >>> It depends on latest softhsm, opendnssec and bind-pkcs11-util & >>> bind-pkcs11 packages which are not in Fedora 21 yet. >>> >>> Thank you for your time! >>> >> Good! I am glad to see a progress. I am also CCing Simo and Rob to be >> in the loop. It would be especially useful if you also show Simo your >> special file permissions (setfacl) and sharing config files between >> daemons. I rather nervous about this part. >> >> To comment on FreeIPA integration - I saw you are adding a new config >> file: >> - install/tools/ipa-dnssec-setmaster >> >> I wonder how consistent and future proof that is. Setting master is >> currently being done in "ipa-*replica-manage", check for example >> "ipa-csreplica-manage". We want to have these operations on a >> sensible place as we will be refactoring them in 4.2. >> >> As for the service installation code itself, I would rather see it in >> >> # ipa-dns-install >> >> which could have new --dnssec-master and --no-dnssec flag. >> >> Martin > > -- Martin Basti From pvoborni at redhat.com Fri Oct 10 13:12:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Oct 2014 15:12:18 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <20141010083936.GZ2328@redhat.com> References: <20141010083936.GZ2328@redhat.com> Message-ID: <5437DB32.2030907@redhat.com> On 10.10.2014 10:39, Alexander Bokovoy wrote: > Hi! > > I'm resending patches 0159 and 0160, and adding two more: > > 0161 -- support user SSH public keys in ID view user overrides > 0162 -- support gidNumber in ID view user override > > SSH public keys to work require support from SSSD and that one is > currently missing. At least, one add/remove the keys to/from the > override objects. > > Compat tree does not support exporting SSH keys. When accessing the tree > anonymously, the entry will be filtered out by ACIs but for > authenticated users we need to explicitly ignore ipaSshPubKey attribute > in the override, so I'm resending updated slapi-nis patch that only > adds one more attribute to filter out. > I'm going to prepare Web UI for, 160, 161, 162. Q: ipaUserOverride object class contains also 'gecos' attribute. Will it be handled be CLI and Web UI as well? Comments for these 3 patches: 1. VERSION was not bumped Patch 160: Apart form #1, is OK (not sure if #1 is needed for ACK) Patch 161: 2. idoverrideuser_show and _find should have post_callback with convert_sshpubkey_post as well - to be consistent. 3. Add blank line before new methods - both post_callbacks 4. I have created a helper method for adding object classes in patch 761 (currently on review) - add_missing_object_class. Would be nice fit, but also I don't want to block this patch with mine. Patch 162: Is it good to have different CLI option name in this and user plugin for the same attribute: --gid vs --gidnumber ? That said, it's sad that --gid was not used in user plugin since the beginning. -- Petr Vobornik From mkosek at redhat.com Fri Oct 10 13:16:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 10 Oct 2014 15:16:01 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <5437DB32.2030907@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> Message-ID: <5437DC11.8040003@redhat.com> On 10/10/2014 03:12 PM, Petr Vobornik wrote: > On 10.10.2014 10:39, Alexander Bokovoy wrote: >> Hi! >> >> I'm resending patches 0159 and 0160, and adding two more: >> >> 0161 -- support user SSH public keys in ID view user overrides >> 0162 -- support gidNumber in ID view user override >> >> SSH public keys to work require support from SSSD and that one is >> currently missing. At least, one add/remove the keys to/from the >> override objects. >> >> Compat tree does not support exporting SSH keys. When accessing the tree >> anonymously, the entry will be filtered out by ACIs but for >> authenticated users we need to explicitly ignore ipaSshPubKey attribute >> in the override, so I'm resending updated slapi-nis patch that only >> adds one more attribute to filter out. >> > > I'm going to prepare Web UI for, 160, 161, 162. > > Q: ipaUserOverride object class contains also 'gecos' attribute. Will it be > handled be CLI and Web UI as well? > > Comments for these 3 patches: > > 1. VERSION was not bumped > > Patch 160: > Apart form #1, is OK (not sure if #1 is needed for ACK) > > Patch 161: > > 2. idoverrideuser_show and _find should have post_callback with > convert_sshpubkey_post as well - to be consistent. > > 3. Add blank line before new methods - both post_callbacks > > 4. I have created a helper method for adding object classes in patch 761 > (currently on review) - add_missing_object_class. Would be nice fit, but also I > don't want to block this patch with mine. > > Patch 162: > > Is it good to have different CLI option name in this and user plugin for the > same attribute: --gid vs --gidnumber ? That said, it's sad that --gid was not > used in user plugin since the beginning. > Also, we will need to have slapi-nis version in the spec file bumped. I already fired a build of slapi-nis to FreeIPA Copr. Martin From jcholast at redhat.com Fri Oct 10 13:24:46 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 10 Oct 2014 15:24:46 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <543513B3.9060808@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> <543513B3.9060808@redhat.com> Message-ID: <5437DE1E.3000307@redhat.com> Dne 8.10.2014 v 12:36 David Kupka napsal(a): > On 10/08/2014 09:29 AM, Jan Cholasta wrote: >> Hi, >> >> Dne 8.10.2014 v 09:09 David Kupka napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4569 >> >> In renew_ca_cert and cainstance.py, dogtag should already be stopped in >> the places you modified, so why the change? > > I didn't noticed that it is already stopped, fixed. >> >> Also I don't think it's a good idea to backup CS.cfg when dogtag is >> still running (in cainstance.py). If the file is being modified by >> dogtag at the time it is backed up, the backup may be corrupted. >> > Fixed, thanks. CAInstance.backup_config should be called only when Dogtag is stopped as well, you don't need to change it. > >> Honza >> > It would be better to stop and start dogtag only once in ipa-upgradeconfig, not every time there is a modification to CS.cfg. -- Jan Cholasta From abokovoy at redhat.com Fri Oct 10 13:36:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Oct 2014 16:36:45 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <5437DB32.2030907@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> Message-ID: <20141010133645.GC2328@redhat.com> On Fri, 10 Oct 2014, Petr Vobornik wrote: >On 10.10.2014 10:39, Alexander Bokovoy wrote: >>Hi! >> >>I'm resending patches 0159 and 0160, and adding two more: >> >>0161 -- support user SSH public keys in ID view user overrides >>0162 -- support gidNumber in ID view user override >> >>SSH public keys to work require support from SSSD and that one is >>currently missing. At least, one add/remove the keys to/from the >>override objects. >> >>Compat tree does not support exporting SSH keys. When accessing the tree >>anonymously, the entry will be filtered out by ACIs but for >>authenticated users we need to explicitly ignore ipaSshPubKey attribute >>in the override, so I'm resending updated slapi-nis patch that only >>adds one more attribute to filter out. >> > >I'm going to prepare Web UI for, 160, 161, 162. > >Q: ipaUserOverride object class contains also 'gecos' attribute. Will >it be handled be CLI and Web UI as well? I'll add another patch for that. > >Comments for these 3 patches: > >1. VERSION was not bumped > >Patch 160: >Apart form #1, is OK (not sure if #1 is needed for ACK) I wonder if I should bump it in a separate patch that would be the last one in the series, to avoid proliferation of API version numbers? :) >Patch 161: > >2. idoverrideuser_show and _find should have post_callback with >convert_sshpubkey_post as well - to be consistent. > >3. Add blank line before new methods - both post_callbacks > >4. I have created a helper method for adding object classes in patch >761 (currently on review) - add_missing_object_class. Would be nice >fit, but also I don't want to block this patch with mine. > >Patch 162: > >Is it good to have different CLI option name in this and user plugin >for the same attribute: --gid vs --gidnumber ? That said, it's sad >that --gid was not used in user plugin since the beginning. I'll fix these. -- / Alexander Bokovoy From tbordaz at redhat.com Fri Oct 10 13:58:57 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 10 Oct 2014 15:58:57 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412887903.3262.14.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> Message-ID: <5437E621.2000302@redhat.com> On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: >> On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: >> >>> On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: >>>> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >>>>>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >>>>>> >>>>>>> The background of this email is this bug: >>>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>>> >>>>>>> Attached are two patches which solve this issue for admin users (not >>>>>>> very helpful, I know). They depend on this fix in 389: >>>>>>> https://fedorahosted.org/389/ticket/47920 >>>>>>> >>>>>>> There are two outstanding issues: >>>>>>> >>>>>>> 1. 389 does not send the post read control for normal users. The >>>>>>> operation itself succeeds, but no control is sent. >>>>>>> >>>>>>> The relevant sections from the log are attached. 389 is denying access >>>>>>> to the following attributes (* = valid, ! = invalid): >>>>>>> ! objectClass >>>>>>> ! ipatokenOTPalgorithm >>>>>>> ! ipatokenOTPdigits >>>>>>> * ipatokenOTPkey >>>>>>> * ipatokenHOTPcounter >>>>>>> ! ipatokenOwner >>>>>>> ! managedBy >>>>>>> ! ipatokenUniqueID >>>>>> Hello Nathaniel, >>>>>> >>>>>> The post read control needs access to the modified entry to >>>>>> return it. >>>>>> This access is granted at the condition, the binddn can access >>>>>> attributes. >>>>> Agreed and understood. >>>>> >>>>>> My understanding is that the target entry is >>>>>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". >>>>> Correct. >>>>> >>>>>> The only ACI I found that match this target is: >>>>>> aci: (targetfilter = "(objectClass=ipaToken)") >>>>>> (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled >>>>>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") >>>>>> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>> Correct. >>>>> >>>>>> Do you know if the target entry has 'ipatokenOwner' or >>>>>> 'managedBy' with the binddn value ? >>>>> Yes, both. So why is access to objectClass (et cetera) being denied? >>>> Good question... I will try to reproduce >>> Thanks! >> Hello, >> >> I tried to reproduce and it seems to work on *master*. >> I am using the attached ldif file. >> The test case is to bind as "cn=active >> guy,cn=accounts,dc=example,dc=com" and to do a modify on >> "cn=active otp,cn=otp,dc=example,dc=com". >> >> The modify updates the 'description' attribute and do a >> postread (description, cn). >> >> The write 'description' is allowed by : >> dn: cn=otp,dc=example,dc=com >> aci: (targetfilter = >> "(objectclass=organizationalPerson)")(target = >> "ldap:///c >> n=*,cn=otp,dc=example,dc=com")(targetattr = >> "objectclass || description || se >> eAlso")(version 3.0; acl "Active user modify otp >> entry"; allow (write) userdn >> = "ldap:///cn=active >> guy,cn=accounts,dc=example,dc=com";) >> >> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. >> Evaluating ALLOW aci(19) " "Active user modify otp >> entry"" >> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 >> op=16 (main): Allow write on entry(cn=active >> otp,cn=otp,dc=example,dc=com).attr(description) to >> cn=active guy,cn=accounts,dc=example,dc=com: allowed >> by aci(19): aciname= "Active user modify otp entry", >> acidn="cn=otp,dc=example,dc=com" >> >> >> The postread is allowed by: >> dn: cn=otp,dc=example,dc=com >> aci: (targetfilter = >> "(objectclass=organizationalPerson)") (targetattr = >> "obje >> ctclass || description || seeAlso || cn")(version >> 3.0; acl "Active user can r >> ead his entries"; allow (read, search, compare) >> userattr = "seeAlso#USERDN";) >> >> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. >> Evaluating ALLOW aci(21) " "Active user can read his >> entries"" >> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ >> ALLOW in cache >> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 >> op=16 (main): Allow read on entry(cn=active >> otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active >> guy,cn=accounts,dc=example,dc=com: cached allow by >> aci(21) >> >> The postread works if I use USERDN or SELFDN. >> >> Please let me know the version of 389-ds that you are testing, >> I will try on that branch > That is not really the same test at all. > > 1. Install FreeIPA from F21 @ example.com > 2. Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com > -W -e postread=* < dn: ipatokenuniqueid=foo,cn=otp,dc=example,dc=com > changetype: add > objectClass: top > objectClass: ipaToken > objectClass: ipaTokenHOTP > ipatokenUniqueID: foo > ipatokenOTPalgorithm: sha1 > ipatokenOTPdigits: 6 > ipatokenOTPkey: 00000000 > ipatokenHOTPcounter: 0 > ipatokenOwner: uid=admin,cn=users,cn=accounts,dc=example,dc=com > managedBy: uid=admin,cn=users,cn=accounts,dc=example,dc=com > EOF > > 3. Create a regular user named 'otp' > 4. Execute: ldapadd -D uid=otp,cn=users,cn=accounts,dc=example,dc=com -W > -e postread=* < dn: ipatokenuniqueid=bar,cn=otp,dc=example,dc=com > changetype: add > objectClass: top > objectClass: ipaToken > objectClass: ipaTokenHOTP > ipatokenUniqueID: bar > ipatokenOTPalgorithm: sha1 > ipatokenOTPdigits: 6 > ipatokenOTPkey: 00000000 > ipatokenHOTPcounter: 0 > ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com > managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com > EOF > > RESULTS: > Step 2 will add the token and return the post read control. Step 4 will > add the token, but will NOT return the post read control. > > Hi Nathaniel, Thanks for the detailed procedure I was able to reproduce the problem: In fact during the step for, the add is successful but the found ACIs do no grant access to the target entry: [09/Oct/2014:21:34:58 -0400] conn=29 fd=82 slot=82 SSL connection from 10.16.78.124 to 10.16.78.124 [09/Oct/2014:21:34:58 -0400] conn=29 SSL 128-bit AES [09/Oct/2014:21:34:58 -0400] conn=29 op=0 BIND dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" method=128 version=3 [09/Oct/2014:21:34:58 -0400] conn=29 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" [09/Oct/2014:21:34:58 -0400] conn=29 op=1 ADD dn="ipatokenuniqueid=bar,cn=otp,dc=example,dc=com" [09/Oct/2014:21:34:59 -0400] conn=29 op=2 UNBIND [09/Oct/2014:21:34:59 -0400] conn=29 op=2 fd=82 closed - U1 [09/Oct/2014:21:34:59 -0400] conn=29 op=1 RESULT *err=0* tag=105 nentries=0 etime=1 The add was granted because of "Users can create self-managed tokens" [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 (main): Allow add on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(NULL) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: allowed by aci(16): aciname= "Users can create self-managed tokens", acidn="dc=example,dc=com" Now the postread control was not granted for any of the attribute of the entry: [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*objectClass*) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenUniqueID*) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPalgorithm*) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPdigits*) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPkey*) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenHOTPcounter*) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOwner*) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*managedBy*) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" Each time the correct aci was selectionned: aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || d escription || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNo tBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSer ial || ipatokenOwner")(version 3.0; acl "*Users/managers can read basic token* info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or use rattr = "managedBy#USERDN";) ... [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed attr:managedBy for entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating ALLOW aci(11) " "*Users/managers can read basic token info*"" [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in cache [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating ALLOW aci(19) " "Admin can manage any entry"" [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in cache [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" [09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: access to entry not allowed (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) But for some reason, it evaluations of the READ access was not accepted. Did you already open a ticket for this problem ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Fri Oct 10 14:04:49 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 10 Oct 2014 16:04:49 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Set IPA CA for freeipa certificates In-Reply-To: <5433FF18.6040103@redhat.com> References: <5433FF18.6040103@redhat.com> Message-ID: <5437E781.40208@redhat.com> Hi, Dne 7.10.2014 v 16:56 David Kupka napsal(a): > https://fedorahosted.org/freeipa/ticket/4618 This works, but I would prefer if the code did not silently ignore when the CA is not found. Honza -- Jan Cholasta From pvoborni at redhat.com Fri Oct 10 14:07:28 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Oct 2014 16:07:28 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <20141010133645.GC2328@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> <20141010133645.GC2328@redhat.com> Message-ID: <5437E820.1090303@redhat.com> On 10.10.2014 15:36, Alexander Bokovoy wrote: > On Fri, 10 Oct 2014, Petr Vobornik wrote: >> On 10.10.2014 10:39, Alexander Bokovoy wrote: >>> Hi! >>> >>> I'm resending patches 0159 and 0160, and adding two more: >>> >>> 0161 -- support user SSH public keys in ID view user overrides >>> 0162 -- support gidNumber in ID view user override >>> >>> SSH public keys to work require support from SSSD and that one is >>> currently missing. At least, one add/remove the keys to/from the >>> override objects. >>> >>> Compat tree does not support exporting SSH keys. When accessing the tree >>> anonymously, the entry will be filtered out by ACIs but for >>> authenticated users we need to explicitly ignore ipaSshPubKey attribute >>> in the override, so I'm resending updated slapi-nis patch that only >>> adds one more attribute to filter out. >>> >> >> I'm going to prepare Web UI for, 160, 161, 162. >> >> Q: ipaUserOverride object class contains also 'gecos' attribute. Will >> it be handled be CLI and Web UI as well? > I'll add another patch for that. > >> >> Comments for these 3 patches: >> >> 1. VERSION was not bumped >> >> Patch 160: >> Apart form #1, is OK (not sure if #1 is needed for ACK) > I wonder if I should bump it in a separate patch that would be the last > one in the series, to avoid proliferation of API version numbers? :) IMHO it should be sufficient. Same outcome as if the patches were squashed. > >> Patch 161: >> >> 2. idoverrideuser_show and _find should have post_callback with >> convert_sshpubkey_post as well - to be consistent. >> >> 3. Add blank line before new methods - both post_callbacks >> >> 4. I have created a helper method for adding object classes in patch >> 761 (currently on review) - add_missing_object_class. Would be nice >> fit, but also I don't want to block this patch with mine. >> >> Patch 162: >> >> Is it good to have different CLI option name in this and user plugin >> for the same attribute: --gid vs --gidnumber ? That said, it's sad >> that --gid was not used in user plugin since the beginning. > I'll fix these. > -- Petr Vobornik From abokovoy at redhat.com Fri Oct 10 14:08:11 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Oct 2014 17:08:11 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <20141010133645.GC2328@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> <20141010133645.GC2328@redhat.com> Message-ID: <20141010140811.GD2328@redhat.com> On Fri, 10 Oct 2014, Alexander Bokovoy wrote: >On Fri, 10 Oct 2014, Petr Vobornik wrote: >>On 10.10.2014 10:39, Alexander Bokovoy wrote: >>>Hi! >>> >>>I'm resending patches 0159 and 0160, and adding two more: >>> >>>0161 -- support user SSH public keys in ID view user overrides >>>0162 -- support gidNumber in ID view user override >>> >>>SSH public keys to work require support from SSSD and that one is >>>currently missing. At least, one add/remove the keys to/from the >>>override objects. >>> >>>Compat tree does not support exporting SSH keys. When accessing the tree >>>anonymously, the entry will be filtered out by ACIs but for >>>authenticated users we need to explicitly ignore ipaSshPubKey attribute >>>in the override, so I'm resending updated slapi-nis patch that only >>>adds one more attribute to filter out. >>> >> >>I'm going to prepare Web UI for, 160, 161, 162. >> >>Q: ipaUserOverride object class contains also 'gecos' attribute. >>Will it be handled be CLI and Web UI as well? >I'll add another patch for that. > >> >>Comments for these 3 patches: >> >>1. VERSION was not bumped >> >>Patch 160: >>Apart form #1, is OK (not sure if #1 is needed for ACK) >I wonder if I should bump it in a separate patch that would be the last >one in the series, to avoid proliferation of API version numbers? :) > >>Patch 161: >> >>2. idoverrideuser_show and _find should have post_callback with >>convert_sshpubkey_post as well - to be consistent. >> >>3. Add blank line before new methods - both post_callbacks >> >>4. I have created a helper method for adding object classes in patch >>761 (currently on review) - add_missing_object_class. Would be nice >>fit, but also I don't want to block this patch with mine. >> >>Patch 162: >> >>Is it good to have different CLI option name in this and user plugin >>for the same attribute: --gid vs --gidnumber ? That said, it's sad >>that --gid was not used in user plugin since the beginning. >I'll fix these. Fixed patches attached, with three more: patch 0163 -- support GECOS patch 0164 -- increase API patch 0165 -- require slapi-nis 0.54 -- / Alexander Bokovoy -------------- next part -------------- From f28587d5c736600682f4b7dcf3e1158940fd5797 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Sep 2014 14:54:50 +0300 Subject: [PATCH 2/6] Support idviews in compat tree --- ACI.txt | 6 ++++++ install/share/71idviews.ldif | 1 + install/share/schema_compat.uldif | 8 ++++++++ install/updates/10-schema_compat.update | 12 ++++++++++++ ipalib/plugins/group.py | 10 ++++++++++ ipalib/plugins/user.py | 11 +++++++++++ ipaserver/install/plugins/update_managed_permissions.py | 11 +++++++++++ 7 files changed, 59 insertions(+) diff --git a/ACI.txt b/ACI.txt index cebdc2c..87c057e 100644 --- a/ACI.txt +++ b/ACI.txt @@ -54,6 +54,8 @@ dn: dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=groups,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "member || memberhost || memberof || memberuid || memberuser")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Group Membership";allow (compare,read,search) userdn = "ldap:///all";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass")(target = "ldap:///cn=groups,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read Group Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = "businesscategory || cn || createtimestamp || description || entryusn || gidnumber || ipaexternalmember || ipantsecurityidentifier || ipauniqueid || mepmanagedby || modifytimestamp || o || objectclass || ou || owner || seealso")(targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Read Groups";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=groups,cn=accounts,dc=ipa,dc=example @@ -256,6 +258,8 @@ dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "memberof")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Membership";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || displayname || entryusn || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || modifytimestamp || objectclass || sn || title || uid || uidnumber")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Read User Standard Attributes";allow (compare,read,search) userdn = "ldap:///anyone";) +dn: dc=ipa,dc=example +aci: (targetattr = "cn || createtimestamp || entryusn || gecos || gidnumber || homedirectory || loginshell || modifytimestamp || objectclass || uid || uidnumber")(target = "ldap:///cn=users,cn=*,cn=views,cn=compat,dc=ipa,dc=example")(version 3.0;acl "permission:System: Read User Views Compat Tree";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Remove Users";allow (delete) groupdn = "ldap:///cn=System: Remove Users,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=users,cn=accounts,dc=ipa,dc=example @@ -264,6 +268,8 @@ dn: cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example aci: (target = "ldap:///cn=caSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example")(targetfilter = "(objectclass=pkiuser)")(version 3.0;acl "permission:System: Add CA Certificate For Renewal";allow (add) groupdn = "ldap:///cn=System: Add CA Certificate For Renewal,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetfilter = "(objectclass=ipacertificate)")(version 3.0;acl "permission:System: Add Certificate Store Entry";allow (add) groupdn = "ldap:///cn=System: Add Certificate Store Entry,cn=permissions,cn=pbac,dc=ipa,dc=example";) +dn: dc=ipa,dc=example +aci: (targetattr = "ipaanchoruuid")(target = "ldap:///cn=*,cn=compat,dc=ipa,dc=example")(targetfilter = "(objectclass=ipaOverrideTarget)")(version 3.0;acl "permission:System: Compat Tree ID View targets";allow (compare,read,search) userdn = "ldap:///anyone";) dn: cn=CAcert,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetattr = "cacertificate")(targetfilter = "(objectclass=pkica)")(version 3.0;acl "permission:System: Modify CA Certificate";allow (write) groupdn = "ldap:///cn=System: Modify CA Certificate,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example diff --git a/install/share/71idviews.ldif b/install/share/71idviews.ldif index 3f8df2e..caa5cff 100644 --- a/install/share/71idviews.ldif +++ b/install/share/71idviews.ldif @@ -5,3 +5,4 @@ objectClasses: (2.16.840.1.113730.3.8.12.29 NAME 'ipaIDView' SUP nsContainer STR objectClasses: (2.16.840.1.113730.3.8.12.30 NAME 'ipaOverrideAnchor' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) MAY ( description ) X-ORIGIN 'IPA v4' ) objectClasses: (2.16.840.1.113730.3.8.12.31 NAME 'ipaUserOverride' DESC 'Override for User Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( uid $ uidNumber $ gidNumber $ homeDirectory $ loginShell $ gecos $ ipaOriginalUid ) X-ORIGIN 'IPA v4' ) objectClasses: (2.16.840.1.113730.3.8.12.32 NAME 'ipaGroupOverride' DESC 'Override for Group Attributes' SUP ipaOverrideAnchor STRUCTURAL MAY ( gidNumber $ cn ) X-ORIGIN 'IPA v4' ) +objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) diff --git a/install/share/schema_compat.uldif b/install/share/schema_compat.uldif index 6de812f..6769fd1 100644 --- a/install/share/schema_compat.uldif +++ b/install/share/schema_compat.uldif @@ -38,6 +38,10 @@ default:schema-compat-entry-attribute: uidNumber=%{uidNumber} default:schema-compat-entry-attribute: gidNumber=%{gidNumber} default:schema-compat-entry-attribute: loginShell=%{loginShell} default:schema-compat-entry-attribute: homeDirectory=%{homeDirectory} +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","") +default:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} +default:schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") dn: cn=groups, cn=Schema Compatibility, cn=plugins, cn=config default:objectClass: top @@ -52,6 +56,10 @@ default:schema-compat-entry-attribute: objectclass=posixGroup default:schema-compat-entry-attribute: gidNumber=%{gidNumber} default:schema-compat-entry-attribute: memberUid=%{memberUid} default:schema-compat-entry-attribute: memberUid=%deref_r("member","uid") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","") +default:schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","") +default:schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} +default:schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","") dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config add:objectClass: top diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update index aeddadb..e88b492 100644 --- a/install/updates/10-schema_compat.update +++ b/install/updates/10-schema_compat.update @@ -47,3 +47,15 @@ dn: cn=Schema Compatibility,cn=plugins,cn=config # rewritten to the original entry if needed add:nsslapd-pluginprecedence: 49 +dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","")' +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","")' +add:schema-compat-entry-attribute: 'ipaanchoruuid=%{ipaanchoruuid}' +add:schema-compat-entry-attribute: '%ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","")' + +dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","objectclass=ipaOverrideTarget","")' +add:schema-compat-entry-attribute: '%ifeq("ipauniqueid","%{ipauniqueid}","ipaanchoruuid=:IPA:$DOMAIN:%{ipauniqueid}","")' +add:schema-compat-entry-attribute: 'ipaanchoruuid=%{ipaanchoruuid}' +add:schema-compat-entry-attribute: '%ifeq("ipaanchoruuid","%{ipaanchoruuid}","objectclass=ipaOverrideTarget","")' + diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py index 9c2e308..03e6893 100644 --- a/ipalib/plugins/group.py +++ b/ipalib/plugins/group.py @@ -212,6 +212,16 @@ class group(LDAPObject): 'objectclass', 'cn', 'memberuid', 'gidnumber', }, }, + 'System: Read Group Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=groups', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'cn', 'memberuid', 'gidnumber', + }, + }, } label = _('User Groups') diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index f95b4fd..e206289 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -435,6 +435,17 @@ class user(LDAPObject): 'homedirectory', 'loginshell', }, }, + 'System: Read User Views Compat Tree': { + 'non_object': True, + 'ipapermbindruletype': 'anonymous', + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=users', 'cn=*', 'cn=views', 'cn=compat', api.env.basedn), + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'objectclass', 'uid', 'cn', 'gecos', 'gidnumber', 'uidnumber', + 'homedirectory', 'loginshell', + }, + }, } label = _('Users') diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py index df49d5d..032485a 100644 --- a/ipaserver/install/plugins/update_managed_permissions.py +++ b/ipaserver/install/plugins/update_managed_permissions.py @@ -117,6 +117,17 @@ NONOBJECT_PERMISSIONS = { }, 'default_privileges': {'IPA Masters Readers'}, }, + 'System: Compat Tree ID View targets': { + 'replaces_global_anonymous_aci': True, + 'ipapermlocation': api.env.basedn, + 'ipapermtarget': DN('cn=*,cn=compat', api.env.basedn), + 'ipapermtargetfilter': {'(objectclass=ipaOverrideTarget)'}, + 'ipapermbindruletype': 'anonymous', + 'ipapermright': {'read', 'search', 'compare'}, + 'ipapermdefaultattr': { + 'ipaAnchorUUID', + }, + }, 'System: Read DNA Configuration': { 'replaces_global_anonymous_aci': True, 'ipapermlocation': DN('cn=dna,cn=ipa,cn=etc', api.env.basedn), -- 2.1.0 -------------- next part -------------- From 6855012f03490188a3d4d188f028b1e54fc37858 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 30 Sep 2014 15:44:31 +0300 Subject: [PATCH 3/6] Support overridding user shell in ID views --- ACI.txt | 2 +- API.txt | 9 ++++++--- ipalib/plugins/idviews.py | 8 ++++++-- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/ACI.txt b/ACI.txt index 87c057e..b2192ce 100644 --- a/ACI.txt +++ b/ACI.txt @@ -123,7 +123,7 @@ aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:S dn: cn=views,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || entryusn || gidnumber || ipaanchoruuid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System: Read Group ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "createtimestamp || description || entryusn || homedirectory || ipaanchoruuid || ipaoriginaluid || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "createtimestamp || description || entryusn || homedirectory || ipaanchoruuid || ipaoriginaluid || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ranges,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipabaseid || ipabaserid || ipaidrangesize || ipanttrusteddomainsid || iparangetype || ipasecondarybaserid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaidrange)")(version 3.0;acl "permission:System: Read ID Ranges";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index c5e76c7..41b852b 100644 --- a/API.txt +++ b/API.txt @@ -2104,7 +2104,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,10,3 +args: 2,11,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2112,6 +2112,7 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') option: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', required=False) @@ -2130,7 +2131,7 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: idoverrideuser_find -args: 2,12,4 +args: 2,13,4 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') @@ -2138,6 +2139,7 @@ option: Str('description', attribute=True, autofill=False, cli_name='desc', mult option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, query=True, required=False) option: Str('ipaanchoruuid', attribute=True, autofill=False, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, query=True, required=False) +option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Int('sizelimit?', autofill=False, minvalue=0) @@ -2150,7 +2152,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,13,3 +args: 2,14,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2159,6 +2161,7 @@ option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) option: Flag('rights', autofill=True, default=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index 3b0df02..afaa6f9 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -650,14 +650,14 @@ class idoverrideuser(baseidoverride): 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { 'objectClass', 'ipaAnchorUUID', 'uidNumber', 'description', - 'homeDirectory', 'uid', 'ipaOriginalUid', + 'homeDirectory', 'uid', 'ipaOriginalUid', 'loginShell', }, }, } object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ - 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', + 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', ] takes_params = baseidoverride.takes_params + ( @@ -679,6 +679,10 @@ class idoverrideuser(baseidoverride): cli_name='homedir', label=_('Home directory'), ), + Str('loginshell?', + cli_name='shell', + label=_('Login shell'), + ), Str('ipaoriginaluid?', flags=['no_option', 'no_output'] ), -- 2.1.0 -------------- next part -------------- From d9006d1ec317d2c01ee9adad8e2e06c5afbf91fd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 10 Oct 2014 09:26:13 +0300 Subject: [PATCH 4/9] Allow user overrides to specify SSH public keys Overrides for users can have SSH public keys. This, however, will not enable SSH public keys from overrides to be actually used until SSSD gets fixed to pull them in. SSSD ticket for SSH public keys in overrides: https://fedorahosted.org/sssd/ticket/2454 Resolves https://fedorahosted.org/freeipa/ticket/4509 --- API.txt | 6 ++++-- ipalib/plugins/idviews.py | 35 +++++++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 2 deletions(-) diff --git a/API.txt b/API.txt index 41b852b..5316ac2 100644 --- a/API.txt +++ b/API.txt @@ -2104,7 +2104,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,11,3 +args: 2,12,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2112,6 +2112,7 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('ipasshpubkey', attribute=True, cli_name='sshpubkey', csv=True, multivalue=True, required=False) option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') @@ -2152,7 +2153,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,14,3 +args: 2,15,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2161,6 +2162,7 @@ option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('ipasshpubkey', attribute=True, autofill=False, cli_name='sshpubkey', csv=True, multivalue=True, required=False) option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index afaa6f9..95bf23a 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -25,6 +25,8 @@ from ipalib.plugins.hostgroup import get_complete_hostgroup_member_list from ipalib import api, Str, Int, Flag, _, ngettext, errors, output from ipalib.constants import IPA_ANCHOR_PREFIX, SID_ANCHOR_PREFIX from ipalib.plugable import Registry +from ipalib.util import (normalize_sshpubkey, validate_sshpubkey, + convert_sshpubkey_post) from ipapython.dn import DN @@ -658,6 +660,7 @@ class idoverrideuser(baseidoverride): object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', + 'ipaSshPubkey', ] takes_params = baseidoverride.takes_params + ( @@ -686,6 +689,13 @@ class idoverrideuser(baseidoverride): Str('ipaoriginaluid?', flags=['no_option', 'no_output'] ), + Str('ipasshpubkey*', validate_sshpubkey, + cli_name='sshpubkey', + label=_('SSH public key'), + normalizer=normalize_sshpubkey, + csv=True, + flags=['no_search'], + ), ) override_object = 'user' @@ -758,6 +768,11 @@ class idoverrideuser_add(baseidoverride_add): self.obj.update_original_uid_reference(entry_attrs) return dn + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + convert_sshpubkey_post(ldap, dn, entry_attrs) + return dn + + @register() class idoverrideuser_del(baseidoverride_del): @@ -777,6 +792,18 @@ class idoverrideuser_mod(baseidoverride_mod): # Update the ipaOriginalUid self.obj.set_anchoruuid_from_dn(dn, entry_attrs) self.obj.update_original_uid_reference(entry_attrs) + if 'objectclass' in entry_attrs: + obj_classes = entry_attrs['objectclass'] + else: + _entry_attrs = ldap.get_entry(dn, ['objectclass']) + obj_classes = entry_attrs['objectclass'] = _entry_attrs['objectclass'] + + if 'ipasshpubkey' in entry_attrs and 'ipasshuser' not in obj_classes: + obj_classes.append('ipasshuser') + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + convert_sshpubkey_post(ldap, dn, entry_attrs) return dn @@ -786,11 +813,19 @@ class idoverrideuser_find(baseidoverride_find): msg_summary = ngettext('%(count)d User ID override matched', '%(count)d User ID overrides matched', 0) + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + convert_sshpubkey_post(ldap, dn, entry_attrs) + return dn + @register() class idoverrideuser_show(baseidoverride_show): __doc__ = _('Display information about an User ID override.') + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + convert_sshpubkey_post(ldap, dn, entry_attrs) + return dn + @register() class idoverridegroup_add(baseidoverride_add): -- 2.1.0 -------------- next part -------------- From 1ef2aa69defc5228c97d6d886c28fcc4a26dee37 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 10 Oct 2014 09:30:51 +0300 Subject: [PATCH 5/9] Allow user overrides to specify GID of the user Resolves https://fedorahosted.org/freeipa/ticket/4617 --- API.txt | 9 ++++++--- ipalib/plugins/idviews.py | 7 ++++++- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/API.txt b/API.txt index 5316ac2..ea5d6fe 100644 --- a/API.txt +++ b/API.txt @@ -2104,12 +2104,13 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,12,3 +args: 2,13,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Int('gidnumber', attribute=True, cli_name='gidnumber', minvalue=1, multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) option: Str('ipasshpubkey', attribute=True, cli_name='sshpubkey', csv=True, multivalue=True, required=False) @@ -2132,11 +2133,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: idoverrideuser_find -args: 2,13,4 +args: 2,14,4 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Int('gidnumber', attribute=True, autofill=False, cli_name='gidnumber', minvalue=1, multivalue=False, query=True, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, query=True, required=False) option: Str('ipaanchoruuid', attribute=True, autofill=False, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, query=True, required=False) @@ -2153,13 +2155,14 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,15,3 +args: 2,16,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Int('gidnumber', attribute=True, autofill=False, cli_name='gidnumber', minvalue=1, multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) option: Str('ipasshpubkey', attribute=True, autofill=False, cli_name='sshpubkey', csv=True, multivalue=True, required=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index 95bf23a..cbf78c1 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -660,7 +660,7 @@ class idoverrideuser(baseidoverride): object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', - 'ipaSshPubkey', + 'ipaSshPubkey', 'gidNumber', ] takes_params = baseidoverride.takes_params + ( @@ -678,6 +678,11 @@ class idoverrideuser(baseidoverride): doc=_('User ID Number'), minvalue=1, ), + Int('gidnumber?', + label=_('GID'), + doc=_('Group ID Number'), + minvalue=1, + ), Str('homedirectory?', cli_name='homedir', label=_('Home directory'), -- 2.1.0 -------------- next part -------------- From fde7c592afb10b91ff6971eaaae1b41e5d44acca Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 10 Oct 2014 16:52:41 +0300 Subject: [PATCH 7/9] Update API version for ID views support --- VERSION | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/VERSION b/VERSION index 78ef7d8..24a6a5e 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=104 -# Last change: mbasti - autofill --admin-email in DNS zone +IPA_API_VERSION_MINOR=105 +# Last change: abbra - ID views attributes -- 2.1.0 -------------- next part -------------- From 3163cffb5c1f7f530cdee4ac6eac418df78fa1d8 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 10 Oct 2014 16:54:34 +0300 Subject: [PATCH 8/9] Require slapi-nis 0.54 or later for ID views support --- freeipa.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index a52a1d1..30ffb89 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -126,7 +126,7 @@ Requires(pre): systemd-units Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base -Requires: slapi-nis >= 0.47.7 +Requires: slapi-nis >= 0.54-1 Requires: pki-ca >= 10.2.0 Requires: pki-kra >= 10.2.0 %if 0%{?rhel} -- 2.1.0 -------------- next part -------------- From 240f859a91f0aeb7612e2986536c22b415547499 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 10 Oct 2014 16:44:47 +0300 Subject: [PATCH 6/9] Allow override of gecos field in ID views --- ACI.txt | 2 +- API.txt | 9 ++++++--- ipalib/plugins/idviews.py | 7 +++++-- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/ACI.txt b/ACI.txt index b2192ce..98e1143 100644 --- a/ACI.txt +++ b/ACI.txt @@ -123,7 +123,7 @@ aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:S dn: cn=views,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || entryusn || gidnumber || ipaanchoruuid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System: Read Group ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "createtimestamp || description || entryusn || homedirectory || ipaanchoruuid || ipaoriginaluid || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "createtimestamp || description || entryusn || gecos || homedirectory || ipaanchoruuid || ipaoriginaluid || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ranges,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipabaseid || ipabaserid || ipaidrangesize || ipanttrusteddomainsid || iparangetype || ipasecondarybaserid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaidrange)")(version 3.0;acl "permission:System: Read ID Ranges";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example diff --git a/API.txt b/API.txt index ea5d6fe..1af7850 100644 --- a/API.txt +++ b/API.txt @@ -2104,12 +2104,13 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,13,3 +args: 2,14,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('gecos', attribute=True, cli_name='gecos', multivalue=False, required=False) option: Int('gidnumber', attribute=True, cli_name='gidnumber', minvalue=1, multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) @@ -2133,11 +2134,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: idoverrideuser_find -args: 2,14,4 +args: 2,15,4 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('gecos', attribute=True, autofill=False, cli_name='gecos', multivalue=False, query=True, required=False) option: Int('gidnumber', attribute=True, autofill=False, cli_name='gidnumber', minvalue=1, multivalue=False, query=True, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, query=True, required=False) option: Str('ipaanchoruuid', attribute=True, autofill=False, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=False) @@ -2155,13 +2157,14 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,16,3 +args: 2,17,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('gecos', attribute=True, autofill=False, cli_name='gecos', multivalue=False, required=False) option: Int('gidnumber', attribute=True, autofill=False, cli_name='gidnumber', minvalue=1, multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index cbf78c1..b55a78e 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -652,7 +652,7 @@ class idoverrideuser(baseidoverride): 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { 'objectClass', 'ipaAnchorUUID', 'uidNumber', 'description', - 'homeDirectory', 'uid', 'ipaOriginalUid', 'loginShell', + 'homeDirectory', 'uid', 'ipaOriginalUid', 'loginShell', 'gecos', }, }, } @@ -660,7 +660,7 @@ class idoverrideuser(baseidoverride): object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', - 'ipaSshPubkey', 'gidNumber', + 'ipaSshPubkey', 'gidNumber', 'gecos', ] takes_params = baseidoverride.takes_params + ( @@ -678,6 +678,9 @@ class idoverrideuser(baseidoverride): doc=_('User ID Number'), minvalue=1, ), + Str('gecos?', + label=_('GECOS'), + ), Int('gidnumber?', label=_('GID'), doc=_('Group ID Number'), -- 2.1.0 From lkrispen at redhat.com Fri Oct 10 14:38:30 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 10 Oct 2014 16:38:30 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5437E621.2000302@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> Message-ID: <5437EF66.7090201@redhat.com> On 10/10/2014 03:58 PM, thierry bordaz wrote: > On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: >> On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: >>> On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: >>> >>>> On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: >>>>> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >>>>>>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >>>>>>> >>>>>>>> The background of this email is this bug: >>>>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>>>> >>>>>>>> Attached are two patches which solve this issue for admin users (not >>>>>>>> very helpful, I know). They depend on this fix in 389: >>>>>>>> https://fedorahosted.org/389/ticket/47920 >>>>>>>> >>>>>>>> There are two outstanding issues: >>>>>>>> >>>>>>>> 1. 389 does not send the post read control for normal users. The >>>>>>>> operation itself succeeds, but no control is sent. >>>>>>>> >>>>>>>> The relevant sections from the log are attached. 389 is denying access >>>>>>>> to the following attributes (* = valid, ! = invalid): >>>>>>>> ! objectClass >>>>>>>> ! ipatokenOTPalgorithm >>>>>>>> ! ipatokenOTPdigits >>>>>>>> * ipatokenOTPkey >>>>>>>> * ipatokenHOTPcounter >>>>>>>> ! ipatokenOwner >>>>>>>> ! managedBy >>>>>>>> ! ipatokenUniqueID >>>>>>> Hello Nathaniel, >>>>>>> >>>>>>> The post read control needs access to the modified entry to >>>>>>> return it. >>>>>>> This access is granted at the condition, the binddn can access >>>>>>> attributes. >>>>>> Agreed and understood. >>>>>> >>>>>>> My understanding is that the target entry is >>>>>>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". >>>>>> Correct. >>>>>> >>>>>>> The only ACI I found that match this target is: >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)") >>>>>>> (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled >>>>>>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") >>>>>>> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>> Correct. >>>>>> >>>>>>> Do you know if the target entry has 'ipatokenOwner' or >>>>>>> 'managedBy' with the binddn value ? >>>>>> Yes, both. So why is access to objectClass (et cetera) being denied? >>>>> Good question... I will try to reproduce >>>> Thanks! >>> Hello, >>> >>> I tried to reproduce and it seems to work on *master*. >>> I am using the attached ldif file. >>> The test case is to bind as "cn=active >>> guy,cn=accounts,dc=example,dc=com" and to do a modify on >>> "cn=active otp,cn=otp,dc=example,dc=com". >>> >>> The modify updates the 'description' attribute and do a >>> postread (description, cn). >>> >>> The write 'description' is allowed by : >>> dn: cn=otp,dc=example,dc=com >>> aci: (targetfilter = >>> "(objectclass=organizationalPerson)")(target = >>> "ldap:///c >>> n=*,cn=otp,dc=example,dc=com")(targetattr = >>> "objectclass || description || se >>> eAlso")(version 3.0; acl "Active user modify otp >>> entry"; allow (write) userdn >>> ="ldap:///cn=active >>> guy,cn=accounts,dc=example,dc=com";) >>> >>> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. >>> Evaluating ALLOW aci(19) " "Active user modify otp >>> entry"" >>> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 >>> op=16 (main): Allow write on entry(cn=active >>> otp,cn=otp,dc=example,dc=com).attr(description) to >>> cn=active guy,cn=accounts,dc=example,dc=com: allowed >>> by aci(19): aciname= "Active user modify otp entry", >>> acidn="cn=otp,dc=example,dc=com" >>> >>> >>> The postread is allowed by: >>> dn: cn=otp,dc=example,dc=com >>> aci: (targetfilter = >>> "(objectclass=organizationalPerson)") (targetattr = >>> "obje >>> ctclass || description || seeAlso || cn")(version >>> 3.0; acl "Active user can r >>> ead his entries"; allow (read, search, compare) >>> userattr = "seeAlso#USERDN";) >>> >>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. >>> Evaluating ALLOW aci(21) " "Active user can read his >>> entries"" >>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ >>> ALLOW in cache >>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 >>> op=16 (main): Allow read on entry(cn=active >>> otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active >>> guy,cn=accounts,dc=example,dc=com: cached allow by >>> aci(21) >>> >>> The postread works if I use USERDN or SELFDN. >>> >>> Please let me know the version of 389-ds that you are testing, >>> I will try on that branch >> That is not really the same test at all. >> >> 1. Install FreeIPA from F21 @ example.com >> 2. Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com >> -W -e postread=* <> dn: ipatokenuniqueid=foo,cn=otp,dc=example,dc=com >> changetype: add >> objectClass: top >> objectClass: ipaToken >> objectClass: ipaTokenHOTP >> ipatokenUniqueID: foo >> ipatokenOTPalgorithm: sha1 >> ipatokenOTPdigits: 6 >> ipatokenOTPkey: 00000000 >> ipatokenHOTPcounter: 0 >> ipatokenOwner: uid=admin,cn=users,cn=accounts,dc=example,dc=com >> managedBy: uid=admin,cn=users,cn=accounts,dc=example,dc=com >> EOF >> >> 3. Create a regular user named 'otp' >> 4. Execute: ldapadd -D uid=otp,cn=users,cn=accounts,dc=example,dc=com -W >> -e postread=* <> dn: ipatokenuniqueid=bar,cn=otp,dc=example,dc=com >> changetype: add >> objectClass: top >> objectClass: ipaToken >> objectClass: ipaTokenHOTP >> ipatokenUniqueID: bar >> ipatokenOTPalgorithm: sha1 >> ipatokenOTPdigits: 6 >> ipatokenOTPkey: 00000000 >> ipatokenHOTPcounter: 0 >> ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com >> managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com >> EOF >> >> RESULTS: >> Step 2 will add the token and return the post read control. Step 4 will >> add the token, but will NOT return the post read control. >> >> > Hi Nathaniel, > > Thanks for the detailed procedure I was able to reproduce the problem: > > In fact during the step for, the add is successful but the found > ACIs do no grant access to the target entry: > > [09/Oct/2014:21:34:58 -0400] conn=29 fd=82 slot=82 SSL > connection from 10.16.78.124 to 10.16.78.124 > [09/Oct/2014:21:34:58 -0400] conn=29 SSL 128-bit AES > [09/Oct/2014:21:34:58 -0400] conn=29 op=0 BIND > dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" method=128 > version=3 > [09/Oct/2014:21:34:58 -0400] conn=29 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 > dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" > [09/Oct/2014:21:34:58 -0400] conn=29 op=1 ADD > dn="ipatokenuniqueid=bar,cn=otp,dc=example,dc=com" > [09/Oct/2014:21:34:59 -0400] conn=29 op=2 UNBIND > [09/Oct/2014:21:34:59 -0400] conn=29 op=2 fd=82 closed - U1 > [09/Oct/2014:21:34:59 -0400] conn=29 op=1 RESULT *err=0* > tag=105 nentries=0 etime=1 > > The add was granted because of "Users can create self-managed tokens" > > > [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 > (main): Allow add on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(NULL) to > uid=otp,cn=users,cn=accounts,dc=example,dc=com: allowed by > aci(16): aciname= "Users can create self-managed tokens", > acidn="dc=example,dc=com" > > Now the postread control was not granted for any of the attribute > of the entry: > > [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*objectClass*) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenUniqueID*) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPalgorithm*) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPdigits*) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPkey*) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenHOTPcounter*) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOwner*) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*managedBy*) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > > Each time the correct aci was selectionned: > > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > "objectclass || d > escription || managedBy || ipatokenUniqueID || > ipatokenDisabled || ipatokenNo > tBefore || ipatokenNotAfter || ipatokenVendor || > ipatokenModel || ipatokenSer > ial || ipatokenOwner")(version 3.0; acl "*Users/managers can > read basic token* > info"; allow (read, search, compare) userattr = > "ipatokenOwner#USERDN" or use > rattr = "managedBy#USERDN";) > > ... > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed > attr:managedBy for > entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating ALLOW > aci(11) " "*Users/managers can read basic token info*"" > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in > cache > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating ALLOW > aci(19) " "Admin can manage any entry"" > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in > cache > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 > (main): Deny read on > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) > to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci > matched the subject by aci(19): aciname= "Admin can manage any > entry", acidn="dc=example,dc=com" > [09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: > access to entry not allowed > (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) > > But for some reason, it evaluations of the READ access was not > accepted. > the key is READ SKIP, looks like it is using cached evaluation of the acis, where the aci did not apply. aci caching is .... > > > Did you already open a ticket for this problem ? > > thanks > thierry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Oct 10 14:38:18 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Oct 2014 17:38:18 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <5437E820.1090303@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> <20141010133645.GC2328@redhat.com> <5437E820.1090303@redhat.com> Message-ID: <20141010143818.GE2328@redhat.com> On Fri, 10 Oct 2014, Petr Vobornik wrote: > On 10.10.2014 15:36, Alexander Bokovoy wrote: >> On Fri, 10 Oct 2014, Petr Vobornik wrote: >>> On 10.10.2014 10:39, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> I'm resending patches 0159 and 0160, and adding two more: >>>> >>>> 0161 -- support user SSH public keys in ID view user overrides >>>> 0162 -- support gidNumber in ID view user override >>>> >>>> SSH public keys to work require support from SSSD and that one is >>>> currently missing. At least, one add/remove the keys to/from the >>>> override objects. >>>> >>>> Compat tree does not support exporting SSH keys. When accessing the tree >>>> anonymously, the entry will be filtered out by ACIs but for >>>> authenticated users we need to explicitly ignore ipaSshPubKey attribute >>>> in the override, so I'm resending updated slapi-nis patch that only >>>> adds one more attribute to filter out. >>>> >>> >>> I'm going to prepare Web UI for, 160, 161, 162. >>> >>> Q: ipaUserOverride object class contains also 'gecos' attribute. Will >>> it be handled be CLI and Web UI as well? >> I'll add another patch for that. >> >>> >>> Comments for these 3 patches: >>> >>> 1. VERSION was not bumped >>> >>> Patch 160: >>> Apart form #1, is OK (not sure if #1 is needed for ACK) >> I wonder if I should bump it in a separate patch that would be the last >> one in the series, to avoid proliferation of API version numbers? :) > > IMHO it should be sufficient. Same outcome as if the patches were squashed. Yep. One more update for patch 0161, Petr noticed we need to call super post_callback() too. -- / Alexander Bokovoy -------------- next part -------------- From bc7eb4c53424412b5488068b49a80f2922f078ab Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 10 Oct 2014 09:26:13 +0300 Subject: [PATCH 4/9] Allow user overrides to specify SSH public keys Overrides for users can have SSH public keys. This, however, will not enable SSH public keys from overrides to be actually used until SSSD gets fixed to pull them in. SSSD ticket for SSH public keys in overrides: https://fedorahosted.org/sssd/ticket/2454 Resolves https://fedorahosted.org/freeipa/ticket/4509 --- API.txt | 6 ++++-- ipalib/plugins/idviews.py | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+), 2 deletions(-) diff --git a/API.txt b/API.txt index 41b852b..5316ac2 100644 --- a/API.txt +++ b/API.txt @@ -2104,7 +2104,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: idoverrideuser_add -args: 2,11,3 +args: 2,12,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2112,6 +2112,7 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('ipasshpubkey', attribute=True, cli_name='sshpubkey', csv=True, multivalue=True, required=False) option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') @@ -2152,7 +2153,7 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: idoverrideuser_mod -args: 2,14,3 +args: 2,15,3 arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True) arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') @@ -2161,6 +2162,7 @@ option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) option: Str('homedirectory', attribute=True, autofill=False, cli_name='homedir', multivalue=False, required=False) option: Str('ipaoriginaluid', attribute=True, autofill=False, cli_name='ipaoriginaluid', multivalue=False, required=False) +option: Str('ipasshpubkey', attribute=True, autofill=False, cli_name='sshpubkey', csv=True, multivalue=True, required=False) option: Str('loginshell', attribute=True, autofill=False, cli_name='shell', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('rename', cli_name='rename', multivalue=False, primary_key=True, required=False) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index afaa6f9..d63a12a 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -25,6 +25,8 @@ from ipalib.plugins.hostgroup import get_complete_hostgroup_member_list from ipalib import api, Str, Int, Flag, _, ngettext, errors, output from ipalib.constants import IPA_ANCHOR_PREFIX, SID_ANCHOR_PREFIX from ipalib.plugable import Registry +from ipalib.util import (normalize_sshpubkey, validate_sshpubkey, + convert_sshpubkey_post) from ipapython.dn import DN @@ -658,6 +660,7 @@ class idoverrideuser(baseidoverride): object_class = baseidoverride.object_class + ['ipaUserOverride'] default_attributes = baseidoverride.default_attributes + [ 'homeDirectory', 'uidNumber', 'uid', 'ipaOriginalUid', 'loginShell', + 'ipaSshPubkey', ] takes_params = baseidoverride.takes_params + ( @@ -686,6 +689,13 @@ class idoverrideuser(baseidoverride): Str('ipaoriginaluid?', flags=['no_option', 'no_output'] ), + Str('ipasshpubkey*', validate_sshpubkey, + cli_name='sshpubkey', + label=_('SSH public key'), + normalizer=normalize_sshpubkey, + csv=True, + flags=['no_search'], + ), ) override_object = 'user' @@ -758,6 +768,13 @@ class idoverrideuser_add(baseidoverride_add): self.obj.update_original_uid_reference(entry_attrs) return dn + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + dn = super(idoverrideuser_add, self).post_callback(ldap, dn, + entry_attrs, *keys, **options) + convert_sshpubkey_post(ldap, dn, entry_attrs) + return dn + + @register() class idoverrideuser_del(baseidoverride_del): @@ -777,6 +794,20 @@ class idoverrideuser_mod(baseidoverride_mod): # Update the ipaOriginalUid self.obj.set_anchoruuid_from_dn(dn, entry_attrs) self.obj.update_original_uid_reference(entry_attrs) + if 'objectclass' in entry_attrs: + obj_classes = entry_attrs['objectclass'] + else: + _entry_attrs = ldap.get_entry(dn, ['objectclass']) + obj_classes = entry_attrs['objectclass'] = _entry_attrs['objectclass'] + + if 'ipasshpubkey' in entry_attrs and 'ipasshuser' not in obj_classes: + obj_classes.append('ipasshuser') + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + dn = super(idoverrideuser_mod, self).post_callback(ldap, dn, + entry_attrs, *keys, **options) + convert_sshpubkey_post(ldap, dn, entry_attrs) return dn @@ -786,11 +817,23 @@ class idoverrideuser_find(baseidoverride_find): msg_summary = ngettext('%(count)d User ID override matched', '%(count)d User ID overrides matched', 0) + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + dn = super(idoverrideuser_find, self).post_callback(ldap, dn, + entry_attrs, *keys, **options) + convert_sshpubkey_post(ldap, dn, entry_attrs) + return dn + @register() class idoverrideuser_show(baseidoverride_show): __doc__ = _('Display information about an User ID override.') + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + dn = super(idoverrideuser_show, self).post_callback(ldap, dn, + entry_attrs, *keys, **options) + convert_sshpubkey_post(ldap, dn, entry_attrs) + return dn + @register() class idoverridegroup_add(baseidoverride_add): -- 2.1.0 From tbordaz at redhat.com Fri Oct 10 15:16:05 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 10 Oct 2014 17:16:05 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5437EF66.7090201@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> <5437EF66.7090201@redhat.com> Message-ID: <5437F835.3000000@redhat.com> On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: > > On 10/10/2014 03:58 PM, thierry bordaz wrote: >> On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: >>>> On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: >>>> >>>>> On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: >>>>>> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: >>>>>>> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >>>>>>>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >>>>>>>> >>>>>>>>> The background of this email is this bug: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>>>>> >>>>>>>>> Attached are two patches which solve this issue for admin users (not >>>>>>>>> very helpful, I know). They depend on this fix in 389: >>>>>>>>> https://fedorahosted.org/389/ticket/47920 >>>>>>>>> >>>>>>>>> There are two outstanding issues: >>>>>>>>> >>>>>>>>> 1. 389 does not send the post read control for normal users. The >>>>>>>>> operation itself succeeds, but no control is sent. >>>>>>>>> >>>>>>>>> The relevant sections from the log are attached. 389 is denying access >>>>>>>>> to the following attributes (* = valid, ! = invalid): >>>>>>>>> ! objectClass >>>>>>>>> ! ipatokenOTPalgorithm >>>>>>>>> ! ipatokenOTPdigits >>>>>>>>> * ipatokenOTPkey >>>>>>>>> * ipatokenHOTPcounter >>>>>>>>> ! ipatokenOwner >>>>>>>>> ! managedBy >>>>>>>>> ! ipatokenUniqueID >>>>>>>> Hello Nathaniel, >>>>>>>> >>>>>>>> The post read control needs access to the modified entry to >>>>>>>> return it. >>>>>>>> This access is granted at the condition, the binddn can access >>>>>>>> attributes. >>>>>>> Agreed and understood. >>>>>>> >>>>>>>> My understanding is that the target entry is >>>>>>>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". >>>>>>> Correct. >>>>>>> >>>>>>>> The only ACI I found that match this target is: >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)") >>>>>>>> (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled >>>>>>>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") >>>>>>>> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>>> Correct. >>>>>>> >>>>>>>> Do you know if the target entry has 'ipatokenOwner' or >>>>>>>> 'managedBy' with the binddn value ? >>>>>>> Yes, both. So why is access to objectClass (et cetera) being denied? >>>>>> Good question... I will try to reproduce >>>>> Thanks! >>>> Hello, >>>> >>>> I tried to reproduce and it seems to work on *master*. >>>> I am using the attached ldif file. >>>> The test case is to bind as "cn=active >>>> guy,cn=accounts,dc=example,dc=com" and to do a modify on >>>> "cn=active otp,cn=otp,dc=example,dc=com". >>>> >>>> The modify updates the 'description' attribute and do a >>>> postread (description, cn). >>>> >>>> The write 'description' is allowed by : >>>> dn: cn=otp,dc=example,dc=com >>>> aci: (targetfilter = >>>> "(objectclass=organizationalPerson)")(target = >>>> "ldap:///c >>>> n=*,cn=otp,dc=example,dc=com")(targetattr = >>>> "objectclass || description || se >>>> eAlso")(version 3.0; acl "Active user modify otp >>>> entry"; allow (write) userdn >>>> ="ldap:///cn=active >>>> guy,cn=accounts,dc=example,dc=com";) >>>> >>>> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. >>>> Evaluating ALLOW aci(19) " "Active user modify otp >>>> entry"" >>>> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 >>>> op=16 (main): Allow write on entry(cn=active >>>> otp,cn=otp,dc=example,dc=com).attr(description) to >>>> cn=active guy,cn=accounts,dc=example,dc=com: allowed >>>> by aci(19): aciname= "Active user modify otp entry", >>>> acidn="cn=otp,dc=example,dc=com" >>>> >>>> >>>> The postread is allowed by: >>>> dn: cn=otp,dc=example,dc=com >>>> aci: (targetfilter = >>>> "(objectclass=organizationalPerson)") (targetattr = >>>> "obje >>>> ctclass || description || seeAlso || cn")(version >>>> 3.0; acl "Active user can r >>>> ead his entries"; allow (read, search, compare) >>>> userattr = "seeAlso#USERDN";) >>>> >>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. >>>> Evaluating ALLOW aci(21) " "Active user can read his >>>> entries"" >>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ >>>> ALLOW in cache >>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 >>>> op=16 (main): Allow read on entry(cn=active >>>> otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active >>>> guy,cn=accounts,dc=example,dc=com: cached allow by >>>> aci(21) >>>> >>>> The postread works if I use USERDN or SELFDN. >>>> >>>> Please let me know the version of 389-ds that you are testing, >>>> I will try on that branch >>> That is not really the same test at all. >>> >>> 1. Install FreeIPA from F21 @ example.com >>> 2. Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com >>> -W -e postread=* <>> dn: ipatokenuniqueid=foo,cn=otp,dc=example,dc=com >>> changetype: add >>> objectClass: top >>> objectClass: ipaToken >>> objectClass: ipaTokenHOTP >>> ipatokenUniqueID: foo >>> ipatokenOTPalgorithm: sha1 >>> ipatokenOTPdigits: 6 >>> ipatokenOTPkey: 00000000 >>> ipatokenHOTPcounter: 0 >>> ipatokenOwner: uid=admin,cn=users,cn=accounts,dc=example,dc=com >>> managedBy: uid=admin,cn=users,cn=accounts,dc=example,dc=com >>> EOF >>> >>> 3. Create a regular user named 'otp' >>> 4. Execute: ldapadd -D uid=otp,cn=users,cn=accounts,dc=example,dc=com -W >>> -e postread=* <>> dn: ipatokenuniqueid=bar,cn=otp,dc=example,dc=com >>> changetype: add >>> objectClass: top >>> objectClass: ipaToken >>> objectClass: ipaTokenHOTP >>> ipatokenUniqueID: bar >>> ipatokenOTPalgorithm: sha1 >>> ipatokenOTPdigits: 6 >>> ipatokenOTPkey: 00000000 >>> ipatokenHOTPcounter: 0 >>> ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com >>> managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com >>> EOF >>> >>> RESULTS: >>> Step 2 will add the token and return the post read control. Step 4 will >>> add the token, but will NOT return the post read control. >>> >>> >> Hi Nathaniel, >> >> Thanks for the detailed procedure I was able to reproduce the >> problem: >> >> In fact during the step for, the add is successful but the found >> ACIs do no grant access to the target entry: >> >> [09/Oct/2014:21:34:58 -0400] conn=29 fd=82 slot=82 SSL >> connection from 10.16.78.124 to 10.16.78.124 >> [09/Oct/2014:21:34:58 -0400] conn=29 SSL 128-bit AES >> [09/Oct/2014:21:34:58 -0400] conn=29 op=0 BIND >> dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" >> method=128 version=3 >> [09/Oct/2014:21:34:58 -0400] conn=29 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 >> dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" >> [09/Oct/2014:21:34:58 -0400] conn=29 op=1 ADD >> dn="ipatokenuniqueid=bar,cn=otp,dc=example,dc=com" >> [09/Oct/2014:21:34:59 -0400] conn=29 op=2 UNBIND >> [09/Oct/2014:21:34:59 -0400] conn=29 op=2 fd=82 closed - U1 >> [09/Oct/2014:21:34:59 -0400] conn=29 op=1 RESULT *err=0* >> tag=105 nentries=0 etime=1 >> >> The add was granted because of "Users can create self-managed tokens" >> >> >> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >> (main): Allow add on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(NULL) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: allowed by >> aci(16): aciname= "Users can create self-managed tokens", >> acidn="dc=example,dc=com" >> >> Now the postread control was not granted for any of the attribute >> of the entry: >> >> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*objectClass*) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenUniqueID*) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPalgorithm*) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPdigits*) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPkey*) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenHOTPcounter*) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOwner*) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*managedBy*) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> >> Each time the correct aci was selectionned: >> >> >> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >> "objectclass || d >> escription || managedBy || ipatokenUniqueID || >> ipatokenDisabled || ipatokenNo >> tBefore || ipatokenNotAfter || ipatokenVendor || >> ipatokenModel || ipatokenSer >> ial || ipatokenOwner")(version 3.0; acl "*Users/managers can >> read basic token* >> info"; allow (read, search, compare) userattr = >> "ipatokenOwner#USERDN" or use >> rattr = "managedBy#USERDN";) >> >> ... >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed >> attr:managedBy for >> entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating >> ALLOW aci(11) " "*Users/managers can read basic token info*"" >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in >> cache >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating >> ALLOW aci(19) " "Admin can manage any entry"" >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in >> cache >> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >> (main): Deny read on >> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) >> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >> matched the subject by aci(19): aciname= "Admin can manage >> any entry", acidn="dc=example,dc=com" >> [09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: >> access to entry not allowed >> (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) >> >> But for some reason, it evaluations of the READ access was not >> accepted. >> > the key is READ SKIP, looks like it is using cached evaluation of the > acis, where the aci did not apply. aci caching is .... Exact. Now If I create two entries x/y and their associated ipatoken tokenX/tokenY and play updating x update tokenX then y updates tokenY x update tokenX then x updates tokenY y update tokenY then x updates tokenX ... each time I got the postread. Something curious going on that make ACL_EvalTestRights return something different that ACL_RES_ALLOW. >> >> Did you already open a ticket for this problem ? >> >> thanks >> thierry >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Fri Oct 10 15:30:17 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 10 Oct 2014 17:30:17 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5437F835.3000000@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> <5437EF66.7090201@redhat.com> <5437F835.3000000@redhat.com> Message-ID: <5437FB89.3090004@redhat.com> On 10/10/2014 05:16 PM, thierry bordaz wrote: > On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: >> >> On 10/10/2014 03:58 PM, thierry bordaz wrote: >>> On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: >>>> On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: >>>>> On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: >>>>> >>>>>> On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: >>>>>>> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: >>>>>>>> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >>>>>>>>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >>>>>>>>> >>>>>>>>>> The background of this email is this bug: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>>>>>> >>>>>>>>>> Attached are two patches which solve this issue for admin users (not >>>>>>>>>> very helpful, I know). They depend on this fix in 389: >>>>>>>>>> https://fedorahosted.org/389/ticket/47920 >>>>>>>>>> >>>>>>>>>> There are two outstanding issues: >>>>>>>>>> >>>>>>>>>> 1. 389 does not send the post read control for normal users. The >>>>>>>>>> operation itself succeeds, but no control is sent. >>>>>>>>>> >>>>>>>>>> The relevant sections from the log are attached. 389 is denying access >>>>>>>>>> to the following attributes (* = valid, ! = invalid): >>>>>>>>>> ! objectClass >>>>>>>>>> ! ipatokenOTPalgorithm >>>>>>>>>> ! ipatokenOTPdigits >>>>>>>>>> * ipatokenOTPkey >>>>>>>>>> * ipatokenHOTPcounter >>>>>>>>>> ! ipatokenOwner >>>>>>>>>> ! managedBy >>>>>>>>>> ! ipatokenUniqueID >>>>>>>>> Hello Nathaniel, >>>>>>>>> >>>>>>>>> The post read control needs access to the modified entry to >>>>>>>>> return it. >>>>>>>>> This access is granted at the condition, the binddn can access >>>>>>>>> attributes. >>>>>>>> Agreed and understood. >>>>>>>> >>>>>>>>> My understanding is that the target entry is >>>>>>>>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". >>>>>>>> Correct. >>>>>>>> >>>>>>>>> The only ACI I found that match this target is: >>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)") >>>>>>>>> (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled >>>>>>>>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") >>>>>>>>> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>>>> Correct. >>>>>>>> >>>>>>>>> Do you know if the target entry has 'ipatokenOwner' or >>>>>>>>> 'managedBy' with the binddn value ? >>>>>>>> Yes, both. So why is access to objectClass (et cetera) being denied? >>>>>>> Good question... I will try to reproduce >>>>>> Thanks! >>>>> Hello, >>>>> >>>>> I tried to reproduce and it seems to work on *master*. >>>>> I am using the attached ldif file. >>>>> The test case is to bind as "cn=active >>>>> guy,cn=accounts,dc=example,dc=com" and to do a modify on >>>>> "cn=active otp,cn=otp,dc=example,dc=com". >>>>> >>>>> The modify updates the 'description' attribute and do a >>>>> postread (description, cn). >>>>> >>>>> The write 'description' is allowed by : >>>>> dn: cn=otp,dc=example,dc=com >>>>> aci: (targetfilter = >>>>> "(objectclass=organizationalPerson)")(target = >>>>> "ldap:///c >>>>> n=*,cn=otp,dc=example,dc=com")(targetattr = >>>>> "objectclass || description || se >>>>> eAlso")(version 3.0; acl "Active user modify otp >>>>> entry"; allow (write) userdn >>>>> ="ldap:///cn=active >>>>> guy,cn=accounts,dc=example,dc=com";) >>>>> >>>>> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. >>>>> Evaluating ALLOW aci(19) " "Active user modify otp >>>>> entry"" >>>>> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 >>>>> op=16 (main): Allow write on entry(cn=active >>>>> otp,cn=otp,dc=example,dc=com).attr(description) to >>>>> cn=active guy,cn=accounts,dc=example,dc=com: allowed >>>>> by aci(19): aciname= "Active user modify otp entry", >>>>> acidn="cn=otp,dc=example,dc=com" >>>>> >>>>> >>>>> The postread is allowed by: >>>>> dn: cn=otp,dc=example,dc=com >>>>> aci: (targetfilter = >>>>> "(objectclass=organizationalPerson)") (targetattr = >>>>> "obje >>>>> ctclass || description || seeAlso || cn")(version >>>>> 3.0; acl "Active user can r >>>>> ead his entries"; allow (read, search, compare) >>>>> userattr = "seeAlso#USERDN";) >>>>> >>>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. >>>>> Evaluating ALLOW aci(21) " "Active user can read his >>>>> entries"" >>>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ >>>>> ALLOW in cache >>>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 >>>>> op=16 (main): Allow read on entry(cn=active >>>>> otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active >>>>> guy,cn=accounts,dc=example,dc=com: cached allow by >>>>> aci(21) >>>>> >>>>> The postread works if I use USERDN or SELFDN. >>>>> >>>>> Please let me know the version of 389-ds that you are testing, >>>>> I will try on that branch >>>> That is not really the same test at all. >>>> >>>> 1. Install FreeIPA from F21 @ example.com >>>> 2. Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com >>>> -W -e postread=* <>>> dn: ipatokenuniqueid=foo,cn=otp,dc=example,dc=com >>>> changetype: add >>>> objectClass: top >>>> objectClass: ipaToken >>>> objectClass: ipaTokenHOTP >>>> ipatokenUniqueID: foo >>>> ipatokenOTPalgorithm: sha1 >>>> ipatokenOTPdigits: 6 >>>> ipatokenOTPkey: 00000000 >>>> ipatokenHOTPcounter: 0 >>>> ipatokenOwner: uid=admin,cn=users,cn=accounts,dc=example,dc=com >>>> managedBy: uid=admin,cn=users,cn=accounts,dc=example,dc=com >>>> EOF >>>> >>>> 3. Create a regular user named 'otp' >>>> 4. Execute: ldapadd -D uid=otp,cn=users,cn=accounts,dc=example,dc=com -W >>>> -e postread=* <>>> dn: ipatokenuniqueid=bar,cn=otp,dc=example,dc=com >>>> changetype: add >>>> objectClass: top >>>> objectClass: ipaToken >>>> objectClass: ipaTokenHOTP >>>> ipatokenUniqueID: bar >>>> ipatokenOTPalgorithm: sha1 >>>> ipatokenOTPdigits: 6 >>>> ipatokenOTPkey: 00000000 >>>> ipatokenHOTPcounter: 0 >>>> ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com >>>> managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com >>>> EOF >>>> >>>> RESULTS: >>>> Step 2 will add the token and return the post read control. Step 4 will >>>> add the token, but will NOT return the post read control. >>>> >>>> >>> Hi Nathaniel, >>> >>> Thanks for the detailed procedure I was able to reproduce the >>> problem: >>> >>> In fact during the step for, the add is successful but the found >>> ACIs do no grant access to the target entry: >>> >>> [09/Oct/2014:21:34:58 -0400] conn=29 fd=82 slot=82 SSL >>> connection from 10.16.78.124 to 10.16.78.124 >>> [09/Oct/2014:21:34:58 -0400] conn=29 SSL 128-bit AES >>> [09/Oct/2014:21:34:58 -0400] conn=29 op=0 BIND >>> dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" >>> method=128 version=3 >>> [09/Oct/2014:21:34:58 -0400] conn=29 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 >>> dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" >>> [09/Oct/2014:21:34:58 -0400] conn=29 op=1 ADD >>> dn="ipatokenuniqueid=bar,cn=otp,dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] conn=29 op=2 UNBIND >>> [09/Oct/2014:21:34:59 -0400] conn=29 op=2 fd=82 closed - U1 >>> [09/Oct/2014:21:34:59 -0400] conn=29 op=1 RESULT *err=0* >>> tag=105 nentries=0 etime=1 >>> >>> The add was granted because of "Users can create self-managed >>> tokens" >>> >>> >>> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Allow add on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(NULL) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: allowed >>> by aci(16): aciname= "Users can create self-managed tokens", >>> acidn="dc=example,dc=com" >>> >>> Now the postread control was not granted for any of the >>> attribute of the entry: >>> >>> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*objectClass*) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenUniqueID*) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPalgorithm*) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPdigits*) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPkey*) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenHOTPcounter*) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOwner*) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*managedBy*) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> >>> Each time the correct aci was selectionned: >>> >>> >>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>> "objectclass || d >>> escription || managedBy || ipatokenUniqueID || >>> ipatokenDisabled || ipatokenNo >>> tBefore || ipatokenNotAfter || ipatokenVendor || >>> ipatokenModel || ipatokenSer >>> ial || ipatokenOwner")(version 3.0; acl "*Users/managers >>> can read basic token* >>> info"; allow (read, search, compare) userattr = >>> "ipatokenOwner#USERDN" or use >>> rattr = "managedBy#USERDN";) >>> >>> ... >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed >>> attr:managedBy for >>> entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating >>> ALLOW aci(11) " "*Users/managers can read basic token info*"" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP >>> in cache >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating >>> ALLOW aci(19) " "Admin can manage any entry"" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP >>> in cache >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: >>> access to entry not allowed >>> (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) >>> >>> But for some reason, it evaluations of the READ access was not >>> accepted. >>> >> the key is READ SKIP, looks like it is using cached evaluation of the >> acis, where the aci did not apply. aci caching is .... > > Exact. > Now If I create two entries x/y and their associated ipatoken > tokenX/tokenY and play updating > x update tokenX then y updates tokenY > x update tokenX then x updates tokenY > y update tokenY then x updates tokenX > ... > each time I got the postread. so it seems to be related to the add operation. can I have a look at teh full acl logging for an ADD ? And I think we need a ticket, is it possible to reproduce without IPA ? > > Something curious going on that make ACL_EvalTestRights return > something different that ACL_RES_ALLOW. > >>> >>> Did you already open a ticket for this problem ? >>> >>> thanks >>> thierry >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Fri Oct 10 15:30:10 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 10 Oct 2014 11:30:10 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5437FB89.3090004@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> <5437EF66.7090201@redhat.com> <5437F835.3000000@redhat.com> <5437FB89.3090004@redhat.com> Message-ID: <1412955010.3520.2.camel@redhat.com> On Fri, 2014-10-10 at 17:30 +0200, Ludwig Krispenz wrote: > > On 10/10/2014 05:16 PM, thierry bordaz wrote: > > > On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: > > > > > > > > On 10/10/2014 03:58 PM, thierry bordaz wrote: > > > > > > > On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: > > > > > > > > > On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: > > > > > > On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: > > > > > > > > > > > > > On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: > > > > > > > > On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: > > > > > > > > > On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: > > > > > > > > > > On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: > > > > > > > > > > > > > > > > > > > > > The background of this email is this bug: > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/4456 > > > > > > > > > > > > > > > > > > > > > > Attached are two patches which solve this issue for admin users (not > > > > > > > > > > > very helpful, I know). They depend on this fix in 389: > > > > > > > > > > > https://fedorahosted.org/389/ticket/47920 > > > > > > > > > > > > > > > > > > > > > > There are two outstanding issues: > > > > > > > > > > > > > > > > > > > > > > 1. 389 does not send the post read control for normal users. The > > > > > > > > > > > operation itself succeeds, but no control is sent. > > > > > > > > > > > > > > > > > > > > > > The relevant sections from the log are attached. 389 is denying access > > > > > > > > > > > to the following attributes (* = valid, ! = invalid): > > > > > > > > > > > ! objectClass > > > > > > > > > > > ! ipatokenOTPalgorithm > > > > > > > > > > > ! ipatokenOTPdigits > > > > > > > > > > > * ipatokenOTPkey > > > > > > > > > > > * ipatokenHOTPcounter > > > > > > > > > > > ! ipatokenOwner > > > > > > > > > > > ! managedBy > > > > > > > > > > > ! ipatokenUniqueID > > > > > > > > > > Hello Nathaniel, > > > > > > > > > > > > > > > > > > > > The post read control needs access to the modified entry to > > > > > > > > > > return it. > > > > > > > > > > This access is granted at the condition, the binddn can access > > > > > > > > > > attributes. > > > > > > > > > Agreed and understood. > > > > > > > > > > > > > > > > > > > My understanding is that the target entry is > > > > > > > > > > ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". > > > > > > > > > Correct. > > > > > > > > > > > > > > > > > > > The only ACI I found that match this target is: > > > > > > > > > > aci: (targetfilter = "(objectClass=ipaToken)") > > > > > > > > > > (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled > > > > > > > > > > || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") > > > > > > > > > > (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > > > > > > > > Correct. > > > > > > > > > > > > > > > > > > > Do you know if the target entry has 'ipatokenOwner' or > > > > > > > > > > 'managedBy' with the binddn value ? > > > > > > > > > Yes, both. So why is access to objectClass (et cetera) being denied? > > > > > > > > Good question... I will try to reproduce > > > > > > > Thanks! > > > > > > Hello, > > > > > > > > > > > > I tried to reproduce and it seems to work on *master*. > > > > > > I am using the attached ldif file. > > > > > > The test case is to bind as "cn=active > > > > > > guy,cn=accounts,dc=example,dc=com" and to do a modify on > > > > > > "cn=active otp,cn=otp,dc=example,dc=com". > > > > > > > > > > > > The modify updates the 'description' attribute and do a > > > > > > postread (description, cn). > > > > > > > > > > > > The write 'description' is allowed by : > > > > > > dn: cn=otp,dc=example,dc=com > > > > > > aci: (targetfilter = > > > > > > "(objectclass=organizationalPerson)")(target = > > > > > > "ldap:///c > > > > > > n=*,cn=otp,dc=example,dc=com")(targetattr = > > > > > > "objectclass || description || se > > > > > > eAlso")(version 3.0; acl "Active user modify otp > > > > > > entry"; allow (write) userdn > > > > > > = "ldap:///cn=active > > > > > > guy,cn=accounts,dc=example,dc=com";) > > > > > > > > > > > > [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. > > > > > > Evaluating ALLOW aci(19) " "Active user modify otp > > > > > > entry"" > > > > > > [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 > > > > > > op=16 (main): Allow write on entry(cn=active > > > > > > otp,cn=otp,dc=example,dc=com).attr(description) to > > > > > > cn=active guy,cn=accounts,dc=example,dc=com: allowed > > > > > > by aci(19): aciname= "Active user modify otp entry", > > > > > > acidn="cn=otp,dc=example,dc=com" > > > > > > > > > > > > > > > > > > The postread is allowed by: > > > > > > dn: cn=otp,dc=example,dc=com > > > > > > aci: (targetfilter = > > > > > > "(objectclass=organizationalPerson)") (targetattr = > > > > > > "obje > > > > > > ctclass || description || seeAlso || cn")(version > > > > > > 3.0; acl "Active user can r > > > > > > ead his entries"; allow (read, search, compare) > > > > > > userattr = "seeAlso#USERDN";) > > > > > > > > > > > > [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. > > > > > > Evaluating ALLOW aci(21) " "Active user can read his > > > > > > entries"" > > > > > > [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ > > > > > > ALLOW in cache > > > > > > [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 > > > > > > op=16 (main): Allow read on entry(cn=active > > > > > > otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active > > > > > > guy,cn=accounts,dc=example,dc=com: cached allow by > > > > > > aci(21) > > > > > > > > > > > > The postread works if I use USERDN or SELFDN. > > > > > > > > > > > > Please let me know the version of 389-ds that you are testing, > > > > > > I will try on that branch > > > > > That is not really the same test at all. > > > > > > > > > > 1. Install FreeIPA from F21 @ example.com > > > > > 2. Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com > > > > > -W -e postread=* < > > > > dn: ipatokenuniqueid=foo,cn=otp,dc=example,dc=com > > > > > changetype: add > > > > > objectClass: top > > > > > objectClass: ipaToken > > > > > objectClass: ipaTokenHOTP > > > > > ipatokenUniqueID: foo > > > > > ipatokenOTPalgorithm: sha1 > > > > > ipatokenOTPdigits: 6 > > > > > ipatokenOTPkey: 00000000 > > > > > ipatokenHOTPcounter: 0 > > > > > ipatokenOwner: uid=admin,cn=users,cn=accounts,dc=example,dc=com > > > > > managedBy: uid=admin,cn=users,cn=accounts,dc=example,dc=com > > > > > EOF > > > > > > > > > > 3. Create a regular user named 'otp' > > > > > 4. Execute: ldapadd -D uid=otp,cn=users,cn=accounts,dc=example,dc=com -W > > > > > -e postread=* < > > > > dn: ipatokenuniqueid=bar,cn=otp,dc=example,dc=com > > > > > changetype: add > > > > > objectClass: top > > > > > objectClass: ipaToken > > > > > objectClass: ipaTokenHOTP > > > > > ipatokenUniqueID: bar > > > > > ipatokenOTPalgorithm: sha1 > > > > > ipatokenOTPdigits: 6 > > > > > ipatokenOTPkey: 00000000 > > > > > ipatokenHOTPcounter: 0 > > > > > ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com > > > > > managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com > > > > > EOF > > > > > > > > > > RESULTS: > > > > > Step 2 will add the token and return the post read control. Step 4 will > > > > > add the token, but will NOT return the post read control. > > > > > > > > > > > > > > Hi Nathaniel, > > > > > > > > Thanks for the detailed procedure I was able to > > > > reproduce the problem: > > > > > > > > In fact during the step for, the add is successful but > > > > the found ACIs do no grant access to the target entry: > > > > [09/Oct/2014:21:34:58 -0400] conn=29 fd=82 > > > > slot=82 SSL connection from 10.16.78.124 to > > > > 10.16.78.124 > > > > [09/Oct/2014:21:34:58 -0400] conn=29 SSL 128-bit > > > > AES > > > > [09/Oct/2014:21:34:58 -0400] conn=29 op=0 BIND > > > > dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" method=128 version=3 > > > > [09/Oct/2014:21:34:58 -0400] conn=29 op=0 RESULT > > > > err=0 tag=97 nentries=0 etime=0 > > > > dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" > > > > [09/Oct/2014:21:34:58 -0400] conn=29 op=1 ADD > > > > dn="ipatokenuniqueid=bar,cn=otp,dc=example,dc=com" > > > > [09/Oct/2014:21:34:59 -0400] conn=29 op=2 UNBIND > > > > [09/Oct/2014:21:34:59 -0400] conn=29 op=2 fd=82 > > > > closed - U1 > > > > [09/Oct/2014:21:34:59 -0400] conn=29 op=1 RESULT > > > > err=0 tag=105 nentries=0 etime=1 > > > > > > > > The add was granted because of "Users can create > > > > self-managed tokens" > > > > > > > > [09/Oct/2014:21:34:58 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Allow add on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(NULL) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: allowed by aci(16): aciname= "Users can create self-managed tokens", acidn="dc=example,dc=com" > > > > > > > > Now the postread control was not granted for any of the > > > > attribute of the entry: > > > > [09/Oct/2014:21:34:58 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(objectClass) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > [09/Oct/2014:21:34:58 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenUniqueID) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenOTPalgorithm) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenOTPdigits) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenOTPkey) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenHOTPcounter) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenOwner) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > > > > > Each time the correct aci was selectionned: > > > > > > > > aci: (targetfilter = > > > > "(objectClass=ipaToken)")(targetattrs = > > > > "objectclass || d > > > > escription || managedBy || ipatokenUniqueID || > > > > ipatokenDisabled || ipatokenNo > > > > tBefore || ipatokenNotAfter || ipatokenVendor > > > > || ipatokenModel || ipatokenSer > > > > ial || ipatokenOwner")(version 3.0; acl > > > > "Users/managers can read basic token > > > > info"; allow (read, search, compare) userattr = > > > > "ipatokenOwner#USERDN" or use > > > > rattr = "managedBy#USERDN";) > > > > > > > > ... > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - > > > > Processed attr:managedBy for > > > > entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. > > > > Evaluating ALLOW aci(11) " "Users/managers can > > > > read basic token info"" > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found > > > > READ SKIP in cache > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. > > > > Evaluating ALLOW aci(19) " "Admin can manage any > > > > entry"" > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found > > > > READ SKIP in cache > > > > [09/Oct/2014:21:34:59 -0400] NSACLPlugin - > > > > conn=29 op=1 (main): Deny read on > > > > entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com" > > > > [09/Oct/2014:21:34:59 -0400] - > > > > process_read_entry_controls: access to entry not > > > > allowed > > > > (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) > > > > But for some reason, it evaluations of the READ access > > > > was not accepted. > > > the key is READ SKIP, looks like it is using cached evaluation of > > > the acis, where the aci did not apply. aci caching is .... > > > > Exact. > > Now If I create two entries x/y and their associated ipatoken > > tokenX/tokenY and play updating > > x update tokenX then y updates tokenY > > x update tokenX then x updates tokenY > > y update tokenY then x updates tokenX > > ... > > each time I got the postread. > so it seems to be related to the add operation. can I have a look at > teh full acl logging for an ADD ? > And I think we need a ticket, https://fedorahosted.org/389/ticket/47924 > is it possible to reproduce without IPA ? Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can find another way to reproduce it. > > Something curious going on that make ACL_EvalTestRights return > > something different that ACL_RES_ALLOW. > > > > > > > > > > Did you already open a ticket for this problem ? > > > > > > > > thanks > > > > thierry > > > > > > From lkrispen at redhat.com Fri Oct 10 15:38:46 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 10 Oct 2014 17:38:46 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412955010.3520.2.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> <5437EF66.7090201@redhat.com> <5437F835.3000000@redhat.com> <5437FB89.3090004@redhat.com> <1412955010.3520.2.camel@redhat.com> Message-ID: <5437FD86.8010902@redhat.com> > https://fedorahosted.org/389/ticket/47924 > >> is it possible to reproduce without IPA ? > Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can > find another way to reproduce it. well, did think about it again, we probaly also would need all the plugins, so could be difficult > >>> Something curious going on that make ACL_EvalTestRights return >>> something different that ACL_RES_ALLOW. >>> >>>>> >>>>> Did you already open a ticket for this problem ? >>>>> >>>>> thanks >>>>> thierry > From npmccallum at redhat.com Fri Oct 10 15:41:04 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 10 Oct 2014 11:41:04 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5437FD86.8010902@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> <5437EF66.7090201@redhat.com> <5437F835.3000000@redhat.com> <5437FB89.3090004@redhat.com> <1412955010.3520.2.camel@redhat.com> <5437FD86.8010902@redhat.com> Message-ID: <1412955664.3520.4.camel@redhat.com> On Fri, 2014-10-10 at 17:38 +0200, Ludwig Krispenz wrote: > > https://fedorahosted.org/389/ticket/47924 > > > >> is it possible to reproduce without IPA ? > > Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can > > find another way to reproduce it. > well, did think about it again, we probaly also would need all the > plugins, so could be difficult I'm not sure you need plugins. You do to make OTP authentication work. But we don't care about that. We just care if add returns the post read control. That should be doable with just schema and ACIs. From tbordaz at redhat.com Fri Oct 10 15:41:22 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 10 Oct 2014 17:41:22 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5437FB89.3090004@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> <5437EF66.7090201@redhat.com> <5437F835.3000000@redhat.com> <5437FB89.3090004@redhat.com> Message-ID: <5437FE22.4080704@redhat.com> On 10/10/2014 05:30 PM, Ludwig Krispenz wrote: > > On 10/10/2014 05:16 PM, thierry bordaz wrote: >> On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: >>> >>> On 10/10/2014 03:58 PM, thierry bordaz wrote: >>>> On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: >>>>>> On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: >>>>>> >>>>>>> On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: >>>>>>>> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: >>>>>>>>> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: >>>>>>>>>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: >>>>>>>>>> >>>>>>>>>>> The background of this email is this bug: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4456 >>>>>>>>>>> >>>>>>>>>>> Attached are two patches which solve this issue for admin users (not >>>>>>>>>>> very helpful, I know). They depend on this fix in 389: >>>>>>>>>>> https://fedorahosted.org/389/ticket/47920 >>>>>>>>>>> >>>>>>>>>>> There are two outstanding issues: >>>>>>>>>>> >>>>>>>>>>> 1. 389 does not send the post read control for normal users. The >>>>>>>>>>> operation itself succeeds, but no control is sent. >>>>>>>>>>> >>>>>>>>>>> The relevant sections from the log are attached. 389 is denying access >>>>>>>>>>> to the following attributes (* = valid, ! = invalid): >>>>>>>>>>> ! objectClass >>>>>>>>>>> ! ipatokenOTPalgorithm >>>>>>>>>>> ! ipatokenOTPdigits >>>>>>>>>>> * ipatokenOTPkey >>>>>>>>>>> * ipatokenHOTPcounter >>>>>>>>>>> ! ipatokenOwner >>>>>>>>>>> ! managedBy >>>>>>>>>>> ! ipatokenUniqueID >>>>>>>>>> Hello Nathaniel, >>>>>>>>>> >>>>>>>>>> The post read control needs access to the modified entry to >>>>>>>>>> return it. >>>>>>>>>> This access is granted at the condition, the binddn can access >>>>>>>>>> attributes. >>>>>>>>> Agreed and understood. >>>>>>>>> >>>>>>>>>> My understanding is that the target entry is >>>>>>>>>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". >>>>>>>>> Correct. >>>>>>>>> >>>>>>>>>> The only ACI I found that match this target is: >>>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)") >>>>>>>>>> (targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled >>>>>>>>>> || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner") >>>>>>>>>> (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>>>>> Correct. >>>>>>>>> >>>>>>>>>> Do you know if the target entry has 'ipatokenOwner' or >>>>>>>>>> 'managedBy' with the binddn value ? >>>>>>>>> Yes, both. So why is access to objectClass (et cetera) being denied? >>>>>>>> Good question... I will try to reproduce >>>>>>> Thanks! >>>>>> Hello, >>>>>> >>>>>> I tried to reproduce and it seems to work on *master*. >>>>>> I am using the attached ldif file. >>>>>> The test case is to bind as "cn=active >>>>>> guy,cn=accounts,dc=example,dc=com" and to do a modify on >>>>>> "cn=active otp,cn=otp,dc=example,dc=com". >>>>>> >>>>>> The modify updates the 'description' attribute and do a >>>>>> postread (description, cn). >>>>>> >>>>>> The write 'description' is allowed by : >>>>>> dn: cn=otp,dc=example,dc=com >>>>>> aci: (targetfilter = >>>>>> "(objectclass=organizationalPerson)")(target = >>>>>> "ldap:///c >>>>>> n=*,cn=otp,dc=example,dc=com")(targetattr = >>>>>> "objectclass || description || se >>>>>> eAlso")(version 3.0; acl "Active user modify otp >>>>>> entry"; allow (write) userdn >>>>>> ="ldap:///cn=active >>>>>> guy,cn=accounts,dc=example,dc=com";) >>>>>> >>>>>> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. >>>>>> Evaluating ALLOW aci(19) " "Active user modify otp >>>>>> entry"" >>>>>> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 >>>>>> op=16 (main): Allow write on entry(cn=active >>>>>> otp,cn=otp,dc=example,dc=com).attr(description) to >>>>>> cn=active guy,cn=accounts,dc=example,dc=com: allowed >>>>>> by aci(19): aciname= "Active user modify otp entry", >>>>>> acidn="cn=otp,dc=example,dc=com" >>>>>> >>>>>> >>>>>> The postread is allowed by: >>>>>> dn: cn=otp,dc=example,dc=com >>>>>> aci: (targetfilter = >>>>>> "(objectclass=organizationalPerson)") (targetattr = >>>>>> "obje >>>>>> ctclass || description || seeAlso || cn")(version >>>>>> 3.0; acl "Active user can r >>>>>> ead his entries"; allow (read, search, compare) >>>>>> userattr = "seeAlso#USERDN";) >>>>>> >>>>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. >>>>>> Evaluating ALLOW aci(21) " "Active user can read his >>>>>> entries"" >>>>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ >>>>>> ALLOW in cache >>>>>> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 >>>>>> op=16 (main): Allow read on entry(cn=active >>>>>> otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active >>>>>> guy,cn=accounts,dc=example,dc=com: cached allow by >>>>>> aci(21) >>>>>> >>>>>> The postread works if I use USERDN or SELFDN. >>>>>> >>>>>> Please let me know the version of 389-ds that you are testing, >>>>>> I will try on that branch >>>>> That is not really the same test at all. >>>>> >>>>> 1. Install FreeIPA from F21 @ example.com >>>>> 2. Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com >>>>> -W -e postread=* <>>>> dn: ipatokenuniqueid=foo,cn=otp,dc=example,dc=com >>>>> changetype: add >>>>> objectClass: top >>>>> objectClass: ipaToken >>>>> objectClass: ipaTokenHOTP >>>>> ipatokenUniqueID: foo >>>>> ipatokenOTPalgorithm: sha1 >>>>> ipatokenOTPdigits: 6 >>>>> ipatokenOTPkey: 00000000 >>>>> ipatokenHOTPcounter: 0 >>>>> ipatokenOwner: uid=admin,cn=users,cn=accounts,dc=example,dc=com >>>>> managedBy: uid=admin,cn=users,cn=accounts,dc=example,dc=com >>>>> EOF >>>>> >>>>> 3. Create a regular user named 'otp' >>>>> 4. Execute: ldapadd -D uid=otp,cn=users,cn=accounts,dc=example,dc=com -W >>>>> -e postread=* <>>>> dn: ipatokenuniqueid=bar,cn=otp,dc=example,dc=com >>>>> changetype: add >>>>> objectClass: top >>>>> objectClass: ipaToken >>>>> objectClass: ipaTokenHOTP >>>>> ipatokenUniqueID: bar >>>>> ipatokenOTPalgorithm: sha1 >>>>> ipatokenOTPdigits: 6 >>>>> ipatokenOTPkey: 00000000 >>>>> ipatokenHOTPcounter: 0 >>>>> ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com >>>>> managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com >>>>> EOF >>>>> >>>>> RESULTS: >>>>> Step 2 will add the token and return the post read control. Step 4 will >>>>> add the token, but will NOT return the post read control. >>>>> >>>>> >>>> Hi Nathaniel, >>>> >>>> Thanks for the detailed procedure I was able to reproduce the >>>> problem: >>>> >>>> In fact during the step for, the add is successful but the >>>> found ACIs do no grant access to the target entry: >>>> >>>> [09/Oct/2014:21:34:58 -0400] conn=29 fd=82 slot=82 SSL >>>> connection from 10.16.78.124 to 10.16.78.124 >>>> [09/Oct/2014:21:34:58 -0400] conn=29 SSL 128-bit AES >>>> [09/Oct/2014:21:34:58 -0400] conn=29 op=0 BIND >>>> dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" >>>> method=128 version=3 >>>> [09/Oct/2014:21:34:58 -0400] conn=29 op=0 RESULT err=0 >>>> tag=97 nentries=0 etime=0 >>>> dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" >>>> [09/Oct/2014:21:34:58 -0400] conn=29 op=1 ADD >>>> dn="ipatokenuniqueid=bar,cn=otp,dc=example,dc=com" >>>> [09/Oct/2014:21:34:59 -0400] conn=29 op=2 UNBIND >>>> [09/Oct/2014:21:34:59 -0400] conn=29 op=2 fd=82 closed - U1 >>>> [09/Oct/2014:21:34:59 -0400] conn=29 op=1 RESULT *err=0* >>>> tag=105 nentries=0 etime=1 >>>> >>>> The add was granted because of "Users can create self-managed >>>> tokens" >>>> >>>> >>>> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Allow add on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(NULL) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: allowed >>>> by aci(16): aciname= "Users can create self-managed >>>> tokens", acidn="dc=example,dc=com" >>>> >>>> Now the postread control was not granted for any of the >>>> attribute of the entry: >>>> >>>> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*objectClass*) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> [09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenUniqueID*) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPalgorithm*) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPdigits*) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOTPkey*) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenHOTPcounter*) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*ipatokenOwner*) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(*managedBy*) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> >>>> Each time the correct aci was selectionned: >>>> >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs >>>> = "objectclass || d >>>> escription || managedBy || ipatokenUniqueID || >>>> ipatokenDisabled || ipatokenNo >>>> tBefore || ipatokenNotAfter || ipatokenVendor || >>>> ipatokenModel || ipatokenSer >>>> ial || ipatokenOwner")(version 3.0; acl "*Users/managers >>>> can read basic token* >>>> info"; allow (read, search, compare) userattr = >>>> "ipatokenOwner#USERDN" or use >>>> rattr = "managedBy#USERDN";) >>>> >>>> ... >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed >>>> attr:managedBy for >>>> entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating >>>> ALLOW aci(11) " "*Users/managers can read basic token info*"" >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP >>>> in cache >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating >>>> ALLOW aci(19) " "Admin can manage any entry"" >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP >>>> in cache >>>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>>> (main): Deny read on >>>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) >>>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>>> matched the subject by aci(19): aciname= "Admin can manage >>>> any entry", acidn="dc=example,dc=com" >>>> [09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: >>>> access to entry not allowed >>>> (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) >>>> >>>> But for some reason, it evaluations of the READ access was not >>>> accepted. >>>> >>> the key is READ SKIP, looks like it is using cached evaluation of >>> the acis, where the aci did not apply. aci caching is .... >> >> Exact. >> Now If I create two entries x/y and their associated ipatoken >> tokenX/tokenY and play updating >> x update tokenX then y updates tokenY >> x update tokenX then x updates tokenY >> y update tokenY then x updates tokenX >> ... >> each time I got the postread. > so it seems to be related to the add operation. can I have a look at > teh full acl logging for an ADD ? Sure, it is on vm-124.idm.lab.bos.redhat.com. You may restart/test on it without problem > And I think we need a ticket, is it possible to reproduce without IPA ? I think so. It is what I am preparing with a CI test. thierry >> >> Something curious going on that make ACL_EvalTestRights return >> something different that ACL_RES_ALLOW. >> >>>> >>>> Did you already open a ticket for this problem ? >>>> >>>> thanks >>>> thierry >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Oct 10 15:42:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Oct 2014 17:42:19 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <20141010143818.GE2328@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> <20141010133645.GC2328@redhat.com> <5437E820.1090303@redhat.com> <20141010143818.GE2328@redhat.com> Message-ID: <5437FE5B.8010708@redhat.com> On 10.10.2014 16:38, Alexander Bokovoy wrote: > On Fri, 10 Oct 2014, Petr Vobornik wrote: >> On 10.10.2014 15:36, Alexander Bokovoy wrote: >>> On Fri, 10 Oct 2014, Petr Vobornik wrote: >>>> On 10.10.2014 10:39, Alexander Bokovoy wrote: >>>>> Hi! >>>>> >>>>> I'm resending patches 0159 and 0160, and adding two more: >>>>> >>>>> 0161 -- support user SSH public keys in ID view user overrides >>>>> 0162 -- support gidNumber in ID view user override >>>>> >>>>> SSH public keys to work require support from SSSD and that one is >>>>> currently missing. At least, one add/remove the keys to/from the >>>>> override objects. >>>>> >>>>> Compat tree does not support exporting SSH keys. When accessing the >>>>> tree >>>>> anonymously, the entry will be filtered out by ACIs but for >>>>> authenticated users we need to explicitly ignore ipaSshPubKey >>>>> attribute >>>>> in the override, so I'm resending updated slapi-nis patch that only >>>>> adds one more attribute to filter out. >>>>> >>>> >>>> I'm going to prepare Web UI for, 160, 161, 162. >>>> >>>> Q: ipaUserOverride object class contains also 'gecos' attribute. Will >>>> it be handled be CLI and Web UI as well? >>> I'll add another patch for that. >>> >>>> >>>> Comments for these 3 patches: >>>> >>>> 1. VERSION was not bumped >>>> >>>> Patch 160: >>>> Apart form #1, is OK (not sure if #1 is needed for ACK) >>> I wonder if I should bump it in a separate patch that would be the last >>> one in the series, to avoid proliferation of API version numbers? :) >> >> IMHO it should be sufficient. Same outcome as if the patches were >> squashed. > Yep. > > One more update for patch 0161, Petr noticed we need to call super > post_callback() too. > idoverrideuser_find callback causes internal error. I've attached new version of the patch which fixes it. Basically it's this change: diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index 25b9bcf..bfa8675 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -831,11 +831,12 @@ class idoverrideuser_find(baseidoverride_find): msg_summary = ngettext('%(count)d User ID override matched', '%(count)d User ID overrides matched', 0) - def post_callback(self, ldap, dn, entry_attrs, *keys, **options): - dn = super(idoverrideuser_find, self).post_callback(ldap, dn, - entry_attrs, *keys, **options) - convert_sshpubkey_post(ldap, dn, entry_attrs) - return dn + def post_callback(self, ldap, entries, truncated, *args, **options): + truncated = super(idoverrideuser_find, self).post_callback( + ldap, entries, truncated, *args, **options) + for entry in entries: + convert_sshpubkey_post(ldap, entry.dn, entry) + return truncated If you are OK with it, then ACK for patches 160, 161-3, 162-1, 164 and 165. Patch 159 should be reviewed by somebody more versed in Compat tree. Btw. 10-schema_compat.update contains whitespace warning(git am) - additional blank line at the end of file. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-abbra-0161-Allow-user-overrides-to-specify-SSH-public-keys-3.patch Type: text/x-patch Size: 7372 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 10 15:43:36 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 10 Oct 2014 11:43:36 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412804761.9441.12.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> Message-ID: <1412955816.3520.6.camel@redhat.com> As a result of this ongoing conversation, I have opened two 389 bugs: 1. Post Read - https://fedorahosted.org/389/ticket/47924 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: > The background of this email is this bug: > https://fedorahosted.org/freeipa/ticket/4456 > > Attached are two patches which solve this issue for admin users (not > very helpful, I know). They depend on this fix in 389: > https://fedorahosted.org/389/ticket/47920 > > There are two outstanding issues: > > 1. 389 does not send the post read control for normal users. The > operation itself succeeds, but no control is sent. > > The relevant sections from the log are attached. 389 is denying access > to the following attributes (* = valid, ! = invalid): > ! objectClass > ! ipatokenOTPalgorithm > ! ipatokenOTPdigits > * ipatokenOTPkey > * ipatokenHOTPcounter > ! ipatokenOwner > ! managedBy > ! ipatokenUniqueID > > The ACIs allowing access to most of these attributes are here: > https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > > Note that I am able to query the entry just fine (including all the > above invalidly restricted attributes). Hence, I know the ACIs are > working just fine. > > Part of the strange thing is that in the post read control request, I > haven't indicated that I want *any* attributes returned (i.e. I want > just the DN). So I'm not sure why it is querying all the attributes. I > would suspect that the proper behavior would be to only check the ACIs > on attributes that will actually be returned. > > 2. The second patch (0002) modifies the ACI for normal user token > addition from this: > > aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > userattr = "managedBy#SELFDN";) > > To this: > > aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > "Users can create self-managed tokens"; allow (add) userattr = > "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > > The idea is to allow users to create tokens which will be expanded by > the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are > checked. Since the expanded UUID no longer matches the ACI, the addition > is denied. Is this truly the correct behavior? I would think that the > ACIs would be checked before the UUID plugin, not after. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Fri Oct 10 15:46:47 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 10 Oct 2014 11:46:47 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5437FD86.8010902@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> <5437EF66.7090201@redhat.com> <5437F835.3000000@redhat.com> <5437FB89.3090004@redhat.com> <1412955010.3520.2.camel@redhat.com> <5437FD86.8010902@redhat.com> Message-ID: <20141010114647.09881217@willson.usersys.redhat.com> On Fri, 10 Oct 2014 17:38:46 +0200 Ludwig Krispenz wrote: > > > https://fedorahosted.org/389/ticket/47924 > > > >> is it possible to reproduce without IPA ? > > Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless > > you can find another way to reproduce it. > well, did think about it again, we probaly also would need all the > plugins, so could be difficult Just a wild guess, for some reason the post-read evaluation is using some cached evaluation of the add. I think the key part here is that we *change* the DN which is key part in determining the access control. I wounder if you can reproduce in 389ds using the DNA plugin ? Use the magic value to generate a number and use the value in the add and read ACIs so that the ADD works only with the magic value. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Fri Oct 10 15:52:15 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 10 Oct 2014 17:52:15 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree Message-ID: <543800AF.9080704@redhat.com> Hello, this is the current status of my work on #4302, and there are a few pieces still missing, eg the management command needs more input checking and error handling, but - I wanted to give people interested a chance to have a look again and get feedback - there came up the following questions I would like to get an opinion. when thinking how to move from an existing deployment with direct management of replication agreement to the new way, there should not be any intermediate disconnects, and if possible transition should be made easy. So I think we should have defined a few modes of operation for the plugin: - initial/bootstrap [optional] - the plugin detects existing agreements and transforms it to segments in the shared tree - pending - the plugin handles and propagates segments in the shared tree, but does not enforce teh deletion or creation of replication agreements - active - directe management of replicatio agreements is rejected, existing segments ond their modifications are applied I did run my tests of the management command as directory manager since admin did not have permissions to read plugin configuration in cn=config, I can add permissions, probably will also need permissions for the part in the shared tree, so what is the expected operation mode, which user needs access to the shared config data and configuration ? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lkrispen-0003-move-replication-topology-to-shared-tree.patch Type: text/x-patch Size: 98269 bytes Desc: not available URL: From abokovoy at redhat.com Fri Oct 10 15:56:33 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Oct 2014 18:56:33 +0300 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <5437FE5B.8010708@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> <20141010133645.GC2328@redhat.com> <5437E820.1090303@redhat.com> <20141010143818.GE2328@redhat.com> <5437FE5B.8010708@redhat.com> Message-ID: <20141010155633.GF2328@redhat.com> On Fri, 10 Oct 2014, Petr Vobornik wrote: >>One more update for patch 0161, Petr noticed we need to call super >>post_callback() too. >> > >idoverrideuser_find callback causes internal error. I've attached new >version of the patch which fixes it. Basically it's this change: > >diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py >index 25b9bcf..bfa8675 100644 >--- a/ipalib/plugins/idviews.py >+++ b/ipalib/plugins/idviews.py >@@ -831,11 +831,12 @@ class idoverrideuser_find(baseidoverride_find): > msg_summary = ngettext('%(count)d User ID override matched', > '%(count)d User ID overrides matched', 0) > >- def post_callback(self, ldap, dn, entry_attrs, *keys, **options): >- dn = super(idoverrideuser_find, self).post_callback(ldap, dn, >- entry_attrs, *keys, **options) >- convert_sshpubkey_post(ldap, dn, entry_attrs) >- return dn >+ def post_callback(self, ldap, entries, truncated, *args, **options): >+ truncated = super(idoverrideuser_find, self).post_callback( >+ ldap, entries, truncated, *args, **options) >+ for entry in entries: >+ convert_sshpubkey_post(ldap, entry.dn, entry) >+ return truncated > >If you are OK with it, then ACK for patches 160, 161-3, 162-1, 164 and 165. I'm fine with your patch, copy/paste error, thanks for fixing it. -- / Alexander Bokovoy From pvoborni at redhat.com Fri Oct 10 16:01:48 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 10 Oct 2014 18:01:48 +0200 Subject: [Freeipa-devel] [PATCH] 772 webui: add new iduseroverride fields Message-ID: <543802EC.4060408@redhat.com> - add gecos, gidnumber, loginshell, sshkeys fields depends on ab's 160-165. Point for discussion: Before this patch, all fields were included in adder dialog and were listed on a search pages. Now: * Search page lacks: gecos, gidnumber, loginshell, sshkeys fields * Adder dialog lacks: sshkeys For reference, other fields are: ipaanchoruuid, description, uid, uidnumber, homedirectory We can't show every field on a search page. Is there a field among the missing ones, which is more important and should be added to a search page? -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0772-webui-add-new-iduseroverride-fields.patch Type: text/x-patch Size: 1564 bytes Desc: not available URL: From simo at redhat.com Fri Oct 10 16:21:54 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 10 Oct 2014 12:21:54 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <543800AF.9080704@redhat.com> References: <543800AF.9080704@redhat.com> Message-ID: <20141010122154.1c693f05@willson.usersys.redhat.com> On Fri, 10 Oct 2014 17:52:15 +0200 Ludwig Krispenz wrote: > Hello, > > this is the current status of my work on #4302, and there are a few > pieces still missing, eg the management command needs more input > checking and error handling, but > - I wanted to give people interested a chance to have a look again > and get feedback > - there came up the following questions I would like to get an > opinion. First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage > when thinking how to move from an existing deployment with direct > management of replication agreement to the new way, there should not > be any intermediate disconnects, and if possible transition should be > made easy. So I think we should have defined a few modes of operation > for the plugin: > - initial/bootstrap [optional] - the plugin detects existing > agreements and transforms it to segments in the shared tree This should not be optional imo, its the only way to do sane upgrades. When the plugin starts it needs to check if there are replication agreements with other freeipa servers (it should ignore anything else). Then check if these agreements have been autogenerated (this should be determined by new naming conventions for agreements in cn=config) or if they are pre-existing, if they are pre-existing then new shared entries will be generated in the shared tree. Note: this upgrade thing could also be done in ipa-upgrade plugins, at server upgrade time. Whichever is easier (main concern is if 2 servers are upgraded at the same time replication conflicts may arise). > - pending - the plugin handles and propagates segments in the shared > tree, but does not enforce teh deletion or creation of replication > agreements Not sure what you mean here, but I think that once the plugin is active it should stay active and actively prevent manual changes to automatically created replication agreements. > - active - directe management of replicatio agreements is rejected, > existing segments ond their modifications are applied This should always be. > I did run my tests of the management command as directory manager > since admin did not have permissions to read plugin configuration in > cn=config, Why would you need to access cn=config ? All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... > I can add permissions, probably will also need permissions > for the part in the shared tree, so what is the expected operation > mode, which user needs access to the shared config data and > configuration ? We need to introduce a role for "Replication Admins" and make the admins group a member by default, then use normal permissions framework to regulate access. Simo. -- Simo Sorce * Red Hat, Inc * New York From purpleidea at gmail.com Fri Oct 10 16:30:56 2014 From: purpleidea at gmail.com (James) Date: Fri, 10 Oct 2014 12:30:56 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <20141010122154.1c693f05@willson.usersys.redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> Message-ID: On 10 October 2014 12:21, Simo Sorce wrote: > First thing, I do not think we want a new command here. > If we need commands outside of the ipa framework they should be > integrated in the ipa-replica-manage tool. > But really one of the reasons to move data in the shared tree was that > we could grow native framework command to handle the topology so we can > manage the topology directly from the UI. > So I am not happy with ipa-tology-manage I agree here... I think the current interface of ipa-replica-manage is fine, however the need to copy the credentials around and the need for a password are the problem. In fact, I particularly like the current interface, and puppet-ipa has already wrapped this successfully. In other words, the design checks out. Good job IPA team. > All management should happen in the shared tree, moving to be able to > avoid directly touching cn=config and avoid the need for DM password is > one of the main reasons to do this work ... I'd just like to +1 / re-iterate this point... In addition, thank you for hacking on this and for posting this for early review. Cheers, James From lkrispen at redhat.com Fri Oct 10 16:33:53 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 10 Oct 2014 18:33:53 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <5437F835.3000000@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <54367B5D.6050900@redhat.com> <1412872075.3262.9.camel@redhat.com> <5436B881.3070002@redhat.com> <1412872807.3262.10.camel@redhat.com> <5436EE75.5080608@redhat.com> <1412887903.3262.14.camel@redhat.com> <5437E621.2000302@redhat.com> <5437EF66.7090201@redhat.com> <5437F835.3000000@redhat.com> Message-ID: <54380A71.6070904@redhat.com> >>> >>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>> "objectclass || d >>> escription || managedBy || ipatokenUniqueID || >>> ipatokenDisabled || ipatokenNo >>> tBefore || ipatokenNotAfter || ipatokenVendor || >>> ipatokenModel || ipatokenSer >>> ial || ipatokenOwner")(version 3.0; acl "*Users/managers >>> can read basic token* >>> info"; allow (read, search, compare) userattr = >>> "ipatokenOwner#USERDN" or use >>> rattr = "managedBy#USERDN";) >>> >>> ... >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed >>> attr:managedBy for >>> entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating >>> ALLOW aci(11) " "*Users/managers can read basic token info*"" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP >>> in cache >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating >>> ALLOW aci(19) " "Admin can manage any entry"" >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP >>> in cache >>> [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 >>> (main): Deny read on >>> entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) >>> to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci >>> matched the subject by aci(19): aciname= "Admin can manage >>> any entry", acidn="dc=example,dc=com" >>> [09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: >>> access to entry not allowed >>> (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) >>> >>> But for some reason, it evaluations of the READ access was not >>> accepted. >>> >> the key is READ SKIP, looks like it is using cached evaluation of the >> acis, where the aci did not apply. aci caching is .... > > Exact. well, I think I've been a bit too fast, the READ SKIP is only logged from the second attribute on, so caching was ok, but the wrong result was cached. What really is strange is these lines: [09/Oct/2014:21:34:58 -0400] NSACLPlugin - 1. Evaluating ALLOW aci(11) " "Users/managers can read basic token info"" [09/Oct/2014:21:34:58 -0400] NSACLPlugin - Attr:ipatokenOwner [09/Oct/2014:21:34:58 -0400] NSACLPlugin - ACL info: userdnattr does not allow ADD permission at level 0. [09/Oct/2014:21:34:58 -0400] NSACLPlugin - Returning UNDEFINED for userdnattr evaluation. why ADD, why UNDEFINED ? > Now If I create two entries x/y and their associated ipatoken > tokenX/tokenY and play updating > x update tokenX then y updates tokenY > x update tokenX then x updates tokenY > y update tokenY then x updates tokenX > ... > each time I got the postread. > > Something curious going on that make ACL_EvalTestRights return > something different that ACL_RES_ALLOW. > >>> >>> Did you already open a ticket for this problem ? >>> >>> thanks >>> thierry >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Fri Oct 10 16:38:36 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 10 Oct 2014 18:38:36 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> Message-ID: <54380B8C.5060101@redhat.com> On 10/10/2014 06:30 PM, James wrote: > On 10 October 2014 12:21, Simo Sorce wrote: > > >> First thing, I do not think we want a new command here. >> If we need commands outside of the ipa framework they should be >> integrated in the ipa-replica-manage tool. >> But really one of the reasons to move data in the shared tree was that >> we could grow native framework command to handle the topology so we can >> manage the topology directly from the UI. >> So I am not happy with ipa-tology-manage > I agree here... I think the current interface of ipa-replica-manage is > fine, however the need to copy the credentials around and the need for > a password are the problem. In fact, I particularly like the current > interface, and puppet-ipa has already wrapped this successfully. In > other words, the design checks out. Good job IPA team. > >> All management should happen in the shared tree, moving to be able to >> avoid directly touching cn=config and avoid the need for DM password is >> one of the main reasons to do this work ... I'll comment later on Simmo's other comments, but I need access to cn=config for two reasons, - I need to know if the plugin is deployed and enabled - the plugin configuration contains the location in the the shared tree where the toplogy information is stored. I do not like to have hardcoded paths. > I'd just like to +1 / re-iterate this point... > > In addition, thank you for hacking on this and for posting this for > early review. > > Cheers, > James From simo at redhat.com Fri Oct 10 16:44:14 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 10 Oct 2014 12:44:14 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <54380B8C.5060101@redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <54380B8C.5060101@redhat.com> Message-ID: <20141010124414.588a0a6d@willson.usersys.redhat.com> On Fri, 10 Oct 2014 18:38:36 +0200 Ludwig Krispenz wrote: > > On 10/10/2014 06:30 PM, James wrote: > > On 10 October 2014 12:21, Simo Sorce wrote: > > > > > >> First thing, I do not think we want a new command here. > >> If we need commands outside of the ipa framework they should be > >> integrated in the ipa-replica-manage tool. > >> But really one of the reasons to move data in the shared tree was > >> that we could grow native framework command to handle the topology > >> so we can manage the topology directly from the UI. > >> So I am not happy with ipa-tology-manage > > I agree here... I think the current interface of ipa-replica-manage > > is fine, however the need to copy the credentials around and the > > need for a password are the problem. In fact, I particularly like > > the current interface, and puppet-ipa has already wrapped this > > successfully. In other words, the design checks out. Good job IPA > > team. > > > >> All management should happen in the shared tree, moving to be able > >> to avoid directly touching cn=config and avoid the need for DM > >> password is one of the main reasons to do this work ... > I'll comment later on Simmo's other comments, but I need access to > cn=config for two reasons, > - I need to know if the plugin is deployed and enabled Let's expose something in rootDSE then, that's the "standard" way to do this (though it is unnecessary, if the shared tree is present you already know it is available). > - the plugin configuration contains the location in the the shared > tree where the toplogy information is > stored. I do not like to have hardcoded paths. In IPA it will be absolutely hardcoded with no chance of changing it. So it is not a problem for IPA tools. Simo. -- Simo Sorce * Red Hat, Inc * New York From ftweedal at redhat.com Mon Oct 13 05:54:29 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 13 Oct 2014 15:54:29 +1000 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design In-Reply-To: <5433D2B9.7080209@redhat.com> References: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> <5433D2B9.7080209@redhat.com> Message-ID: <20141013055429.GG5346@dhcp-40-8.bne.redhat.com> On Tue, Oct 07, 2014 at 01:47:05PM +0200, Martin Kosek wrote: > On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > > Hi all, > > > > The Dogtag lightweight sub-CAs design has undergone major revision > > and expansion ahead of beginning the implementation (I plan to begin > > later this week). This feature will provide an API for admins to > > create sub-CAs for separate security domains and augment the > > existing API so that certificates requests can be directed to a > > particular sub-CA. > > > > This feature will be used in FreeIPA for issuing user or service > > certificates for particular purposes (that will be rejected when use > > for other purposes). > > > > Please review the document and provide feedback. > > > > http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > > > Feedback/suggestions for the REST API (that FreeIPA will use) and > > ACI considerations (e.g. is it appropriate to use the existing > > "agent" credential or should a separate credential or more > > fine-grained ACIs be used) are particularly encouraged. > > > > Cheers, > > > > Fraser > > Thanks for sharing the design! Couple initial comments: > > > Creating sub-CAs > > > > Creation of sub-CAs at any time after the initial spawning of an CA instance > > is a requirement. Preferably, restart would not be needed, however, if needed, > > it must be able to be performed without manual intervention. > > I am all for having the operation in effect without requiring restart, > especially given the change is in replicated tree. What do you mean by "restart > without manual operation"? That Dogtag would restart itself when it detects > that subCA would be added? > This is an artifact of earlier discussions. The requirement was that if a restart was required to complete the addition of a sub-CA, it could be triggered automatically. But I think it is now clear that it should be possible to do it without a restart. > > Key generation and storage > > Are we referring to > http://www.freeipa.org/page/V4/PKCS11_in_LDAP > http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > ? Contact people: Jan Cholasta, Petr Spacek > (Probably clear from the subsequent discussion, but for the sake of a direct answer...) No, not specifically referring to the above. The requirement is to generate sub-CA signing keys and propagate them to clones, securely; this is for a Dogtag CA subsystem feature, so it should be possible to do it without a KRA subsystem, SSSD, etc. > > > ACI considerations > > Agent credential is used by FreeIPA web interface, all authorization is then > done on python framework level. We can add more agents and then switch the used > certificate, but I wonder how to use it in authorization decisions. Apache > service will need to to have access to all these agents anyway. > > First we need to think how fine grained authorization we want to do. I think we > will want to be able to for example say that user Foo can generate certificates > in specified subCA. I am not sure it is a good way to go, it would also make > such private key distribution on IPA replicas + renewal a challenge. > > Right now, we only have "Virtual Operations" concept to authorize different > operations with Dogtag CA, but it does not distinguish between different CAs. > We could add a new Virtual Operation for every subCA, but it looks clumsy. But > the ACI-based mechanism and our permission system would still be the easiest > way to go, IMHO, compared to utilizing PKI agents. > > Martin From mkosek at redhat.com Mon Oct 13 06:19:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 13 Oct 2014 08:19:12 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <20141010124414.588a0a6d@willson.usersys.redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <54380B8C.5060101@redhat.com> <20141010124414.588a0a6d@willson.usersys.redhat.com> Message-ID: <543B6EE0.5040107@redhat.com> On 10/10/2014 06:44 PM, Simo Sorce wrote: > On Fri, 10 Oct 2014 18:38:36 +0200 > Ludwig Krispenz wrote: > >> >> On 10/10/2014 06:30 PM, James wrote: >>> On 10 October 2014 12:21, Simo Sorce wrote: >>> >>> >>>> First thing, I do not think we want a new command here. >>>> If we need commands outside of the ipa framework they should be >>>> integrated in the ipa-replica-manage tool. >>>> But really one of the reasons to move data in the shared tree was >>>> that we could grow native framework command to handle the topology >>>> so we can manage the topology directly from the UI. >>>> So I am not happy with ipa-tology-manage >>> I agree here... I think the current interface of ipa-replica-manage >>> is fine, however the need to copy the credentials around and the >>> need for a password are the problem. In fact, I particularly like >>> the current interface, and puppet-ipa has already wrapped this >>> successfully. In other words, the design checks out. Good job IPA >>> team. >>> >>>> All management should happen in the shared tree, moving to be able >>>> to avoid directly touching cn=config and avoid the need for DM >>>> password is one of the main reasons to do this work ... >> I'll comment later on Simmo's other comments, but I need access to >> cn=config for two reasons, >> - I need to know if the plugin is deployed and enabled > > Let's expose something in rootDSE then, that's the "standard" way to > do this (though it is unnecessary, if the shared tree is present you > already know it is available). +1, for the plugin enabled/disabled status. However, in case you really need to let admin or other privileged person to look in specified part of cn=config, this can be done with standard permissions. We already have for example permission for reading replication agreements: dn: cn=config aci: (targetattr = "cn || createtimestamp || description || entryusn || modifytimestamp || nsds50ruv || nsds5beginreplicarefresh || nsds5debugreplicatimeout || nsds5flags || nsds5replicaabortcleanruv || ... winsyncsubtreepair || winsyncwindowsfilter")(targetfilter = "(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version 3.0;acl "permission:System: Read Replication Agreements"; allow (compare,read,search) groupdn = "ldap:///cn=System: Read Replication Agreements,cn=permissions, cn=pbac,dc=ipa,dc=example";) Martin From ftweedal at redhat.com Mon Oct 13 06:38:07 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 13 Oct 2014 16:38:07 +1000 Subject: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design In-Reply-To: <20141007094012.184c3812@willson.usersys.redhat.com> References: <20141007033109.GS5346@dhcp-40-8.bne.redhat.com> <5433D2B9.7080209@redhat.com> <20141007090629.5135145e@willson.usersys.redhat.com> <5433EABD.5090103@redhat.com> <20141007094012.184c3812@willson.usersys.redhat.com> Message-ID: <20141013063807.GH5346@dhcp-40-8.bne.redhat.com> On Tue, Oct 07, 2014 at 09:40:12AM -0400, Simo Sorce wrote: > On Tue, 07 Oct 2014 09:29:33 -0400 > Rob Crittenden wrote: > > > Simo Sorce wrote: > > > On Tue, 07 Oct 2014 13:47:05 +0200 > > > Martin Kosek wrote: > > > > > >> On 10/07/2014 05:31 AM, Fraser Tweedale wrote: > > >>> Hi all, > > >>> > > >>> The Dogtag lightweight sub-CAs design has undergone major revision > > >>> and expansion ahead of beginning the implementation (I plan to > > >>> begin later this week). This feature will provide an API for > > >>> admins to create sub-CAs for separate security domains and > > >>> augment the existing API so that certificates requests can be > > >>> directed to a particular sub-CA. > > >>> > > >>> This feature will be used in FreeIPA for issuing user or service > > >>> certificates for particular purposes (that will be rejected when > > >>> use for other purposes). > > >>> > > >>> Please review the document and provide feedback. > > >>> > > >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs > > >>> > > >>> Feedback/suggestions for the REST API (that FreeIPA will use) and > > >>> ACI considerations (e.g. is it appropriate to use the existing > > >>> "agent" credential or should a separate credential or more > > >>> fine-grained ACIs be used) are particularly encouraged. > > >>> > > >>> Cheers, > > >>> > > >>> Fraser > > >> > > >> Thanks for sharing the design! Couple initial comments: > > >> > > >>> Creating sub-CAs > > >>> > > >>> Creation of sub-CAs at any time after the initial spawning of an > > >>> CA instance is a requirement. Preferably, restart would not be > > >>> needed, however, if needed, it must be able to be performed > > >>> without manual intervention. > > >> > > >> I am all for having the operation in effect without requiring > > >> restart, especially given the change is in replicated tree. What > > >> do you mean by "restart without manual operation"? That Dogtag > > >> would restart itself when it detects that subCA would be added? > > >> > > >>> Key generation and storage > > >> > > >> Are we referring to > > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP > > >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > > >> ? Contact people: Jan Cholasta, Petr Spacek > > >> > > >> > > >>> ACI considerations > > >> > > >> Agent credential is used by FreeIPA web interface, all > > >> authorization is then done on python framework level. We can add > > >> more agents and then switch the used certificate, but I wonder how > > >> to use it in authorization decisions. Apache service will need to > > >> to have access to all these agents anyway. > > > > > > We really need to move to a separate service for agent access, the > > > framework is supposed to not have any more power than the user that > > > connects to it. By giving the framework direct access to > > > credentials we fundamentally change the proposition and erode the > > > security properties of the separation. > > > > > > We have discussed before a proxy process that pass in commands as > > > they come from the framework but assumes agent identity only after > > > checking how the framework authenticated to it (via GSSAPI). > > > > > >> First we need to think how fine grained authorization we want to > > >> do. > > > > > > We need to associate a user to an agent credential via a group, so > > > that we can assign the rights via roles. > > > > > >> I think we will want to be able to for example say that user Foo > > >> can generate certificates in specified subCA. I am not sure it is > > >> a good way to go, it would also make such private key distribution > > >> on IPA replicas + renewal a challenge. > > > > > > I do not think we need to start with very fine grained permissions > > > initially. > > > > > >> Right now, we only have "Virtual Operations" concept to authorize > > >> different operations with Dogtag CA, but it does not distinguish > > >> between different CAs. We could add a new Virtual Operation for > > >> every subCA, but it looks clumsy. But the ACI-based mechanism and > > >> our permission system would still be the easiest way to go, IMHO, > > >> compared to utilizing PKI agents. > > > > > > We need to have a different agent certificate per role, and then in > > > the proxy process associate the right agent certificate based on > > > what the framework asks and internal checking that the user is > > > indeed allowed to do so. > > > > > > The framework will select the 'role' to use based on the operation > > > to be performed. > > > > I totally agree in principle but this will add significant complexity > > to replication and renewal. > > We already have this issue with DNSSEC, so I think we can solve it the > same way (storing keys in LDAP encrypted with a master key). > > > Each agent cert will need to be tracked by certmonger and renewed > > automatically. The basic framework for that is in place and IIRC > > fairly generalized so this should be relatively simple, but we've had > > a few bumps in the road to renewal. > > Alternatively I think we can avoid this by having the proxy process > store the certs in LDAP (encrypted with the current main agent cert) > and renew them by calling out to certmonger if the certs are close to > expiration. We can make it simpler than it is now. > > > What I think will be more challenging is dealing with distribution of > > additional agent certs to other masters. We handle it now via > > ipa-replica-manage. > > See above :) > > > Given that it is a requirement to be able to generate sub-CAs > > post-install there needs to be some mechanism to share this > > certificate amongst the other IPA masters. > > > > On the bright side Fraser has already considered some of this, at > > least for sub-CA key distribution, but there are no no details > > fleshed out yet. > > This is critical in general, so having this privileged process on the > ipa side is necessary. It can handle access to keys for other uses too. > > For example I would like to use the same mechanism to switch to have > only an encrypted krbMaster key in LDAP and use this privileged process > pull it, unencrypt it with the local cert and then store it in a keytab > for the KDC to use). This is clearly a future development but it is > something we really need to move towards instead of adding "simpler" > workarounds in the current code. > > Simo. > >From further investigation, Dogtag CA clones all share a "subsystem certificate" that supports key wrapping; it should be possible (and fairly straightforward) to use this for securely distributing the sub-CA signing keys in LDAP. Taking inspiration from the DNSSEC design, sub-CA signing keys would be unwrapped and added to the certificate database "just in time", when the replica first has need to use it. I agree that a common framework for distributing secrets among clones/replica is something we want. Fraser > -- > Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Oct 13 07:02:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 13 Oct 2014 09:02:58 +0200 Subject: [Freeipa-devel] FreeIPA upstream guide - next steps Message-ID: <543B7922.5060707@redhat.com> Hello all, Just FYI, based on the "[Freeipa-users] What should we do with upstream guide?" thread I started doing actions on FreeIPA.org wiki side: - Created http://www.freeipa.org/page/Upstream_User_Guide with the details about the decisions that were made - Updated http://www.freeipa.org/page/Documentation#User_Documentation with links to downstream guides + direct links for reporting bugs - Created https://git.fedorahosted.org/cgit/freeipa-docs.git/tree/DEPRECATION - Given that I was in this work already, I created redirects for other obsolete generated developer documentation: - http://www.freeipa.org/developer-docs/ - http://www.freeipa.org/freeipa2-dev-doc/ - http://www.freeipa.org/docs/master/ Updates or refinements welcome. Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pvoborni at redhat.com Mon Oct 13 10:14:55 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 13 Oct 2014 12:14:55 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <20141010155633.GF2328@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> <20141010133645.GC2328@redhat.com> <5437E820.1090303@redhat.com> <20141010143818.GE2328@redhat.com> <5437FE5B.8010708@redhat.com> <20141010155633.GF2328@redhat.com> Message-ID: <543BA61F.2060303@redhat.com> On 10.10.2014 17:56, Alexander Bokovoy wrote: > On Fri, 10 Oct 2014, Petr Vobornik wrote: >>> One more update for patch 0161, Petr noticed we need to call super >>> post_callback() too. >>> >> >> idoverrideuser_find callback causes internal error. I've attached new >> version of the patch which fixes it. Basically it's this change: >> >> >> If you are OK with it, then ACK for patches 160, 161-3, 162-1, 164 and >> 165. > I'm fine with your patch, copy/paste error, thanks for fixing it. > > also ACK for 163. patch 159 still needs review. pushed to: master: * 63be2ee9f0296e1366c77258929c7ce2dad53154 Support overridding user shell in ID views * ca42d3469a6f83376d33b08d7bb4b43c2e93d604 Allow user overrides to specify SSH public keys * b50524b10c82ed7931a2e84dbb029e8909aa8f3f Allow user overrides to specify GID of the user * 5ec23ccb5f1d21c6e6c56650c18d1b4296d59ac9 Allow override of gecos field in ID views * 6637449ad2d8885f6df43b4098f09289c7405129 Update API version for ID views support * 9fcc9a0163b7f485deae2fd000ae0ab554f9bb72 Require slapi-nis 0.54 or later for ID views support ipa-4-1: * 8a8d2e71f384bfa50477042cb8e82f14237caa7c Support overridding user shell in ID views * ad6d019b4784853c59fb2a38c5de149b02640841 Allow user overrides to specify SSH public keys * 240d93bd80a3fdc9f67640f74380eb748ffff43c Allow user overrides to specify GID of the user * aa0f5d35c5221e1d8ae270d354ff21d173b3194e Allow override of gecos field in ID views * 79c0b31c72a8d8db676f3a621371983e5d9cdf53 Update API version for ID views support * a4798c78372a66545d338b809afb45b5f9ada94d Require slapi-nis 0.54 or later for ID views support -- Petr Vobornik From mkosek at redhat.com Mon Oct 13 10:26:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 13 Oct 2014 12:26:26 +0200 Subject: [Freeipa-devel] [PATCH] 351 Support MS CA as the external CA in ipa-server-install and ipa-ca-install In-Reply-To: <54362EC9.1090005@redhat.com> References: <54350996.5010707@redhat.com> <543516AD.6020900@redhat.com> <54352410.2060005@redhat.com> <54362EC9.1090005@redhat.com> Message-ID: <543BA8D2.20807@redhat.com> On 10/09/2014 08:44 AM, Martin Kosek wrote: > On 10/08/2014 01:46 PM, Jan Cholasta wrote: >> Dne 8.10.2014 v 12:49 Martin Kosek napsal(a): >>> On 10/08/2014 11:53 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patch fixes . >>>> >>>> Note that this requires pki-core 10.2.0-3. >>>> >>>> Honza >>> >>> The approach looks OK, but I would like to be better in naming documentation: >>> >>> + cert_group.add_option("--external-ca-type", dest="external_ca_type", >>> + type="choice", choices=("generic", "ms"), >>> + help="Type of the external CA") >>> >>> I would name the option either "ad-cs" or "windows-server-ca", i.e. "Active >>> Directory Certificate Services" or "Windows Server CA". "ms" sounds too generic >>> to me in this context. When using trademarks we should be specific about what >>> do we mean. >> >> Microsoft docs refer to it as "Microsoft Certificate Services" or simply >> "Certificate Services", so I went with "ms-cs". > > Works for me. Just please update the man and refer to this type as "Microsoft > Certificate Services (MS CS)" just in case MS CS alone does not ring a bell of > a user. > > But that's just a minor issue, what is more concerning is that IPA installation > crashed with the signed CA certificate (this part worked smoothly btw): > > ... > [17/27]: setting audit signing renewal to 2 years > [18/27]: configuring certificate server to start on boot > [19/27]: restarting certificate server > [20/27]: requesting RA certificate from CA > [error] IndexError: list index out of range > Unexpected error - see /var/log/ipaserver-install.log for details: > IndexError: list index out of range > > See > https://mkosek.fedorapeople.org/ticket-4496.tgz > > for related logs. Jan found the root cause for this failure, we have a bug logged: https://bugzilla.redhat.com/show_bug.cgi?id=1151147 With related workaround specified in https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11 I was able to install FreeIPA with MS Windows 2012 AD CA. Thus, ACK, pushed to master, ipa-4-1. Next steps with this ticket will be based on how Dogtag approach the reported bug. Martin From mkosek at redhat.com Mon Oct 13 10:39:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 13 Oct 2014 12:39:35 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1412955816.3520.6.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <1412955816.3520.6.camel@redhat.com> Message-ID: <543BABE7.4020101@redhat.com> On 10/10/2014 05:43 PM, Nathaniel McCallum wrote: > As a result of this ongoing conversation, I have opened two 389 bugs: > > 1. Post Read - https://fedorahosted.org/389/ticket/47924 > 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 > > On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: >> The background of this email is this bug: >> https://fedorahosted.org/freeipa/ticket/4456 >> >> Attached are two patches which solve this issue for admin users (not >> very helpful, I know). They depend on this fix in 389: >> https://fedorahosted.org/389/ticket/47920 >> >> There are two outstanding issues: >> >> 1. 389 does not send the post read control for normal users. The >> operation itself succeeds, but no control is sent. >> >> The relevant sections from the log are attached. 389 is denying access >> to the following attributes (* = valid, ! = invalid): >> ! objectClass >> ! ipatokenOTPalgorithm >> ! ipatokenOTPdigits >> * ipatokenOTPkey >> * ipatokenHOTPcounter >> ! ipatokenOwner >> ! managedBy >> ! ipatokenUniqueID >> >> The ACIs allowing access to most of these attributes are here: >> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >> >> Note that I am able to query the entry just fine (including all the >> above invalidly restricted attributes). Hence, I know the ACIs are >> working just fine. >> >> Part of the strange thing is that in the post read control request, I >> haven't indicated that I want *any* attributes returned (i.e. I want >> just the DN). So I'm not sure why it is querying all the attributes. I >> would suspect that the proper behavior would be to only check the ACIs >> on attributes that will actually be returned. >> >> 2. The second patch (0002) modifies the ACI for normal user token >> addition from this: >> >> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and >> userattr = "managedBy#SELFDN";) >> >> To this: >> >> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, >> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >> "Users can create self-managed tokens"; allow (add) userattr = >> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) >> >> The idea is to allow users to create tokens which will be expanded by >> the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are >> checked. Since the expanded UUID no longer matches the ACI, the addition >> is denied. Is this truly the correct behavior? I would think that the >> ACIs would be checked before the UUID plugin, not after. Given the number of issues we have with this patch on the DS side, it is likely we will need to go some simpler way for FreeIPA 4.1, in terms just of hiding the option where appropriate. Also, few comments to your current patch set (though the patches themselves will probably not land in 4.1): Patch 0001: - while it may work (after DS fixes), it adds PostRead for all our commands, not just otptoken-add. I would rather have some attribute like "read_dn_from_postread" on LDAPObject which defaults to False to make sure there is no regression or performance hit with other LDAP calls. - Wider adoption of the PostRead call would be left for future, when we stop doing post-execute LDAP read call and only rely on PostRead result. Patch 0002: - "cn=IPA Token Unique IDs,cn=IPA UUID,cn=plugins,cn=config" should be created in LDAP update files only. Currently it will not be created on upgrades. Martin From pvoborni at redhat.com Mon Oct 13 10:42:42 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 13 Oct 2014 12:42:42 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <54356B81.4020505@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> Message-ID: <543BACA2.4070506@redhat.com> On 8.10.2014 18:51, Petr Vobornik wrote: > On 1.10.2014 18:15, Petr Vobornik wrote: >> Hello list, >> >> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >> > > New revisions of 761 and 763 with updated API and ACIs: > > ipa host-allow-operation HOSTNAME retrieve-keytab --users=STR --groups STR > ipa host-disallow-operation HOSTNAME retrieve-keytab --users=STR > --groups STR > ipa host-allow-operation HOSTNAME create-keytab --users=STR --groups STR > ipa host-disallow-operation HOSTNAME create-keytab --users=STR > --groups STR > > ipa service-allow-operation PRINCIPAL retrieve-keytab --users=STR > --groups STR > ipa service-disallow-operation PRINCIPAL retrieve-keytab --users=STR > --groups STR > ipa service-allow-operation PRINCIPAL create-keytab --users=STR > --groups STR > ipa service-disallow-operation PRINCIPAL create-keytab --users=STR > --groups STR > > ACIs are targeted to specific operations by including subtypes. > patch #761 rebased because of VERSION bump -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0761-3-keytab-manipulation-permission-management.patch Type: text/x-patch Size: 27241 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0763-1-tests-management-of-keytab-permissions.patch Type: text/x-patch Size: 30836 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 13 11:24:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 13 Oct 2014 13:24:10 +0200 Subject: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA Message-ID: <543BB65A.1060705@redhat.com> Hello all, Last week me, Jakub and Stef discussed a design for a candidate for a FreeIPA&Gnome keyring related thesis: https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa Apparently, there was a misunderstanding when crafting the topic proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by SSSD on user log on even in non-password authentication case (like SSO). With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring, the keyring also cannot re-encrypt itself when the long term password changes on the server (this is no problem locally as Gnome keyring is hooked to PAM password change module). Thus, there is the idea to store the master key/AUTHTOK centrally on the server. Given the sensitivity of the password, it would be best to store it in the upcoming FreeIPA Password Vault/KRA: http://www.freeipa.org/page/V4/Password_Vault However, here comes the problem with how to authorize the operation on SSSD level. To make it working, SSSD, host/client.example.com at EXAMPLE.COM would need to be able to retrieve and decipher a key from (any) user's Vault, which is probably not what we want to allow. We may add S4U2Proxy rules so that host/client.example.com at EXAMPLE.COM can get vault/server.example.com at EXAMPLE.COM for the client, but then SSSD could grab any user's secret when he logs in. Are there any ideas how to overcome this issue? Otherwise, it seems that the Vault idea is not the right way. Maybe centralizing access to Gnome keyring is not a good idea at all, we will see. Thank you. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From sbose at redhat.com Mon Oct 13 12:15:10 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 13 Oct 2014 14:15:10 +0200 Subject: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA In-Reply-To: <543BB65A.1060705@redhat.com> References: <543BB65A.1060705@redhat.com> Message-ID: <20141013121510.GF31737@localhost.localdomain> On Mon, Oct 13, 2014 at 01:24:10PM +0200, Martin Kosek wrote: > Hello all, > > Last week me, Jakub and Stef discussed a design for a candidate for a > FreeIPA&Gnome keyring related thesis: > > https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa > > Apparently, there was a misunderstanding when crafting the topic proposal, it > is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about > storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by > SSSD on user log on even in non-password authentication case (like SSO). > > With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring, > the keyring also cannot re-encrypt itself when the long term password changes > on the server (this is no problem locally as Gnome keyring is hooked to PAM > password change module). Thus, there is the idea to store the master > key/AUTHTOK centrally on the server. > > Given the sensitivity of the password, it would be best to store it in the > upcoming FreeIPA Password Vault/KRA: > > http://www.freeipa.org/page/V4/Password_Vault > > However, here comes the problem with how to authorize the operation on SSSD > level. To make it working, SSSD, host/client.example.com at EXAMPLE.COM would need > to be able to retrieve and decipher a key from (any) user's Vault, which is > probably not what we want to allow. We may add S4U2Proxy rules so that > host/client.example.com at EXAMPLE.COM can get > vault/server.example.com at EXAMPLE.COM for the client, but then SSSD could grab > any user's secret when he logs in. > > Are there any ideas how to overcome this issue? Otherwise, it seems that the > Vault idea is not the right way. Maybe centralizing access to Gnome keyring is > not a good idea at all, we will see. What about using a new authorization data type for the key. Then only the KDCs on the IPA servers need access to the key. The authorization data can be added to the service ticket of the host the user logs into. Since SSSD does ticket validation by default this service ticket would be available for password based logins as well. bye, Sumit > > Thank you. > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jcholast at redhat.com Mon Oct 13 12:48:14 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 13 Oct 2014 14:48:14 +0200 Subject: [Freeipa-devel] [PATCHES] 354-356 Check LDAP instead of local configuration to see if IPA CA is enabled Message-ID: <543BCA0E.8040208@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-354-Do-not-create-ipa-pki-proxy.conf-if-CA-is-not-config.patch Type: text/x-patch Size: 1300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-355-Do-not-fix-trust-flags-in-the-DS-NSS-DB-in-ipa-upgra.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-356-Check-LDAP-instead-of-local-configuration-to-see-if-.patch Type: text/x-patch Size: 25474 bytes Desc: not available URL: From npmccallum at redhat.com Mon Oct 13 17:23:27 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 13 Oct 2014 13:23:27 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <543BABE7.4020101@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <1412955816.3520.6.camel@redhat.com> <543BABE7.4020101@redhat.com> Message-ID: <1413221007.14998.1.camel@redhat.com> On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: > On 10/10/2014 05:43 PM, Nathaniel McCallum wrote: > > As a result of this ongoing conversation, I have opened two 389 bugs: > > > > 1. Post Read - https://fedorahosted.org/389/ticket/47924 > > 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 > > > > On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: > >> The background of this email is this bug: > >> https://fedorahosted.org/freeipa/ticket/4456 > >> > >> Attached are two patches which solve this issue for admin users (not > >> very helpful, I know). They depend on this fix in 389: > >> https://fedorahosted.org/389/ticket/47920 > >> > >> There are two outstanding issues: > >> > >> 1. 389 does not send the post read control for normal users. The > >> operation itself succeeds, but no control is sent. > >> > >> The relevant sections from the log are attached. 389 is denying access > >> to the following attributes (* = valid, ! = invalid): > >> ! objectClass > >> ! ipatokenOTPalgorithm > >> ! ipatokenOTPdigits > >> * ipatokenOTPkey > >> * ipatokenHOTPcounter > >> ! ipatokenOwner > >> ! managedBy > >> ! ipatokenUniqueID > >> > >> The ACIs allowing access to most of these attributes are here: > >> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > >> > >> Note that I am able to query the entry just fine (including all the > >> above invalidly restricted attributes). Hence, I know the ACIs are > >> working just fine. > >> > >> Part of the strange thing is that in the post read control request, I > >> haven't indicated that I want *any* attributes returned (i.e. I want > >> just the DN). So I'm not sure why it is querying all the attributes. I > >> would suspect that the proper behavior would be to only check the ACIs > >> on attributes that will actually be returned. > >> > >> 2. The second patch (0002) modifies the ACI for normal user token > >> addition from this: > >> > >> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > >> userattr = "managedBy#SELFDN";) > >> > >> To this: > >> > >> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > >> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > >> "Users can create self-managed tokens"; allow (add) userattr = > >> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > >> > >> The idea is to allow users to create tokens which will be expanded by > >> the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are > >> checked. Since the expanded UUID no longer matches the ACI, the addition > >> is denied. Is this truly the correct behavior? I would think that the > >> ACIs would be checked before the UUID plugin, not after. > > Given the number of issues we have with this patch on the DS side, it is likely > we will need to go some simpler way for FreeIPA 4.1, in terms just of hiding > the option where appropriate. We have solved the first DS issue via a sensible workaround. Attached are two new patches. These take into account your feedback below and incorporate the aforementioned workaround. The only thing these patches lack is the tightening of the ACI (problem #2 in the first email). Merging these patches I believe provides benefits over our current code, even though we don't get the final benefit of forcing normal users to use autogeneration. If we test/merge these now, then when the second DS problem is solved, we can simply update the ACI independently via a trivial second patch (s/\*/autogenerate/). > Also, few comments to your current patch set (though the patches themselves > will probably not land in 4.1): > > Patch 0001: > - while it may work (after DS fixes), it adds PostRead for all our commands, > not just otptoken-add. I would rather have some attribute like > "read_dn_from_postread" on LDAPObject which defaults to False to make sure > there is no regression or performance hit with other LDAP calls. In the new code, we actually get a performance gain as the manual post read is eliminated if the post read control is successful. Only one issue can arise, which is when the post read control evaluates ACIs in a different context than a normal manual read. This problem is well known and is trivial to fix (s/USERDN/SELFDN/). > - Wider adoption of the PostRead call would be left for future, when we stop > doing post-execute LDAP read call and only rely on PostRead result. This is already integrated. > Patch 0002: > - "cn=IPA Token Unique IDs,cn=IPA UUID,cn=plugins,cn=config" should be created > in LDAP update files only. Currently it will not be created on upgrades. Fixed. I believe the following patches are ready for review. Should we review on this thread? Or should I create separate threads for the patches? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-post-read-control-on-add-operations.patch Type: text/x-patch Size: 5071 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Use-UUID-plugin-to-generate-ipaTokenUniqueIDs.patch Type: text/x-patch Size: 10781 bytes Desc: not available URL: From ssorce at redhat.com Mon Oct 13 17:37:26 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 13 Oct 2014 13:37:26 -0400 Subject: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA In-Reply-To: <543BB65A.1060705@redhat.com> References: <543BB65A.1060705@redhat.com> Message-ID: <20141013133726.622953ae@willson.usersys.redhat.com> On Mon, 13 Oct 2014 13:24:10 +0200 Martin Kosek wrote: > Hello all, > > Last week me, Jakub and Stef discussed a design for a candidate for a > FreeIPA&Gnome keyring related thesis: > > https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa > > Apparently, there was a misunderstanding when crafting the topic > proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA > tree, but only about storing a *master key*/AUTHTOK in FreeIPA so > that keyring can be unlocked by SSSD on user log on even in > non-password authentication case (like SSO). > > With SSO, Gnome keyring cannot grab the long term secret to unlock > the keyring, the keyring also cannot re-encrypt itself when the long > term password changes on the server (this is no problem locally as > Gnome keyring is hooked to PAM password change module). Thus, there > is the idea to store the master key/AUTHTOK centrally on the server. > > Given the sensitivity of the password, it would be best to store it > in the upcoming FreeIPA Password Vault/KRA: > > http://www.freeipa.org/page/V4/Password_Vault > > However, here comes the problem with how to authorize the operation > on SSSD level. To make it working, SSSD, > host/client.example.com at EXAMPLE.COM would need to be able to retrieve > and decipher a key from (any) user's Vault, which is probably not > what we want to allow. We may add S4U2Proxy rules so that > host/client.example.com at EXAMPLE.COM can get > vault/server.example.com at EXAMPLE.COM for the client, but then SSSD > could grab any user's secret when he logs in. > > Are there any ideas how to overcome this issue? Otherwise, it seems > that the Vault idea is not the right way. Maybe centralizing access > to Gnome keyring is not a good idea at all, we will see. SSSD has access to the user credentials at authentication, that's what it should use to retrieve the user's master key. Neither using its host key nor s4u2proxy is necessary (nor advisable). Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Oct 13 17:39:51 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 13 Oct 2014 13:39:51 -0400 Subject: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA In-Reply-To: <20141013121510.GF31737@localhost.localdomain> References: <543BB65A.1060705@redhat.com> <20141013121510.GF31737@localhost.localdomain> Message-ID: <20141013133951.7ce7a7b7@willson.usersys.redhat.com> On Mon, 13 Oct 2014 14:15:10 +0200 Sumit Bose wrote: > What about using a new authorization data type for the key. Then only > the KDCs on the IPA servers need access to the key. The authorization > data can be added to the service ticket of the host the user logs > into. Since SSSD does ticket validation by default this service > ticket would be available for password based logins as well. The KDC has no way to know what is the host the user is logging on, so it would end up sending this data to any host the user logs into (think SSH). Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Oct 14 06:37:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Oct 2014 08:37:29 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1413221007.14998.1.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <1412955816.3520.6.camel@redhat.com> <543BABE7.4020101@redhat.com> <1413221007.14998.1.camel@redhat.com> Message-ID: <543CC4A9.2030803@redhat.com> On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: > On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: >> On 10/10/2014 05:43 PM, Nathaniel McCallum wrote: >>> As a result of this ongoing conversation, I have opened two 389 bugs: >>> >>> 1. Post Read - https://fedorahosted.org/389/ticket/47924 >>> 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 >>> >>> On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: >>>> The background of this email is this bug: >>>> https://fedorahosted.org/freeipa/ticket/4456 >>>> >>>> Attached are two patches which solve this issue for admin users (not >>>> very helpful, I know). They depend on this fix in 389: >>>> https://fedorahosted.org/389/ticket/47920 >>>> >>>> There are two outstanding issues: >>>> >>>> 1. 389 does not send the post read control for normal users. The >>>> operation itself succeeds, but no control is sent. >>>> >>>> The relevant sections from the log are attached. 389 is denying access >>>> to the following attributes (* = valid, ! = invalid): >>>> ! objectClass >>>> ! ipatokenOTPalgorithm >>>> ! ipatokenOTPdigits >>>> * ipatokenOTPkey >>>> * ipatokenHOTPcounter >>>> ! ipatokenOwner >>>> ! managedBy >>>> ! ipatokenUniqueID >>>> >>>> The ACIs allowing access to most of these attributes are here: >>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 >>>> >>>> Note that I am able to query the entry just fine (including all the >>>> above invalidly restricted attributes). Hence, I know the ACIs are >>>> working just fine. >>>> >>>> Part of the strange thing is that in the post read control request, I >>>> haven't indicated that I want *any* attributes returned (i.e. I want >>>> just the DN). So I'm not sure why it is querying all the attributes. I >>>> would suspect that the proper behavior would be to only check the ACIs >>>> on attributes that will actually be returned. >>>> >>>> 2. The second patch (0002) modifies the ACI for normal user token >>>> addition from this: >>>> >>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and >>>> userattr = "managedBy#SELFDN";) >>>> >>>> To this: >>>> >>>> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, >>>> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>> "Users can create self-managed tokens"; allow (add) userattr = >>>> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) >>>> >>>> The idea is to allow users to create tokens which will be expanded by >>>> the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are >>>> checked. Since the expanded UUID no longer matches the ACI, the addition >>>> is denied. Is this truly the correct behavior? I would think that the >>>> ACIs would be checked before the UUID plugin, not after. >> >> Given the number of issues we have with this patch on the DS side, it is likely >> we will need to go some simpler way for FreeIPA 4.1, in terms just of hiding >> the option where appropriate. > > We have solved the first DS issue via a sensible workaround. Attached > are two new patches. These take into account your feedback below and > incorporate the aforementioned workaround. > > The only thing these patches lack is the tightening of the ACI (problem > #2 in the first email). Merging these patches I believe provides > benefits over our current code, even though we don't get the final > benefit of forcing normal users to use autogeneration. > > If we test/merge these now, then when the second DS problem is solved, > we can simply update the ACI independently via a trivial second patch > (s/\*/autogenerate/). Ok. We can merge the patches if they at least improve the situation and prepare us for the future. >> Also, few comments to your current patch set (though the patches themselves >> will probably not land in 4.1): >> >> Patch 0001: >> - while it may work (after DS fixes), it adds PostRead for all our commands, >> not just otptoken-add. I would rather have some attribute like >> "read_dn_from_postread" on LDAPObject which defaults to False to make sure >> there is no regression or performance hit with other LDAP calls. > > In the new code, we actually get a performance gain as the manual post > read is eliminated if the post read control is successful. Only one > issue can arise, which is when the post read control evaluates ACIs in a > different context than a normal manual read. This problem is well known > and is trivial to fix (s/USERDN/SELFDN/). That's my point - with such a big change, we can hit many unforeseen issues and we are close to deadline. I would rather like to use the PostRead control only in otptoken_add command. CCing Petr and Honza to chime in. >> - Wider adoption of the PostRead call would be left for future, when we stop >> doing post-execute LDAP read call and only rely on PostRead result. > > This is already integrated. > >> Patch 0002: >> - "cn=IPA Token Unique IDs,cn=IPA UUID,cn=plugins,cn=config" should be created >> in LDAP update files only. Currently it will not be created on upgrades. > > Fixed. I would recommend testing your patches before you send them. Just based on reading the update file change I know it won't work - try yourselves :-) > I believe the following patches are ready for review. Should we review > on this thread? Or should I create separate threads for the patches? This thread is fine. You will also need to bump the Requires in our spec file, to get the fixed DS version. Martin From abokovoy at redhat.com Tue Oct 14 06:46:24 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Oct 2014 09:46:24 +0300 Subject: [Freeipa-devel] [PATCH] 0002 Ignore irrelevant subtrees in schema compat plugin In-Reply-To: <543544CF.1040309@redhat.com> References: <543544CF.1040309@redhat.com> Message-ID: <20141014064624.GK4143@redhat.com> On Wed, 08 Oct 2014, Ludwig Krispenz wrote: >Please review attached patch for ticket: >https://fedorahosted.org/freeipa/ticket/4586 > >This reduces the number of internal searches and contention for >database locks. Together with DS fix for >https://fedorahosted.org/389/ticket/47918 >the issues reported in 4586 did no longer occur. >From 1e871d2d39c7dc3e49d55ccf1d5a163d40d68dcf Mon Sep 17 00:00:00 2001 >From: Ludwig Krispenz >Date: Wed, 8 Oct 2014 15:11:54 +0200 >Subject: [PATCH] Ignore irrelevant subtrees in schema compat plugin > >For changes in cn=changelog or o=ipaca the scheam comapat plugin doesn't need to be >executed. It saves many internal searches and reduces contribution to lock >contention across backens in DS. cf ticket 4586 >--- > install/updates/10-schema_compat.update | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > >diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update >index aeddadbe3a7231e7795c1c8420dc5a1353f907cc..e5bc70350a28a0e572fa3678ba9ba5bf5075529f 100644 >--- a/install/updates/10-schema_compat.update >+++ b/install/updates/10-schema_compat.update >@@ -18,11 +18,15 @@ add: schema-compat-entry-attribute: 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCatego > add: schema-compat-entry-attribute: 'sudoRunAsUser=%ifeq("ipaSudoRunAsUserCategory","all","ALL","%deref_f(\"ipaSudoRunAs\",\"(objectclass=posixAccount)\",\"uid\")")' > add: schema-compat-entry-attribute: 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%{ipaSudoRunAsExtGroup}")' > add: schema-compat-entry-attribute: 'sudoRunAsGroup=%ifeq("ipaSudoRunAsGroupCategory","all","ALL","%deref_f(\"ipaSudoRunAsGroup\",\"(objectclass=posixGroup)\",\"cn\")")' >+add: schema-compat-ignore-subtree: cn=changelog >+add: schema-compat-ignore-subtree: o=ipaca > > # Change padding for host and userCategory so the pad returns the same value > # as the original, '' or -. > dn: cn=ng,cn=Schema Compatibility,cn=plugins,cn=config > replace: schema-compat-entry-attribute:'nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","-",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","-"),%{nisDomainName:-})::nisNetgroupTriple=(%link("%ifeq(\"hostCategory\",\"all\",\"\",\"%collect(\\\"%{externalHost}\\\",\\\"%deref(\\\\\\\"memberHost\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberHost\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"fqdn\\\\\\\")\\\")\")","%ifeq(\"hostCategory\",\"all\",\"\",\"-\")",",","%ifeq(\"userCategory\",\"all\",\"\",\"%collect(\\\"%deref(\\\\\\\"memberUser\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\",\\\"%deref_r(\\\\\\\"memberUser\\\\\\\",\\\\\\\"member\\\\\\\",\\\\\\\"uid\\\\\\\")\\\")\")","%ifeq(\"userCategory\",\"all\",\"\",\"-\")"),%{nisDomainName:-})' >+add: schema-compat-ignore-subtree: cn=changelog >+add: schema-compat-ignore-subtree: o=ipaca > > dn: cn=computers, cn=Schema Compatibility, cn=plugins, cn=config > default:objectClass: top >@@ -37,10 +41,20 @@ default:schema-compat-entry-attribute: objectclass=device > default:schema-compat-entry-attribute: objectclass=ieee802Device > default:schema-compat-entry-attribute: cn=%{fqdn} > default:schema-compat-entry-attribute: macAddress=%{macAddress} >+add: schema-compat-ignore-subtree: cn=changelog >+add: schema-compat-ignore-subtree: o=ipaca > > dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config > add:schema-compat-entry-attribute: sudoOrder=%{sudoOrder} > >+dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >+add: schema-compat-ignore-subtree: cn=changelog >+add: schema-compat-ignore-subtree: o=ipaca >+ >+dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >+add: schema-compat-ignore-subtree: cn=changelog >+add: schema-compat-ignore-subtree: o=ipaca >+ > dn: cn=Schema Compatibility,cn=plugins,cn=config > # We need to run schema-compat pre-bind callback before > # other IPA pre-bind callbacks to make sure bind DN is ACK -- / Alexander Bokovoy From jcholast at redhat.com Tue Oct 14 06:51:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Oct 2014 08:51:03 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <543CC4A9.2030803@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <1412955816.3520.6.camel@redhat.com> <543BABE7.4020101@redhat.com> <1413221007.14998.1.camel@redhat.com> <543CC4A9.2030803@redhat.com> Message-ID: <543CC7D7.3040109@redhat.com> Dne 14.10.2014 v 08:37 Martin Kosek napsal(a): > On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: >> On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: >>> Also, few comments to your current patch set (though the patches themselves >>> will probably not land in 4.1): >>> >>> Patch 0001: >>> - while it may work (after DS fixes), it adds PostRead for all our commands, >>> not just otptoken-add. I would rather have some attribute like >>> "read_dn_from_postread" on LDAPObject which defaults to False to make sure >>> there is no regression or performance hit with other LDAP calls. >> >> In the new code, we actually get a performance gain as the manual post >> read is eliminated if the post read control is successful. Only one >> issue can arise, which is when the post read control evaluates ACIs in a >> different context than a normal manual read. This problem is well known >> and is trivial to fix (s/USERDN/SELFDN/). > > That's my point - with such a big change, we can hit many unforeseen issues and > we are close to deadline. I would rather like to use the PostRead control only > in otptoken_add command. CCing Petr and Honza to chime in. I agree it should be opt-in for now. Add a boolean argument to add_entry as a switch. -- Jan Cholasta From dkupka at redhat.com Tue Oct 14 06:55:56 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 14 Oct 2014 08:55:56 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Set IPA CA for freeipa certificates In-Reply-To: <5437E781.40208@redhat.com> References: <5433FF18.6040103@redhat.com> <5437E781.40208@redhat.com> Message-ID: <543CC8FC.3040603@redhat.com> On 10/10/2014 04:04 PM, Jan Cholasta wrote: > Hi, > > Dne 7.10.2014 v 16:56 David Kupka napsal(a): >> https://fedorahosted.org/freeipa/ticket/4618 > > This works, but I would prefer if the code did not silently ignore when > the CA is not found. > > Honza > Ok, modified patch attached. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0020-2-Set-IPA-CA-for-freeipa-certificates.patch Type: text/x-patch Size: 1571 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 14 07:32:28 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Oct 2014 09:32:28 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Set IPA CA for freeipa certificates In-Reply-To: <543CC8FC.3040603@redhat.com> References: <5433FF18.6040103@redhat.com> <5437E781.40208@redhat.com> <543CC8FC.3040603@redhat.com> Message-ID: <543CD18C.8010400@redhat.com> Dne 14.10.2014 v 08:55 David Kupka napsal(a): > On 10/10/2014 04:04 PM, Jan Cholasta wrote: >> Hi, >> >> Dne 7.10.2014 v 16:56 David Kupka napsal(a): >>> https://fedorahosted.org/freeipa/ticket/4618 >> >> This works, but I would prefer if the code did not silently ignore when >> the CA is not found. >> >> Honza >> > Ok, modified patch attached. > Nitpick: no periods at the end of exception messages please. Otherwise ACK. -- Jan Cholasta From dkupka at redhat.com Tue Oct 14 07:43:39 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 14 Oct 2014 09:43:39 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Set IPA CA for freeipa certificates In-Reply-To: <543CD18C.8010400@redhat.com> References: <5433FF18.6040103@redhat.com> <5437E781.40208@redhat.com> <543CC8FC.3040603@redhat.com> <543CD18C.8010400@redhat.com> Message-ID: <543CD42B.4070303@redhat.com> On 10/14/2014 09:32 AM, Jan Cholasta wrote: > Dne 14.10.2014 v 08:55 David Kupka napsal(a): >> On 10/10/2014 04:04 PM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 7.10.2014 v 16:56 David Kupka napsal(a): >>>> https://fedorahosted.org/freeipa/ticket/4618 >>> >>> This works, but I would prefer if the code did not silently ignore when >>> the CA is not found. >>> >>> Honza >>> >> Ok, modified patch attached. >> > > Nitpick: no periods at the end of exception messages please. > > Otherwise ACK. > Removed. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0020-3-Set-IPA-CA-for-freeipa-certificates.patch Type: text/x-patch Size: 1571 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 14 07:49:01 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Oct 2014 09:49:01 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Set IPA CA for freeipa certificates In-Reply-To: <543CD42B.4070303@redhat.com> References: <5433FF18.6040103@redhat.com> <5437E781.40208@redhat.com> <543CC8FC.3040603@redhat.com> <543CD18C.8010400@redhat.com> <543CD42B.4070303@redhat.com> Message-ID: <543CD56D.3010204@redhat.com> Dne 14.10.2014 v 09:43 David Kupka napsal(a): > On 10/14/2014 09:32 AM, Jan Cholasta wrote: >> Dne 14.10.2014 v 08:55 David Kupka napsal(a): >>> On 10/10/2014 04:04 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 7.10.2014 v 16:56 David Kupka napsal(a): >>>>> https://fedorahosted.org/freeipa/ticket/4618 >>>> >>>> This works, but I would prefer if the code did not silently ignore when >>>> the CA is not found. >>>> >>>> Honza >>>> >>> Ok, modified patch attached. >>> >> >> Nitpick: no periods at the end of exception messages please. >> >> Otherwise ACK. >> > Removed. > Thanks, ACK. -- Jan Cholasta From lkrispen at redhat.com Tue Oct 14 08:12:24 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 14 Oct 2014 10:12:24 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <543B6EE0.5040107@redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <54380B8C.5060101@redhat.com> <20141010124414.588a0a6d@willson.usersys.redhat.com> <543B6EE0.5040107@redhat.com> Message-ID: <543CDAE8.8070900@redhat.com> On 10/13/2014 08:19 AM, Martin Kosek wrote: > On 10/10/2014 06:44 PM, Simo Sorce wrote: >> On Fri, 10 Oct 2014 18:38:36 +0200 >> Ludwig Krispenz wrote: >> >>> On 10/10/2014 06:30 PM, James wrote: >>>> On 10 October 2014 12:21, Simo Sorce wrote: >>>> >>>> >>>>> First thing, I do not think we want a new command here. >>>>> If we need commands outside of the ipa framework they should be >>>>> integrated in the ipa-replica-manage tool. >>>>> But really one of the reasons to move data in the shared tree was >>>>> that we could grow native framework command to handle the topology >>>>> so we can manage the topology directly from the UI. >>>>> So I am not happy with ipa-tology-manage >>>> I agree here... I think the current interface of ipa-replica-manage >>>> is fine, however the need to copy the credentials around and the >>>> need for a password are the problem. In fact, I particularly like >>>> the current interface, and puppet-ipa has already wrapped this >>>> successfully. In other words, the design checks out. Good job IPA >>>> team. >>>> >>>>> All management should happen in the shared tree, moving to be able >>>>> to avoid directly touching cn=config and avoid the need for DM >>>>> password is one of the main reasons to do this work ... >>> I'll comment later on Simmo's other comments, but I need access to >>> cn=config for two reasons, >>> - I need to know if the plugin is deployed and enabled >> Let's expose something in rootDSE then, that's the "standard" way to >> do this (though it is unnecessary, if the shared tree is present you >> already know it is available). > +1, ok for me, I was just straightforward reading cn=config to get cn=config info, but I like the idea to do it via rootdse. we have to expose the suffix(es) controlled by the topology plugin and the entry point for the shared config info. > for the plugin enabled/disabled status. However, in case you really need to > let admin or other privileged person to look in specified part of cn=config, > this can be done with standard permissions. We already have for example > permission for reading replication agreements: > > dn: cn=config > aci: (targetattr = "cn || createtimestamp || description || entryusn || > modifytimestamp || nsds50ruv || nsds5beginreplicarefresh || > nsds5debugreplicatimeout || nsds5flags || nsds5replicaabortcleanruv || ... > winsyncsubtreepair || winsyncwindowsfilter")(targetfilter = > "(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version > 3.0;acl "permission:System: Read Replication Agreements"; allow > (compare,read,search) groupdn = "ldap:///cn=System: Read Replication > Agreements,cn=permissions, cn=pbac,dc=ipa,dc=example";) > > Martin From lkrispen at redhat.com Tue Oct 14 08:21:57 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 14 Oct 2014 10:21:57 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <20141010122154.1c693f05@willson.usersys.redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> Message-ID: <543CDD25.1090407@redhat.com> On 10/10/2014 06:21 PM, Simo Sorce wrote: > On Fri, 10 Oct 2014 17:52:15 +0200 > Ludwig Krispenz wrote: > >> Hello, >> >> this is the current status of my work on #4302, and there are a few >> pieces still missing, eg the management command needs more input >> checking and error handling, but >> - I wanted to give people interested a chance to have a look again >> and get feedback >> - there came up the following questions I would like to get an >> opinion. > First thing, I do not think we want a new command here. > If we need commands outside of the ipa framework they should be > integrated in the ipa-replica-manage tool. > But really one of the reasons to move data in the shared tree was that > we could grow native framework command to handle the topology so we can > manage the topology directly from the UI. > So I am not happy with ipa-tology-manage we already have ipa-replica-manage and ipa-csreplica-manage, and - I did'n want to integrate the topology management into both and duplicate code - there is much change on the way to refactor the ipa commands, to move code into libraries, to expose to openLMI and I have no clear picture yet how this will look like, so I thought implementing the management command as subclasses of admintool would be a good starting point - I do not insist that ipa-topology-manage will survive as a command in the end, but I also do not want to mess with ipa-replica-manage and ipa-csreplica-manage now, when these changes also probably would have no future. > e > >> when thinking how to move from an existing deployment with direct >> management of replication agreement to the new way, there should not >> be any intermediate disconnects, and if possible transition should be >> made easy. So I think we should have defined a few modes of operation >> for the plugin: >> - initial/bootstrap [optional] - the plugin detects existing >> agreements and transforms it to segments in the shared tree > This should not be optional imo, its the only way to do sane upgrades. > When the plugin starts it needs to check if there are replication > agreements with other freeipa servers (it should ignore anything else). > > Then check if these agreements have been autogenerated (this should be > determined by new naming conventions for agreements in cn=config) or > if they are pre-existing, if they are pre-existing then new shared > entries will be generated in the shared tree. > > Note: this upgrade thing could also be done in ipa-upgrade plugins, at > server upgrade time. Whichever is easier (main concern is if 2 servers > are upgraded at the same time replication conflicts may arise). > >> - pending - the plugin handles and propagates segments in the shared >> tree, but does not enforce teh deletion or creation of replication >> agreements > Not sure what you mean here, but I think that once the plugin is > active it should stay active and actively prevent manual changes to > automatically created replication agreements. > >> - active - directe management of replicatio agreements is rejected, >> existing segments ond their modifications are applied > This should always be. > >> I did run my tests of the management command as directory manager >> since admin did not have permissions to read plugin configuration in >> cn=config, > Why would you need to access cn=config ? > All management should happen in the shared tree, moving to be able to > avoid directly touching cn=config and avoid the need for DM password is > one of the main reasons to do this work ... > >> I can add permissions, probably will also need permissions >> for the part in the shared tree, so what is the expected operation >> mode, which user needs access to the shared config data and >> configuration ? > We need to introduce a role for "Replication Admins" and make the > admins group a member by default, then use normal permissions framework > to regulate access. > > Simo. > > From pviktori at redhat.com Tue Oct 14 08:23:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Oct 2014 10:23:09 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <543CC7D7.3040109@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <1412955816.3520.6.camel@redhat.com> <543BABE7.4020101@redhat.com> <1413221007.14998.1.camel@redhat.com> <543CC4A9.2030803@redhat.com> <543CC7D7.3040109@redhat.com> Message-ID: <543CDD6D.1090306@redhat.com> On 10/14/2014 08:51 AM, Jan Cholasta wrote: > Dne 14.10.2014 v 08:37 Martin Kosek napsal(a): >> On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: >>> On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: >>>> Also, few comments to your current patch set (though the patches >>>> themselves >>>> will probably not land in 4.1): >>>> >>>> Patch 0001: >>>> - while it may work (after DS fixes), it adds PostRead for all our >>>> commands, >>>> not just otptoken-add. I would rather have some attribute like >>>> "read_dn_from_postread" on LDAPObject which defaults to False to >>>> make sure >>>> there is no regression or performance hit with other LDAP calls. As Honza says later in the mail, this should be an argument for add_entry (or alternatively an additional add_entry_with_postread method). Storing settings in data objects leads to trouble ? when you get such an object from somewhere, you never know what an operation on it will do. >>> In the new code, we actually get a performance gain as the manual post >>> read is eliminated if the post read control is successful. Only one >>> issue can arise, which is when the post read control evaluates ACIs in a >>> different context than a normal manual read. This problem is well known >>> and is trivial to fix (s/USERDN/SELFDN/). >> >> That's my point - with such a big change, we can hit many unforeseen >> issues and >> we are close to deadline. I would rather like to use the PostRead >> control only >> in otptoken_add command. CCing Petr and Honza to chime in. > > I agree it should be opt-in for now. Add a boolean argument to add_entry > as a switch. +1 Also, I think the add_entry should not return anything; rather the PostRead result should be merged into the added entry object. Honza, what do you think? In the future it might be useful for add_entry to return a list of controls, the `ctrls` in this patch. -- Petr? From jcholast at redhat.com Tue Oct 14 08:38:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Oct 2014 10:38:23 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <543CDD6D.1090306@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <1412955816.3520.6.camel@redhat.com> <543BABE7.4020101@redhat.com> <1413221007.14998.1.camel@redhat.com> <543CC4A9.2030803@redhat.com> <543CC7D7.3040109@redhat.com> <543CDD6D.1090306@redhat.com> Message-ID: <543CE0FF.3050404@redhat.com> Dne 14.10.2014 v 10:23 Petr Viktorin napsal(a): > On 10/14/2014 08:51 AM, Jan Cholasta wrote: >> Dne 14.10.2014 v 08:37 Martin Kosek napsal(a): >>> On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: >>>> On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: >>>>> Also, few comments to your current patch set (though the patches >>>>> themselves >>>>> will probably not land in 4.1): >>>>> >>>>> Patch 0001: >>>>> - while it may work (after DS fixes), it adds PostRead for all our >>>>> commands, >>>>> not just otptoken-add. I would rather have some attribute like >>>>> "read_dn_from_postread" on LDAPObject which defaults to False to >>>>> make sure >>>>> there is no regression or performance hit with other LDAP calls. > > As Honza says later in the mail, this should be an argument for > add_entry (or alternatively an additional add_entry_with_postread > method). Storing settings in data objects leads to trouble ? when you > get such an object from somewhere, you never know what an operation on > it will do. I would prefer add_entry argument rather than a new method, as that's how find_entries does controls. > >>>> In the new code, we actually get a performance gain as the manual post >>>> read is eliminated if the post read control is successful. Only one >>>> issue can arise, which is when the post read control evaluates ACIs >>>> in a >>>> different context than a normal manual read. This problem is well known >>>> and is trivial to fix (s/USERDN/SELFDN/). >>> >>> That's my point - with such a big change, we can hit many unforeseen >>> issues and >>> we are close to deadline. I would rather like to use the PostRead >>> control only >>> in otptoken_add command. CCing Petr and Honza to chime in. >> >> I agree it should be opt-in for now. Add a boolean argument to add_entry >> as a switch. > > +1 > > Also, I think the add_entry should not return anything; rather the > PostRead result should be merged into the added entry object. Honza, > what do you think? It should, good point. > > In the future it might be useful for add_entry to return a list of > controls, the `ctrls` in this patch. > -- Jan Cholasta From tbabej at redhat.com Tue Oct 14 08:46:57 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 14 Oct 2014 10:46:57 +0200 Subject: [Freeipa-devel] WFH 2014-10-14 Message-ID: <543CE301.9020008@redhat.com> -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Tue Oct 14 08:47:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Oct 2014 10:47:33 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <543CDD25.1090407@redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <543CDD25.1090407@redhat.com> Message-ID: <543CE325.6040709@redhat.com> On 10/14/2014 10:21 AM, Ludwig Krispenz wrote: > > On 10/10/2014 06:21 PM, Simo Sorce wrote: >> On Fri, 10 Oct 2014 17:52:15 +0200 >> Ludwig Krispenz wrote: >> >>> Hello, >>> >>> this is the current status of my work on #4302, and there are a few >>> pieces still missing, eg the management command needs more input >>> checking and error handling, but >>> - I wanted to give people interested a chance to have a look again >>> and get feedback >>> - there came up the following questions I would like to get an >>> opinion. >> First thing, I do not think we want a new command here. >> If we need commands outside of the ipa framework they should be >> integrated in the ipa-replica-manage tool. >> But really one of the reasons to move data in the shared tree was that >> we could grow native framework command to handle the topology so we can >> manage the topology directly from the UI. >> So I am not happy with ipa-tology-manage > we already have ipa-replica-manage and ipa-csreplica-manage, and > - I did'n want to integrate the topology management into both and > duplicate code > - there is much change on the way to refactor the ipa commands, to move > code into libraries, to expose to openLMI > and I have no clear picture yet how this will look like, so I thought > implementing the management command as subclasses of admintool would be > a good starting point - I do not insist that ipa-topology-manage will > survive as a command in the end, but I also do not want to mess with > ipa-replica-manage and ipa-csreplica-manage now, when these changes also > probably would have no future. +1 Given the pending refactoring of ipa-replica-manage, I think a separate tool for now is better way to get to the result Simo wants. For now I'd put a TODO in ipa_topology_manage saying the CLI is not final. Of course, if anything can be moved to framework commands, that should happen now. Ludwig, please use self.log.info(...) (or .error(), etc.) instead of print for messages, unless the message doesn't make sense in a log file (e.g. prompting for interactive input). -- Petr? From jcholast at redhat.com Tue Oct 14 08:52:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Oct 2014 10:52:48 +0200 Subject: [Freeipa-devel] [PATCH] 333 Handle profile changes in dogtag-ipa-ca-renew-agent Message-ID: <543CE460.7070006@redhat.com> Hi, the attached patch fixes . (The original patch was posted at .) How to test: 1. install server 2. run "ipa-certupdate" 3. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca'", the request should be in CA_WORKING state 4. run "ipa-cacert-manage renew" 5. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca'", the request should be in MONITORING state, there should be no ca-error Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-333.2-Handle-profile-changes-in-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 6851 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 14 08:57:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Oct 2014 10:57:12 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Set IPA CA for freeipa certificates In-Reply-To: <543CD56D.3010204@redhat.com> References: <5433FF18.6040103@redhat.com> <5437E781.40208@redhat.com> <543CC8FC.3040603@redhat.com> <543CD18C.8010400@redhat.com> <543CD42B.4070303@redhat.com> <543CD56D.3010204@redhat.com> Message-ID: <543CE568.3020304@redhat.com> On 10/14/2014 09:49 AM, Jan Cholasta wrote: > Dne 14.10.2014 v 09:43 David Kupka napsal(a): >> On 10/14/2014 09:32 AM, Jan Cholasta wrote: >>> Dne 14.10.2014 v 08:55 David Kupka napsal(a): >>>> On 10/10/2014 04:04 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 7.10.2014 v 16:56 David Kupka napsal(a): >>>>>> https://fedorahosted.org/freeipa/ticket/4618 >>>>> >>>>> This works, but I would prefer if the code did not silently ignore >>>>> when >>>>> the CA is not found. >>>>> >>>>> Honza >>>>> >>>> Ok, modified patch attached. >>>> >>> >>> Nitpick: no periods at the end of exception messages please. >>> >>> Otherwise ACK. >>> >> Removed. >> > > Thanks, ACK. > Pushed to: master: c8f7cb0163c766aa46a3435dfc9984bf8761f27d ipa-4-1: eea9da2a1b751534035aea71aa4f0ad5ecf31b09 ipa-4-0: 2e7f8da23810babf9d0e7312c495e86535593a83 -- Petr? From pviktori at redhat.com Tue Oct 14 09:01:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 14 Oct 2014 11:01:38 +0200 Subject: [Freeipa-devel] [PATCH] 0002 Ignore irrelevant subtrees in schema compat plugin In-Reply-To: <20141014064624.GK4143@redhat.com> References: <543544CF.1040309@redhat.com> <20141014064624.GK4143@redhat.com> Message-ID: <543CE672.2070704@redhat.com> On 10/14/2014 08:46 AM, Alexander Bokovoy wrote: > On Wed, 08 Oct 2014, Ludwig Krispenz wrote: >> Please review attached patch for ticket: >> https://fedorahosted.org/freeipa/ticket/4586 >> >> This reduces the number of internal searches and contention for >> database locks. Together with DS fix for >> https://fedorahosted.org/389/ticket/47918 >> the issues reported in 4586 did no longer occur. > >> From 1e871d2d39c7dc3e49d55ccf1d5a163d40d68dcf Mon Sep 17 00:00:00 2001 >> From: Ludwig Krispenz >> Date: Wed, 8 Oct 2014 15:11:54 +0200 >> Subject: [PATCH] Ignore irrelevant subtrees in schema compat plugin >> >> For changes in cn=changelog or o=ipaca the scheam comapat plugin >> doesn't need to be >> executed. It saves many internal searches and reduces contribution to >> lock >> contention across backens in DS. cf ticket 4586 > ACK Added ticket link to commit message, pushed to: master: 08c3fe17ef5ef103068fe09a4e855ada11381b03 ipa-4-1: 57eab1e18e5371c9edc41b1f1e98ead56f741eae ipa-4-0: 86b5dce4d837c7c03d370287fc30416d16b1dd82 -- Petr? From lkrispen at redhat.com Tue Oct 14 09:46:47 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 14 Oct 2014 11:46:47 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <20141010122154.1c693f05@willson.usersys.redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> Message-ID: <543CF107.9010209@redhat.com> On 10/10/2014 06:21 PM, Simo Sorce wrote: > On Fri, 10 Oct 2014 17:52:15 +0200 > Ludwig Krispenz wrote: > >> Hello, >> >> this is the current status of my work on #4302, and there are a few >> pieces still missing, eg the management command needs more input >> checking and error handling, but >> - I wanted to give people interested a chance to have a look again >> and get feedback >> - there came up the following questions I would like to get an >> opinion. > First thing, I do not think we want a new command here. > If we need commands outside of the ipa framework they should be > integrated in the ipa-replica-manage tool. > But really one of the reasons to move data in the shared tree was that > we could grow native framework command to handle the topology so we can > manage the topology directly from the UI. > So I am not happy with ipa-tology-manage > >> when thinking how to move from an existing deployment with direct >> management of replication agreement to the new way, there should not >> be any intermediate disconnects, and if possible transition should be >> made easy. So I think we should have defined a few modes of operation >> for the plugin: >> - initial/bootstrap [optional] - the plugin detects existing >> agreements and transforms it to segments in the shared tree > This should not be optional imo, its the only way to do sane upgrades. > When the plugin starts it needs to check if there are replication > agreements with other freeipa servers (it should ignore anything else). it is fine for me if it is not optional, I agree that it is needed for smooth upgrades. the reason that I brought this up is that I had the impression that it is not wanted, that configuration should be in full responsibility of an admin creating the shared topology from scratch. If we agree that the shared topology should be populated from existing agreements I'm happy, if not I would make it at least optional. the problem to solve is, when does this auto generation stop ? I think it should be done only once, at the initial startup of the plugin and not allow to bypass the topology plugin later by stopping th eserver, editing cn=config to add a new agreement and having it added at startup to the shared tree, so there shoul be some way to flag that the initial phase is done. I'm not sure if this can and should be handled with naming conventions. > > Then check if these agreements have been autogenerated (this should be > determined by new naming conventions for agreements in cn=config) or > if they are pre-existing, if they are pre-existing then new shared > entries will be generated in the shared tree. > > Note: this upgrade thing could also be done in ipa-upgrade plugins, at > server upgrade time. Whichever is easier (main concern is if 2 servers > are upgraded at the same time replication conflicts may arise). > >> - pending - the plugin handles and propagates segments in the shared >> tree, but does not enforce teh deletion or creation of replication >> agreements > Not sure what you mean here, but I think that once the plugin is > active it should stay active and actively prevent manual changes to > automatically created replication agreements. why I wanted this state had two reasons. - Since the information in the shared tree is authoritative and if you start to build the shared tree from scratch (if the above initialization would not be done) there is the problem that adding the shared topology is not atomic, one segment is added, all others do not yet exist and other replication agreements would be deleted, in the best case replication is just interrupted. So I was suggesting a pending mode, you can add/delete segments from the shared tree, verify connectivity and then say go and let the shared tree become authoritative. - A similar problem arises when adding a new replica, we had decided to leave ipa-replica-install untouched, so it will install a new server and try to setup replication agreements between the server replica-prepare was run and the new replica, but it would be rejected by the plugin when it is enforcing new agreements to be generated only via shared config. So temporariliy disable the authority of the plugin could help. > >> - active - directe management of replicatio agreements is rejected, >> existing segments ond their modifications are applied > This should always be. > >> I did run my tests of the management command as directory manager >> since admin did not have permissions to read plugin configuration in >> cn=config, > Why would you need to access cn=config ? > All management should happen in the shared tree, moving to be able to > avoid directly touching cn=config and avoid the need for DM password is > one of the main reasons to do this work ... > >> I can add permissions, probably will also need permissions >> for the part in the shared tree, so what is the expected operation >> mode, which user needs access to the shared config data and >> configuration ? > We need to introduce a role for "Replication Admins" and make the > admins group a member by default, then use normal permissions framework > to regulate access. > > Simo. > > From dkupka at redhat.com Tue Oct 14 10:47:22 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 14 Oct 2014 12:47:22 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <5437DE1E.3000307@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> <543513B3.9060808@redhat.com> <5437DE1E.3000307@redhat.com> Message-ID: <543CFF3A.7000607@redhat.com> On 10/10/2014 03:24 PM, Jan Cholasta wrote: > Dne 8.10.2014 v 12:36 David Kupka napsal(a): >> On 10/08/2014 09:29 AM, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 8.10.2014 v 09:09 David Kupka napsal(a): >>>> https://fedorahosted.org/freeipa/ticket/4569 >>> >>> In renew_ca_cert and cainstance.py, dogtag should already be stopped in >>> the places you modified, so why the change? >> >> I didn't noticed that it is already stopped, fixed. >>> >>> Also I don't think it's a good idea to backup CS.cfg when dogtag is >>> still running (in cainstance.py). If the file is being modified by >>> dogtag at the time it is backed up, the backup may be corrupted. >>> >> Fixed, thanks. > > CAInstance.backup_config should be called only when Dogtag is stopped as > well, you don't need to change it. > backup_config is callable from outside of cainstance.py so it's safer to check that dogtag is stopped and stop it if necessary. When dogtag is already stopped it won't do anything. >> >>> Honza >>> >> > > It would be better to stop and start dogtag only once in > ipa-upgradeconfig, not every time there is a modification to CS.cfg. > OK. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-3-ipa40-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 4795 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-3-ipa41-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 4833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-3-master-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 4817 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 14 11:21:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Oct 2014 13:21:53 +0200 Subject: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA In-Reply-To: <20141013133726.622953ae@willson.usersys.redhat.com> References: <543BB65A.1060705@redhat.com> <20141013133726.622953ae@willson.usersys.redhat.com> Message-ID: <543D0751.8040401@redhat.com> On 10/13/2014 07:37 PM, Simo Sorce wrote: > On Mon, 13 Oct 2014 13:24:10 +0200 > Martin Kosek wrote: > >> Hello all, >> >> Last week me, Jakub and Stef discussed a design for a candidate for a >> FreeIPA&Gnome keyring related thesis: >> >> https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa >> >> Apparently, there was a misunderstanding when crafting the topic >> proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA >> tree, but only about storing a *master key*/AUTHTOK in FreeIPA so >> that keyring can be unlocked by SSSD on user log on even in >> non-password authentication case (like SSO). >> >> With SSO, Gnome keyring cannot grab the long term secret to unlock >> the keyring, the keyring also cannot re-encrypt itself when the long >> term password changes on the server (this is no problem locally as >> Gnome keyring is hooked to PAM password change module). Thus, there >> is the idea to store the master key/AUTHTOK centrally on the server. >> >> Given the sensitivity of the password, it would be best to store it >> in the upcoming FreeIPA Password Vault/KRA: >> >> http://www.freeipa.org/page/V4/Password_Vault >> >> However, here comes the problem with how to authorize the operation >> on SSSD level. To make it working, SSSD, >> host/client.example.com at EXAMPLE.COM would need to be able to retrieve >> and decipher a key from (any) user's Vault, which is probably not >> what we want to allow. We may add S4U2Proxy rules so that >> host/client.example.com at EXAMPLE.COM can get >> vault/server.example.com at EXAMPLE.COM for the client, but then SSSD >> could grab any user's secret when he logs in. >> >> Are there any ideas how to overcome this issue? Otherwise, it seems >> that the Vault idea is not the right way. Maybe centralizing access >> to Gnome keyring is not a good idea at all, we will see. > > SSSD has access to the user credentials at authentication, that's what > it should use to retrieve the user's master key. I am confused. I thought this would only work if someone authenticates with user+password or sends his TGT, right? Otherwise SSSD cannot use user credentials... It is true that authenticating with user+password will still be the most common authentication method on desktop interactive login, so it should cover the most scenarios. Question is if we are even interested in use cases like unlocking GNOME keyring after ssh-ing to a host with Kerberos. Martin > Neither using its host key nor s4u2proxy is necessary (nor advisable). From jcholast at redhat.com Tue Oct 14 11:39:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Oct 2014 13:39:05 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <543CFF3A.7000607@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> <543513B3.9060808@redhat.com> <5437DE1E.3000307@redhat.com> <543CFF3A.7000607@redhat.com> Message-ID: <543D0B59.8070102@redhat.com> Dne 14.10.2014 v 12:47 David Kupka napsal(a): > > > On 10/10/2014 03:24 PM, Jan Cholasta wrote: >> Dne 8.10.2014 v 12:36 David Kupka napsal(a): >>> On 10/08/2014 09:29 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 8.10.2014 v 09:09 David Kupka napsal(a): >>>>> https://fedorahosted.org/freeipa/ticket/4569 >>>> >>>> In renew_ca_cert and cainstance.py, dogtag should already be stopped in >>>> the places you modified, so why the change? >>> >>> I didn't noticed that it is already stopped, fixed. >>>> >>>> Also I don't think it's a good idea to backup CS.cfg when dogtag is >>>> still running (in cainstance.py). If the file is being modified by >>>> dogtag at the time it is backed up, the backup may be corrupted. >>>> >>> Fixed, thanks. >> >> CAInstance.backup_config should be called only when Dogtag is stopped as >> well, you don't need to change it. >> > > backup_config is callable from outside of cainstance.py so it's safer to > check that dogtag is stopped and stop it if necessary. When dogtag is > already stopped it won't do anything. If dogtag is not stopped in backup_config, it's an error, so an exception should be raised. You should use stopped_service only in places where you actually want dogtag to become stopped. If there were multiple consecutive stopped_service calls when dogtag should be stopped but isn't, it would cause multiple dogtag restarts, which would work, but it would waste time and be hard to debug. > >>> >>>> Honza >>>> >>> >> >> It would be better to stop and start dogtag only once in >> ipa-upgradeconfig, not every time there is a modification to CS.cfg. >> > OK. > > > -- Jan Cholasta From pspacek at redhat.com Tue Oct 14 11:44:40 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 Oct 2014 13:44:40 +0200 Subject: [Freeipa-devel] [PATCH 0131-0132] Add missing attributes to named.conf In-Reply-To: <54377745.4000204@redhat.com> References: <542E7E48.2020900@redhat.com> <54377745.4000204@redhat.com> Message-ID: <543D0CA8.8010805@redhat.com> On 10.10.2014 08:05, David Kupka wrote: > On 10/03/2014 12:45 PM, Martin Basti wrote: >> Hello! >> >> Patch 131: >> https://fedorahosted.org/freeipa/ticket/3801#comment:31 >> >> Patch 132: >> I modified named.conf in 131, so I change the rest of paths to be >> ipaplatform specified. >> >> Patches attached >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Hi! > The upgrade processes looks fine to me. And I didn't find any surprise in the > code. So it's A and C/2 from me. For the rest go to Petr^2. Full ACK. Thank you! -- Petr^2 Spacek From pspacek at redhat.com Tue Oct 14 11:45:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 14 Oct 2014 13:45:51 +0200 Subject: [Freeipa-devel] [PATCH 0131-0132] Add missing attributes to named.conf In-Reply-To: <543D0CA8.8010805@redhat.com> References: <542E7E48.2020900@redhat.com> <54377745.4000204@redhat.com> <543D0CA8.8010805@redhat.com> Message-ID: <543D0CEF.8070704@redhat.com> On 14.10.2014 13:44, Petr Spacek wrote: > On 10.10.2014 08:05, David Kupka wrote: >> On 10/03/2014 12:45 PM, Martin Basti wrote: >>> Hello! >>> >>> Patch 131: >>> https://fedorahosted.org/freeipa/ticket/3801#comment:31 >>> >>> Patch 132: >>> I modified named.conf in 131, so I change the rest of paths to be >>> ipaplatform specified. >>> >>> Patches attached >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Hi! >> The upgrade processes looks fine to me. And I didn't find any surprise in the >> code. So it's A and C/2 from me. For the rest go to Petr^2. > > Full ACK. Thank you! BTW this can be pushed right away. It should not depend on other DNSSEC patches and should not break anything. -- Petr^2 Spacek From mkosek at redhat.com Tue Oct 14 11:57:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Oct 2014 13:57:55 +0200 Subject: [Freeipa-devel] [PATCH 0131-0132] Add missing attributes to named.conf In-Reply-To: <543D0CA8.8010805@redhat.com> References: <542E7E48.2020900@redhat.com> <54377745.4000204@redhat.com> <543D0CA8.8010805@redhat.com> Message-ID: <543D0FC3.4040804@redhat.com> On 10/14/2014 01:44 PM, Petr Spacek wrote: > On 10.10.2014 08:05, David Kupka wrote: >> On 10/03/2014 12:45 PM, Martin Basti wrote: >>> Hello! >>> >>> Patch 131: >>> https://fedorahosted.org/freeipa/ticket/3801#comment:31 >>> >>> Patch 132: >>> I modified named.conf in 131, so I change the rest of paths to be >>> ipaplatform specified. >>> >>> Patches attached >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> Hi! >> The upgrade processes looks fine to me. And I didn't find any surprise in the >> code. So it's A and C/2 from me. For the rest go to Petr^2. > > Full ACK. Thank you! > Pushed to: master: 7ad70025eb2deaf5c7c79149673dc2fbde2b7c2c ipa-4-1: bac2cc979907b1069ccb0c563636b6e06f9a0721 Martin From dkupka at redhat.com Tue Oct 14 12:19:45 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 14 Oct 2014 14:19:45 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <543D0B59.8070102@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> <543513B3.9060808@redhat.com> <5437DE1E.3000307@redhat.com> <543CFF3A.7000607@redhat.com> <543D0B59.8070102@redhat.com> Message-ID: <543D14E1.5080702@redhat.com> On 10/14/2014 01:39 PM, Jan Cholasta wrote: > Dne 14.10.2014 v 12:47 David Kupka napsal(a): >> >> >> On 10/10/2014 03:24 PM, Jan Cholasta wrote: >>> Dne 8.10.2014 v 12:36 David Kupka napsal(a): >>>> On 10/08/2014 09:29 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 8.10.2014 v 09:09 David Kupka napsal(a): >>>>>> https://fedorahosted.org/freeipa/ticket/4569 >>>>> >>>>> In renew_ca_cert and cainstance.py, dogtag should already be >>>>> stopped in >>>>> the places you modified, so why the change? >>>> >>>> I didn't noticed that it is already stopped, fixed. >>>>> >>>>> Also I don't think it's a good idea to backup CS.cfg when dogtag is >>>>> still running (in cainstance.py). If the file is being modified by >>>>> dogtag at the time it is backed up, the backup may be corrupted. >>>>> >>>> Fixed, thanks. >>> >>> CAInstance.backup_config should be called only when Dogtag is stopped as >>> well, you don't need to change it. >>> >> >> backup_config is callable from outside of cainstance.py so it's safer to >> check that dogtag is stopped and stop it if necessary. When dogtag is >> already stopped it won't do anything. > > If dogtag is not stopped in backup_config, it's an error, so an > exception should be raised. > > You should use stopped_service only in places where you actually want > dogtag to become stopped. If there were multiple consecutive > stopped_service calls when dogtag should be stopped but isn't, it would > cause multiple dogtag restarts, which would work, but it would waste > time and be hard to debug. Ok, thanks for explanation. > >> >>>> >>>>> Honza >>>>> >>>> >>> >>> It would be better to stop and start dogtag only once in >>> ipa-upgradeconfig, not every time there is a modification to CS.cfg. >>> >> OK. >> >> >> > > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-4-ipa40-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 3910 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-4-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 3948 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 14 12:28:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Oct 2014 14:28:53 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <543D14E1.5080702@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> <543513B3.9060808@redhat.com> <5437DE1E.3000307@redhat.com> <543CFF3A.7000607@redhat.com> <543D0B59.8070102@redhat.com> <543D14E1.5080702@redhat.com> Message-ID: <543D1705.9020307@redhat.com> Dne 14.10.2014 v 14:19 David Kupka napsal(a): > > > On 10/14/2014 01:39 PM, Jan Cholasta wrote: >> Dne 14.10.2014 v 12:47 David Kupka napsal(a): >>> >>> >>> On 10/10/2014 03:24 PM, Jan Cholasta wrote: >>>> Dne 8.10.2014 v 12:36 David Kupka napsal(a): >>>>> On 10/08/2014 09:29 AM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> Dne 8.10.2014 v 09:09 David Kupka napsal(a): >>>>>>> https://fedorahosted.org/freeipa/ticket/4569 >>>>>> >>>>>> In renew_ca_cert and cainstance.py, dogtag should already be >>>>>> stopped in >>>>>> the places you modified, so why the change? >>>>> >>>>> I didn't noticed that it is already stopped, fixed. >>>>>> >>>>>> Also I don't think it's a good idea to backup CS.cfg when dogtag is >>>>>> still running (in cainstance.py). If the file is being modified by >>>>>> dogtag at the time it is backed up, the backup may be corrupted. >>>>>> >>>>> Fixed, thanks. >>>> >>>> CAInstance.backup_config should be called only when Dogtag is >>>> stopped as >>>> well, you don't need to change it. >>>> >>> >>> backup_config is callable from outside of cainstance.py so it's safer to >>> check that dogtag is stopped and stop it if necessary. When dogtag is >>> already stopped it won't do anything. >> >> If dogtag is not stopped in backup_config, it's an error, so an >> exception should be raised. What I meant by this is that you should add this check to backup_config, because it's not there ATM. Sorry for confusing you. -- Jan Cholasta From simo at redhat.com Tue Oct 14 12:39:53 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Oct 2014 08:39:53 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <543CDAE8.8070900@redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <54380B8C.5060101@redhat.com> <20141010124414.588a0a6d@willson.usersys.redhat.com> <543B6EE0.5040107@redhat.com> <543CDAE8.8070900@redhat.com> Message-ID: <20141014083953.55946afc@willson.usersys.redhat.com> On Tue, 14 Oct 2014 10:12:24 +0200 Ludwig Krispenz wrote: > ok for me, I was just straightforward reading cn=config to get > cn=config info, but I like the idea to do it via rootdse. > we have to expose the suffix(es) controlled by the topology plugin > and the entry point for the shared config info. I was thinking in rootDSE we'd expose just if the feature was available. For IPA that would suffice, for generic 389ds then you'd have top look at configuration to find DNs. I am not sure exposing DNs directly from rootDSE is necessary. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Oct 14 12:41:48 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Oct 2014 08:41:48 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <543CDD25.1090407@redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <543CDD25.1090407@redhat.com> Message-ID: <20141014084148.3deae70b@willson.usersys.redhat.com> On Tue, 14 Oct 2014 10:21:57 +0200 Ludwig Krispenz wrote: > we already have ipa-replica-manage and ipa-csreplica-manage, and > - I did'n want to integrate the topology management into both and > duplicate code > - there is much change on the way to refactor the ipa commands, to > move code into libraries, to expose to openLMI > and I have no clear picture yet how this will look like, so I thought > implementing the management command as subclasses of admintool would > be a good starting point - I do not insist that ipa-topology-manage > will survive as a command in the end, but I also do not want to mess > with ipa-replica-manage and ipa-csreplica-manage now, when these > changes also probably would have no future. The ideal outcome is to have commands in the admintools indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Tue Oct 14 13:10:21 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 14 Oct 2014 15:10:21 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <20141014083953.55946afc@willson.usersys.redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <54380B8C.5060101@redhat.com> <20141010124414.588a0a6d@willson.usersys.redhat.com> <543B6EE0.5040107@redhat.com> <543CDAE8.8070900@redhat.com> <20141014083953.55946afc@willson.usersys.redhat.com> Message-ID: <543D20BD.7010007@redhat.com> On 10/14/2014 02:39 PM, Simo Sorce wrote: > On Tue, 14 Oct 2014 10:12:24 +0200 > Ludwig Krispenz wrote: > >> ok for me, I was just straightforward reading cn=config to get >> cn=config info, but I like the idea to do it via rootdse. >> we have to expose the suffix(es) controlled by the topology plugin >> and the entry point for the shared config info. > I was thinking in rootDSE we'd expose just if the feature was available. > For IPA that would suffice, for generic 389ds then you'd have top look > at configuration to find DNs. > I am not sure exposing DNs directly from rootDSE is necessary. I had two cases in mind, which I think would apply to IPA. - in an IPA installation in many scenarios you two suffixes: "dc=.....,dc=com" and "o=ipaca". It could be possible to use the plugin to manage "dc=.." only. Or do you say it's all or nothing ? If there is a choice, client utilities need to be able to find out which suffix is managed. - even in an ipa installation nobody prevents an admin to add other backends to the directory server for other usage, so you might have "dc=example,dc=com" "dc=test,dc=com" "dc=anotherbackend,dc=com" "o=ipaca" in which suffix is the shared topology data ? should we query each suffix to see if something useful is returned ? > > Simo. > From rcritten at redhat.com Tue Oct 14 13:17:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Oct 2014 09:17:46 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <20141014084148.3deae70b@willson.usersys.redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <543CDD25.1090407@redhat.com> <20141014084148.3deae70b@willson.usersys.redhat.com> Message-ID: <543D227A.1070301@redhat.com> Simo Sorce wrote: > On Tue, 14 Oct 2014 10:21:57 +0200 > Ludwig Krispenz wrote: > >> we already have ipa-replica-manage and ipa-csreplica-manage, and >> - I did'n want to integrate the topology management into both and >> duplicate code >> - there is much change on the way to refactor the ipa commands, to >> move code into libraries, to expose to openLMI >> and I have no clear picture yet how this will look like, so I thought >> implementing the management command as subclasses of admintool would >> be a good starting point - I do not insist that ipa-topology-manage >> will survive as a command in the end, but I also do not want to mess >> with ipa-replica-manage and ipa-csreplica-manage now, when these >> changes also probably would have no future. > > The ideal outcome is to have commands in the admintools indeed. I thought the ideal was to have this in the framework so it was manageable via the UI, which the admin tools are not. Isn't that one of the main drivers for this reorganization? And to not require DM for anything? rob From dkupka at redhat.com Tue Oct 14 13:18:14 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 14 Oct 2014 15:18:14 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <543D1705.9020307@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> <543513B3.9060808@redhat.com> <5437DE1E.3000307@redhat.com> <543CFF3A.7000607@redhat.com> <543D0B59.8070102@redhat.com> <543D14E1.5080702@redhat.com> <543D1705.9020307@redhat.com> Message-ID: <543D2296.7040304@redhat.com> On 10/14/2014 02:28 PM, Jan Cholasta wrote: > Dne 14.10.2014 v 14:19 David Kupka napsal(a): >> >> >> On 10/14/2014 01:39 PM, Jan Cholasta wrote: >>> Dne 14.10.2014 v 12:47 David Kupka napsal(a): >>>> >>>> >>>> On 10/10/2014 03:24 PM, Jan Cholasta wrote: >>>>> Dne 8.10.2014 v 12:36 David Kupka napsal(a): >>>>>> On 10/08/2014 09:29 AM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Dne 8.10.2014 v 09:09 David Kupka napsal(a): >>>>>>>> https://fedorahosted.org/freeipa/ticket/4569 >>>>>>> >>>>>>> In renew_ca_cert and cainstance.py, dogtag should already be >>>>>>> stopped in >>>>>>> the places you modified, so why the change? >>>>>> >>>>>> I didn't noticed that it is already stopped, fixed. >>>>>>> >>>>>>> Also I don't think it's a good idea to backup CS.cfg when dogtag is >>>>>>> still running (in cainstance.py). If the file is being modified by >>>>>>> dogtag at the time it is backed up, the backup may be corrupted. >>>>>>> >>>>>> Fixed, thanks. >>>>> >>>>> CAInstance.backup_config should be called only when Dogtag is >>>>> stopped as >>>>> well, you don't need to change it. >>>>> >>>> >>>> backup_config is callable from outside of cainstance.py so it's >>>> safer to >>>> check that dogtag is stopped and stop it if necessary. When dogtag is >>>> already stopped it won't do anything. >>> >>> If dogtag is not stopped in backup_config, it's an error, so an >>> exception should be raised. > > What I meant by this is that you should add this check to backup_config, > because it's not there ATM. Sorry for confusing you. > Ok, hope that I finally understood. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-5-ipa40-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 4662 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0019-5-Stop-dogtag-when-updating-its-configuration-in-ipa-u.patch Type: text/x-patch Size: 4700 bytes Desc: not available URL: From ssorce at redhat.com Tue Oct 14 13:53:55 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 14 Oct 2014 09:53:55 -0400 Subject: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA In-Reply-To: <543D0751.8040401@redhat.com> References: <543BB65A.1060705@redhat.com> <20141013133726.622953ae@willson.usersys.redhat.com> <543D0751.8040401@redhat.com> Message-ID: <20141014095355.57660db2@willson.usersys.redhat.com> On Tue, 14 Oct 2014 13:21:53 +0200 Martin Kosek wrote: > On 10/13/2014 07:37 PM, Simo Sorce wrote: > > On Mon, 13 Oct 2014 13:24:10 +0200 > > Martin Kosek wrote: > > > >> Hello all, > >> > >> Last week me, Jakub and Stef discussed a design for a candidate > >> for a FreeIPA&Gnome keyring related thesis: > >> > >> https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa > >> > >> Apparently, there was a misunderstanding when crafting the topic > >> proposal, it is not about storing Gnome Keyring *secrets* in > >> FreeIPA tree, but only about storing a *master key*/AUTHTOK in > >> FreeIPA so that keyring can be unlocked by SSSD on user log on > >> even in non-password authentication case (like SSO). > >> > >> With SSO, Gnome keyring cannot grab the long term secret to unlock > >> the keyring, the keyring also cannot re-encrypt itself when the > >> long term password changes on the server (this is no problem > >> locally as Gnome keyring is hooked to PAM password change module). > >> Thus, there is the idea to store the master key/AUTHTOK centrally > >> on the server. > >> > >> Given the sensitivity of the password, it would be best to store it > >> in the upcoming FreeIPA Password Vault/KRA: > >> > >> http://www.freeipa.org/page/V4/Password_Vault > >> > >> However, here comes the problem with how to authorize the operation > >> on SSSD level. To make it working, SSSD, > >> host/client.example.com at EXAMPLE.COM would need to be able to > >> retrieve and decipher a key from (any) user's Vault, which is > >> probably not what we want to allow. We may add S4U2Proxy rules so > >> that host/client.example.com at EXAMPLE.COM can get > >> vault/server.example.com at EXAMPLE.COM for the client, but then SSSD > >> could grab any user's secret when he logs in. > >> > >> Are there any ideas how to overcome this issue? Otherwise, it seems > >> that the Vault idea is not the right way. Maybe centralizing access > >> to Gnome keyring is not a good idea at all, we will see. > > > > SSSD has access to the user credentials at authentication, that's > > what it should use to retrieve the user's master key. > > I am confused. I thought this would only work if someone > authenticates with user+password or sends his TGT, right? Otherwise > SSSD cannot use user credentials... Well isn't this always the case when you do a GDM login ? You are not really going to use the gnome-keyring when you log in via SSH. > It is true that authenticating with user+password will still be the > most common authentication method on desktop interactive login, so it > should cover the most scenarios. Question is if we are even > interested in use cases like unlocking GNOME keyring after ssh-ing to > a host with Kerberos. No, it doesn't happen today either as most people log in via ssh keys so gnome-keyring would have no password there either even if it were hooked in the sshd PAM stack (which is not). Also I think we could offer an option to cache this key (maybe encrypted in the host keytab (not that it helps much if someone get hold of the machine), so that it always works for offline or password-less logins (think swiping the fingeprint and bypassing SSSD auth altogether). Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Tue Oct 14 13:59:56 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 14 Oct 2014 15:59:56 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <543D2296.7040304@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> <543513B3.9060808@redhat.com> <5437DE1E.3000307@redhat.com> <543CFF3A.7000607@redhat.com> <543D0B59.8070102@redhat.com> <543D14E1.5080702@redhat.com> <543D1705.9020307@redhat.com> <543D2296.7040304@redhat.com> Message-ID: <543D2C5C.7070508@redhat.com> Dne 14.10.2014 v 15:18 David Kupka napsal(a): > On 10/14/2014 02:28 PM, Jan Cholasta wrote: >> Dne 14.10.2014 v 14:19 David Kupka napsal(a): >>> >>> >>> On 10/14/2014 01:39 PM, Jan Cholasta wrote: >>>> Dne 14.10.2014 v 12:47 David Kupka napsal(a): >>>>> >>>>> >>>>> On 10/10/2014 03:24 PM, Jan Cholasta wrote: >>>>>> Dne 8.10.2014 v 12:36 David Kupka napsal(a): >>>>>>> On 10/08/2014 09:29 AM, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Dne 8.10.2014 v 09:09 David Kupka napsal(a): >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4569 >>>>>>>> >>>>>>>> In renew_ca_cert and cainstance.py, dogtag should already be >>>>>>>> stopped in >>>>>>>> the places you modified, so why the change? >>>>>>> >>>>>>> I didn't noticed that it is already stopped, fixed. >>>>>>>> >>>>>>>> Also I don't think it's a good idea to backup CS.cfg when dogtag is >>>>>>>> still running (in cainstance.py). If the file is being modified by >>>>>>>> dogtag at the time it is backed up, the backup may be corrupted. >>>>>>>> >>>>>>> Fixed, thanks. >>>>>> >>>>>> CAInstance.backup_config should be called only when Dogtag is >>>>>> stopped as >>>>>> well, you don't need to change it. >>>>>> >>>>> >>>>> backup_config is callable from outside of cainstance.py so it's >>>>> safer to >>>>> check that dogtag is stopped and stop it if necessary. When dogtag is >>>>> already stopped it won't do anything. >>>> >>>> If dogtag is not stopped in backup_config, it's an error, so an >>>> exception should be raised. >> >> What I meant by this is that you should add this check to backup_config, >> because it's not there ATM. Sorry for confusing you. >> > > Ok, hope that I finally understood. > ACK. -- Jan Cholasta From simo at redhat.com Tue Oct 14 14:23:37 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Oct 2014 10:23:37 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <543D20BD.7010007@redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <54380B8C.5060101@redhat.com> <20141010124414.588a0a6d@willson.usersys.redhat.com> <543B6EE0.5040107@redhat.com> <543CDAE8.8070900@redhat.com> <20141014083953.55946afc@willson.usersys.redhat.com> <543D20BD.7010007@redhat.com> Message-ID: <20141014102337.474cc110@willson.usersys.redhat.com> On Tue, 14 Oct 2014 15:10:21 +0200 Ludwig Krispenz wrote: > > On 10/14/2014 02:39 PM, Simo Sorce wrote: > > On Tue, 14 Oct 2014 10:12:24 +0200 > > Ludwig Krispenz wrote: > > > >> ok for me, I was just straightforward reading cn=config to get > >> cn=config info, but I like the idea to do it via rootdse. > >> we have to expose the suffix(es) controlled by the topology plugin > >> and the entry point for the shared config info. > > I was thinking in rootDSE we'd expose just if the feature was > > available. For IPA that would suffice, for generic 389ds then you'd > > have top look at configuration to find DNs. > > I am not sure exposing DNs directly from rootDSE is necessary. > I had two cases in mind, which I think would apply to IPA. > > - in an IPA installation in many scenarios you two suffixes: > "dc=.....,dc=com" and "o=ipaca". It could be possible to use the > plugin to manage "dc=.." only. Or do you say it's all or nothing ? > If there is a choice, client utilities need to be able to find out > which suffix is managed. > > - even in an ipa installation nobody prevents an admin to add other > backends to the directory server for other usage, so you might have > "dc=example,dc=com" > "dc=test,dc=com" > "dc=anotherbackend,dc=com" > "o=ipaca" > > in which suffix is the shared topology data ? should we query each > suffix to see if something useful is returned ? Well, at least for the IPA case I do not think we want to have multiple topology trees, even for multiple topologies, rather we want to have the ability to mark the same segment as used for X,Y,Z topologies (1-1 between topology and database). This will make it much simpler to handle simple configurations in which you simply want the CA and IPA topologies to be identical, by having a default that says new segments cover both topologies in the UI. Of course we also need to be able eventually to separate those, but again I see it done better by 'tagging' the single object with the topology it belongs to, than having completely different trees by default. (Having separate trees supported is also a desirable feature for the generic plugin so one does not exclude the other). Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Oct 14 14:38:35 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Oct 2014 10:38:35 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <543CF107.9010209@redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <543CF107.9010209@redhat.com> Message-ID: <20141014103835.47ef514b@willson.usersys.redhat.com> On Tue, 14 Oct 2014 11:46:47 +0200 Ludwig Krispenz wrote: > > On 10/10/2014 06:21 PM, Simo Sorce wrote: > > On Fri, 10 Oct 2014 17:52:15 +0200 > > Ludwig Krispenz wrote: > > > >> Hello, > >> > >> this is the current status of my work on #4302, and there are a few > >> pieces still missing, eg the management command needs more input > >> checking and error handling, but > >> - I wanted to give people interested a chance to have a look again > >> and get feedback > >> - there came up the following questions I would like to get an > >> opinion. > > First thing, I do not think we want a new command here. > > If we need commands outside of the ipa framework they should be > > integrated in the ipa-replica-manage tool. > > But really one of the reasons to move data in the shared tree was > > that we could grow native framework command to handle the topology > > so we can manage the topology directly from the UI. > > So I am not happy with ipa-tology-manage > > > >> when thinking how to move from an existing deployment with direct > >> management of replication agreement to the new way, there should > >> not be any intermediate disconnects, and if possible transition > >> should be made easy. So I think we should have defined a few modes > >> of operation for the plugin: > >> - initial/bootstrap [optional] - the plugin detects existing > >> agreements and transforms it to segments in the shared tree > > This should not be optional imo, its the only way to do sane > > upgrades. When the plugin starts it needs to check if there are > > replication agreements with other freeipa servers (it should ignore > > anything else). > it is fine for me if it is not optional, I agree that it is needed > for smooth upgrades. > the reason that I brought this up is that I had the impression that > it is not wanted, that > configuration should be in full responsibility of an admin creating > the shared topology from > scratch. > If we agree that the shared topology should be populated from > existing agreements I'm happy, if not I would make it at least > optional. Yes I think it makes sense to do so. We want a change as transparent as possible. > the problem to solve is, when does this auto generation stop ? My idea is that the new replication agreements in cn=config are tagged so only those that are untagged get "imported" at startup. Once the plugin has started we deny access to create arbitrary agreements between 2 ipa servers, so "import" will simply not happen. NOTE: I think the code must allow creation of agreements between 1 IPA server and an unrelated server, but those will not match the 'both server are IPA servers condition so no "import" will happen. > I think it should be done only once, at the initial startup of the > plugin and not allow to bypass the topology plugin later by stopping > th eserver, editing cn=config to add a new agreement and having it > added at startup to the shared tree, > so there shoul be some way to flag that the initial phase is done. I do not think this is necessary. I think it is fine to import whatever untagged agreements are found if both servers they reference are IPA servers. > I'm not sure if this can and should be handled with naming > conventions. I think agreements that are generate by the topology must be tagged so you know this is not a pre-existing agreement that you have to import, rather an agreement you have to validate or delete. Tagging can be done via naming convention or by adding some additional attribute. I think naming convention would be the easiest solution. > > > > Then check if these agreements have been autogenerated (this should > > be determined by new naming conventions for agreements in > > cn=config) or if they are pre-existing, if they are pre-existing > > then new shared entries will be generated in the shared tree. > > > > Note: this upgrade thing could also be done in ipa-upgrade plugins, > > at server upgrade time. Whichever is easier (main concern is if 2 > > servers are upgraded at the same time replication conflicts may > > arise). > > > >> - pending - the plugin handles and propagates segments in the > >> shared tree, but does not enforce teh deletion or creation of > >> replication agreements > > Not sure what you mean here, but I think that once the plugin is > > active it should stay active and actively prevent manual changes to > > automatically created replication agreements. > why I wanted this state had two reasons. > - Since the information in the shared tree is authoritative and if > you start to build the shared tree from scratch (if the above > initialization would not be done) > there is the problem that adding the shared topology is not atomic, > one segment is added, all others do not yet exist and other > replication agreements > would be deleted, in the best case replication is just interrupted. I am not sure I follow this, can you give an example of how this would happen ? > So I was suggesting a pending mode, you can add/delete segments from > the shared tree, verify connectivity and then say go and let the > shared tree become authoritative. Why automatically importing agreements would not work ? The plugin itself can bypass topology checks when importing so you should simply end up with whatever is the current situation in your domain once all servers have been upgraded. I think it is actually crucial that it can work this way because server will take some times to be upgraded one after the other, so for some time there will be some servers with the topology plugin activated and some that do not have it. Incomplete topology info will be expected. Also exposing the topology plugin in rootDSE here gain us a big win as the UI can show which servers still do not have the plugin enabled (as opposed to malfunctioning servers) and can mark deal appropriately with missing topology links by showing them grayed out until the old replica gets updated or something like that. > - A similar problem arises when adding a new replica, we had decided > to leave ipa-replica-install untouched, so it will install a new > server and try to setup replication agreements between the server > replica-prepare was run and the new replica, but it would be rejected > by the plugin when it is enforcing new agreements to be generated > only via shared config. So temporariliy disable the authority of the > plugin could help. Actually I was not a ware this decision was made, seriously, one of the main drivers for this feature is to get replica installation to finally stop needing DM passwords, so I am completely taken back by this decision to not touch ipa-replica-install/ipa-replica-manage and insted introduce ipa-topology-manage, I think we are only adding more work later to reconcile tools and change them and making life harder by adding this problem that new replicas can't properly add themselves to the topology until after they are fully installed. Sounds wrong. Simo. > > > >> - active - directe management of replicatio agreements is rejected, > >> existing segments ond their modifications are applied > > This should always be. > > > >> I did run my tests of the management command as directory manager > >> since admin did not have permissions to read plugin configuration > >> in cn=config, > > Why would you need to access cn=config ? > > All management should happen in the shared tree, moving to be able > > to avoid directly touching cn=config and avoid the need for DM > > password is one of the main reasons to do this work ... > > > >> I can add permissions, probably will also need permissions > >> for the part in the shared tree, so what is the expected operation > >> mode, which user needs access to the shared config data and > >> configuration ? > > We need to introduce a role for "Replication Admins" and make the > > admins group a member by default, then use normal permissions > > framework to regulate access. > > > > Simo. > > > > > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Oct 14 14:43:30 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 14 Oct 2014 10:43:30 -0400 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <543D227A.1070301@redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <543CDD25.1090407@redhat.com> <20141014084148.3deae70b@willson.usersys.redhat.com> <543D227A.1070301@redhat.com> Message-ID: <20141014104330.5a019ab6@willson.usersys.redhat.com> On Tue, 14 Oct 2014 09:17:46 -0400 Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 14 Oct 2014 10:21:57 +0200 > > Ludwig Krispenz wrote: > > > >> we already have ipa-replica-manage and ipa-csreplica-manage, and > >> - I did'n want to integrate the topology management into both and > >> duplicate code > >> - there is much change on the way to refactor the ipa commands, to > >> move code into libraries, to expose to openLMI > >> and I have no clear picture yet how this will look like, so I > >> thought implementing the management command as subclasses of > >> admintool would be a good starting point - I do not insist that > >> ipa-topology-manage will survive as a command in the end, but I > >> also do not want to mess with ipa-replica-manage and > >> ipa-csreplica-manage now, when these changes also probably would > >> have no future. > > > > The ideal outcome is to have commands in the admintools indeed. > > I thought the ideal was to have this in the framework so it was > manageable via the UI, which the admin tools are not. Isn't that one > of the main drivers for this reorganization? And to not require DM for > anything? Sorry I had a brain fart, I wrote admintools, but I meant ipa tool. That's really non-negotiable to me, as we want this stuff to be available in the UI, and we do not want to end up maintaining 2 sets of tools that do the same things. Thank you for pointing that out Rob ! Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Oct 14 15:15:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 14 Oct 2014 17:15:58 +0200 Subject: [Freeipa-devel] New git committers Message-ID: <543D3E2E.9060909@redhat.com> Hello, I am pleased to announce that Tomas Babej and Jan Cholasta were selected as new members of the git committers group for the main repository. So if your patch is acked, you know who to bug :-) I would recommend both to use the "ipatool" [1] for pushing the changes, it makes the whole job much easier and safer. [1] http://www.freeipa.org/page/Contribute/Repository#Process_tools -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From lkrispen at redhat.com Tue Oct 14 15:26:16 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 14 Oct 2014 17:26:16 +0200 Subject: [Freeipa-devel] [PATCH] move replication topology to shared tree In-Reply-To: <20141014103835.47ef514b@willson.usersys.redhat.com> References: <543800AF.9080704@redhat.com> <20141010122154.1c693f05@willson.usersys.redhat.com> <543CF107.9010209@redhat.com> <20141014103835.47ef514b@willson.usersys.redhat.com> Message-ID: <543D4098.2050400@redhat.com> On 10/14/2014 04:38 PM, Simo Sorce wrote: > On Tue, 14 Oct 2014 11:46:47 +0200 > Ludwig Krispenz wrote: > >> On 10/10/2014 06:21 PM, Simo Sorce wrote: >>> On Fri, 10 Oct 2014 17:52:15 +0200 >>> Ludwig Krispenz wrote: >>> >>>> Hello, >>>> >>>> this is the current status of my work on #4302, and there are a few >>>> pieces still missing, eg the management command needs more input >>>> checking and error handling, but >>>> - I wanted to give people interested a chance to have a look again >>>> and get feedback >>>> - there came up the following questions I would like to get an >>>> opinion. >>> First thing, I do not think we want a new command here. >>> If we need commands outside of the ipa framework they should be >>> integrated in the ipa-replica-manage tool. >>> But really one of the reasons to move data in the shared tree was >>> that we could grow native framework command to handle the topology >>> so we can manage the topology directly from the UI. >>> So I am not happy with ipa-tology-manage >>> >>>> when thinking how to move from an existing deployment with direct >>>> management of replication agreement to the new way, there should >>>> not be any intermediate disconnects, and if possible transition >>>> should be made easy. So I think we should have defined a few modes >>>> of operation for the plugin: >>>> - initial/bootstrap [optional] - the plugin detects existing >>>> agreements and transforms it to segments in the shared tree >>> This should not be optional imo, its the only way to do sane >>> upgrades. When the plugin starts it needs to check if there are >>> replication agreements with other freeipa servers (it should ignore >>> anything else). >> it is fine for me if it is not optional, I agree that it is needed >> for smooth upgrades. >> the reason that I brought this up is that I had the impression that >> it is not wanted, that >> configuration should be in full responsibility of an admin creating >> the shared topology from >> scratch. >> If we agree that the shared topology should be populated from >> existing agreements I'm happy, if not I would make it at least >> optional. > Yes I think it makes sense to do so. We want a change as transparent > as possible. > >> the problem to solve is, when does this auto generation stop ? > My idea is that the new replication agreements in cn=config are tagged > so only those that are untagged get "imported" at startup. > > Once the plugin has started we deny access to create arbitrary > agreements between 2 ipa servers, so "import" will simply not happen. > > NOTE: I think the code must allow creation of agreements between 1 IPA > server and an unrelated server, but those will not match the 'both > server are IPA servers condition so no "import" will happen. > >> I think it should be done only once, at the initial startup of the >> plugin and not allow to bypass the topology plugin later by stopping >> th eserver, editing cn=config to add a new agreement and having it >> added at startup to the shared tree, >> so there shoul be some way to flag that the initial phase is done. > I do not think this is necessary. I think it is fine to import whatever > untagged agreements are found if both servers they reference are IPA > servers. > >> I'm not sure if this can and should be handled with naming >> conventions. > I think agreements that are generate by the topology must be tagged so > you know this is not a pre-existing agreement that you have to import, > rather an agreement you have to validate or delete. > Tagging can be done via naming convention or by adding some additional > attribute. I think naming convention would be the easiest solution. > >>> Then check if these agreements have been autogenerated (this should >>> be determined by new naming conventions for agreements in >>> cn=config) or if they are pre-existing, if they are pre-existing >>> then new shared entries will be generated in the shared tree. >>> >>> Note: this upgrade thing could also be done in ipa-upgrade plugins, >>> at server upgrade time. Whichever is easier (main concern is if 2 >>> servers are upgraded at the same time replication conflicts may >>> arise). >>> >>>> - pending - the plugin handles and propagates segments in the >>>> shared tree, but does not enforce teh deletion or creation of >>>> replication agreements >>> Not sure what you mean here, but I think that once the plugin is >>> active it should stay active and actively prevent manual changes to >>> automatically created replication agreements. >> why I wanted this state had two reasons. >> - Since the information in the shared tree is authoritative and if >> you start to build the shared tree from scratch (if the above >> initialization would not be done) >> there is the problem that adding the shared topology is not atomic, >> one segment is added, all others do not yet exist and other >> replication agreements >> would be deleted, in the best case replication is just interrupted. > I am not sure I follow this, can you give an example of how this would > happen ? If we agree that initially existing replication agreements will be loaded and made into segments this is not a concern. > >> So I was suggesting a pending mode, you can add/delete segments from >> the shared tree, verify connectivity and then say go and let the >> shared tree become authoritative. > Why automatically importing agreements would not work ? > The plugin itself can bypass topology checks when importing so you > should simply end up with whatever is the current situation in your > domain once all servers have been upgraded. > > I think it is actually crucial that it can work this way because server > will take some times to be upgraded one after the other, so for some > time there will be some servers with the topology plugin activated and > some that do not have it. Incomplete topology info will be expected. > Also exposing the topology plugin in rootDSE here gain us a big win as > the UI can show which servers still do not have the plugin enabled (as > opposed to malfunctioning servers) and can mark deal appropriately > with missing topology links by showing them grayed out until the old > replica gets updated or something like that. > >> - A similar problem arises when adding a new replica, we had decided >> to leave ipa-replica-install untouched, so it will install a new >> server and try to setup replication agreements between the server >> replica-prepare was run and the new replica, but it would be rejected >> by the plugin when it is enforcing new agreements to be generated >> only via shared config. So temporariliy disable the authority of the >> plugin could help. > Actually I was not a ware this decision was made, seriously, one of the > main drivers for this feature is to get replica installation to finally > stop needing DM passwords, so I am completely taken back by this > decision to not touch ipa-replica-install/ipa-replica-manage and insted > introduce ipa-topology-manage, I think we are only adding more work > later to reconcile tools and change them and making life harder by > adding this problem that new replicas can't properly add themselves to > the topology until after they are fully installed. Sounds wrong. maybe that was a misunderstanding or we didn't discuss far enough, but I understand your and Rob's concerns and will rework this. > > Simo. > >>>> - active - directe management of replicatio agreements is rejected, >>>> existing segments ond their modifications are applied >>> This should always be. >>> >>>> I did run my tests of the management command as directory manager >>>> since admin did not have permissions to read plugin configuration >>>> in cn=config, >>> Why would you need to access cn=config ? >>> All management should happen in the shared tree, moving to be able >>> to avoid directly touching cn=config and avoid the need for DM >>> password is one of the main reasons to do this work ... >>> >>>> I can add permissions, probably will also need permissions >>>> for the part in the shared tree, so what is the expected operation >>>> mode, which user needs access to the shared config data and >>>> configuration ? >>> We need to introduce a role for "Replication Admins" and make the >>> admins group a member by default, then use normal permissions >>> framework to regulate access. >>> >>> Simo. >>> >>> > > From npmccallum at redhat.com Tue Oct 14 18:33:24 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 14 Oct 2014 14:33:24 -0400 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <543CE0FF.3050404@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <1412955816.3520.6.camel@redhat.com> <543BABE7.4020101@redhat.com> <1413221007.14998.1.camel@redhat.com> <543CC4A9.2030803@redhat.com> <543CC7D7.3040109@redhat.com> <543CDD6D.1090306@redhat.com> <543CE0FF.3050404@redhat.com> Message-ID: <1413311604.6617.10.camel@redhat.com> On Tue, 2014-10-14 at 10:38 +0200, Jan Cholasta wrote: > Dne 14.10.2014 v 10:23 Petr Viktorin napsal(a): > > On 10/14/2014 08:51 AM, Jan Cholasta wrote: > >> Dne 14.10.2014 v 08:37 Martin Kosek napsal(a): > >>> On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: > >>>> On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: > >>>>> Also, few comments to your current patch set (though the patches > >>>>> themselves > >>>>> will probably not land in 4.1): > >>>>> > >>>>> Patch 0001: > >>>>> - while it may work (after DS fixes), it adds PostRead for all our > >>>>> commands, > >>>>> not just otptoken-add. I would rather have some attribute like > >>>>> "read_dn_from_postread" on LDAPObject which defaults to False to > >>>>> make sure > >>>>> there is no regression or performance hit with other LDAP calls. > > > > As Honza says later in the mail, this should be an argument for > > add_entry (or alternatively an additional add_entry_with_postread > > method). Storing settings in data objects leads to trouble ? when you > > get such an object from somewhere, you never know what an operation on > > it will do. > > I would prefer add_entry argument rather than a new method, as that's > how find_entries does controls. > > > > >>>> In the new code, we actually get a performance gain as the manual post > >>>> read is eliminated if the post read control is successful. Only one > >>>> issue can arise, which is when the post read control evaluates ACIs > >>>> in a > >>>> different context than a normal manual read. This problem is well known > >>>> and is trivial to fix (s/USERDN/SELFDN/). > >>> > >>> That's my point - with such a big change, we can hit many unforeseen > >>> issues and > >>> we are close to deadline. I would rather like to use the PostRead > >>> control only > >>> in otptoken_add command. CCing Petr and Honza to chime in. > >> > >> I agree it should be opt-in for now. Add a boolean argument to add_entry > >> as a switch. > > > > +1 > > > > Also, I think the add_entry should not return anything; rather the > > PostRead result should be merged into the added entry object. Honza, > > what do you think? > > It should, good point. > > > > > In the future it might be useful for add_entry to return a list of > > controls, the `ctrls` in this patch. If we're going to implement temporary workarounds like this in order to merge this patch, I'd prefer to just wait until 4.2. Without activating the post read control for all add operations, there is really no benefit to this patch and added risk. I propose that for 4.1, we use the attached patch to remove the field from the UI. Once we have proper ACI/UUID-plugin integration in 389, we can revisit these patches. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-token-ID-from-self-service-UI.patch Type: text/x-patch Size: 1244 bytes Desc: not available URL: From npmccallum at redhat.com Tue Oct 14 19:01:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 14 Oct 2014 15:01:14 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <5436BC59.2090008@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> <5436BC59.2090008@redhat.com> Message-ID: <1413313274.6617.12.camel@redhat.com> On Thu, 2014-10-09 at 18:48 +0200, thierry bordaz wrote: > On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: > > > On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: > > > On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: > > > > > > > On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: > > > > > On Wed, 08 Oct 2014 15:53:39 -0400 > > > > > Nathaniel McCallum wrote: > > > > > > > > > > > As I understand my code, all servers will have csnD. Some servers will > > > > > > have valueB and others will have valueD, but valueB == valueD. > > > > > > > > > > > > We *never* discard a CSN. We only discard the counter/watermark mods > > > > > > in the replication operation. > > > > > What Thierry is saying is that the individual attributes in the entry > > > > > have associate the last CSN that modified them. Because you remove the > > > > > mods when ValueD == ValueB the counter attribute will not have the > > > > > associated CSN changed. But it doesn't really matter because the plugin > > > > > will always keep things consistent. > > > > Attached is a new version. It removes this optimization. If server X has > > > > valueB/csnB and receives valueD/csnD and valueB == valueD, the > > > > replication will be applied without any modification. However, if valueB > > > > > valueD and csnD > csnB, the counter mods will still be stripped. > > > > It also collapses the error check from betxnpre to bepre now that we > > > > have a fix for https://fedorahosted.org/389/ticket/47919 committed. The > > > > betxnpre functions are completely removed. Also, a dependency on 389 > > > > 1.3.3.4 (not yet released) is added. > > > > > > > > Nathaniel > > > Hello Nathaniel, > > > > > > For me the code is fine. Ack. > > New attached patch. > > > > > I have two minor comments: > > > * in preop_mod, when a direct update moves the counter > > > backward you send UNWILLING to perform with a message. > > > The message is allocated with slapi_ch_smprintf, you > > > may free it with slapi_ch_free_string (rather than > > > 'free'). > > Fixed. > > > > > * About this message, for example when you have these > > > MODS (I admit they make no sens): > > > > > > changetype: modify > > > ipatokenHOTPcounter: MOD_DELETE > > > - > > > ipatokenHOTPcounter: MOD_INCREMENT > > > > > > The returned message will be "Will not decrement > > > ipatokenHOTPcounter", because 'simulate' will return > > > 'COUNTER_UNSET+1'. > > > Is it the message you expected ? > > I changed the logic in simulate(). Please review it. > > > > Nathaniel > > > Hello Nathaniel, > > > The patch is ok for me. Ack. Since the ACK, the upstream 389 fix actually landed in 1.3.3.5. This patch changes nothing except the dependency version. I have tested it against the 1.3.3.5 build. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.8-Create-ipa-otp-counter-389DS-plugin.patch Type: text/x-patch Size: 34602 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 15 07:14:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Oct 2014 09:14:38 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig In-Reply-To: <543D2C5C.7070508@redhat.com> References: <5434E345.4070402@redhat.com> <5434E7D7.3020401@redhat.com> <543513B3.9060808@redhat.com> <5437DE1E.3000307@redhat.com> <543CFF3A.7000607@redhat.com> <543D0B59.8070102@redhat.com> <543D14E1.5080702@redhat.com> <543D1705.9020307@redhat.com> <543D2296.7040304@redhat.com> <543D2C5C.7070508@redhat.com> Message-ID: <543E1EDE.9060705@redhat.com> On 10/14/2014 03:59 PM, Jan Cholasta wrote: > Dne 14.10.2014 v 15:18 David Kupka napsal(a): >> On 10/14/2014 02:28 PM, Jan Cholasta wrote: >>> Dne 14.10.2014 v 14:19 David Kupka napsal(a): >>>> >>>> >>>> On 10/14/2014 01:39 PM, Jan Cholasta wrote: >>>>> Dne 14.10.2014 v 12:47 David Kupka napsal(a): >>>>>> >>>>>> >>>>>> On 10/10/2014 03:24 PM, Jan Cholasta wrote: >>>>>>> Dne 8.10.2014 v 12:36 David Kupka napsal(a): >>>>>>>> On 10/08/2014 09:29 AM, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Dne 8.10.2014 v 09:09 David Kupka napsal(a): >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4569 >>>>>>>>> >>>>>>>>> In renew_ca_cert and cainstance.py, dogtag should already be >>>>>>>>> stopped in >>>>>>>>> the places you modified, so why the change? >>>>>>>> >>>>>>>> I didn't noticed that it is already stopped, fixed. >>>>>>>>> >>>>>>>>> Also I don't think it's a good idea to backup CS.cfg when dogtag is >>>>>>>>> still running (in cainstance.py). If the file is being modified by >>>>>>>>> dogtag at the time it is backed up, the backup may be corrupted. >>>>>>>>> >>>>>>>> Fixed, thanks. >>>>>>> >>>>>>> CAInstance.backup_config should be called only when Dogtag is >>>>>>> stopped as >>>>>>> well, you don't need to change it. >>>>>>> >>>>>> >>>>>> backup_config is callable from outside of cainstance.py so it's >>>>>> safer to >>>>>> check that dogtag is stopped and stop it if necessary. When dogtag is >>>>>> already stopped it won't do anything. >>>>> >>>>> If dogtag is not stopped in backup_config, it's an error, so an >>>>> exception should be raised. >>> >>> What I meant by this is that you should add this check to backup_config, >>> because it's not there ATM. Sorry for confusing you. >>> >> >> Ok, hope that I finally understood. >> > > ACK. > Pushed to: master: c44f4dcbea210e7802deda1909a3ec70aa6b6460 ipa-4-1: 080c8635de15e3954333e402e9a750d551ff8abd ipa-4-0: 320ea12373f0172a9505c5e4f7c12b20c3439ac5 Martin From mkosek at redhat.com Wed Oct 15 07:22:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Oct 2014 09:22:07 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1413313274.6617.12.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> <5436BC59.2090008@redhat.com> <1413313274.6617.12.camel@redhat.com> Message-ID: <543E209F.9020709@redhat.com> On 10/14/2014 09:01 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-09 at 18:48 +0200, thierry bordaz wrote: >> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: >> >>> On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: >>>> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: >>>> >>>>> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: >>>>>> On Wed, 08 Oct 2014 15:53:39 -0400 >>>>>> Nathaniel McCallum wrote: >>>>>> >>>>>>> As I understand my code, all servers will have csnD. Some servers will >>>>>>> have valueB and others will have valueD, but valueB == valueD. >>>>>>> >>>>>>> We *never* discard a CSN. We only discard the counter/watermark mods >>>>>>> in the replication operation. >>>>>> What Thierry is saying is that the individual attributes in the entry >>>>>> have associate the last CSN that modified them. Because you remove the >>>>>> mods when ValueD == ValueB the counter attribute will not have the >>>>>> associated CSN changed. But it doesn't really matter because the plugin >>>>>> will always keep things consistent. >>>>> Attached is a new version. It removes this optimization. If server X has >>>>> valueB/csnB and receives valueD/csnD and valueB == valueD, the >>>>> replication will be applied without any modification. However, if valueB >>>>>> valueD and csnD > csnB, the counter mods will still be stripped. >>>>> It also collapses the error check from betxnpre to bepre now that we >>>>> have a fix for https://fedorahosted.org/389/ticket/47919 committed. The >>>>> betxnpre functions are completely removed. Also, a dependency on 389 >>>>> 1.3.3.4 (not yet released) is added. >>>>> >>>>> Nathaniel >>>> Hello Nathaniel, >>>> >>>> For me the code is fine. Ack. >>> New attached patch. >>> >>>> I have two minor comments: >>>> * in preop_mod, when a direct update moves the counter >>>> backward you send UNWILLING to perform with a message. >>>> The message is allocated with slapi_ch_smprintf, you >>>> may free it with slapi_ch_free_string (rather than >>>> 'free'). >>> Fixed. >>> >>>> * About this message, for example when you have these >>>> MODS (I admit they make no sens): >>>> >>>> changetype: modify >>>> ipatokenHOTPcounter: MOD_DELETE >>>> - >>>> ipatokenHOTPcounter: MOD_INCREMENT >>>> >>>> The returned message will be "Will not decrement >>>> ipatokenHOTPcounter", because 'simulate' will return >>>> 'COUNTER_UNSET+1'. >>>> Is it the message you expected ? >>> I changed the logic in simulate(). Please review it. >>> >>> Nathaniel >>> >> Hello Nathaniel, >> >> >> The patch is ok for me. Ack. > > Since the ACK, the upstream 389 fix actually landed in 1.3.3.5. This > patch changes nothing except the dependency version. I have tested it > against the 1.3.3.5 build. > > Nathaniel Great! As soon as the new build land in Fedora 21 (and we add it to our Copr), the patch can be pushed. Martin From dkupka at redhat.com Wed Oct 15 09:08:10 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 15 Oct 2014 11:08:10 +0200 Subject: [Freeipa-devel] [PATCH] 0023 Fix typo causing certmonger is provided with wrong path to, ipa-submit. Message-ID: <543E397A.5060003@redhat.com> https://fedorahosted.org/freeipa/ticket/4624 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0023-Fix-typo-causing-certmonger-is-provided-with-wrong-p.patch Type: text/x-patch Size: 1796 bytes Desc: not available URL: From dkupka at redhat.com Wed Oct 15 10:55:22 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 15 Oct 2014 12:55:22 +0200 Subject: [Freeipa-devel] [PATCH] 0023 Fix typo causing certmonger is provided with wrong path to, ipa-submit. In-Reply-To: <543E397A.5060003@redhat.com> References: <543E397A.5060003@redhat.com> Message-ID: <543E529A.3000109@redhat.com> I forget to attach patch for ipa-4-0 branch. Attaching both now. On 10/15/2014 11:08 AM, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4624 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0023-Fix-typo-causing-certmonger-is-provided-with-wrong-p.patch Type: text/x-patch Size: 1796 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0023-ipa40-Fix-typo-causing-certmonger-is-provided-with-wrong-p.patch Type: text/x-patch Size: 1792 bytes Desc: not available URL: From tbordaz at redhat.com Wed Oct 15 11:08:23 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 15 Oct 2014 13:08:23 +0200 Subject: [Freeipa-devel] [PATCH] 0004 permission-add gives confusing error when adding ACI to generated tree Message-ID: <543E55A7.2000105@redhat.com> https://fedorahosted.org/freeipa/ticket/4523 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0004-permission-add-gives-confusing-error-when-adding-ACI.patch Type: text/x-patch Size: 1344 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 15 11:26:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Oct 2014 13:26:14 +0200 Subject: [Freeipa-devel] [PATCH] 0004 permission-add gives confusing error when adding ACI to generated tree In-Reply-To: <543E55A7.2000105@redhat.com> References: <543E55A7.2000105@redhat.com> Message-ID: <543E59D6.2060300@redhat.com> On 10/15/2014 01:08 PM, thierry bordaz wrote: > https://fedorahosted.org/freeipa/ticket/4523 I see 2 issues with the patch: 1) Patch description should not contain " Reviewed by:", this gets added later by a script (or human) 2) The exception handling clause should be as focused as possible, i.e. not including whole command, but rather just the failing call, i.e.: def post_callback(self, ldap, dn, entry, *keys, **options): try: self.obj.add_aci(entry) except Exception: You can use try: ... except errors.NotFound: self.obj.handle_not_found(*keys) to raise the right error. Martin From tbordaz at redhat.com Wed Oct 15 11:57:57 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 15 Oct 2014 13:57:57 +0200 Subject: [Freeipa-devel] [PATCH] 0004 permission-add gives confusing error when adding ACI to generated tree In-Reply-To: <543E59D6.2060300@redhat.com> References: <543E55A7.2000105@redhat.com> <543E59D6.2060300@redhat.com> Message-ID: <543E6145.7060709@redhat.com> On 10/15/2014 01:26 PM, Martin Kosek wrote: > On 10/15/2014 01:08 PM, thierry bordaz wrote: >> https://fedorahosted.org/freeipa/ticket/4523 > I see 2 issues with the patch: > > 1) Patch description should not contain " > Reviewed by:", this gets added later by a script (or human) ok > > 2) The exception handling clause should be as focused as possible, i.e. not > including whole command, but rather just the failing call, i.e.: > > def post_callback(self, ldap, dn, entry, *keys, **options): > try: > self.obj.add_aci(entry) > except Exception: > > You can use > > try: > ... > except errors.NotFound: > self.obj.handle_not_found(*keys) > > to raise the right error. > > Martin Currently the exception is handled on the failure of baseldap.LDAPCreate.execute(). Do you recommend to make the fix inside baseldap.LDAPCreate.execute rather than at the 'permission_add.execute' level ? Also using handle_not_found looks good, but it reports something like: ipa permission-add user1 --right read --attrs cn --subtree 'cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' ipa: ERROR: user1: permission not found If the entry 'user1' exists, it is not clear what was not found. Displaying the dn of the entry would help to know that we are updating an entry into the 'compat' tree. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Oct 15 12:20:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 15 Oct 2014 14:20:21 +0200 Subject: [Freeipa-devel] [PATCH] 773-777 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type Message-ID: <543E6685.8000704@redhat.com> ticket: https://fedorahosted.org/freeipa/ticket/4221 == [PATCH] 773 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type == We should not allow setting --rid-base for ranges of ipa-trust-ad-posix since we do not perform any RID -> UID/GID mappings for these ranges (objects have UID/GID set in AD). Thus, setting RID base makes no sense. Since ipaBaseRID is a MUST in ipaTrustedADDomainRange object class, value '0' is allowed and used internally for 'ipa-trust-ad-posix' range type. No schema change is done. == [PATCH] 774 unittests: baserid for ipa-ad-trust-posix idranges == == [PATCH] 775 ldapupdater: set baserid to 0 for ipa-ad-trust-posix ranges == New updater plugin which sets baserid to 0 for ranges with type ipa-ad-trust-posix https://fedorahosted.org/freeipa/ticket/4221 == [PATCH] 776 idrange: include raw range type in output == iparangetype output is a localized human-readable value which is not suitable for machine-based API consumers Solved by new iparangetyperaw output attribute which contains iparangetype's raw value Note: I don't like this approach. It would be better to return just the raw value a do the transformation in clients. But we do have a precedent: http://www.redhat.com/archives/freeipa-devel/2012-January/msg00190.html == [PATCH] 777 webui: prohibit setting rid base with ipa-trust-ad-posix type == Base RID is no longer editable for ipa-trust-ad-posix range type Adder dialog: - Range type selector was moved up because it affects a field above it Details page: - Only fields relevant to range's type are visible https://fedorahosted.org/freeipa/ticket/4221 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0777-webui-prohibit-setting-rid-base-with-ipa-trust-ad-po.patch Type: text/x-patch Size: 5410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0776-idrange-include-raw-range-type-in-output.patch Type: text/x-patch Size: 4486 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0775-ldapupdater-set-baserid-to-0-for-ipa-ad-trust-posix-.patch Type: text/x-patch Size: 4524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0774-unittests-baserid-for-ipa-ad-trust-posix-idranges.patch Type: text/x-patch Size: 13048 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0773-ranges-prohibit-setting-rid-base-with-ipa-trust-ad-p.patch Type: text/x-patch Size: 4757 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 15 12:58:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 15 Oct 2014 14:58:42 +0200 Subject: [Freeipa-devel] [PATCHES] 0661-0670 Switch the test suite to pytest Message-ID: <543E6F82.7090309@redhat.com> This almost completes the switch to pytest. There are two missing things: - the details of test results (--with-xunit) are not read correctly by Jenkins. I have a theory I'm investigating here. - the beakerlib integration is still not ready I'll not be available for the rest of the week so I'm sending this early, in case someone wants to take a look. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0661-dogtag-plugin-Don-t-use-doctest-syntax-for-non-docte.patch Type: text/x-patch Size: 2478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0662-Configure-pytest-to-run-doctests.patch Type: text/x-patch Size: 1409 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0663-Declarative-tests-Move-cleanup-to-setup_class-teardo.patch Type: text/x-patch Size: 2716 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0664-Declarative-tests-Switch-to-pytest.patch Type: text/x-patch Size: 4225 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0665-Integration-Port-the-ordering-plugin-to-pytest.patch Type: text/x-patch Size: 6664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0666-test_webui-Don-t-use-__init__-for-test-classes.patch Type: text/x-patch Size: 4096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0667-Switch-make-test-to-pytest.patch Type: text/x-patch Size: 1987 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0668-Add-local-pytest-plugin-for-with-xunit-and-logging-l.patch Type: text/x-patch Size: 3796 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0669-Include-pytest.ini-in-built-packages.patch Type: text/x-patch Size: 3528 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0670-Use-pytest-in-ipa-run-tests.patch Type: text/x-patch Size: 2954 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 15 13:58:22 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 15 Oct 2014 15:58:22 +0200 Subject: [Freeipa-devel] [PATCH] Fix printing of reverse zones in ipa-dns-install. In-Reply-To: <543E7B72.6000500@gmail.com> References: <543E7B72.6000500@gmail.com> Message-ID: <543E7D7E.8080809@redhat.com> New contributor :-) ACK Thank you! -- Martin Basti From dkupka at redhat.com Wed Oct 15 14:04:07 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 15 Oct 2014 16:04:07 +0200 Subject: [Freeipa-devel] [PATCH] Fix printing of reverse zones in ipa-dns-install. In-Reply-To: <543E7D7E.8080809@redhat.com> References: <543E7B72.6000500@gmail.com> <543E7D7E.8080809@redhat.com> Message-ID: <543E7ED7.8050302@redhat.com> Submitting the patch again. I sent it from my gmail account accidentally. On 10/15/2014 03:58 PM, Martin Basti wrote: > New contributor :-) > > ACK > Thank you! > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0024-Fix-printing-of-reverse-zones-in-ipa-dns-install.patch Type: text/x-patch Size: 1074 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 15 14:04:52 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 15 Oct 2014 16:04:52 +0200 Subject: [Freeipa-devel] [PATCH] Fix printing of reverse zones in ipa-dns-install. In-Reply-To: <543E7ED7.8050302@redhat.com> References: <543E7B72.6000500@gmail.com> <543E7D7E.8080809@redhat.com> <543E7ED7.8050302@redhat.com> Message-ID: <543E7F04.2080603@redhat.com> On 15/10/14 16:04, David Kupka wrote: > Submitting the patch again. I sent it from my gmail account accidentally. > > On 10/15/2014 03:58 PM, Martin Basti wrote: >> New contributor :-) >> >> ACK >> Thank you! >> > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACKing my previous ACK -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Oct 15 14:29:46 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Oct 2014 16:29:46 +0200 Subject: [Freeipa-devel] [PATCH] 0023 Fix typo causing certmonger is provided with wrong path to, ipa-submit. In-Reply-To: <543E529A.3000109@redhat.com> References: <543E397A.5060003@redhat.com> <543E529A.3000109@redhat.com> Message-ID: <543E84DA.2070805@redhat.com> Hi, Dne 15.10.2014 v 12:55 David Kupka napsal(a): > I forget to attach patch for ipa-4-0 branch. Attaching both now. > > On 10/15/2014 11:08 AM, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4624 The code could be more robust, but given that it will be gone soon (hopefully), ACK. Honza -- Jan Cholasta From mkosek at redhat.com Wed Oct 15 14:33:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 15 Oct 2014 16:33:27 +0200 Subject: [Freeipa-devel] [PATCH] 0004 permission-add gives confusing error when adding ACI to generated tree In-Reply-To: <543E6145.7060709@redhat.com> References: <543E55A7.2000105@redhat.com> <543E59D6.2060300@redhat.com> <543E6145.7060709@redhat.com> Message-ID: <543E85B7.6090306@redhat.com> On 10/15/2014 01:57 PM, thierry bordaz wrote: > On 10/15/2014 01:26 PM, Martin Kosek wrote: >> On 10/15/2014 01:08 PM, thierry bordaz wrote: >>> https://fedorahosted.org/freeipa/ticket/4523 >> I see 2 issues with the patch: >> >> 1) Patch description should not contain " >> Reviewed by:", this gets added later by a script (or human) > ok >> >> 2) The exception handling clause should be as focused as possible, i.e. not >> including whole command, but rather just the failing call, i.e.: >> >> def post_callback(self, ldap, dn, entry, *keys, **options): >> try: >> self.obj.add_aci(entry) >> except Exception: >> >> You can use >> >> try: >> ... >> except errors.NotFound: >> self.obj.handle_not_found(*keys) >> >> to raise the right error. >> >> Martin > Currently the exception is handled on the failure of > baseldap.LDAPCreate.execute(). Do you recommend to make the fix inside > baseldap.LDAPCreate.execute rather than at the 'permission_add.execute' level ? No, not there. I thought that the exception happens in def post_callback(self, ldap, dn, entry, *keys, **options): try: self.obj.add_aci(entry) except Exception: ... > Also using handle_not_found looks good, but it reports something like: > > ipa permission-add user1 --right read --attrs cn --subtree > 'cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' > ipa: ERROR: user1: permission not found > > > If the entry 'user1' exists, it is not clear what was not found. > Displaying the dn of the entry would help to know that we are updating an entry > into the 'compat' tree. Ah, sorry, I think I mislead you with this advise. You probably could use the same except clause as already used: except errors.NotFound: raise errors.ValidationError( name='ipapermlocation', error=_('Entry %s does not exist') % location) Martin From jcholast at redhat.com Wed Oct 15 14:38:15 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Oct 2014 16:38:15 +0200 Subject: [Freeipa-devel] [PATCH] 334 Do not wait for new CA certificate to appear in LDAP in ipa-certupdate Message-ID: <543E86D7.50208@redhat.com> Hi, the attached patch fixes . It depends on my patch 333, which is also attached. (The original patch was posted at .) How to test: 1. install server 2. run "ipa-certupdate" 3. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca'", the request should be in MONITORING state, there should be no ca-error Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-333.2-Handle-profile-changes-in-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 6851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-334.2-Do-not-wait-for-new-CA-certificate-to-appear-in-LDAP.patch Type: text/x-patch Size: 6262 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 15 14:42:47 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 15 Oct 2014 16:42:47 +0200 Subject: [Freeipa-devel] [PATCH] 353 Allow specifying signing algorithm of the IPA CA cert in ipa-ca-install In-Reply-To: <54352188.4030609@redhat.com> References: <54352188.4030609@redhat.com> Message-ID: <543E87E7.8060802@redhat.com> On 8.10.2014 13:35, Jan Cholasta wrote: > Hi, > > the attached patch provides an additional fix for > . > > Honza > Requires rebase because of `ca_type=options.external_ca_type)`. Works fine with older version. -- Petr Vobornik From jcholast at redhat.com Wed Oct 15 14:43:51 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 15 Oct 2014 16:43:51 +0200 Subject: [Freeipa-devel] [PATCH] 335 Fail if certmonger can't see new CA certificate in LDAP in ipa-cacert-manage Message-ID: <543E8827.5070402@redhat.com> Hi, the attached patch fixes . It depends on my patches 333 and 334, which are also attached. (The original patch was posted at .) How to test: 1. install server 2. kinit as admin 3. run "ipa-cacert-manage renew --external-ca", it will produce a CSR 4. sign the CSR with some external CA to get new IPA CA certificate 5. run "while true; do ldapdelete -H ldap://$HOSTNAME -Y GSSAPI 'cn=caSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,'; done" in background 6. run "ipa-cacert-manage renew --external-cert-file= --external-cert-file=" 7. stop the loop from step 5 8. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca'", the request should be in MONITORING state, there should be no ca-error Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-333.2-Handle-profile-changes-in-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 6851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-334.2-Do-not-wait-for-new-CA-certificate-to-appear-in-LDAP.patch Type: text/x-patch Size: 6262 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-335.2-Fail-if-certmonger-can-t-see-new-CA-certificate-in-L.patch Type: text/x-patch Size: 3804 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 15 14:59:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 15 Oct 2014 10:59:59 -0400 Subject: [Freeipa-devel] [PATCH 0070] Remove token ID from self-service UI Message-ID: <1413385199.6617.18.camel@redhat.com> Also, fix labels to properly use i18n strings for token types. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0070-Remove-token-ID-from-self-service-UI.patch Type: text/x-patch Size: 1244 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 15 16:32:01 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 15 Oct 2014 12:32:01 -0400 Subject: [Freeipa-devel] [PATCH 0071] Display token type when viewing token Message-ID: <1413390721.6617.20.camel@redhat.com> When viewing a token from the CLI or UI, the type of the token should be displayed. https://fedorahosted.org/freeipa/ticket/4563 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0071-Display-token-type-when-viewing-token.patch Type: text/x-patch Size: 4143 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 15 16:33:07 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 15 Oct 2014 12:33:07 -0400 Subject: [Freeipa-devel] [PATCH 0072] Remove token vendor, model and serial defaults Message-ID: <1413390787.6617.21.camel@redhat.com> These defaults are pretty useless and cause more confusion than they are worth. The serial default never worked anyway. And now that we are displaying the token type separately, there is no reason to doubly record these data points. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0072-Remove-token-vendor-model-and-serial-defaults.patch Type: text/x-patch Size: 6590 bytes Desc: not available URL: From pspacek at redhat.com Wed Oct 15 19:26:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 15 Oct 2014 21:26:27 +0200 Subject: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name In-Reply-To: <1413311604.6617.10.camel@redhat.com> References: <1412804761.9441.12.camel@redhat.com> <1412955816.3520.6.camel@redhat.com> <543BABE7.4020101@redhat.com> <1413221007.14998.1.camel@redhat.com> <543CC4A9.2030803@redhat.com> <543CC7D7.3040109@redhat.com> <543CDD6D.1090306@redhat.com> <543CE0FF.3050404@redhat.com> <1413311604.6617.10.camel@redhat.com> Message-ID: <543ECA63.2020400@redhat.com> On 14.10.2014 20:33, Nathaniel McCallum wrote: > On Tue, 2014-10-14 at 10:38 +0200, Jan Cholasta wrote: >> Dne 14.10.2014 v 10:23 Petr Viktorin napsal(a): >>> On 10/14/2014 08:51 AM, Jan Cholasta wrote: >>>> Dne 14.10.2014 v 08:37 Martin Kosek napsal(a): >>>>> On 10/13/2014 07:23 PM, Nathaniel McCallum wrote: >>>>>> On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote: >>>>>>> Also, few comments to your current patch set (though the patches >>>>>>> themselves >>>>>>> will probably not land in 4.1): >>>>>>> >>>>>>> Patch 0001: >>>>>>> - while it may work (after DS fixes), it adds PostRead for all our >>>>>>> commands, >>>>>>> not just otptoken-add. I would rather have some attribute like >>>>>>> "read_dn_from_postread" on LDAPObject which defaults to False to >>>>>>> make sure >>>>>>> there is no regression or performance hit with other LDAP calls. >>> >>> As Honza says later in the mail, this should be an argument for >>> add_entry (or alternatively an additional add_entry_with_postread >>> method). Storing settings in data objects leads to trouble ? when you >>> get such an object from somewhere, you never know what an operation on >>> it will do. >> >> I would prefer add_entry argument rather than a new method, as that's >> how find_entries does controls. >> >>> >>>>>> In the new code, we actually get a performance gain as the manual post >>>>>> read is eliminated if the post read control is successful. Only one >>>>>> issue can arise, which is when the post read control evaluates ACIs >>>>>> in a >>>>>> different context than a normal manual read. This problem is well known >>>>>> and is trivial to fix (s/USERDN/SELFDN/). >>>>> >>>>> That's my point - with such a big change, we can hit many unforeseen >>>>> issues and >>>>> we are close to deadline. I would rather like to use the PostRead >>>>> control only >>>>> in otptoken_add command. CCing Petr and Honza to chime in. >>>> >>>> I agree it should be opt-in for now. Add a boolean argument to add_entry >>>> as a switch. >>> >>> +1 >>> >>> Also, I think the add_entry should not return anything; rather the >>> PostRead result should be merged into the added entry object. Honza, >>> what do you think? >> >> It should, good point. >> >>> >>> In the future it might be useful for add_entry to return a list of >>> controls, the `ctrls` in this patch. > > If we're going to implement temporary workarounds like this in order to > merge this patch, I'd prefer to just wait until 4.2. Without activating > the post read control for all add operations, there is really no benefit > to this patch and added risk. It would be really nice to has this opt-in feature in 4.1 - it would make DNSSEC support easier for me. I guess that answer is 'no' so I'm going to implement a workaround. > I propose that for 4.1, we use the attached patch to remove the field > from the UI. Once we have proper ACI/UUID-plugin integration in 389, we > can revisit these patches. -- Petr^2 Spacek From edewata at redhat.com Thu Oct 16 03:59:16 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 15 Oct 2014 22:59:16 -0500 Subject: [Freeipa-devel] [PATCH] 352 Fixed KRA backend. Message-ID: <543F4294.1080001@redhat.com> The KRA backend has been simplified since most of the tasks have been moved somewhere else. The transport certificate will be installed on the client, and it is not needed by KRA backend. The KRA agent's PEM certificate is now generated during installation due to permission issue. The kra_host() for now is removed since the current ldap_enable() cannot register the KRA service, so it is using the kra_host environment variable. The KRA installer has been modified to use Dogtag's CLI go create KRA agent and setup the client authentication. The proxy settings have been updated to include KRA's URLs. The certs.install_pem_from_p12() has been updated to generate the proper client certificate using the -clcerts option and also take a password file. Some constants have been renamed for clarity. The DOGTAG_AGENT_P12 has been renamed to DOGTAG_ADMIN_P12 since file actually contains the Dogtag admin's certificate and private key and it can be used to access both CA and KRA. The DOGTAG_AGENT_PEM has been renamed to KRA_AGENT_PEM since it can only be used for KRA. Ticket #3872 -- Endi S. Dewata -------------- next part -------------- From 018d849db0f08285aeeb26e3fc886c8c161b3f33 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Wed, 1 Oct 2014 14:59:46 -0400 Subject: [PATCH] Fixed KRA backend. The KRA backend has been simplified since most of the tasks have been moved somewhere else. The transport certificate will be installed on the client, and it is not needed by KRA backend. The KRA agent's PEM certificate is now generated during installation due to permission issue. The kra_host() for now is removed since the current ldap_enable() cannot register the KRA service, so it is using the kra_host environment variable. The KRA installer has been modified to use Dogtag's CLI go create KRA agent and setup the client authentication. The proxy settings have been updated to include KRA's URLs. The certs.install_pem_from_p12() has been updated to generate the proper client certificate using the -clcerts option and also take a password file. Some constants have been renamed for clarity. The DOGTAG_AGENT_P12 has been renamed to DOGTAG_ADMIN_P12 since file actually contains the Dogtag admin's certificate and private key and it can be used to access both CA and KRA. The DOGTAG_AGENT_PEM has been renamed to KRA_AGENT_PEM since it can only be used for KRA. Ticket #3872 --- install/conf/ipa-pki-proxy.conf | 2 +- ipaplatform/base/paths.py | 4 +- ipaserver/install/cainstance.py | 4 +- ipaserver/install/certs.py | 10 ++-- ipaserver/install/ipa_backup.py | 3 +- ipaserver/install/krainstance.py | 83 ++++++++++++++++++++++++--- ipaserver/plugins/dogtag.py | 120 +++++---------------------------------- 7 files changed, 100 insertions(+), 126 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 2370b4d7a7467a7e47c0d223915e018c9a009e83..5d21156848f3b5ddf14c42d92a26a30a9f94af36 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -19,7 +19,7 @@ ProxyRequests Off # matches for agent port and eeca port - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://localhost:$DOGTAG_PORT diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index 0ba6b46c562a3d3f97e3631fd9dc0f27536bc6bc..3652a3213d2d116b34d7c4239964c511f572ed6b 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -127,8 +127,8 @@ class BasePathNamespace(object): HOME_DIR = "/home" ROOT_IPA_CACHE = "/root/.ipa_cache" ROOT_PKI = "/root/.pki" - DOGTAG_AGENT_P12 = "/root/ca-agent.p12" - DOGTAG_AGENT_PEM = "/etc/httpd/alias/agent.pem" + DOGTAG_ADMIN_P12 = "/root/ca-agent.p12" + KRA_AGENT_PEM = "/etc/httpd/alias/kra-agent.pem" CACERT_P12 = "/root/cacert.p12" ROOT_IPA_CSR = "/root/ipa.csr" ROOT_TMP_CA_P12 = "/root/tmp-ca.p12" diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 2c912206a37accfdf217c955755b82ed0d2056af..aa6de498726e779e62cd96ec13d9e52cd1262714 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -514,7 +514,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_admin_nickname", "ipa-ca-agent") config.set("CA", "pki_admin_subject_dn", str(DN(('cn', 'ipa-ca-agent'), self.subject_base))) - config.set("CA", "pki_client_admin_cert_p12", paths.DOGTAG_AGENT_P12) + config.set("CA", "pki_client_admin_cert_p12", paths.DOGTAG_ADMIN_P12) # Directory server config.set("CA", "pki_ds_ldap_port", str(self.ds_port)) @@ -979,7 +979,7 @@ class CAInstance(DogtagInstance): try: ipautil.run([paths.PK12UTIL, "-n", "ipa-ca-agent", - "-o", paths.DOGTAG_AGENT_P12, + "-o", paths.DOGTAG_ADMIN_P12, "-d", self.agent_db, "-k", pwd_name, "-w", pwd_name]) diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index 5399a0fa566c6f7df81a9d1e347f6ac99e5188c9..d1e58da722126d0381787e13b9112d595dfc2cc7 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -637,11 +637,13 @@ class CertDB(object): self.create_pin_file() self.export_ca_cert(nickname, False) - def install_pem_from_p12(self, p12_fname, p12_passwd, pem_fname): - pwd = ipautil.write_tmp_file(p12_passwd) - ipautil.run([paths.OPENSSL, "pkcs12", "-nodes", + def install_pem_from_p12(self, p12_fname, p12_passwd, pem_fname, pwd_fname=None): + if p12_passwd: + pwd = ipautil.write_tmp_file(p12_passwd) + pwd_fname = pwd.name + ipautil.run([paths.OPENSSL, "pkcs12", "-clcerts", "-nodes", "-in", p12_fname, "-out", pem_fname, - "-passin", "file:" + pwd.name]) + "-passin", "file:" + pwd_fname]) def publish_ca_cert(self, location): shutil.copy(self.cacert_fname, location) diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py index ded02171cbf62687620666d55c9802f9670b1942..7e0b40caee7d15e49f474d33a390fc792c3c196c 100644 --- a/ipaserver/install/ipa_backup.py +++ b/ipaserver/install/ipa_backup.py @@ -153,7 +153,8 @@ class Backup(admintool.AdminTool): paths.NTP_CONF, paths.SMB_CONF, paths.SAMBA_KEYTAB, - paths.DOGTAG_AGENT_P12, + paths.DOGTAG_ADMIN_P12, + paths.KRA_AGENT_PEM, paths.CACERT_P12, paths.KRB5KDC_KDC_CONF, paths.SYSTEMD_IPA_SERVICE, diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index 1af1c0f721cd9b0df7c6134798494d507e2ba07c..7c1bded4173420a7e8f0ebfe40fe7e12ba0476c4 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -169,7 +169,7 @@ class KRAInstance(DogtagInstance): str(DN(('cn', 'ipa-ca-agent'), self.subject_base))) config.set("KRA", "pki_import_admin_cert", "True") config.set("KRA", "pki_admin_cert_file", paths.ADMIN_CERT_PATH) - config.set("KRA", "pki_client_admin_cert_p12", paths.DOGTAG_AGENT_P12) + config.set("KRA", "pki_client_admin_cert_p12", paths.DOGTAG_ADMIN_P12) # Directory server config.set("KRA", "pki_ds_ldap_port", str(self.ds_port)) @@ -259,16 +259,81 @@ class KRAInstance(DogtagInstance): """ Add RA agent created for CA to KRA agent group. """ - conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) - conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) - entry_dn = DN(('uid', "ipara"), ('ou', 'People'), ('o', 'ipaca')) - dn = DN(('cn', 'Data Recovery Manager Agents'), ('ou', 'groups'), - self.basedn) - modlist = [(0, 'uniqueMember', '%s' % entry_dn)] - conn.modify_s(dn, modlist) + # import CA certificate into temporary security database + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-import", + "--pkcs12", paths.KRACERT_P12, + "--pkcs12-password", self.admin_password] + ipautil.run(args) - conn.unbind() + # trust CA certificate + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-mod", "Certificate Authority - %s" % api.env.realm, + "--trust", "CT,c,"] + ipautil.run(args) + + # import Dogtag admin certificate into temporary security database + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-import", + "--pkcs12", paths.DOGTAG_ADMIN_P12, + "--pkcs12-password", self.admin_password] + ipautil.run(args) + + # as Dogtag admin, create ipakra user in KRA + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-add", "ipakra", + "--fullName", "IPA KRA User"] + ipautil.run(args) + + # as Dogtag admin, add ipakra into KRA agents group + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-membership-add", "ipakra", "Data Recovery Manager Agents"] + ipautil.run(args) + + # assign ipaCert to ipakra + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + # export ipaCert without private key + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--cert", filename] + ipautil.run(args) + + # as Dogtag admin, upload and assign ipaCert to ipakra + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-cert-add", "ipakra", + "--input", filename] + ipautil.run(args) + + finally: + os.remove(filename) + + # export ipaCert with private key for client authentication + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--client-cert", paths.KRA_AGENT_PEM] + ipautil.run(args) @staticmethod def update_cert_config(nickname, cert, dogtag_constants=None): diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 0e141a45c290b84d65b15b8c2c638577a3a39363..b6d216e6626ef3e62c7d4f6227b76213ae9d85c3 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1890,122 +1890,28 @@ class kra(Backend): """ def __init__(self, kra_port=443): - if api.env.in_tree: - self.sec_dir = os.path.join(api.env.dot_ipa, 'alias') - pwd_file = os.path.join(self.sec_dir, '.pwd') - self.pem_file = os.path.join(self.sec_dir, ".pemfile") - else: - self.sec_dir = paths.HTTPD_ALIAS_DIR - pwd_file = paths.ALIAS_PWDFILE_TXT - self.pem_file = paths.DOGTAG_AGENT_PEM self.kra_port = kra_port - self.transport_nick = "IPA KRA Transport Cert" - self.password = "" - with open(pwd_file, "r") as f: - self.password = f.readline().strip() - self.keyclient = None super(kra, self).__init__() - def _create_pem_file(self): - """ Create PEM file used by KRA plugin for authentication. + def get_client(self): - This function reads the IPA HTTPD database and extracts the - Dogtag agent certificate and keys into a PKCS#12 temporary file. - The PKCS#12 file is then converted into PEM format so that it - can be used by python-requests to authenticate to the KRA. + if not api.env.enable_kra: + return None - :return: None - """ - (p12_pwd_fd, p12_pwd_fname) = tempfile.mkstemp() - (p12_fd, p12_fname) = tempfile.mkstemp() + crypto = cryptoutil.NSSCryptoProvider( + paths.HTTPD_ALIAS_DIR, + password_file=paths.ALIAS_PWDFILE_TXT) - try: - os.write(p12_pwd_fd, self.password) - os.close(p12_pwd_fd) - os.close(p12_fd) + connection = PKIConnection( + 'https', + api.env.kra_host, + str(self.kra_port), + 'kra') - certdb = CertDB(api.env.realm) - certdb.export_pkcs12(p12_fname, p12_pwd_fname, "ipaCert") + connection.set_authentication_cert(paths.KRA_AGENT_PEM) - certdb.install_pem_from_p12(p12_fname, self.password, self.pem_file) - except: - self.debug("Error when creating PEM file for KRA operations") - raise - finally: - os.remove(p12_fname) - os.remove(p12_pwd_fname) - - def _transport_cert_present(self): - """ Check if the client certDB contains the KRA transport certificate - :return: True/False - """ - # certutil -L -d db_dir -n cert_nick - certdb = CertDB(api.env.realm) - return certdb.has_nickname(self.transport_nick) - - def _setup(self): - """ Do initial setup and crypto initialization of the KRA client - - Creates a PEM file containing the KRA agent cert/keys to be used for - authentication to the KRA (if it does not already exist), Sets up a - connection to the KRA and initializes an NSS certificate database to - store the transport certificate, Retrieves the transport certificate - if it is not already present. - """ - #set up pem file if not present - if not os.path.exists(self.pem_file): - self._create_pem_file() - - # set up connection - connection = PKIConnection('https', - self.kra_host, - str(self.kra_port), - 'kra') - connection.set_authentication_cert(self.pem_file) - - crypto = cryptoutil.NSSCryptoProvider(self.sec_dir, self.password) - - #create kraclient - kraclient = KRAClient(connection, crypto) - - # get transport cert if needed - if not self._transport_cert_present(): - transport_cert = kraclient.system_certs.get_transport_cert() - crypto.import_cert(self.transport_nick, transport_cert, "u,u,u") - - crypto.initialize() - - self.keyclient = kraclient.keys - self.keyclient.set_transport_cert(self.transport_nick) - - @cachedproperty - def kra_host(self): - """ - :return: host - as str - - Select our KRA host. - """ - ldap2 = self.api.Backend.ldap2 - if host_has_service(api.env.kra_host, ldap2, "kra"): - return api.env.kra_host - if api.env.host != api.env.kra_host: - if host_has_service(api.env.host, ldap2, "kra"): - return api.env.host - host = select_any_master(ldap2, "kra") - if host: - return host - else: - return api.env.kra_host - - def get_keyclient(self): - """Return a keyclient to perform key archival and retrieval. - :return: pki.key.keyclient - """ - if self.keyclient is None: - self._setup() - return self.keyclient + return KRAClient(connection, crypto) api.register(kra) -- 1.9.0 From edewata at redhat.com Thu Oct 16 03:59:24 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 15 Oct 2014 22:59:24 -0500 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. Message-ID: <543F429C.2040006@redhat.com> This patch provides the initial vault implementation which allows the admin to create a vault, archive a secret, and retrieve the secret using a standard vault. It currently has limitations including: - The vault only supports the standard vault type. - The vault can only be used by the admin user. - The transport certificate has to be installed manually. These limitations, other vault features, schema and ACL changes will be addressed in subsequent patches. The NSSConnection class has to be modified not to shutdown existing database because some of the vault clients (e.g. vault-archive and vault-retrieve) also use a database to encrypt/decrypt the secret. Ticket #3872 -- Endi S. Dewata -------------- next part -------------- From 1ad4307323c9e76ed51e5cdbd736e8834864f6fc Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 16 Sep 2014 20:11:35 -0400 Subject: [PATCH] Added initial vault implementation. This patch provides the initial vault implementation which allows the admin to create a vault, archive a secret, and retrieve the secret using a standard vault. It currently has limitations including: - The vault only supports the standard vault type. - The vault can only be used by the admin user. - The transport certificate has to be installed manually. These limitations, other vault features, schema and ACL changes will be addressed in subsequent patches. The NSSConnection class has to be modified not to shutdown existing database because some of the vault clients (e.g. vault-archive and vault-retrieve) also use a database to encrypt/decrypt the secret. Ticket #3872 --- API.txt | 160 ++++++++ VERSION | 4 +- install/share/60basev4.ldif | 3 + install/share/Makefile.am | 1 + install/share/copy-schema-to-ca.py | 1 + install/updates/40-vault.update | 27 ++ install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/user.py | 9 + ipalib/plugins/vault.py | 726 +++++++++++++++++++++++++++++++++++++ ipapython/nsslib.py | 22 +- ipaserver/install/dsinstance.py | 1 + 13 files changed, 943 insertions(+), 14 deletions(-) create mode 100644 install/share/60basev4.ldif create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py diff --git a/API.txt b/API.txt index 1af78509732b13eec07208114cea00e56c1059b4..1eec3527e36bc250acddbf0e2fe7a6baa30abd74 100644 --- a/API.txt +++ b/API.txt @@ -4373,6 +4373,166 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('in?', cli_name='in') +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret', attribute=True, cli_name='secret', multivalue=False, required=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_archive +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('encrypted_data?', cli_name='encrypted_data') +option: Str('in?', cli_name='in') +option: Bytes('nonce?', cli_name='nonce') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret?', cli_name='secret') +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,10,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Bytes('secret', attribute=True, autofill=False, cli_name='secret', multivalue=False, query=True, required=False) +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret', attribute=True, autofill=False, cli_name='secret', multivalue=False, required=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_retrieve +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('out?', cli_name='out') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_add +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vaultcontainer_find +args: 1,9,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vaultcontainer_mod +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/VERSION b/VERSION index 24a6a5ebc70e7ddf6626666e5f9252c44a29d368..4dff96f7242e4a0ff8f914f3e15c5833d4753113 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=105 -# Last change: abbra - ID views attributes +IPA_API_VERSION_MINOR=106 +# Last change: edewata - initial vault implementation diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif new file mode 100644 index 0000000000000000000000000000000000000000..5a077b5a393067169015c71458632a1b3ee77189 --- /dev/null +++ b/install/share/60basev4.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.12.35 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 7d8ceb60e6374e133cfb6e3684bc307dbf313ce7..95bd6a1d246679822fc57156c58efd1182ee5a13 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -14,6 +14,7 @@ app_DATA = \ 60ipaconfig.ldif \ 60basev2.ldif \ 60basev3.ldif \ + 60basev4.ldif \ 60ipadns.ldif \ 61kerberos-ipav3.ldif \ 65ipacertstore.ldif \ diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py index fc53fe4cb52486cc618bec77aabe8283ad5eadbc..fb938d212f0f4ddd9a8250a362b89c29d3078efd 100755 --- a/install/share/copy-schema-to-ca.py +++ b/install/share/copy-schema-to-ca.py @@ -29,6 +29,7 @@ SCHEMA_FILENAMES = ( "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..59e5b629ce4e6c5acac06df78f02106afa6c859e --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,27 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: vaults +default: description: Root vault container + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: services +default: description: Services vault container + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: shared +default: description: Shared vault container + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: users +default: description: Users vault container diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 2b3157d2e656e214a0706d3ab1c780c651b0df91..5c7214343443504f9527039460ef90b80a52603d 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -31,6 +31,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index 325414b64fdacd4d8df261588cfc9b7481923be1..f64e02b5cf2a949a3c0ea7c1702132a3a09c1c19 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -97,6 +97,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index f95b4fd4a9bc3f478f6fd523bf242002a5b6649f..97cd5916f5c63509587879bbebfce7c8644a0c25 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -22,6 +22,7 @@ from time import gmtime, strftime import string import posixpath import os +import traceback from ipalib import api, errors from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime @@ -878,6 +879,14 @@ class user_del(LDAPDelete): else: self.api.Command.otptoken_del(token) + # Delete user's private vault container. + try: + vaultcontainer_id = self.api.Object.vaultcontainer.get_private_id(owner) + (vaultcontainer_parent_id, vaultcontainer_name) = self.api.Object.vaultcontainer.split_id(vaultcontainer_id) + self.api.Command.vaultcontainer_del(vaultcontainer_name, parent=vaultcontainer_parent_id) + except errors.NotFound: + pass + return dn diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..210c3e5f2d25f99053c3a3fe28d9694689186254 --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,726 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# 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 PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +import json +import os +import random +import shutil +import string +import tempfile + +import pki +import pki.account +import pki.crypto +import pki.key + +from ipalib import api, errors +from ipalib import Str, Bytes +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import * +from ipalib.plugins import baseldap +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipaplatform.paths import paths + +__doc__ = _(""" +Vaults + +Manage vaults and vault containers. + +EXAMPLES: + + List private vaults: + ipa vault-find + + List shared vaults: + ipa vault-find --parent /shared + + Add a vault: + ipa vault-add MyVault + + Show a vault: + ipa vault-show MyVault + + Archive a secret: + ipa vault-archive MyVault --in secret.in + + Retrieve a secret: + ipa vault-retrieve MyVault --out secret.out + + Delete a vault: + ipa vault-del MyVault + + List private vault containers: + ipa vaultcontainer-find + + List top-level vault containers: + ipa vaultcontainer-find --parent / + + Add a vault container: + ipa vaultcontainer-add MyContainer + + Show a vault container: + ipa vaultcontainer-show MyContainer + + Delete a vault container: + ipa vaultcontainer-del MyContainer +""") + +register = Registry() +transport_cert_nickname = "KRA Transport Certificate" + + at register() +class vaultcontainer(LDAPObject): + """ + Vault container object. + """ + container_dn = api.env.container_vault + object_name = _('vault container') + object_name_plural = _('vault containers') + + object_class = ['ipaVaultContainer'] + default_attributes = [ + 'cn', 'description', + ] + search_display_attributes = [ + 'cn', 'description', + ] + + label = _('Vault Containers') + label_singular = _('Vault Container') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='container_name', + label=_('Container name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Container description'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + ) + + def get_private_id(self, username=None): + """ + Returns user's private container ID (i.e. /users//). + """ + + if not username: + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + + return u'/users/' + username + u'/' + + def normalize_id(self, id): + """ + Normalizes container ID. + """ + + # if ID is empty, return user's private container ID + if not id: + return self.get_private_id() + + # make sure ID ends with slash + if not id.endswith(u'/'): + id += u'/' + + # if it's an absolute ID, do nothing + if id.startswith(u'/'): + return id + + # otherwise, prepend with user's private container ID + return self.get_private_id() + id + + def split_id(self, id): + """ + Split a normalized container ID into (parent ID, container name) tuple. + """ + + # handle root ID + if id == u'/': + return (None, None) + + # split ID into parent ID, container name, and empty string + parts = id.rsplit(u'/', 2) + + # return parent ID and container name + return (parts[-3] + u'/', parts[-2]) + + def get_dn(self, *keys, **kwargs): + """ + Generate vault container DN. + """ + + id = keys[0] + dn = DN(self.container_dn, api.env.basedn) + + # if ID is not specified, return base DN + if not id: + return dn + + # for each name in the ID, prepend the base DN + for name in id.split(u'/'): + if name: + dn = DN(('cn', name), dn) + + return dn + + + at register() +class vaultcontainer_add(LDAPCreate): + __doc__ = _('Create a new vault container.') + + msg_summary = _('Added vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + + name = entry_attrs.get('cn') + parent_id = self.obj.normalize_id(options.get('parent')) + + # add parent container if it doesn't exist + try: + (grandparent_id, parent_name) = self.obj.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + id = parent_id + name + dn = self.obj.get_dn(id) + + return dn + + + at register() +class vaultcontainer_del(LDAPDelete): + __doc__ = _('Delete a vault container.') + + msg_summary = _('Deleted vault container "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_find(LDAPSearch): + __doc__ = _('Search for vault containers.') + + msg_summary = ngettext( + '%(count)d vault container matched', '%(count)d vault containers matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + + parent_id = self.obj.normalize_id(options.get('parent')) + base_dn = self.obj.get_dn(parent_id) + return (filter, base_dn, scope) + + + at register() +class vaultcontainer_mod(LDAPUpdate): + __doc__ = _('Modify a vault container.') + + msg_summary = _('Modified vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[1] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_show(LDAPRetrieve): + __doc__ = _('Display information about a vault container.') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vault(LDAPObject): + """ + Vault object. + """ + container_dn = api.env.container_vault + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', 'description', + ] + search_display_attributes = [ + 'cn', 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='vault_name', + label=_('Vault name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + Bytes('secret?', + cli_name='secret', + label=_('Secret'), + doc=_('Secret'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + ) + + def get_dn(self, *keys, **kwargs): + """ + Generate vault DN. + """ + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(kwargs.get('parent')) + parent_dn = api.Object.vaultcontainer.get_dn(parent_id) + dn = DN(('cn', name), parent_dn) + + return dn + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('in?', + cli_name='in', + doc=_('Input file containing the secret'), + ), + ) + + msg_summary = _('Added vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + + name = entry_attrs.get('cn') + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + + # add parent container if it doesn't exist + try: + (grandparent_id, parent_name) = api.Object.vaultcontainer.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + secret = options.get('secret') + file = options.get('in') + + # don't send these parameters to server + if 'secret' in options: + del options['secret'] + if 'in' in options: + del options['in'] + + if secret: + pass + + elif file: + with open(file) as f: + secret = f.read() + + # create the vault + response = super(vault_add, self).forward(*args, **options) + + # archive an empty secret + api.Command.vault_archive(vault_id, secret=secret) + + return response + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + msg_summary = _('Deleted vault "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + vault_id = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(vault_id, parent=parent_id) + + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa-' + vault_id + + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + return dn + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + msg_summary = ngettext( + '%(count)d vault matched', '%(count)d vaults matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + base_dn = api.Object.vaultcontainer.get_dn(parent_id) + return (filter, base_dn, scope) + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + msg_summary = _('Modified vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[1] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_archive(LDAPRetrieve): + __doc__ = _('Archive a secret into a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Bytes('secret?', + cli_name='secret', + doc=_('Secret to archive'), + ), + Str('in?', + cli_name='in', + doc=_('Input file containing the secret'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + Bytes('encrypted_data?', + cli_name='encrypted_data', + doc=_('Data encrypted with session key and encoded in base-64'), + ), + Bytes('nonce?', + cli_name='nonce', + doc=_('Nonce encrypted encoded in base-64'), + ), + ) + + msg_summary = _('Archived secret into vault "%(value)s"') + + def execute(self, *args, **options): + + vault_id = args[0] + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa-' + vault_id + + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + encrypted_data = base64.b64decode(options['encrypted_data']) + nonce = base64.b64decode(options['nonce']) + + kra_client.keys.archive_encrypted_data( + client_key_id, + pki.key.KeyClient.PASS_PHRASE_TYPE, + encrypted_data, + wrapped_session_key, + "{1 2 840 113549 3 7}", + base64.encodestring(nonce), + ) + + kra_account.logout() + + return super(vault_archive, self).execute(*args, **options) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + secret = options.get('secret') + file = options.get('in') + + # don't send these parameters to server + if 'secret' in options: + del options['secret'] + if 'in' in options: + del options['in'] + + if secret: + pass + + elif file: + with open(file) as f: + secret = f.read() + + else: + secret = '' + + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + + nonce = crypto.generate_nonce_iv() + session_key = crypto.generate_session_key() + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + encrypted_data = crypto.symmetric_wrap( + secret, + session_key, + nonce_iv=nonce + ) + + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + options['encrypted_data'] = base64.b64encode(encrypted_data) + options['nonce'] = base64.b64encode(nonce) + + return super(vault_archive, self).forward(*args, **options) + + + at register() +class vault_retrieve(LDAPRetrieve): + __doc__ = _('Retrieve a secret from a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Str('out?', + cli_name='out', + doc=_('Output file to store the secret'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + ) + + msg_summary = _('Retrieved secret from vault "%(value)s"') + + def execute(self, *args, **options): + + vault_id = args[0] + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + + response = super(vault_retrieve, self).execute(*args, **options) + + client_key_id = 'ipa-' + vault_id + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + key_client = kra_client.keys + key_info = key_client.get_active_key_info(client_key_id) + + key = key_client.retrieve_key( + key_info.get_key_id(), + wrapped_session_key) + + response['result']['encrypted_data'] = base64.b64encode(key.encrypted_data) + response['result']['nonce'] = base64.b64encode(key.nonce_data) + + kra_account.logout() + + return response + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + if 'file' in options: + del options['file'] + + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + + session_key = crypto.generate_session_key() + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + + response = super(vault_retrieve, self).forward(*args, **options) + + encrypted_data = base64.b64decode(response['result']['encrypted_data']) + nonce = base64.b64decode(response['result']['nonce']) + + secret = crypto.symmetric_unwrap( + encrypted_data, + session_key, + nonce_iv=nonce) + + if file: + with open(file, 'w') as f: + f.write(secret) + + else: + response['result']['secret'] = unicode(secret) + + return response diff --git a/ipapython/nsslib.py b/ipapython/nsslib.py index 93b0c56fcff4fc69841a6823aae8f694c1f76ff0..6acfb66057b5238921bd2a574f7bab5e47b13c72 100644 --- a/ipapython/nsslib.py +++ b/ipapython/nsslib.py @@ -184,19 +184,17 @@ class NSSConnection(httplib.HTTPConnection, NSSAddressFamilyFallback): httplib.HTTPConnection.__init__(self, host, port, strict) NSSAddressFamilyFallback.__init__(self, family) - if not dbdir: - raise RuntimeError("dbdir is required") - root_logger.debug('%s init %s', self.__class__.__name__, host) - if not no_init and nss.nss_is_initialized(): - # close any open NSS database and use the new one - ssl.clear_session_cache() - try: - nss.nss_shutdown() - except NSPRError, e: - if e.errno != error.SEC_ERROR_NOT_INITIALIZED: - raise e - nss.nss_init(dbdir) + + # If the main program already initialized a database, use the current + # database. Do not shutdown the current database. If the main program + # did not initialize a database and initialization is allowed, then + # initialize the specified database. + if not nss.nss_is_initialized() and not no_init: + if not dbdir: + raise RuntimeError("dbdir is required") + nss.nss_init(dbdir) + ssl.set_domestic_policy() nss.set_password_callback(self.password_callback) diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index c9a1c15e9495108382f6e2e8a58f6cc4e8f79c98..f307f96e44ef78c85a5691aa7fdf780ea04dd6b7 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -56,6 +56,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", -- 1.9.0 From mkosek at redhat.com Thu Oct 16 06:03:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 08:03:15 +0200 Subject: [Freeipa-devel] [PATCH] Fix printing of reverse zones in ipa-dns-install. In-Reply-To: <543E7F04.2080603@redhat.com> References: <543E7B72.6000500@gmail.com> <543E7D7E.8080809@redhat.com> <543E7ED7.8050302@redhat.com> <543E7F04.2080603@redhat.com> Message-ID: <543F5FA3.4000305@redhat.com> On 10/15/2014 04:04 PM, Martin Basti wrote: > On 15/10/14 16:04, David Kupka wrote: >> Submitting the patch again. I sent it from my gmail account accidentally. >> >> On 10/15/2014 03:58 PM, Martin Basti wrote: >>> New contributor :-) >>> >>> ACK >>> Thank you! >>> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACKing my previous ACK Pushed to: master: 47731f45845a4cc27da65b98a6ba82388824f363 ipa-4-1: 7e5a71dd463c401f2e1c9cd36a35b5b57fb8b005 Martin From mkosek at redhat.com Thu Oct 16 07:53:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 09:53:32 +0200 Subject: [Freeipa-devel] [PATCH] 0023 Fix typo causing certmonger is provided with wrong path to, ipa-submit. In-Reply-To: <543E84DA.2070805@redhat.com> References: <543E397A.5060003@redhat.com> <543E529A.3000109@redhat.com> <543E84DA.2070805@redhat.com> Message-ID: <543F797C.8050204@redhat.com> On 10/15/2014 04:29 PM, Jan Cholasta wrote: > Hi, > > Dne 15.10.2014 v 12:55 David Kupka napsal(a): >> I forget to attach patch for ipa-4-0 branch. Attaching both now. >> >> On 10/15/2014 11:08 AM, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4624 > > The code could be more robust, but given that it will be gone soon (hopefully), > ACK. > > Honza > Pushed to: master: 3f9d1a71f1087ab1b203e8ce51eeb14194f7f0a2 ipa-4-1: f0464801e52ce8bae2f693aacc42d4de0a6898eb ipa-4-0: 40f967828999d243efe503b36c025b5d392c89a8 Martin From jcholast at redhat.com Thu Oct 16 07:54:57 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Oct 2014 09:54:57 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <543BACA2.4070506@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> Message-ID: <543F79D1.6050705@redhat.com> Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): > On 8.10.2014 18:51, Petr Vobornik wrote: >> On 1.10.2014 18:15, Petr Vobornik wrote: >>> Hello list, >>> >>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>> >> >> New revisions of 761 and 763 with updated API and ACIs: >> >> ipa host-allow-operation HOSTNAME retrieve-keytab --users=STR --groups >> STR >> ipa host-disallow-operation HOSTNAME retrieve-keytab --users=STR >> --groups STR >> ipa host-allow-operation HOSTNAME create-keytab --users=STR >> --groups STR >> ipa host-disallow-operation HOSTNAME create-keytab --users=STR >> --groups STR >> >> ipa service-allow-operation PRINCIPAL retrieve-keytab --users=STR >> --groups STR >> ipa service-disallow-operation PRINCIPAL retrieve-keytab --users=STR >> --groups STR >> ipa service-allow-operation PRINCIPAL create-keytab --users=STR >> --groups STR >> ipa service-disallow-operation PRINCIPAL create-keytab --users=STR >> --groups STR >> >> ACIs are targeted to specific operations by including subtypes. >> > > patch #761 rebased because of VERSION bump Since we are apparently not going to treat ipaAllowedToPerform as a member attribute, you should remove reference to it from attribute_members and relationships attributes of service and host. What's up with ipaallowedtoperform_subtypes_map? Why rename the operations? You probably don't want to hardcode 'ipaallowedtoperform_read_keys' in rename_ipaallowedtoperform_to_ldap(). Why do you override get_args() in service_{,dis}allow_operation instead of overriding takes_args? I'm not particularly happy about the '_subtype' option bussiness, but at least it's not invasive, so I guess it's OK. Note that I still think this API sucks and we should instead go with the generic member-like attribute approach, or take our time to design it properly so that it fits in the framework (no time in 4.1) instead of making it a hacky Franken-API like it is now. -- Jan Cholasta From jcholast at redhat.com Thu Oct 16 08:00:17 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Oct 2014 10:00:17 +0200 Subject: [Freeipa-devel] [PATCH] 353 Allow specifying signing algorithm of the IPA CA cert in ipa-ca-install In-Reply-To: <543E87E7.8060802@redhat.com> References: <54352188.4030609@redhat.com> <543E87E7.8060802@redhat.com> Message-ID: <543F7B11.5010401@redhat.com> Dne 15.10.2014 v 16:42 Petr Vobornik napsal(a): > On 8.10.2014 13:35, Jan Cholasta wrote: >> Hi, >> >> the attached patch provides an additional fix for >> . >> >> Honza >> > > Requires rebase because of `ca_type=options.external_ca_type)`. Works > fine with older version. Rebased on top of current ipa-4-1, patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-353.1-Allow-specifying-signing-algorithm-of-the-IPA-CA-cer.patch Type: text/x-patch Size: 3617 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 16 08:41:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 10:41:18 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.4 Message-ID: <543F84AE.5010407@redhat.com> Hello all! I think we have all the bits and pieces ready to release next stabilization release of FreeIPA 4.0 - FreeIPA 4.0.4! There were a lot of bug fixes or minor enhancements, let us offer it for others to use. I created the first version of release notes on the wiki, updates welcome: http://www.freeipa.org/page/Releases/4.0.4 Does anybody know any issue preventing us from releasing it? If yes, please let me know. Also, who wants to be the Release Man for this version? :-) -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pvoborni at redhat.com Thu Oct 16 09:24:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Oct 2014 11:24:39 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <543F79D1.6050705@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> Message-ID: <543F8ED7.8010806@redhat.com> On 16.10.2014 09:54, Jan Cholasta wrote: > Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): >> On 8.10.2014 18:51, Petr Vobornik wrote: >>> On 1.10.2014 18:15, Petr Vobornik wrote: >>>> Hello list, >>>> >>>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>>> >>> >>> New revisions of 761 and 763 with updated API and ACIs: >>> >>> ipa host-allow-operation HOSTNAME retrieve-keytab --users=STR --groups >>> STR >>> ipa host-disallow-operation HOSTNAME retrieve-keytab --users=STR >>> --groups STR >>> ipa host-allow-operation HOSTNAME create-keytab --users=STR >>> --groups STR >>> ipa host-disallow-operation HOSTNAME create-keytab --users=STR >>> --groups STR >>> >>> ipa service-allow-operation PRINCIPAL retrieve-keytab --users=STR >>> --groups STR >>> ipa service-disallow-operation PRINCIPAL retrieve-keytab --users=STR >>> --groups STR >>> ipa service-allow-operation PRINCIPAL create-keytab --users=STR >>> --groups STR >>> ipa service-disallow-operation PRINCIPAL create-keytab --users=STR >>> --groups STR >>> >>> ACIs are targeted to specific operations by including subtypes. >>> >> >> patch #761 rebased because of VERSION bump > > Since we are apparently not going to treat ipaAllowedToPerform as a > member attribute, you should remove reference to it from > attribute_members and relationships attributes of service and host. I still think of it a as member attribute, at least internally. > > What's up with ipaallowedtoperform_subtypes_map? Why rename the operations? It's not renaming. It's a change of internal raw LDAP value into self-describing name consistent with terminology of ipa-getkeytab > > You probably don't want to hardcode 'ipaallowedtoperform_read_keys' in > rename_ipaallowedtoperform_to_ldap(). Fixed, but it doesn't make much difference given that the method has only one purpose. > > Why do you override get_args() in service_{,dis}allow_operation instead > of overriding takes_args? Fixed > > I'm not particularly happy about the '_subtype' option bussiness, but at > least it's not invasive, so I guess it's OK. > > Note that I still think this API sucks and we should instead go with the > generic member-like attribute approach, or take our time to design it > properly so that it fits in the framework (no time in 4.1) instead of > making it a hacky Franken-API like it is now. > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0761-4-keytab-manipulation-permission-management.patch Type: text/x-patch Size: 27146 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 16 09:53:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Oct 2014 11:53:48 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <543F8ED7.8010806@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> <543F8ED7.8010806@redhat.com> Message-ID: <543F95AC.1090700@redhat.com> Dne 16.10.2014 v 11:24 Petr Vobornik napsal(a): > On 16.10.2014 09:54, Jan Cholasta wrote: >> Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): >>> On 8.10.2014 18:51, Petr Vobornik wrote: >>>> On 1.10.2014 18:15, Petr Vobornik wrote: >>>>> Hello list, >>>>> >>>>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>>>> >>>> >>>> New revisions of 761 and 763 with updated API and ACIs: >>>> >>>> ipa host-allow-operation HOSTNAME retrieve-keytab --users=STR --groups >>>> STR >>>> ipa host-disallow-operation HOSTNAME retrieve-keytab --users=STR >>>> --groups STR >>>> ipa host-allow-operation HOSTNAME create-keytab --users=STR >>>> --groups STR >>>> ipa host-disallow-operation HOSTNAME create-keytab --users=STR >>>> --groups STR >>>> >>>> ipa service-allow-operation PRINCIPAL retrieve-keytab --users=STR >>>> --groups STR >>>> ipa service-disallow-operation PRINCIPAL retrieve-keytab --users=STR >>>> --groups STR >>>> ipa service-allow-operation PRINCIPAL create-keytab --users=STR >>>> --groups STR >>>> ipa service-disallow-operation PRINCIPAL create-keytab --users=STR >>>> --groups STR >>>> >>>> ACIs are targeted to specific operations by including subtypes. >>>> >>> >>> patch #761 rebased because of VERSION bump >> >> Since we are apparently not going to treat ipaAllowedToPerform as a >> member attribute, you should remove reference to it from >> attribute_members and relationships attributes of service and host. > > I still think of it a as member attribute, at least internally. Given the implementation, I see you can't remove it from attribute_members, but it should be removed from relationships nonetheless. > >> >> What's up with ipaallowedtoperform_subtypes_map? Why rename the >> operations? > > It's not renaming. It's a change of internal raw LDAP value into > self-describing name consistent with terminology of ipa-getkeytab OK, you are obviously not responsible for this mess, so let's go with it. > >> >> You probably don't want to hardcode 'ipaallowedtoperform_read_keys' in >> rename_ipaallowedtoperform_to_ldap(). > > Fixed, but it doesn't make much difference given that the method has > only one purpose. Sorry, I missed the comment at the beginning of service_allow_operation, it indeed does not make any difference. (I can't say I'm a fan of such ugly hacks though.) > >> >> Why do you override get_args() in service_{,dis}allow_operation instead >> of overriding takes_args? > > Fixed > >> >> I'm not particularly happy about the '_subtype' option bussiness, but at >> least it's not invasive, so I guess it's OK. >> >> Note that I still think this API sucks and we should instead go with the >> generic member-like attribute approach, or take our time to design it >> properly so that it fits in the framework (no time in 4.1) instead of >> making it a hacky Franken-API like it is now. >> -- Jan Cholasta From tbordaz at redhat.com Thu Oct 16 10:08:21 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 16 Oct 2014 12:08:21 +0200 Subject: [Freeipa-devel] [PATCH] 0004 permission-add gives confusing error when adding ACI to generated tree In-Reply-To: <543E85B7.6090306@redhat.com> References: <543E55A7.2000105@redhat.com> <543E59D6.2060300@redhat.com> <543E6145.7060709@redhat.com> <543E85B7.6090306@redhat.com> Message-ID: <543F9915.7030305@redhat.com> On 10/15/2014 04:33 PM, Martin Kosek wrote: > On 10/15/2014 01:57 PM, thierry bordaz wrote: >> On 10/15/2014 01:26 PM, Martin Kosek wrote: >>> On 10/15/2014 01:08 PM, thierry bordaz wrote: >>>> https://fedorahosted.org/freeipa/ticket/4523 >>> I see 2 issues with the patch: >>> >>> 1) Patch description should not contain " >>> Reviewed by:", this gets added later by a script (or human) >> ok >>> 2) The exception handling clause should be as focused as possible, i.e. not >>> including whole command, but rather just the failing call, i.e.: >>> >>> def post_callback(self, ldap, dn, entry, *keys, **options): >>> try: >>> self.obj.add_aci(entry) >>> except Exception: >>> >>> You can use >>> >>> try: >>> ... >>> except errors.NotFound: >>> self.obj.handle_not_found(*keys) >>> >>> to raise the right error. >>> >>> Martin >> Currently the exception is handled on the failure of >> baseldap.LDAPCreate.execute(). Do you recommend to make the fix inside >> baseldap.LDAPCreate.execute rather than at the 'permission_add.execute' level ? > No, not there. I thought that the exception happens in > > def post_callback(self, ldap, dn, entry, *keys, **options): > try: > self.obj.add_aci(entry) > except Exception: > ... > >> Also using handle_not_found looks good, but it reports something like: >> >> ipa permission-add user1 --right read --attrs cn --subtree >> 'cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' >> ipa: ERROR: user1: permission not found >> >> >> If the entry 'user1' exists, it is not clear what was not found. >> Displaying the dn of the entry would help to know that we are updating an entry >> into the 'compat' tree. > Ah, sorry, I think I mislead you with this advise. You probably could use the > same except clause as already used: > > except errors.NotFound: > raise errors.ValidationError( > name='ipapermlocation', > error=_('Entry %s does not exist') % location) > > Martin Thanks Martin for your review. Here is a second fix. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0004-2-permission-add-gives-confusing-error-when-adding-ACI.patch Type: text/x-patch Size: 1473 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 16 10:32:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Oct 2014 12:32:08 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <543F95AC.1090700@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> <543F8ED7.8010806@redhat.com> <543F95AC.1090700@redhat.com> Message-ID: <543F9EA8.2030005@redhat.com> On 16.10.2014 11:53, Jan Cholasta wrote: > Dne 16.10.2014 v 11:24 Petr Vobornik napsal(a): >> On 16.10.2014 09:54, Jan Cholasta wrote: >>> Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): >>>> On 8.10.2014 18:51, Petr Vobornik wrote: >>>>> On 1.10.2014 18:15, Petr Vobornik wrote: >>>>>> Hello list, >>>>>> >>>>>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>>>>> >>>>> >>>>> New revisions of 761 and 763 with updated API and ACIs: >>>>> >>>>> ipa host-allow-operation HOSTNAME retrieve-keytab --users=STR --groups >>>>> STR >>>>> ipa host-disallow-operation HOSTNAME retrieve-keytab --users=STR >>>>> --groups STR >>>>> ipa host-allow-operation HOSTNAME create-keytab --users=STR >>>>> --groups STR >>>>> ipa host-disallow-operation HOSTNAME create-keytab --users=STR >>>>> --groups STR >>>>> >>>>> ipa service-allow-operation PRINCIPAL retrieve-keytab --users=STR >>>>> --groups STR >>>>> ipa service-disallow-operation PRINCIPAL retrieve-keytab >>>>> --users=STR >>>>> --groups STR >>>>> ipa service-allow-operation PRINCIPAL create-keytab --users=STR >>>>> --groups STR >>>>> ipa service-disallow-operation PRINCIPAL create-keytab --users=STR >>>>> --groups STR >>>>> >>>>> ACIs are targeted to specific operations by including subtypes. >>>>> >>>> >>>> patch #761 rebased because of VERSION bump >>> >>> Since we are apparently not going to treat ipaAllowedToPerform as a >>> member attribute, you should remove reference to it from >>> attribute_members and relationships attributes of service and host. >> >> I still think of it a as member attribute, at least internally. > > Given the implementation, I see you can't remove it from > attribute_members, but it should be removed from relationships nonetheless. > affected parts of relationships removed >> >>> >>> What's up with ipaallowedtoperform_subtypes_map? Why rename the >>> operations? >> >> It's not renaming. It's a change of internal raw LDAP value into >> self-describing name consistent with terminology of ipa-getkeytab > > OK, you are obviously not responsible for this mess, so let's go with it. > >> >>> >>> You probably don't want to hardcode 'ipaallowedtoperform_read_keys' in >>> rename_ipaallowedtoperform_to_ldap(). >> >> Fixed, but it doesn't make much difference given that the method has >> only one purpose. > > Sorry, I missed the comment at the beginning of service_allow_operation, > it indeed does not make any difference. (I can't say I'm a fan of such > ugly hacks though.) > >> >>> >>> Why do you override get_args() in service_{,dis}allow_operation instead >>> of overriding takes_args? >> >> Fixed >> >>> >>> I'm not particularly happy about the '_subtype' option bussiness, but at >>> least it's not invasive, so I guess it's OK. >>> >>> Note that I still think this API sucks and we should instead go with the >>> generic member-like attribute approach, or take our time to design it >>> properly so that it fits in the framework (no time in 4.1) instead of >>> making it a hacky Franken-API like it is now. >>> > > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0761-5-keytab-manipulation-permission-management.patch Type: text/x-patch Size: 26132 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 16 10:45:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 12:45:55 +0200 Subject: [Freeipa-devel] [PATCH] 0004 permission-add gives confusing error when adding ACI to generated tree In-Reply-To: <543F9915.7030305@redhat.com> References: <543E55A7.2000105@redhat.com> <543E59D6.2060300@redhat.com> <543E6145.7060709@redhat.com> <543E85B7.6090306@redhat.com> <543F9915.7030305@redhat.com> Message-ID: <543FA1E3.7030608@redhat.com> On 10/16/2014 12:08 PM, thierry bordaz wrote: > On 10/15/2014 04:33 PM, Martin Kosek wrote: >> On 10/15/2014 01:57 PM, thierry bordaz wrote: >>> On 10/15/2014 01:26 PM, Martin Kosek wrote: >>>> On 10/15/2014 01:08 PM, thierry bordaz wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4523 >>>> I see 2 issues with the patch: >>>> >>>> 1) Patch description should not contain " >>>> Reviewed by:", this gets added later by a script (or human) >>> ok >>>> 2) The exception handling clause should be as focused as possible, i.e. not >>>> including whole command, but rather just the failing call, i.e.: >>>> >>>> def post_callback(self, ldap, dn, entry, *keys, **options): >>>> try: >>>> self.obj.add_aci(entry) >>>> except Exception: >>>> >>>> You can use >>>> >>>> try: >>>> ... >>>> except errors.NotFound: >>>> self.obj.handle_not_found(*keys) >>>> >>>> to raise the right error. >>>> >>>> Martin >>> Currently the exception is handled on the failure of >>> baseldap.LDAPCreate.execute(). Do you recommend to make the fix inside >>> baseldap.LDAPCreate.execute rather than at the 'permission_add.execute' level ? >> No, not there. I thought that the exception happens in >> >> def post_callback(self, ldap, dn, entry, *keys, **options): >> try: >> self.obj.add_aci(entry) >> except Exception: >> ... >> >>> Also using handle_not_found looks good, but it reports something like: >>> >>> ipa permission-add user1 --right read --attrs cn --subtree >>> 'cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' >>> ipa: ERROR: user1: permission not found >>> >>> >>> If the entry 'user1' exists, it is not clear what was not found. >>> Displaying the dn of the entry would help to know that we are updating an entry >>> into the 'compat' tree. >> Ah, sorry, I think I mislead you with this advise. You probably could use the >> same except clause as already used: >> >> except errors.NotFound: >> raise errors.ValidationError( >> name='ipapermlocation', >> error=_('Entry %s does not exist') % location) >> >> Martin > Thanks Martin for your review. Here is a second fix. I am sorry, this is still not what I meant. You cannot wrap whole permission-add command, wait for very general error and then report very specific error. Try-except clauses need to be as close to the guarded problem as possible. See PEP8 for example (http://legacy.python.org/dev/peps/pep-0008/): .. Additionally, for all try/except clauses, limit the try clause to the absolute minimum amount of code necessary. Again, this avoids masking bugs ... To speed up the resolution of this patch, please see a proposed patch, I hope it works for you. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-484-raise-better-error-message-for-permission-added-to-g.patch Type: text/x-patch Size: 1832 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 16 11:34:26 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Oct 2014 13:34:26 +0200 Subject: [Freeipa-devel] [PATCH] 353 Allow specifying signing algorithm of the IPA CA cert in ipa-ca-install In-Reply-To: <543F7B11.5010401@redhat.com> References: <54352188.4030609@redhat.com> <543E87E7.8060802@redhat.com> <543F7B11.5010401@redhat.com> Message-ID: <543FAD42.3030307@redhat.com> On 16.10.2014 10:00, Jan Cholasta wrote: > Dne 15.10.2014 v 16:42 Petr Vobornik napsal(a): >> On 8.10.2014 13:35, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch provides an additional fix for >>> . >>> >>> Honza >>> >> >> Requires rebase because of `ca_type=options.external_ca_type)`. Works >> fine with older version. > > Rebased on top of current ipa-4-1, patch attached. > ACK Pushed to: master: cf860c71545fe93bebcb7dcb426795240e776eb3 ipa-4-1: e50d197fc0b79b9aebf6b820a7a672af6777d876 -- Petr Vobornik From nmav at redhat.com Wed Oct 15 14:24:46 2014 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Wed, 15 Oct 2014 16:24:46 +0200 Subject: [Freeipa-devel] isolated pkcs11 module Message-ID: <1413383086.1780.5.camel@dhcp-2-127.brq.redhat.com> Hi, Concerning: https://bugs.freedesktop.org/show_bug.cgi?id=51949#c3 What are your requirements? We currently have working code (but not yet merged) for an isolated security module via p11-kit. Our requirements are to protect private keys by keeping them outside a process' boundary. The main target is to run softhsm (v2) in an isolated mode. If we can combine efforts would be nice. regards, Nikos From tbordaz at redhat.com Thu Oct 16 13:32:09 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 16 Oct 2014 15:32:09 +0200 Subject: [Freeipa-devel] [PATCH] 0004 permission-add gives confusing error when adding ACI to generated tree In-Reply-To: <543FA1E3.7030608@redhat.com> References: <543E55A7.2000105@redhat.com> <543E59D6.2060300@redhat.com> <543E6145.7060709@redhat.com> <543E85B7.6090306@redhat.com> <543F9915.7030305@redhat.com> <543FA1E3.7030608@redhat.com> Message-ID: <543FC8D9.4040201@redhat.com> On 10/16/2014 12:45 PM, Martin Kosek wrote: > On 10/16/2014 12:08 PM, thierry bordaz wrote: >> On 10/15/2014 04:33 PM, Martin Kosek wrote: >>> On 10/15/2014 01:57 PM, thierry bordaz wrote: >>>> On 10/15/2014 01:26 PM, Martin Kosek wrote: >>>>> On 10/15/2014 01:08 PM, thierry bordaz wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4523 >>>>> I see 2 issues with the patch: >>>>> >>>>> 1) Patch description should not contain " >>>>> Reviewed by:", this gets added later by a script (or human) >>>> ok >>>>> 2) The exception handling clause should be as focused as possible, i.e. not >>>>> including whole command, but rather just the failing call, i.e.: >>>>> >>>>> def post_callback(self, ldap, dn, entry, *keys, **options): >>>>> try: >>>>> self.obj.add_aci(entry) >>>>> except Exception: >>>>> >>>>> You can use >>>>> >>>>> try: >>>>> ... >>>>> except errors.NotFound: >>>>> self.obj.handle_not_found(*keys) >>>>> >>>>> to raise the right error. >>>>> >>>>> Martin >>>> Currently the exception is handled on the failure of >>>> baseldap.LDAPCreate.execute(). Do you recommend to make the fix inside >>>> baseldap.LDAPCreate.execute rather than at the 'permission_add.execute' level ? >>> No, not there. I thought that the exception happens in >>> >>> def post_callback(self, ldap, dn, entry, *keys, **options): >>> try: >>> self.obj.add_aci(entry) >>> except Exception: >>> ... >>> >>>> Also using handle_not_found looks good, but it reports something like: >>>> >>>> ipa permission-add user1 --right read --attrs cn --subtree >>>> 'cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' >>>> ipa: ERROR: user1: permission not found >>>> >>>> >>>> If the entry 'user1' exists, it is not clear what was not found. >>>> Displaying the dn of the entry would help to know that we are updating an entry >>>> into the 'compat' tree. >>> Ah, sorry, I think I mislead you with this advise. You probably could use the >>> same except clause as already used: >>> >>> except errors.NotFound: >>> raise errors.ValidationError( >>> name='ipapermlocation', >>> error=_('Entry %s does not exist') % location) >>> >>> Martin >> Thanks Martin for your review. Here is a second fix. > I am sorry, this is still not what I meant. You cannot wrap whole > permission-add command, wait for very general error and then report very > specific error. Try-except clauses need to be as close to the guarded problem > as possible. > > See PEP8 for example (http://legacy.python.org/dev/peps/pep-0008/): > > .. > Additionally, for all try/except clauses, limit the try clause to the absolute > minimum amount of code necessary. Again, this avoids masking bugs > ... > > To speed up the resolution of this patch, please see a proposed patch, I hope > it works for you. > > Martin Thanks Martin for the patch and the explanations. I missed that the LDAPCreate triggered the exception when calling permission_add.post_callback. Now I understand what you meant by catching the exception as close as possible. Thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0004-3-permission-add-gives-confusing-error-when-adding-ACI.patch Type: text/x-patch Size: 1922 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 16 14:02:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 16:02:49 +0200 Subject: [Freeipa-devel] [PATCH] 0004 permission-add gives confusing error when adding ACI to generated tree In-Reply-To: <543FC8D9.4040201@redhat.com> References: <543E55A7.2000105@redhat.com> <543E59D6.2060300@redhat.com> <543E6145.7060709@redhat.com> <543E85B7.6090306@redhat.com> <543F9915.7030305@redhat.com> <543FA1E3.7030608@redhat.com> <543FC8D9.4040201@redhat.com> Message-ID: <543FD009.2000403@redhat.com> On 10/16/2014 03:32 PM, thierry bordaz wrote: > On 10/16/2014 12:45 PM, Martin Kosek wrote: >> On 10/16/2014 12:08 PM, thierry bordaz wrote: >>> On 10/15/2014 04:33 PM, Martin Kosek wrote: >>>> On 10/15/2014 01:57 PM, thierry bordaz wrote: >>>>> On 10/15/2014 01:26 PM, Martin Kosek wrote: >>>>>> On 10/15/2014 01:08 PM, thierry bordaz wrote: >>>>>>> https://fedorahosted.org/freeipa/ticket/4523 >>>>>> I see 2 issues with the patch: >>>>>> >>>>>> 1) Patch description should not contain " >>>>>> Reviewed by:", this gets added later by a script (or human) >>>>> ok >>>>>> 2) The exception handling clause should be as focused as possible, i.e. not >>>>>> including whole command, but rather just the failing call, i.e.: >>>>>> >>>>>> def post_callback(self, ldap, dn, entry, *keys, **options): >>>>>> try: >>>>>> self.obj.add_aci(entry) >>>>>> except Exception: >>>>>> >>>>>> You can use >>>>>> >>>>>> try: >>>>>> ... >>>>>> except errors.NotFound: >>>>>> self.obj.handle_not_found(*keys) >>>>>> >>>>>> to raise the right error. >>>>>> >>>>>> Martin >>>>> Currently the exception is handled on the failure of >>>>> baseldap.LDAPCreate.execute(). Do you recommend to make the fix inside >>>>> baseldap.LDAPCreate.execute rather than at the 'permission_add.execute' >>>>> level ? >>>> No, not there. I thought that the exception happens in >>>> >>>> def post_callback(self, ldap, dn, entry, *keys, **options): >>>> try: >>>> self.obj.add_aci(entry) >>>> except Exception: >>>> ... >>>> >>>>> Also using handle_not_found looks good, but it reports something like: >>>>> >>>>> ipa permission-add user1 --right read --attrs cn --subtree >>>>> 'cn=compat,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' >>>>> ipa: ERROR: user1: permission not found >>>>> >>>>> >>>>> If the entry 'user1' exists, it is not clear what was not found. >>>>> Displaying the dn of the entry would help to know that we are updating an >>>>> entry >>>>> into the 'compat' tree. >>>> Ah, sorry, I think I mislead you with this advise. You probably could use the >>>> same except clause as already used: >>>> >>>> except errors.NotFound: >>>> raise errors.ValidationError( >>>> name='ipapermlocation', >>>> error=_('Entry %s does not exist') % location) >>>> >>>> Martin >>> Thanks Martin for your review. Here is a second fix. >> I am sorry, this is still not what I meant. You cannot wrap whole >> permission-add command, wait for very general error and then report very >> specific error. Try-except clauses need to be as close to the guarded problem >> as possible. >> >> See PEP8 for example (http://legacy.python.org/dev/peps/pep-0008/): >> >> .. >> Additionally, for all try/except clauses, limit the try clause to the absolute >> minimum amount of code necessary. Again, this avoids masking bugs >> ... >> >> To speed up the resolution of this patch, please see a proposed patch, I hope >> it works for you. >> >> Martin > Thanks Martin for the patch and the explanations. I missed that the LDAPCreate > triggered the exception when calling permission_add.post_callback. Now I > understand what you meant by catching the exception as close as possible. > > Thierry > I understand that as an ACK from you then :-) Given the effort I had to develop the patch, I will push that original version and add you as a reviewer. Pushed to: master: 061f7ff331531fa01801fb597feed924de6a2fd7 ipa-4-1: 0a54b1c948e5c25d971f5b0ef4bc079cbd605069 Thanks! Martin From pvoborni at redhat.com Thu Oct 16 14:28:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Oct 2014 16:28:56 +0200 Subject: [Freeipa-devel] [PATCHES] 349-350 Add ipa-client-install switch --request-cert to request cert for the host In-Reply-To: <5434F817.4000908@redhat.com> References: <5434F817.4000908@redhat.com> Message-ID: <543FD628.3060609@redhat.com> On 8.10.2014 10:38, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Honza > Works fine. Just minor ones: 1. The new option deserves a 'help' text. basic_group.add_option("--request-cert", dest="request_cert", action="store_true", default=False) 2. Typo: 'A RA is not' -- Petr Vobornik From jcholast at redhat.com Thu Oct 16 15:29:52 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Oct 2014 17:29:52 +0200 Subject: [Freeipa-devel] [PATCHES] 349-350 Add ipa-client-install switch --request-cert to request cert for the host In-Reply-To: <543FD628.3060609@redhat.com> References: <5434F817.4000908@redhat.com> <543FD628.3060609@redhat.com> Message-ID: <543FE470.3000108@redhat.com> Dne 16.10.2014 v 16:28 Petr Vobornik napsal(a): > On 8.10.2014 10:38, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Honza >> > > Works fine. Just minor ones: > > 1. The new option deserves a 'help' text. > > basic_group.add_option("--request-cert", dest="request_cert", > action="store_true", default=False) Good point, will fix. > > > 2. Typo: 'A RA is not' Not a typo, it was reverted from and has been around since . -- Jan Cholasta From mkosek at redhat.com Thu Oct 16 15:35:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 17:35:46 +0200 Subject: [Freeipa-devel] [PATCH 0071] Display token type when viewing token In-Reply-To: <1413390721.6617.20.camel@redhat.com> References: <1413390721.6617.20.camel@redhat.com> Message-ID: <543FE5D2.5080808@redhat.com> On 10/15/2014 06:32 PM, Nathaniel McCallum wrote: > When viewing a token from the CLI or UI, the type of the token > should be displayed. > > https://fedorahosted.org/freeipa/ticket/4563 Adding objectclass to default_attributes is unprecedented and something we should not do before release. It would also put objectclass attribute in default otptoken-* operations. What I would do in this case is to - keep default_attributes as is - add 'objectclass' to attrs_list in pre_callback - do whatever you already do with it in post_callback - remove the objectclass if it was not called for explicitly, e.g.: if not options.get('all', False) or options.get('pkey_only', False): entry_attrs.pop('objectclass', None) This approach is used for example in idrange.py so I would stick with it (I am not saying it is pretty, I am just saying our API should give consistent output). Martin From jcholast at redhat.com Thu Oct 16 15:40:38 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Oct 2014 17:40:38 +0200 Subject: [Freeipa-devel] [PATCH] 347 Fix CA cert validity check for CA-less and external CA installer options In-Reply-To: <5434132E.1000304@redhat.com> References: <5434132E.1000304@redhat.com> Message-ID: <543FE6F6.5040303@redhat.com> Dne 7.10.2014 v 18:22 Jan Cholasta napsal(a): > Hi, > > the attached patch fixes . > > Honza Attached a patch with a proper fix. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-347.1-Fix-CA-cert-validity-check-for-CA-less-and-external-.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 16 15:47:38 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Oct 2014 17:47:38 +0200 Subject: [Freeipa-devel] [PATCHES] 349-350 Add ipa-client-install switch --request-cert to request cert for the host In-Reply-To: <543FE470.3000108@redhat.com> References: <5434F817.4000908@redhat.com> <543FD628.3060609@redhat.com> <543FE470.3000108@redhat.com> Message-ID: <543FE89A.4040707@redhat.com> Dne 16.10.2014 v 17:29 Jan Cholasta napsal(a): > Dne 16.10.2014 v 16:28 Petr Vobornik napsal(a): >> On 8.10.2014 10:38, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix . >>> >>> Honza >>> >> >> Works fine. Just minor ones: >> >> 1. The new option deserves a 'help' text. >> >> basic_group.add_option("--request-cert", dest="request_cert", >> action="store_true", default=False) > > Good point, will fix. > >> >> >> 2. Typo: 'A RA is not' > > Not a typo, it was reverted from > > and has been around since > . > Updated rebased patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-349.1-Fix-certmonger.request_cert.patch Type: text/x-patch Size: 1361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-350.1-Add-ipa-client-install-switch-request-cert-to-reques.patch Type: text/x-patch Size: 8279 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 16 15:54:00 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Oct 2014 17:54:00 +0200 Subject: [Freeipa-devel] [PATCH 0070] Remove token ID from self-service UI In-Reply-To: <1413385199.6617.18.camel@redhat.com> References: <1413385199.6617.18.camel@redhat.com> Message-ID: <543FEA18.6050409@redhat.com> On 15.10.2014 16:59, Nathaniel McCallum wrote: > Also, fix labels to properly use i18n strings for token types. > ACK Pushed to: master: c5f7ca58a1b74344c3d39493a9b0645a8f4b64a7 ipa-4-1: 0f69e753bda8ee44d5580967f1c877d2db5d22a5 -- Petr Vobornik From pvoborni at redhat.com Thu Oct 16 15:58:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Oct 2014 17:58:13 +0200 Subject: [Freeipa-devel] [PATCH 0072] Remove token vendor, model and serial defaults In-Reply-To: <1413390787.6617.21.camel@redhat.com> References: <1413390787.6617.21.camel@redhat.com> Message-ID: <543FEB15.5020303@redhat.com> On 15.10.2014 18:33, Nathaniel McCallum wrote: > These defaults are pretty useless and cause more confusion than > they are worth. The serial default never worked anyway. And now > that we are displaying the token type separately, there is no > reason to doubly record these data points. > ACK Pushed to: master: 284792e7d8e06dd6dba24da4362aab56bbaaaef4 ipa-4-1: 7ddf4b35394292a1dcd84ec501cd8f6dcf3cef08 -- Petr Vobornik From mbasti at redhat.com Thu Oct 16 15:59:25 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 16 Oct 2014 17:59:25 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <5437880E.5010002@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> Message-ID: <543FEB5D.5020402@redhat.com> On 10/10/14 09:17, Martin Kosek wrote: > On 10/09/2014 03:57 PM, Petr Spacek wrote: >> Hello, >> >> it would be great if people could look at current state of DNSSEC >> patches for >> FreeIPA. >> >> It consist of several relatively independent parts: >> - python-pkcs#11 interface written by Martin Basti: >> https://github.com/spacekpe/freeipa-pkcs11 >> >> - DNSSEC daemons written by me: >> https://github.com/spacekpe/ipadnssecd >> >> - FreeIPA integration written by Martin Basti: >> https://github.com/bastiak/freeipa/tree/dnssec Here is updated repo with installers, please review: https://github.com/bastiak/freeipa/tree/dnssec-4 branch dnssec-4 TODO: integrate ipadnssecd daemons and pkcs11 helper, when finished >> >> For now brief visual inspection is good enough :-) >> >> Current state >> ============= >> - It works only on single DNSSEC "master" server because we still do >> not have >> the key wrapping machinery. >> - The "master" server has to be configured manually using >> ipa-dnssec-setmaster >> utility. >> - DNSSEC keys are generated on the fly when DNSSEC is enabled for >> particular zone. >> - Metadata for BIND are generated on the fly. >> - BIND automatically signs the zone. >> >> It depends on latest softhsm, opendnssec and bind-pkcs11-util & >> bind-pkcs11 >> packages which are not in Fedora 21 yet. >> >> Thank you for your time! >> > > Good! I am glad to see a progress. I am also CCing Simo and Rob to be > in the loop. It would be especially useful if you also show Simo your > special file permissions (setfacl) and sharing config files between > daemons. I rather nervous about this part. > > To comment on FreeIPA integration - I saw you are adding a new config > file: > - install/tools/ipa-dnssec-setmaster > > I wonder how consistent and future proof that is. Setting master is > currently being done in "ipa-*replica-manage", check for example > "ipa-csreplica-manage". We want to have these operations on a sensible > place as we will be refactoring them in 4.2. > > As for the service installation code itself, I would rather see it in > > # ipa-dns-install > > which could have new --dnssec-master and --no-dnssec flag. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin Basti From mkosek at redhat.com Thu Oct 16 16:12:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 18:12:36 +0200 Subject: [Freeipa-devel] [PATCH] 347 Fix CA cert validity check for CA-less and external CA installer options In-Reply-To: <543FE6F6.5040303@redhat.com> References: <5434132E.1000304@redhat.com> <543FE6F6.5040303@redhat.com> Message-ID: <543FEE74.3060007@redhat.com> On 10/16/2014 05:40 PM, Jan Cholasta wrote: > Dne 7.10.2014 v 18:22 Jan Cholasta napsal(a): >> Hi, >> >> the attached patch fixes . >> >> Honza > > Attached a patch with a proper fix. This version works fine, ACK. Pushed to: master: fdc70e89e9fa83b45ef403eda401c0c85f205480 ipa-4-1: 9607fe3b9676d88904de91e9dfd21f6fb691cf39 Martin From pvoborni at redhat.com Thu Oct 16 17:03:04 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Oct 2014 19:03:04 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <543F95AC.1090700@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> <543F8ED7.8010806@redhat.com> <543F95AC.1090700@redhat.com> Message-ID: <543FFA48.8090504@redhat.com> On 16.10.2014 11:53, Jan Cholasta wrote: > Dne 16.10.2014 v 11:24 Petr Vobornik napsal(a): >> On 16.10.2014 09:54, Jan Cholasta wrote: >>> Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): >>>> On 8.10.2014 18:51, Petr Vobornik wrote: >>>>> On 1.10.2014 18:15, Petr Vobornik wrote: >>>>>> Hello list, >>>>>> >>>>>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>>>>> >>>>> >>>>> New revisions of 761 and 763 with updated API and ACIs: Given: > Given the implementation, I see you can't remove it from snip > OK, you are obviously not responsible for this mess, so let's go with it. snip > ugly hacks though.)> snip >>> I'm not particularly happy about the '_subtype' option bussiness, but at >>> least it's not invasive, so I guess it's OK. >>> >>> Note that I still think this API sucks and we should instead go with the >>> generic member-like attribute approach, or take our time to design it >>> properly so that it fits in the framework (no time in 4.1) instead of >>> making it a hacky Franken-API like it is now. >>> and a discussion with Honza I've attached alternative versions of this patch - based on 761-1 with API as follows: ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR ipa service-allow-retrieve-keytab PRINCIPAL --users=STR --groups STR ipa service-disallow-retrieve-keytab PRINCIPAL --users=STR --groups STR ipa service-allow-create-keytab PRINCIPAL --users=STR --groups STR ipa service-disallow-create-keytab PRINCIPAL --users=STR --groups STR and updated ACIs Both approaches have their own drawbacks. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0761-6-keytab-manipulation-permission-management.patch Type: text/x-patch Size: 32862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0763-2-tests-management-of-keytab-permissions.patch Type: text/x-patch Size: 30495 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 16 17:13:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 16 Oct 2014 19:13:03 +0200 Subject: [Freeipa-devel] [PATCHES] 349-350 Add ipa-client-install switch --request-cert to request cert for the host In-Reply-To: <543FE89A.4040707@redhat.com> References: <5434F817.4000908@redhat.com> <543FD628.3060609@redhat.com> <543FE470.3000108@redhat.com> <543FE89A.4040707@redhat.com> Message-ID: <543FFC9F.8040602@redhat.com> On 16.10.2014 17:47, Jan Cholasta wrote: > Dne 16.10.2014 v 17:29 Jan Cholasta napsal(a): >> Dne 16.10.2014 v 16:28 Petr Vobornik napsal(a): >>> On 8.10.2014 10:38, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix >>>> . >>>> >>>> Honza > > Updated rebased patches attached. > ACK pushed to master: * 4333a623da4190a7e59e7397159e8200d131904b Fix certmonger.request_cert * ca7e0c270f5e3b685fd2fbe34b676e85c373c5d0 Add ipa-client-install switch --request-cert to request cert for the host ipa-4-1: * 68a36a28045a39afa1131f19e0298a828a367ee5 Fix certmonger.request_cert * b5f9d40dba05ebfdc3f635d5016bd28a5a03ce63 Add ipa-client-install switch --request-cert to request cert for the host -- Petr Vobornik From jcholast at redhat.com Thu Oct 16 17:43:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 16 Oct 2014 19:43:06 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <543FEB5D.5020402@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> Message-ID: <544003AA.7020805@redhat.com> Hi, Dne 16.10.2014 v 17:59 Martin Basti napsal(a): > On 10/10/14 09:17, Martin Kosek wrote: >> On 10/09/2014 03:57 PM, Petr Spacek wrote: >>> Hello, >>> >>> it would be great if people could look at current state of DNSSEC >>> patches for >>> FreeIPA. >>> >>> It consist of several relatively independent parts: >>> - python-pkcs#11 interface written by Martin Basti: >>> https://github.com/spacekpe/freeipa-pkcs11 >>> >>> - DNSSEC daemons written by me: >>> https://github.com/spacekpe/ipadnssecd >>> >>> - FreeIPA integration written by Martin Basti: >>> https://github.com/bastiak/freeipa/tree/dnssec > Here is updated repo with installers, please review: > https://github.com/bastiak/freeipa/tree/dnssec-4 > branch dnssec-4 > > TODO: integrate ipadnssecd daemons and pkcs11 helper, when finished Commit "DNSSEC: schema": 1) ipaSecretKeyRef is missing X-ORIGIN. 2) Nitpick: rename 60ipapkcs11.ldif to 60ipapk11.ldif. Commit "DNSSEC: DNS key synchronization daemon": 1) Maybe we should rename uuid-ipauniqueid.ldif to uuid.ldif, now that it contains more than just ipauniqueid. 2) ipaConfigString values use camel case, so I would prefer "dnssecVersion" instead of "dnssec-version". 3) Use ipapython.ipautil.ipa_generate_password() to generate the PIN in DNSKeySyncInstance.__setup_softhsm() 4) You probably should put a constant with a path to softhsm2-util to ipaplatform.paths and use that in ipautil.run(). 5) There are some PEP8 errors in ipaserver/install/dnskeysyncinstance.py. Commit "DNSSEC: opendnssec services": 1) There are some PEP8 errors in ipaserver/install/odsexporterinstance.py and ipaserver/install/opendnssecinstance.py. 2) Nitpick: rename OdsExporterInstance to ODSExporterInstance 3) Not something you can fix in this commit, but shouldn't ipa-ods-exporter be named ipa-odsexportd, so that the naming is consistent with the rest of our daemons? 4) dns_exporter_principal is a bit misleading name for a variable that holds a DN in OdsExporterInstance.__setup_principal(). 5) To follow up on the disable/mask issue: IMO you should create a special service class for ods-signerd in ipaplatform which calls "systemctl mask" when disabled, instead of adding a mask method. 6) IMO the KEYMASTER constant should be u'dnssecKeyMaster', again to make it consistent with other ipaConfigString values. Commit "DNSSEC: platform and service variables": 1) IMO some of the path constants should be renamed for consistency: NAMED = "/usr/sbin/named" NAMED_PKCS11 = "/usr/sbin/named-pkcs11" SOFTHSM_CONF = "/etc/softhsm2.conf" DNSSEC_TOKENS_DIR = "/var/lib/ipa/dnssec/tokens" DNSSEC_SOFTHSM_PIN_SO = "/etc/ipa/softhsm_pin_so" DNSSEC_SOFTHSM_PIN = "/var/lib/ipa/dnssec/softhsm_pin" VAR_OPENDNSSEC_DIR = "/var/opendnssec" ETC_OPENDNSSEC_DIR = "/etc/opendnssec" ODS_KSMUTIL = "/usr/bin/ods-ksmutil" 2) Why do you use the default /etc/softhsm2.conf file, instead of using e.g. /etc/ipa/dnssec/softhsm2.conf and passing it to SoftHSM in the SOFTHSM2_CONF environment variable? 3) You should provide /usr/lib/ equivalent for: SOFTHSM_LIB = "/usr/lib64/pkcs11/libsofthsm2.so" and use it when necessary. 4) I think /etc/ipa/softhsm_pin_so should be moved to /etc/ipa/dnssec/softhsm_pin_so. 5) Nitpick: unnecessary whitespace change in ipaplatform/redhat/services.py 6) Instead of making changes to the redhat platform module and reverting them in the rhel platform module, you should do them in the fedora platform module only. 7) IMO it would be better to move the new RedHatTaskNamespace methods to service-specific classes (create them if necessary). Commit "DNSSEC: validate forwarders": 1) I'm not sure if failing on DNSSEC-disabled forwarders by default is a good idea. Perhaps there could be some auto-detection code? Something along the lines of: if forwarders_support_dnssec: if not options.no_dnssec_validation: enable_dnssec_in_ipa() else: print "WARNING: DNSSEC will not be enabled" 2) Please don't use ValidationError in check_forwarders(), use ValueError instead and re-raise it as ValidationError only where necessary. Commit "DNSSEC: modify named service to support dnssec": 1) Rather than checking if paths.DNSSEC_KEYFROMLABEL is None, add a method with the check to named-specific service class in ipaplatform. Commit "DNSSEC: installation": 1) This should be handled in OpenDNSSECInstance.get_masters() itself: + ods.ldap_connect() # we need connection before getting masters More tomorrow! Honza -- Jan Cholasta From pspacek at redhat.com Thu Oct 16 18:01:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 16 Oct 2014 20:01:54 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <544003AA.7020805@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> <544003AA.7020805@redhat.com> Message-ID: <54400812.1010101@redhat.com> On 16.10.2014 19:43, Jan Cholasta wrote: > Dne 16.10.2014 v 17:59 Martin Basti napsal(a): >> On 10/10/14 09:17, Martin Kosek wrote: >>> On 10/09/2014 03:57 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> it would be great if people could look at current state of DNSSEC >>>> patches for >>>> FreeIPA. >>>> >>>> It consist of several relatively independent parts: >>>> - python-pkcs#11 interface written by Martin Basti: >>>> https://github.com/spacekpe/freeipa-pkcs11 >>>> >>>> - DNSSEC daemons written by me: >>>> https://github.com/spacekpe/ipadnssecd >>>> >>>> - FreeIPA integration written by Martin Basti: >>>> https://github.com/bastiak/freeipa/tree/dnssec >> Here is updated repo with installers, please review: >> https://github.com/bastiak/freeipa/tree/dnssec-4 >> branch dnssec-4 >> >> TODO: integrate ipadnssecd daemons and pkcs11 helper, when finished ... > 3) > > Not something you can fix in this commit, but shouldn't ipa-ods-exporter be > named ipa-odsexportd, so that the naming is consistent with the rest of our > daemons? Side note: ipa-ods-exporter is not a daemon :-) It is single-shot binary activated via socket. It is replacement for "ODS signer" and uses the same protocol. Anyway, I don't care much. Feel free pick a new name and let me know. > 2) > > Why do you use the default /etc/softhsm2.conf file, instead of using e.g. > /etc/ipa/dnssec/softhsm2.conf and passing it to SoftHSM in the SOFTHSM2_CONF > environment variable? I don't like the idea. The same library is used from named and ods-enforcerd so we would have to modify environment variables for all of them and do some monkey patching in /etc/systemd. AFAIK current ipactl/framework is sooo clever so it deletes service files related to all services "managed" by IPA if they are located in /etc/systemd. As a result we don't have any way how to override values supplies by other packages now. > 4) > > I think /etc/ipa/softhsm_pin_so should be moved to > /etc/ipa/dnssec/softhsm_pin_so. Is it a good idea to store both PINs on the same spot? softhsm_pin_so is not necessary at run-time so it can be readable only by root:root. > Commit "DNSSEC: validate forwarders": > > 1) > > I'm not sure if failing on DNSSEC-disabled forwarders by default is a good > idea. Perhaps there could be some auto-detection code? Something along the > lines of: > > if forwarders_support_dnssec: > if not options.no_dnssec_validation: > enable_dnssec_in_ipa() > else: > print "WARNING: DNSSEC will not be enabled" We have discussed this with Martin and the intent is to tell people that their infrastructure is broken and has to be fixed - sooner is better. There is an option --no-dnssec-validation for people who like broken infrastructure. -- Petr^2 Spacek From mkosek at redhat.com Thu Oct 16 18:28:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 20:28:27 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <543FFA48.8090504@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> <543F8ED7.8010806@redhat.com> <543F95AC.1090700@redhat.com> <543FFA48.8090504@redhat.com> Message-ID: <54400E4B.8010308@redhat.com> On 10/16/2014 07:03 PM, Petr Vobornik wrote: > On 16.10.2014 11:53, Jan Cholasta wrote: >> Dne 16.10.2014 v 11:24 Petr Vobornik napsal(a): >>> On 16.10.2014 09:54, Jan Cholasta wrote: >>>> Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): >>>>> On 8.10.2014 18:51, Petr Vobornik wrote: >>>>>> On 1.10.2014 18:15, Petr Vobornik wrote: >>>>>>> Hello list, >>>>>>> >>>>>>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>>>>>> >>>>>> >>>>>> New revisions of 761 and 763 with updated API and ACIs: > > Given: > >> Given the implementation, I see you can't remove it from > snip >> OK, you are obviously not responsible for this mess, so let's go with it. > snip >> ugly hacks though.)> > snip >>>> I'm not particularly happy about the '_subtype' option bussiness, but at >>>> least it's not invasive, so I guess it's OK. >>>> >>>> Note that I still think this API sucks and we should instead go with the >>>> generic member-like attribute approach, or take our time to design it >>>> properly so that it fits in the framework (no time in 4.1) instead of >>>> making it a hacky Franken-API like it is now. >>>> > > and a discussion with Honza > > I've attached alternative versions of this patch - based on 761-1 with API as > follows: > > ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR > ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR > ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR > ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR > > ipa service-allow-retrieve-keytab PRINCIPAL --users=STR --groups STR > ipa service-disallow-retrieve-keytab PRINCIPAL --users=STR --groups STR > ipa service-allow-create-keytab PRINCIPAL --users=STR --groups STR > ipa service-disallow-create-keytab PRINCIPAL --users=STR --groups STR > > and updated ACIs > > Both approaches have their own drawbacks. Given the discussion we had, I think I can live with this version too, especially if it makes the API or the code less hackier than with the API version I proposed. So if Honza ACKs the code, I am fine with this API version. Martin From mkosek at redhat.com Thu Oct 16 18:39:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 20:39:05 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <54400812.1010101@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> <544003AA.7020805@redhat.com> <54400812.1010101@redhat.com> Message-ID: <544010C9.3080607@redhat.com> On 10/16/2014 08:01 PM, Petr Spacek wrote: .... >> 1) >> >> I'm not sure if failing on DNSSEC-disabled forwarders by default is a good >> idea. Perhaps there could be some auto-detection code? Something along the >> lines of: >> >> if forwarders_support_dnssec: >> if not options.no_dnssec_validation: >> enable_dnssec_in_ipa() >> else: >> print "WARNING: DNSSEC will not be enabled" > > We have discussed this with Martin ... Martin Basti/Martin2... Given there are more Martins in the team, you should be more specific :-) > and the intent is to tell people that their > infrastructure is broken and has to be fixed - sooner is better. > > There is an option --no-dnssec-validation for people who like broken > infrastructure. Broken infrastructure is rather strong word for the situation when just DNSSEC is not configured (it may work for the customer otherwise). "Infrastructure does not follow most up to date standards" may be more precise. From my POV, this may be too strict. People may already use ipa-server-install in their scripts and it suddenly requiring new option may be seen as breakage. So maybe it would be better to just print big fat warning including [yes|no] question to continue during ipa-server-install and just print warning in unattended mode (and disable DNSEC validation) We can always be more strict in next release. CCing Simo and Rob in case they have different opinions. Martin From mkosek at redhat.com Thu Oct 16 19:02:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 16 Oct 2014 21:02:55 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <543E209F.9020709@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> <5436BC59.2090008@redhat.com> <1413313274.6617.12.camel@redhat.com> <543E209F.9020709@redhat.com> Message-ID: <5440165F.8050902@redhat.com> On 10/15/2014 09:22 AM, Martin Kosek wrote: > On 10/14/2014 09:01 PM, Nathaniel McCallum wrote: >> On Thu, 2014-10-09 at 18:48 +0200, thierry bordaz wrote: >>> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: >>> >>>> On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: >>>>> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: >>>>> >>>>>> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: >>>>>>> On Wed, 08 Oct 2014 15:53:39 -0400 >>>>>>> Nathaniel McCallum wrote: >>>>>>> >>>>>>>> As I understand my code, all servers will have csnD. Some servers will >>>>>>>> have valueB and others will have valueD, but valueB == valueD. >>>>>>>> >>>>>>>> We *never* discard a CSN. We only discard the counter/watermark mods >>>>>>>> in the replication operation. >>>>>>> What Thierry is saying is that the individual attributes in the entry >>>>>>> have associate the last CSN that modified them. Because you remove the >>>>>>> mods when ValueD == ValueB the counter attribute will not have the >>>>>>> associated CSN changed. But it doesn't really matter because the plugin >>>>>>> will always keep things consistent. >>>>>> Attached is a new version. It removes this optimization. If server X has >>>>>> valueB/csnB and receives valueD/csnD and valueB == valueD, the >>>>>> replication will be applied without any modification. However, if valueB >>>>>>> valueD and csnD > csnB, the counter mods will still be stripped. >>>>>> It also collapses the error check from betxnpre to bepre now that we >>>>>> have a fix for https://fedorahosted.org/389/ticket/47919 committed. The >>>>>> betxnpre functions are completely removed. Also, a dependency on 389 >>>>>> 1.3.3.4 (not yet released) is added. >>>>>> >>>>>> Nathaniel >>>>> Hello Nathaniel, >>>>> >>>>> For me the code is fine. Ack. >>>> New attached patch. >>>> >>>>> I have two minor comments: >>>>> * in preop_mod, when a direct update moves the counter >>>>> backward you send UNWILLING to perform with a message. >>>>> The message is allocated with slapi_ch_smprintf, you >>>>> may free it with slapi_ch_free_string (rather than >>>>> 'free'). >>>> Fixed. >>>> >>>>> * About this message, for example when you have these >>>>> MODS (I admit they make no sens): >>>>> >>>>> changetype: modify >>>>> ipatokenHOTPcounter: MOD_DELETE >>>>> - >>>>> ipatokenHOTPcounter: MOD_INCREMENT >>>>> >>>>> The returned message will be "Will not decrement >>>>> ipatokenHOTPcounter", because 'simulate' will return >>>>> 'COUNTER_UNSET+1'. >>>>> Is it the message you expected ? >>>> I changed the logic in simulate(). Please review it. >>>> >>>> Nathaniel >>>> >>> Hello Nathaniel, >>> >>> >>> The patch is ok for me. Ack. >> >> Since the ACK, the upstream 389 fix actually landed in 1.3.3.5. This >> patch changes nothing except the dependency version. I have tested it >> against the 1.3.3.5 build. >> >> Nathaniel > > Great! As soon as the new build land in Fedora 21 (and we add it to our Copr), > the patch can be pushed. > > Martin Ok, 1.3.3.5 is in koji and our Copr repo. I almost pushed the patch, but I just spotted you forgot to solve the upgrades - so NACK. "cn=IPA OTP Counter,cn=plugins,cn=config" plugin configuration also needs to be added in some update file. Martin From ssorce at redhat.com Thu Oct 16 19:32:49 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 16 Oct 2014 15:32:49 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <544010C9.3080607@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> <544003AA.7020805@redhat.com> <54400812.1010101@redhat.com> <544010C9.3080607@redhat.com> Message-ID: <20141016153249.5f42824d@willson.usersys.redhat.com> On Thu, 16 Oct 2014 20:39:05 +0200 Martin Kosek wrote: > On 10/16/2014 08:01 PM, Petr Spacek wrote: > .... > >> 1) > >> > >> I'm not sure if failing on DNSSEC-disabled forwarders by default > >> is a good idea. Perhaps there could be some auto-detection code? > >> Something along the lines of: > >> > >> if forwarders_support_dnssec: > >> if not options.no_dnssec_validation: > >> enable_dnssec_in_ipa() > >> else: > >> print "WARNING: DNSSEC will not be enabled" > > > > We have discussed this with Martin > > ... Martin Basti/Martin2... Given there are more Martins in the team, > you should be more specific :-) > > > and the intent is to tell people that their > > infrastructure is broken and has to be fixed - sooner is better. > > > > There is an option --no-dnssec-validation for people who like broken > > infrastructure. > > Broken infrastructure is rather strong word for the situation when > just DNSSEC is not configured (it may work for the customer > otherwise). "Infrastructure does not follow most up to date > standards" may be more precise. > > From my POV, this may be too strict. People may already use > ipa-server-install in their scripts and it suddenly requiring new > option may be seen as breakage. > > So maybe it would be better to just print big fat warning including > [yes|no] question to continue during ipa-server-install and just > print warning in unattended mode (and disable DNSEC validation) > > We can always be more strict in next release. CCing Simo and Rob in > case they have different opinions. My opinion is that DNSSEC is too new to make it required by default in any way. For the first release it should be completely optional and opt in. Once we sort out the initial hurdles we can slowly add warnings and what not and at some point in the future switch the defaults and start complaining. We have to assume that most forwarders will be broken, so perhaps the correct course of action if someone decides to try DNSSEC and the forwarders do not support it is to give a fat warning and disable DNSSEC for non-managed zones. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Thu Oct 16 19:55:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 16 Oct 2014 21:55:39 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <20141016153249.5f42824d@willson.usersys.redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> <544003AA.7020805@redhat.com> <54400812.1010101@redhat.com> <544010C9.3080607@redhat.com> <20141016153249.5f42824d@willson.usersys.redhat.com> Message-ID: <544022BB.3040305@redhat.com> On 16.10.2014 21:32, Simo Sorce wrote: > On Thu, 16 Oct 2014 20:39:05 +0200 > Martin Kosek wrote: > >> On 10/16/2014 08:01 PM, Petr Spacek wrote: >> .... >>>> 1) >>>> >>>> I'm not sure if failing on DNSSEC-disabled forwarders by default >>>> is a good idea. Perhaps there could be some auto-detection code? >>>> Something along the lines of: >>>> >>>> if forwarders_support_dnssec: >>>> if not options.no_dnssec_validation: >>>> enable_dnssec_in_ipa() >>>> else: >>>> print "WARNING: DNSSEC will not be enabled" >>> >>> We have discussed this with Martin >> >> ... Martin Basti/Martin2... Given there are more Martins in the team, >> you should be more specific :-) >> >>> and the intent is to tell people that their >>> infrastructure is broken and has to be fixed - sooner is better. >>> >>> There is an option --no-dnssec-validation for people who like broken >>> infrastructure. >> >> Broken infrastructure is rather strong word for the situation when >> just DNSSEC is not configured (it may work for the customer >> otherwise). "Infrastructure does not follow most up to date >> standards" may be more precise. >> >> From my POV, this may be too strict. People may already use >> ipa-server-install in their scripts and it suddenly requiring new >> option may be seen as breakage. >> >> So maybe it would be better to just print big fat warning including >> [yes|no] question to continue during ipa-server-install and just >> print warning in unattended mode (and disable DNSEC validation) >> >> We can always be more strict in next release. CCing Simo and Rob in >> case they have different opinions. > > My opinion is that DNSSEC is too new to make it required by default in > any way. Sure, the standard is only 9.5 years old (RFC 4033). With this course we will be stuck with insecure DNS forever, like with with SSL 3.0 :-) > For the first release it should be completely optional and opt in. Once > we sort out the initial hurdles we can slowly add warnings and what not > and at some point in the future switch the defaults and start > complaining. I'm afraid that nobody will notice it if it is completely disabled ... > We have to assume that most forwarders will be broken, so perhaps the That is the reason why there is detection & warning. Please note that 'fixing' the issue is typically just about adding line "dnssec-enabled yes;" to named.conf on the "broken" forwarder (which is default even in RHEL 6 BTW). Biggest problem is to convince admin to add the line to the config file, it is not a technical problem. > correct course of action if someone decides to try DNSSEC and the > forwarders do not support it is to give a fat warning and disable > DNSSEC for non-managed zones. It is not possible to do DNSSEC validation only for part of the tree *unless you manually install trust anchors to validators*. Keep in mind that validator has to be able to build chain of trust from name-under-validation to nearest trust anchor, i.e. typically to DNS root. -- Petr^2 Spacek From edewata at redhat.com Thu Oct 16 21:12:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 16 Oct 2014 16:12:18 -0500 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. In-Reply-To: <543F429C.2040006@redhat.com> References: <543F429C.2040006@redhat.com> Message-ID: <544034B2.5010609@redhat.com> On 10/15/2014 10:59 PM, Endi Sukma Dewata wrote: > The NSSConnection class has to be modified not to shutdown existing > database because some of the vault clients (e.g. vault-archive and > vault-retrieve) also use a database to encrypt/decrypt the secret. The problem is described in more detail in this ticket: https://fedorahosted.org/freeipa/ticket/4638 The changes to the NSSConnection in the first patch caused the installation to fail. Attached is a new patch that uses the solution proposed by jdennis. -- Endi S. Dewata -------------- next part -------------- >From 65929b64da8d273a8b991845e47e69c1b3182f79 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 16 Sep 2014 20:11:35 -0400 Subject: [PATCH] Added initial vault implementation. This patch provides the initial vault implementation which allows the admin to create a vault, archive a secret, and retrieve the secret using a standard vault. It currently has limitations including: - The vault only supports the standard vault type. - The vault can only be used by the admin user. - The transport certificate has to be installed manually. These limitations, other vault features, schema and ACL changes will be addressed in subsequent patches. The NSSConnection class has been modified not to shutdown existing database because some of the vault clients (e.g. vault-archive and vault-retrieve) also use a database to encrypt/decrypt the secret. Ticket #4638, #3872 --- API.txt | 160 ++++++++ VERSION | 4 +- install/share/60basev4.ldif | 3 + install/share/Makefile.am | 1 + install/share/copy-schema-to-ca.py | 1 + install/updates/40-vault.update | 27 ++ install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/user.py | 9 + ipalib/plugins/vault.py | 726 +++++++++++++++++++++++++++++++++++++ ipalib/rpc.py | 34 +- ipapython/nsslib.py | 31 +- ipaserver/install/dsinstance.py | 1 + 14 files changed, 973 insertions(+), 27 deletions(-) create mode 100644 install/share/60basev4.ldif create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py diff --git a/API.txt b/API.txt index 1af78509732b13eec07208114cea00e56c1059b4..1eec3527e36bc250acddbf0e2fe7a6baa30abd74 100644 --- a/API.txt +++ b/API.txt @@ -4373,6 +4373,166 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('in?', cli_name='in') +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret', attribute=True, cli_name='secret', multivalue=False, required=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_archive +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('encrypted_data?', cli_name='encrypted_data') +option: Str('in?', cli_name='in') +option: Bytes('nonce?', cli_name='nonce') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret?', cli_name='secret') +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,10,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Bytes('secret', attribute=True, autofill=False, cli_name='secret', multivalue=False, query=True, required=False) +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret', attribute=True, autofill=False, cli_name='secret', multivalue=False, required=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_retrieve +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('out?', cli_name='out') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_add +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vaultcontainer_find +args: 1,9,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vaultcontainer_mod +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/VERSION b/VERSION index 24a6a5ebc70e7ddf6626666e5f9252c44a29d368..4dff96f7242e4a0ff8f914f3e15c5833d4753113 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=105 -# Last change: abbra - ID views attributes +IPA_API_VERSION_MINOR=106 +# Last change: edewata - initial vault implementation diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif new file mode 100644 index 0000000000000000000000000000000000000000..5a077b5a393067169015c71458632a1b3ee77189 --- /dev/null +++ b/install/share/60basev4.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.12.35 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 7d8ceb60e6374e133cfb6e3684bc307dbf313ce7..95bd6a1d246679822fc57156c58efd1182ee5a13 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -14,6 +14,7 @@ app_DATA = \ 60ipaconfig.ldif \ 60basev2.ldif \ 60basev3.ldif \ + 60basev4.ldif \ 60ipadns.ldif \ 61kerberos-ipav3.ldif \ 65ipacertstore.ldif \ diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py index fc53fe4cb52486cc618bec77aabe8283ad5eadbc..fb938d212f0f4ddd9a8250a362b89c29d3078efd 100755 --- a/install/share/copy-schema-to-ca.py +++ b/install/share/copy-schema-to-ca.py @@ -29,6 +29,7 @@ SCHEMA_FILENAMES = ( "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..59e5b629ce4e6c5acac06df78f02106afa6c859e --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,27 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: vaults +default: description: Root vault container + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: services +default: description: Services vault container + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: shared +default: description: Shared vault container + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: users +default: description: Users vault container diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 2b3157d2e656e214a0706d3ab1c780c651b0df91..5c7214343443504f9527039460ef90b80a52603d 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -31,6 +31,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index 325414b64fdacd4d8df261588cfc9b7481923be1..f64e02b5cf2a949a3c0ea7c1702132a3a09c1c19 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -97,6 +97,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index f95b4fd4a9bc3f478f6fd523bf242002a5b6649f..97cd5916f5c63509587879bbebfce7c8644a0c25 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -22,6 +22,7 @@ from time import gmtime, strftime import string import posixpath import os +import traceback from ipalib import api, errors from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime @@ -878,6 +879,14 @@ class user_del(LDAPDelete): else: self.api.Command.otptoken_del(token) + # Delete user's private vault container. + try: + vaultcontainer_id = self.api.Object.vaultcontainer.get_private_id(owner) + (vaultcontainer_parent_id, vaultcontainer_name) = self.api.Object.vaultcontainer.split_id(vaultcontainer_id) + self.api.Command.vaultcontainer_del(vaultcontainer_name, parent=vaultcontainer_parent_id) + except errors.NotFound: + pass + return dn diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..eb5847cef8de3d5c21723e307afcceda4aaf0f82 --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,726 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# 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 PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +import json +import os +import random +import shutil +import string +import tempfile + +import pki +import pki.account +import pki.crypto +import pki.key + +from ipalib import api, errors +from ipalib import Str, Bytes +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import * +from ipalib.plugins import baseldap +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipaplatform.paths import paths +import ipapython.nsslib + +__doc__ = _(""" +Vaults + +Manage vaults and vault containers. + +EXAMPLES: + + List private vaults: + ipa vault-find + + List shared vaults: + ipa vault-find --parent /shared + + Add a vault: + ipa vault-add MyVault + + Show a vault: + ipa vault-show MyVault + + Archive a secret: + ipa vault-archive MyVault --in secret.in + + Retrieve a secret: + ipa vault-retrieve MyVault --out secret.out + + Delete a vault: + ipa vault-del MyVault + + List private vault containers: + ipa vaultcontainer-find + + List top-level vault containers: + ipa vaultcontainer-find --parent / + + Add a vault container: + ipa vaultcontainer-add MyContainer + + Show a vault container: + ipa vaultcontainer-show MyContainer + + Delete a vault container: + ipa vaultcontainer-del MyContainer +""") + +register = Registry() +transport_cert_nickname = "KRA Transport Certificate" + + at register() +class vaultcontainer(LDAPObject): + """ + Vault container object. + """ + container_dn = api.env.container_vault + object_name = _('vault container') + object_name_plural = _('vault containers') + + object_class = ['ipaVaultContainer'] + default_attributes = [ + 'cn', 'description', + ] + search_display_attributes = [ + 'cn', 'description', + ] + + label = _('Vault Containers') + label_singular = _('Vault Container') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='container_name', + label=_('Container name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Container description'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + ) + + def get_private_id(self, username=None): + """ + Returns user's private container ID (i.e. /users//). + """ + + if not username: + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + + return u'/users/' + username + u'/' + + def normalize_id(self, id): + """ + Normalizes container ID. + """ + + # if ID is empty, return user's private container ID + if not id: + return self.get_private_id() + + # make sure ID ends with slash + if not id.endswith(u'/'): + id += u'/' + + # if it's an absolute ID, do nothing + if id.startswith(u'/'): + return id + + # otherwise, prepend with user's private container ID + return self.get_private_id() + id + + def split_id(self, id): + """ + Split a normalized container ID into (parent ID, container name) tuple. + """ + + # handle root ID + if id == u'/': + return (None, None) + + # split ID into parent ID, container name, and empty string + parts = id.rsplit(u'/', 2) + + # return parent ID and container name + return (parts[-3] + u'/', parts[-2]) + + def get_dn(self, *keys, **kwargs): + """ + Generate vault container DN. + """ + + id = keys[0] + dn = DN(self.container_dn, api.env.basedn) + + # if ID is not specified, return base DN + if not id: + return dn + + # for each name in the ID, prepend the base DN + for name in id.split(u'/'): + if name: + dn = DN(('cn', name), dn) + + return dn + + + at register() +class vaultcontainer_add(LDAPCreate): + __doc__ = _('Create a new vault container.') + + msg_summary = _('Added vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + + name = entry_attrs.get('cn') + parent_id = self.obj.normalize_id(options.get('parent')) + + # add parent container if it doesn't exist + try: + (grandparent_id, parent_name) = self.obj.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + id = parent_id + name + dn = self.obj.get_dn(id) + + return dn + + + at register() +class vaultcontainer_del(LDAPDelete): + __doc__ = _('Delete a vault container.') + + msg_summary = _('Deleted vault container "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_find(LDAPSearch): + __doc__ = _('Search for vault containers.') + + msg_summary = ngettext( + '%(count)d vault container matched', '%(count)d vault containers matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + + parent_id = self.obj.normalize_id(options.get('parent')) + base_dn = self.obj.get_dn(parent_id) + return (filter, base_dn, scope) + + + at register() +class vaultcontainer_mod(LDAPUpdate): + __doc__ = _('Modify a vault container.') + + msg_summary = _('Modified vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[1] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_show(LDAPRetrieve): + __doc__ = _('Display information about a vault container.') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vault(LDAPObject): + """ + Vault object. + """ + container_dn = api.env.container_vault + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', 'description', + ] + search_display_attributes = [ + 'cn', 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='vault_name', + label=_('Vault name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + Bytes('secret?', + cli_name='secret', + label=_('Secret'), + doc=_('Secret'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + ) + + def get_dn(self, *keys, **kwargs): + """ + Generate vault DN. + """ + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(kwargs.get('parent')) + parent_dn = api.Object.vaultcontainer.get_dn(parent_id) + dn = DN(('cn', name), parent_dn) + + return dn + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('in?', + cli_name='in', + doc=_('Input file containing the secret'), + ), + ) + + msg_summary = _('Added vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + + name = entry_attrs.get('cn') + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + + # add parent container if it doesn't exist + try: + (grandparent_id, parent_name) = api.Object.vaultcontainer.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + secret = options.get('secret') + file = options.get('in') + + # don't send these parameters to server + if 'secret' in options: + del options['secret'] + if 'in' in options: + del options['in'] + + if secret: + pass + + elif file: + with open(file) as f: + secret = f.read() + + # create the vault + response = super(vault_add, self).forward(*args, **options) + + # archive an empty secret + api.Command.vault_archive(vault_id, secret=secret) + + return response + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + msg_summary = _('Deleted vault "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + vault_id = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(vault_id, parent=parent_id) + + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa-' + vault_id + + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + return dn + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + msg_summary = ngettext( + '%(count)d vault matched', '%(count)d vaults matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + base_dn = api.Object.vaultcontainer.get_dn(parent_id) + return (filter, base_dn, scope) + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + msg_summary = _('Modified vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[1] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_archive(LDAPRetrieve): + __doc__ = _('Archive a secret into a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Bytes('secret?', + cli_name='secret', + doc=_('Secret to archive'), + ), + Str('in?', + cli_name='in', + doc=_('Input file containing the secret'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + Bytes('encrypted_data?', + cli_name='encrypted_data', + doc=_('Data encrypted with session key and encoded in base-64'), + ), + Bytes('nonce?', + cli_name='nonce', + doc=_('Nonce encrypted encoded in base-64'), + ), + ) + + msg_summary = _('Archived secret into vault "%(value)s"') + + def execute(self, *args, **options): + + vault_id = args[0] + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa-' + vault_id + + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + encrypted_data = base64.b64decode(options['encrypted_data']) + nonce = base64.b64decode(options['nonce']) + + kra_client.keys.archive_encrypted_data( + client_key_id, + pki.key.KeyClient.PASS_PHRASE_TYPE, + encrypted_data, + wrapped_session_key, + "{1 2 840 113549 3 7}", + base64.encodestring(nonce), + ) + + kra_account.logout() + + return super(vault_archive, self).execute(*args, **options) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + secret = options.get('secret') + file = options.get('in') + + # don't send these parameters to server + if 'secret' in options: + del options['secret'] + if 'in' in options: + del options['in'] + + if secret: + pass + + elif file: + with open(file) as f: + secret = f.read() + + else: + secret = '' + + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + nonce = crypto.generate_nonce_iv() + session_key = crypto.generate_session_key() + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + encrypted_data = crypto.symmetric_wrap( + secret, + session_key, + nonce_iv=nonce + ) + + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + options['encrypted_data'] = base64.b64encode(encrypted_data) + options['nonce'] = base64.b64encode(nonce) + + return super(vault_archive, self).forward(*args, **options) + + + at register() +class vault_retrieve(LDAPRetrieve): + __doc__ = _('Retrieve a secret from a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Str('out?', + cli_name='out', + doc=_('Output file to store the secret'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + ) + + msg_summary = _('Retrieved secret from vault "%(value)s"') + + def execute(self, *args, **options): + + vault_id = args[0] + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + + response = super(vault_retrieve, self).execute(*args, **options) + + client_key_id = 'ipa-' + vault_id + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + key_client = kra_client.keys + key_info = key_client.get_active_key_info(client_key_id) + + key = key_client.retrieve_key( + key_info.get_key_id(), + wrapped_session_key) + + response['result']['encrypted_data'] = base64.b64encode(key.encrypted_data) + response['result']['nonce'] = base64.b64encode(key.nonce_data) + + kra_account.logout() + + return response + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + session_key = crypto.generate_session_key() + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + + response = super(vault_retrieve, self).forward(*args, **options) + + encrypted_data = base64.b64decode(response['result']['encrypted_data']) + nonce = base64.b64decode(response['result']['nonce']) + + secret = crypto.symmetric_unwrap( + encrypted_data, + session_key, + nonce_iv=nonce) + + if file: + with open(file, 'w') as f: + f.write(secret) + + else: + response['result']['secret'] = unicode(secret) + + return response diff --git a/ipalib/rpc.py b/ipalib/rpc.py index 5934f0c26e4b7c0a44adbab978c1f9b319d72e9f..4e44a0cf9597bdb46619665798d38a30265947f6 100644 --- a/ipalib/rpc.py +++ b/ipalib/rpc.py @@ -63,6 +63,7 @@ from ipaplatform.paths import paths from ipapython.cookie import Cookie from ipapython.dnsutil import DNSName from ipalib.text import _ +import ipapython.nsslib from ipapython.nsslib import NSSHTTPS, NSSConnection from ipalib.krb_utils import KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, KRB5KRB_AP_ERR_TKT_EXPIRED, \ KRB5_FCC_PERM, KRB5_FCC_NOFILE, KRB5_CC_FORMAT, KRB5_REALM_CANT_RESOLVE @@ -450,14 +451,10 @@ class LanguageAwareTransport(MultiProtocolTransport): class SSLTransport(LanguageAwareTransport): """Handles an HTTPS transaction to an XML-RPC server.""" - def __nss_initialized(self, dbdir): + def get_connection_dbdir(self): """ - If there is another connections open it may have already - initialized NSS. This is likely to lead to an NSS shutdown - failure. One way to mitigate this is to tell NSS to not - initialize if it has already been done in another open connection. - - Returns True if another connection is using the same db. + If there is a connections open it may have already initialized + NSS database. Return the database location used by the connection. """ for value in context.__dict__.values(): if not isinstance(value, Connection): @@ -466,25 +463,32 @@ class SSLTransport(LanguageAwareTransport): getattr(value.conn, '_ServerProxy__transport', None), SSLTransport): continue - if hasattr(value.conn._ServerProxy__transport, 'dbdir') and \ - value.conn._ServerProxy__transport.dbdir == dbdir: - return True - return False + if hasattr(value.conn._ServerProxy__transport, 'dbdir'): + return value.conn._ServerProxy__transport.dbdir + return None def make_connection(self, host): host, self._extra_headers, x509 = self.get_host_info(host) # Python 2.7 changed the internal class used in xmlrpclib from # HTTP to HTTPConnection. We need to use the proper subclass - # If we an existing connection exists using the same NSS database - # there is no need to re-initialize. Pass thsi into the NSS - # connection creator. if sys.version_info >= (2, 7): if self._connection and host == self._connection[0]: return self._connection[1] dbdir = getattr(context, 'nss_dir', paths.IPA_NSSDB_DIR) - no_init = self.__nss_initialized(dbdir) + connection_dbdir = self.get_connection_dbdir() + + if connection_dbdir: + # If an existing connection exists using the same NSS database + # there is no need to re-initialize. + # connection creator. + no_init = dbdir == connection_dbdir + else: + # If the NSS database is already used, there is no need to + # re-initialize. + no_init = dbdir == ipapython.nsslib.current_dbdir + if sys.version_info < (2, 7): conn = NSSHTTPS(host, 443, dbdir=dbdir, no_init=no_init) else: diff --git a/ipapython/nsslib.py b/ipapython/nsslib.py index 93b0c56fcff4fc69841a6823aae8f694c1f76ff0..06a192bc1449bfc2208da417667e5c26d1323407 100644 --- a/ipapython/nsslib.py +++ b/ipapython/nsslib.py @@ -23,6 +23,7 @@ import httplib import getpass import socket from ipapython.ipa_log_manager import * +from ipalib.request import context, Connection from nss.error import NSPRError import nss.io as io @@ -31,6 +32,8 @@ import nss.ssl as ssl import nss.error as error from ipaplatform.paths import paths +current_dbdir = None + def auth_certificate_callback(sock, check_sig, is_server, certdb): cert_is_valid = False @@ -184,19 +187,27 @@ class NSSConnection(httplib.HTTPConnection, NSSAddressFamilyFallback): httplib.HTTPConnection.__init__(self, host, port, strict) NSSAddressFamilyFallback.__init__(self, family) + root_logger.debug('%s init %s', self.__class__.__name__, host) + if not dbdir: raise RuntimeError("dbdir is required") - root_logger.debug('%s init %s', self.__class__.__name__, host) - if not no_init and nss.nss_is_initialized(): - # close any open NSS database and use the new one - ssl.clear_session_cache() - try: - nss.nss_shutdown() - except NSPRError, e: - if e.errno != error.SEC_ERROR_NOT_INITIALIZED: - raise e - nss.nss_init(dbdir) + global current_dbdir + + # If initialization is requested, initialize the new database. + if not no_init: + + if nss.nss_is_initialized(): + ssl.clear_session_cache() + try: + nss.nss_shutdown() + except NSPRError, e: + if e.errno != error.SEC_ERROR_NOT_INITIALIZED: + raise e + + nss.nss_init(dbdir) + current_dbdir = dbdir + ssl.set_domestic_policy() nss.set_password_callback(self.password_callback) diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index c9a1c15e9495108382f6e2e8a58f6cc4e8f79c98..f307f96e44ef78c85a5691aa7fdf780ea04dd6b7 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -56,6 +56,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", -- 1.9.0 From npmccallum at redhat.com Thu Oct 16 21:37:21 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 16 Oct 2014 17:37:21 -0400 Subject: [Freeipa-devel] [PATCH 0071] Display token type when viewing token In-Reply-To: <543FE5D2.5080808@redhat.com> References: <1413390721.6617.20.camel@redhat.com> <543FE5D2.5080808@redhat.com> Message-ID: <1413495441.3525.2.camel@redhat.com> On Thu, 2014-10-16 at 17:35 +0200, Martin Kosek wrote: > On 10/15/2014 06:32 PM, Nathaniel McCallum wrote: > > When viewing a token from the CLI or UI, the type of the token > > should be displayed. > > > > https://fedorahosted.org/freeipa/ticket/4563 > > Adding objectclass to default_attributes is unprecedented and something we > should not do before release. It would also put objectclass attribute in > default otptoken-* operations. > > What I would do in this case is to > - keep default_attributes as is > - add 'objectclass' to attrs_list in pre_callback > - do whatever you already do with it in post_callback > - remove the objectclass if it was not called for explicitly, e.g.: > > if not options.get('all', False) or options.get('pkey_only', False): > entry_attrs.pop('objectclass', None) > > This approach is used for example in idrange.py so I would stick with it (I am > not saying it is pretty, I am just saying our API should give consistent output). Fixed and tested. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0071.1-Display-token-type-when-viewing-token.patch Type: text/x-patch Size: 5572 bytes Desc: not available URL: From npmccallum at redhat.com Thu Oct 16 21:53:33 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 16 Oct 2014 17:53:33 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <5440165F.8050902@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> <5436BC59.2090008@redhat.com> <1413313274.6617.12.camel@redhat.com> <543E209F.9020709@redhat.com> <5440165F.8050902@redhat.com> Message-ID: <1413496413.3525.4.camel@redhat.com> On Thu, 2014-10-16 at 21:02 +0200, Martin Kosek wrote: > On 10/15/2014 09:22 AM, Martin Kosek wrote: > > On 10/14/2014 09:01 PM, Nathaniel McCallum wrote: > >> On Thu, 2014-10-09 at 18:48 +0200, thierry bordaz wrote: > >>> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: > >>> > >>>> On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: > >>>>> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: > >>>>> > >>>>>> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: > >>>>>>> On Wed, 08 Oct 2014 15:53:39 -0400 > >>>>>>> Nathaniel McCallum wrote: > >>>>>>> > >>>>>>>> As I understand my code, all servers will have csnD. Some servers will > >>>>>>>> have valueB and others will have valueD, but valueB == valueD. > >>>>>>>> > >>>>>>>> We *never* discard a CSN. We only discard the counter/watermark mods > >>>>>>>> in the replication operation. > >>>>>>> What Thierry is saying is that the individual attributes in the entry > >>>>>>> have associate the last CSN that modified them. Because you remove the > >>>>>>> mods when ValueD == ValueB the counter attribute will not have the > >>>>>>> associated CSN changed. But it doesn't really matter because the plugin > >>>>>>> will always keep things consistent. > >>>>>> Attached is a new version. It removes this optimization. If server X has > >>>>>> valueB/csnB and receives valueD/csnD and valueB == valueD, the > >>>>>> replication will be applied without any modification. However, if valueB > >>>>>>> valueD and csnD > csnB, the counter mods will still be stripped. > >>>>>> It also collapses the error check from betxnpre to bepre now that we > >>>>>> have a fix for https://fedorahosted.org/389/ticket/47919 committed. The > >>>>>> betxnpre functions are completely removed. Also, a dependency on 389 > >>>>>> 1.3.3.4 (not yet released) is added. > >>>>>> > >>>>>> Nathaniel > >>>>> Hello Nathaniel, > >>>>> > >>>>> For me the code is fine. Ack. > >>>> New attached patch. > >>>> > >>>>> I have two minor comments: > >>>>> * in preop_mod, when a direct update moves the counter > >>>>> backward you send UNWILLING to perform with a message. > >>>>> The message is allocated with slapi_ch_smprintf, you > >>>>> may free it with slapi_ch_free_string (rather than > >>>>> 'free'). > >>>> Fixed. > >>>> > >>>>> * About this message, for example when you have these > >>>>> MODS (I admit they make no sens): > >>>>> > >>>>> changetype: modify > >>>>> ipatokenHOTPcounter: MOD_DELETE > >>>>> - > >>>>> ipatokenHOTPcounter: MOD_INCREMENT > >>>>> > >>>>> The returned message will be "Will not decrement > >>>>> ipatokenHOTPcounter", because 'simulate' will return > >>>>> 'COUNTER_UNSET+1'. > >>>>> Is it the message you expected ? > >>>> I changed the logic in simulate(). Please review it. > >>>> > >>>> Nathaniel > >>>> > >>> Hello Nathaniel, > >>> > >>> > >>> The patch is ok for me. Ack. > >> > >> Since the ACK, the upstream 389 fix actually landed in 1.3.3.5. This > >> patch changes nothing except the dependency version. I have tested it > >> against the 1.3.3.5 build. > >> > >> Nathaniel > > > > Great! As soon as the new build land in Fedora 21 (and we add it to our Copr), > > the patch can be pushed. > > > > Martin > > Ok, 1.3.3.5 is in koji and our Copr repo. +1 > I almost pushed the patch, but I just > spotted you forgot to solve the upgrades - so NACK. You asked me to do that in another patch, not this one. :) > "cn=IPA OTP Counter,cn=plugins,cn=config" plugin configuration also needs to be > added in some update file. So I'm generally confused then. If we have to add the plugin config to an update file, why bother creating daemons/ipa-slapi-plugins/ipa-otp-counter/otp-counter-conf.ldif or modifying ipaserver/install/dsinstance.py at all? Should these changes be removed? Nathaniel From jcholast at redhat.com Fri Oct 17 08:08:55 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 17 Oct 2014 10:08:55 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <54400812.1010101@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> <544003AA.7020805@redhat.com> <54400812.1010101@redhat.com> Message-ID: <5440CE97.2020300@redhat.com> Dne 16.10.2014 v 20:01 Petr Spacek napsal(a): > On 16.10.2014 19:43, Jan Cholasta wrote: >> Dne 16.10.2014 v 17:59 Martin Basti napsal(a): >>> On 10/10/14 09:17, Martin Kosek wrote: >>>> On 10/09/2014 03:57 PM, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> it would be great if people could look at current state of DNSSEC >>>>> patches for >>>>> FreeIPA. >>>>> >>>>> It consist of several relatively independent parts: >>>>> - python-pkcs#11 interface written by Martin Basti: >>>>> https://github.com/spacekpe/freeipa-pkcs11 >>>>> >>>>> - DNSSEC daemons written by me: >>>>> https://github.com/spacekpe/ipadnssecd >>>>> >>>>> - FreeIPA integration written by Martin Basti: >>>>> https://github.com/bastiak/freeipa/tree/dnssec >>> Here is updated repo with installers, please review: >>> https://github.com/bastiak/freeipa/tree/dnssec-4 >>> branch dnssec-4 >>> >>> TODO: integrate ipadnssecd daemons and pkcs11 helper, when finished > > ... > >> 3) >> >> Not something you can fix in this commit, but shouldn't >> ipa-ods-exporter be >> named ipa-odsexportd, so that the naming is consistent with the rest >> of our >> daemons? > > Side note: ipa-ods-exporter is not a daemon :-) It is single-shot binary > activated via socket. It is replacement for "ODS signer" and uses the > same protocol. > > Anyway, I don't care much. Feel free pick a new name and let me know. Nevermind, I thought it was a daemon. > >> 2) >> >> Why do you use the default /etc/softhsm2.conf file, instead of using e.g. >> /etc/ipa/dnssec/softhsm2.conf and passing it to SoftHSM in the >> SOFTHSM2_CONF >> environment variable? > > I don't like the idea. The same library is used from named and > ods-enforcerd so we would have to modify environment variables for all > of them and do some monkey patching in /etc/systemd. > > AFAIK current ipactl/framework is sooo clever so it deletes service > files related to all services "managed" by IPA if they are located in > /etc/systemd. As a result we don't have any way how to override values > supplies by other packages now. IMO if we can have a private instance of something we should have it. To configure named properly, you just have to add a line with "SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf" to /etc/sysconfig/named. > >> 4) >> >> I think /etc/ipa/softhsm_pin_so should be moved to >> /etc/ipa/dnssec/softhsm_pin_so. > > Is it a good idea to store both PINs on the same spot? softhsm_pin_so is > not necessary at run-time so it can be readable only by root:root. What do you mean by "the same spot"? > >> Commit "DNSSEC: validate forwarders": >> >> 1) >> >> I'm not sure if failing on DNSSEC-disabled forwarders by default is a >> good >> idea. Perhaps there could be some auto-detection code? Something along >> the >> lines of: >> >> if forwarders_support_dnssec: >> if not options.no_dnssec_validation: >> enable_dnssec_in_ipa() >> else: >> print "WARNING: DNSSEC will not be enabled" > > We have discussed this with Martin and the intent is to tell people that > their infrastructure is broken and has to be fixed - sooner is better. > > There is an option --no-dnssec-validation for people who like broken > infrastructure. > -- Jan Cholasta From jcholast at redhat.com Fri Oct 17 08:15:38 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 17 Oct 2014 10:15:38 +0200 Subject: [Freeipa-devel] [PATCHES] 354-356 Check LDAP instead of local configuration to see if IPA CA is enabled In-Reply-To: <543BCA0E.8040208@redhat.com> References: <543BCA0E.8040208@redhat.com> Message-ID: <5440D02A.7080403@redhat.com> Dne 13.10.2014 v 14:48 Jan Cholasta napsal(a): > Hi, > > the attached patches fix . > > Honza Rebased on top of current ipa-4-1, patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-354.1-Do-not-create-ipa-pki-proxy.conf-if-CA-is-not-config.patch Type: text/x-patch Size: 1344 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-355.1-Do-not-fix-trust-flags-in-the-DS-NSS-DB-in-ipa-upgra.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-356.1-Check-LDAP-instead-of-local-configuration-to-see-if-.patch Type: text/x-patch Size: 26485 bytes Desc: not available URL: From pspacek at redhat.com Fri Oct 17 08:35:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 17 Oct 2014 10:35:07 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <5440CE97.2020300@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> <544003AA.7020805@redhat.com> <54400812.1010101@redhat.com> <5440CE97.2020300@redhat.com> Message-ID: <5440D4BB.5040604@redhat.com> On 17.10.2014 10:08, Jan Cholasta wrote: > Dne 16.10.2014 v 20:01 Petr Spacek napsal(a): >> On 16.10.2014 19:43, Jan Cholasta wrote: >>> Dne 16.10.2014 v 17:59 Martin Basti napsal(a): >>>> On 10/10/14 09:17, Martin Kosek wrote: >>>>> On 10/09/2014 03:57 PM, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> it would be great if people could look at current state of DNSSEC >>>>>> patches for >>>>>> FreeIPA. >>>>>> >>>>>> It consist of several relatively independent parts: >>>>>> - python-pkcs#11 interface written by Martin Basti: >>>>>> https://github.com/spacekpe/freeipa-pkcs11 >>>>>> >>>>>> - DNSSEC daemons written by me: >>>>>> https://github.com/spacekpe/ipadnssecd >>>>>> >>>>>> - FreeIPA integration written by Martin Basti: >>>>>> https://github.com/bastiak/freeipa/tree/dnssec >>>> Here is updated repo with installers, please review: >>>> https://github.com/bastiak/freeipa/tree/dnssec-4 >>>> branch dnssec-4 >>>> >>>> TODO: integrate ipadnssecd daemons and pkcs11 helper, when finished >> >> ... >> >>> 3) >>> >>> Not something you can fix in this commit, but shouldn't >>> ipa-ods-exporter be >>> named ipa-odsexportd, so that the naming is consistent with the rest >>> of our >>> daemons? >> >> Side note: ipa-ods-exporter is not a daemon :-) It is single-shot binary >> activated via socket. It is replacement for "ODS signer" and uses the >> same protocol. >> >> Anyway, I don't care much. Feel free pick a new name and let me know. > > Nevermind, I thought it was a daemon. > >> >>> 2) >>> >>> Why do you use the default /etc/softhsm2.conf file, instead of using e.g. >>> /etc/ipa/dnssec/softhsm2.conf and passing it to SoftHSM in the >>> SOFTHSM2_CONF >>> environment variable? >> >> I don't like the idea. The same library is used from named and >> ods-enforcerd so we would have to modify environment variables for all >> of them and do some monkey patching in /etc/systemd. >> >> AFAIK current ipactl/framework is sooo clever so it deletes service >> files related to all services "managed" by IPA if they are located in >> /etc/systemd. As a result we don't have any way how to override values >> supplies by other packages now. > > IMO if we can have a private instance of something we should have it. To > configure named properly, you just have to add a line with > "SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf" to /etc/sysconfig/named. Ok, I did not realize that we don't actually need systemd unit overrides. We need to do the same with /etc/sysconfig/ods and unit files for ipa-dnskeysynd and ipa-ods-exporter. >>> 4) >>> >>> I think /etc/ipa/softhsm_pin_so should be moved to >>> /etc/ipa/dnssec/softhsm_pin_so. >> >> Is it a good idea to store both PINs on the same spot? softhsm_pin_so is >> not necessary at run-time so it can be readable only by root:root. > > What do you mean by "the same spot"? Nevermind, I can't read. -- Petr^2 Spacek From mkosek at redhat.com Fri Oct 17 08:59:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 10:59:35 +0200 Subject: [Freeipa-devel] [PATCH 0071] Display token type when viewing token In-Reply-To: <1413495441.3525.2.camel@redhat.com> References: <1413390721.6617.20.camel@redhat.com> <543FE5D2.5080808@redhat.com> <1413495441.3525.2.camel@redhat.com> Message-ID: <5440DA77.20306@redhat.com> On 10/16/2014 11:37 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-16 at 17:35 +0200, Martin Kosek wrote: >> On 10/15/2014 06:32 PM, Nathaniel McCallum wrote: >>> When viewing a token from the CLI or UI, the type of the token >>> should be displayed. >>> >>> https://fedorahosted.org/freeipa/ticket/4563 >> >> Adding objectclass to default_attributes is unprecedented and something we >> should not do before release. It would also put objectclass attribute in >> default otptoken-* operations. >> >> What I would do in this case is to >> - keep default_attributes as is >> - add 'objectclass' to attrs_list in pre_callback >> - do whatever you already do with it in post_callback >> - remove the objectclass if it was not called for explicitly, e.g.: >> >> if not options.get('all', False) or options.get('pkey_only', False): >> entry_attrs.pop('objectclass', None) >> >> This approach is used for example in idrange.py so I would stick with it (I am >> not saying it is pretty, I am just saying our API should give consistent output). > > Fixed and tested. > Works fine in CLI, though I found couple more issues: 1) In type you return "HOTP" or "TOTP" while on the input you accept lowercased versions - is that OK? # ipa otptoken-add --type=TOTP --owner=fbar barbar ipa: ERROR: invalid 'type': must be one of 'totp', 'hotp' It just did not seem consistent to me. 2) You are suddenly adding camelcased attribute, compared to other places: + attrs_list.append("objectClass") 3) I do not see the OTP token type in Web UI OTP token view - is it just me or is it really missing? Martin From jcholast at redhat.com Fri Oct 17 09:06:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 17 Oct 2014 11:06:48 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <54400E4B.8010308@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> <543F8ED7.8010806@redhat.com> <543F95AC.1090700@redhat.com> <543FFA48.8090504@redhat.com> <54400E4B.8010308@redhat.com> Message-ID: <5440DC28.40904@redhat.com> Dne 16.10.2014 v 20:28 Martin Kosek napsal(a): > On 10/16/2014 07:03 PM, Petr Vobornik wrote: >> On 16.10.2014 11:53, Jan Cholasta wrote: >>> Dne 16.10.2014 v 11:24 Petr Vobornik napsal(a): >>>> On 16.10.2014 09:54, Jan Cholasta wrote: >>>>> Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): >>>>>> On 8.10.2014 18:51, Petr Vobornik wrote: >>>>>>> On 1.10.2014 18:15, Petr Vobornik wrote: >>>>>>>> Hello list, >>>>>>>> >>>>>>>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>>>>>>> >>>>>>> >>>>>>> New revisions of 761 and 763 with updated API and ACIs: >> >> Given: >> >>> Given the implementation, I see you can't remove it from >> snip >>> OK, you are obviously not responsible for this mess, so let's go with >>> it. >> snip >>> ugly hacks though.)> >> snip >>>>> I'm not particularly happy about the '_subtype' option bussiness, >>>>> but at >>>>> least it's not invasive, so I guess it's OK. >>>>> >>>>> Note that I still think this API sucks and we should instead go >>>>> with the >>>>> generic member-like attribute approach, or take our time to design it >>>>> properly so that it fits in the framework (no time in 4.1) instead of >>>>> making it a hacky Franken-API like it is now. >>>>> >> >> and a discussion with Honza >> >> I've attached alternative versions of this patch - based on 761-1 with >> API as >> follows: >> >> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR >> ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR >> ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR >> >> ipa service-allow-retrieve-keytab PRINCIPAL --users=STR --groups STR >> ipa service-disallow-retrieve-keytab PRINCIPAL --users=STR --groups >> STR >> ipa service-allow-create-keytab PRINCIPAL --users=STR --groups STR >> ipa service-disallow-create-keytab PRINCIPAL --users=STR --groups STR >> >> and updated ACIs >> >> Both approaches have their own drawbacks. > > Given the discussion we had, I think I can live with this version too, > especially if it makes the API or the code less hackier than with the > API version I proposed. > > So if Honza ACKs the code, I am fine with this API version. Patch 761: ACK on the approach. The commands do not show failed members in CLI, to fix this, add: Str('ipaallowedtoperform_read_keys', label=_('Failed allowed to retrieve keytab'), ), Str('ipaallowedtoperform_write_keys', label=_('Failed allowed to create keytab'), ), to the global output param lists in service and host plugins. (Feel free to fix the label to your liking.) Patch 763: ACK. -- Jan Cholasta From sbose at redhat.com Fri Oct 17 09:53:44 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 17 Oct 2014 11:53:44 +0200 Subject: [Freeipa-devel] [PATCH] 131-132 extdom: add support for sss_nss_getorigbyname() Message-ID: <20141017095344.GA9734@localhost.localdomain> Hi, the first patch replaces sss_nss_getsidbyname() by sss_nss_getorigbyname() for the new version of the extdom interface. The new call returns more data about the original object and allows the IPA client to have the same information about the object in the SSSD cache as the IPA servers. The second patch just removes an obsolete dependency. bye, Sumit -------------- next part -------------- From 928c04c35601b7bc1c57c1320e4a746abc35e947 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 10 Oct 2014 10:56:37 +0200 Subject: [PATCH 131/132] extdom: add support for sss_nss_getorigbyname() --- .../ipa-extdom-extop/ipa_extdom_common.c | 167 +++++++++++++++++---- 1 file changed, 135 insertions(+), 32 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index d1d214ae769946a89ffe1702382e5db70035fdac..685edac2b26f425c42ff84105400a219f4cfca2f 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -254,6 +254,34 @@ static int get_user_grouplist(const char *name, gid_t gid, return LDAP_SUCCESS; } +static int add_kv_list(BerElement *ber, struct sss_nss_kv *kv_list) +{ + size_t c; + int ret; + const char *single_value_string_array[] = {NULL, NULL}; + + ret = ber_printf(ber,"{"); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + for (c = 0; kv_list[c].key != NULL; c++) { + single_value_string_array[0] = kv_list[c].value; + ret = ber_printf(ber,"{s{v}}", kv_list[c].key, + single_value_string_array); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + } + + ret = ber_printf(ber,"}"); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + return LDAP_SUCCESS; +} + static int pack_ber_sid(const char *sid, struct berval **berval) { BerElement *ber = NULL; @@ -285,7 +313,7 @@ static int pack_ber_user(enum response_types response_type, const char *domain_name, const char *user_name, uid_t uid, gid_t gid, const char *gecos, const char *homedir, - const char *shell, const char *sid_str, + const char *shell, struct sss_nss_kv *kv_list, struct berval **berval) { BerElement *ber = NULL; @@ -299,7 +327,6 @@ static int pack_ber_user(enum response_types response_type, size_t c; char *locat; char *short_user_name = NULL; - const char *single_value_string_array[] = {NULL, NULL}; short_user_name = strdup(user_name); if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { @@ -370,12 +397,11 @@ static int pack_ber_user(enum response_types response_type, goto done; } - single_value_string_array[0] = sid_str; - ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, - single_value_string_array); - if (ret == -1) { - ret = LDAP_OPERATIONS_ERROR; - goto done; + if (kv_list != NULL) { + ret = add_kv_list(ber, kv_list); + if (ret != LDAP_SUCCESS) { + goto done; + } } } @@ -402,7 +428,7 @@ done: static int pack_ber_group(enum response_types response_type, const char *domain_name, const char *group_name, - gid_t gid, char **members, const char *sid_str, + gid_t gid, char **members, struct sss_nss_kv *kv_list, struct berval **berval) { BerElement *ber = NULL; @@ -410,7 +436,6 @@ static int pack_ber_group(enum response_types response_type, size_t c; char *locat; char *short_group_name = NULL; - const char *single_value_string_array[] = {NULL, NULL}; short_group_name = strdup(group_name); if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { @@ -455,12 +480,11 @@ static int pack_ber_group(enum response_types response_type, goto done; } - single_value_string_array[0] = sid_str; - ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, - single_value_string_array); - if (ret == -1) { - ret = LDAP_OPERATIONS_ERROR; - goto done; + if (kv_list != NULL) { + ret = add_kv_list(ber, kv_list); + if (ret != LDAP_SUCCESS) { + goto done; + } } } @@ -521,13 +545,14 @@ static int handle_uid_request(enum request_types request_type, uid_t uid, enum sss_id_type id_type; size_t buf_len; char *buf = NULL; + struct sss_nss_kv *kv_list = NULL; ret = get_buffer(&buf_len, &buf); if (ret != LDAP_SUCCESS) { return ret; } - if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + if (request_type == REQ_SIMPLE) { ret = sss_nss_getsidbyid(uid, &sid_str, &id_type); if (ret != 0 || !(id_type == SSS_ID_TYPE_UID || id_type == SSS_ID_TYPE_BOTH)) { @@ -538,9 +563,7 @@ static int handle_uid_request(enum request_types request_type, uid_t uid, } goto done; } - } - if (request_type == REQ_SIMPLE) { ret = pack_ber_sid(sid_str, berval); } else { ret = getpwuid_r(uid, &pwd, buf, buf_len, &pwd_result); @@ -553,14 +576,28 @@ static int handle_uid_request(enum request_types request_type, uid_t uid, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(pwd.pw_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER : RESP_USER_GROUPLIST), domain_name, pwd.pw_name, pwd.pw_uid, pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, - pwd.pw_shell, sid_str, berval); + pwd.pw_shell, kv_list, berval); } done: + sss_nss_free_kv(kv_list); free(sid_str); free(buf); return ret; @@ -576,13 +613,14 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, enum sss_id_type id_type; size_t buf_len; char *buf = NULL; + struct sss_nss_kv *kv_list; ret = get_buffer(&buf_len, &buf); if (ret != LDAP_SUCCESS) { return ret; } - if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + if (request_type == REQ_SIMPLE) { ret = sss_nss_getsidbyid(gid, &sid_str, &id_type); if (ret != 0 || id_type != SSS_ID_TYPE_GID) { if (ret == ENOENT) { @@ -592,9 +630,7 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, } goto done; } - } - if (request_type == REQ_SIMPLE) { ret = pack_ber_sid(sid_str, berval); } else { ret = getgrgid_r(gid, &grp, buf, buf_len, &grp_result); @@ -607,13 +643,27 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(grp.gr_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_GID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP : RESP_GROUP_MEMBERS), domain_name, grp.gr_name, grp.gr_gid, - grp.gr_mem, sid_str, berval); + grp.gr_mem, kv_list, berval); } done: + sss_nss_free_kv(kv_list); free(sid_str); free(buf); return ret; @@ -634,6 +684,7 @@ static int handle_sid_request(enum request_types request_type, const char *sid, size_t buf_len; char *buf = NULL; enum sss_id_type id_type; + struct sss_nss_kv *kv_list; ret = sss_nss_getnamebysid(sid, &fq_name, &id_type); if (ret != 0) { @@ -682,11 +733,24 @@ static int handle_sid_request(enum request_types request_type, const char *sid, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(pwd.pw_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER : RESP_USER_GROUPLIST), domain_name, pwd.pw_name, pwd.pw_uid, pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, - pwd.pw_shell, sid, berval); + pwd.pw_shell, kv_list, berval); break; case SSS_ID_TYPE_GID: ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); @@ -700,10 +764,23 @@ static int handle_sid_request(enum request_types request_type, const char *sid, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(grp.gr_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_GID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP : RESP_GROUP_MEMBERS), domain_name, grp.gr_name, grp.gr_gid, - grp.gr_mem, sid, berval); + grp.gr_mem, kv_list, berval); break; default: ret = LDAP_OPERATIONS_ERROR; @@ -711,6 +788,7 @@ static int handle_sid_request(enum request_types request_type, const char *sid, } done: + sss_nss_free_kv(kv_list); free(fq_name); free(object_name); free(domain_name); @@ -733,6 +811,7 @@ static int handle_name_request(enum request_types request_type, enum sss_id_type id_type; size_t buf_len; char *buf = NULL; + struct sss_nss_kv *kv_list; ret = asprintf(&fq_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR, domain_name); @@ -743,7 +822,7 @@ static int handle_name_request(enum request_types request_type, goto done; } - if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + if (request_type == REQ_SIMPLE) { ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); if (ret != 0) { if (ret == ENOENT) { @@ -751,11 +830,9 @@ static int handle_name_request(enum request_types request_type, } else { ret = LDAP_OPERATIONS_ERROR; } - goto done; + goto done; } - } - if (request_type == REQ_SIMPLE) { ret = pack_ber_sid(sid_str, berval); } else { ret = get_buffer(&buf_len, &buf); @@ -772,11 +849,23 @@ static int handle_name_request(enum request_types request_type, } if (pwd_result != NULL) { + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(pwd.pw_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER : RESP_USER_GROUPLIST), domain_name, pwd.pw_name, pwd.pw_uid, pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, - pwd.pw_shell, sid_str, berval); + pwd.pw_shell, kv_list, berval); } else { /* no user entry found */ ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); if (ret != 0) { @@ -789,14 +878,28 @@ static int handle_name_request(enum request_types request_type, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(grp.gr_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_GID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP : RESP_GROUP_MEMBERS), domain_name, grp.gr_name, grp.gr_gid, - grp.gr_mem, sid_str, berval); + grp.gr_mem, kv_list, berval); } } done: + sss_nss_free_kv(kv_list); free(fq_name); free(sid_str); free(buf); -- 1.8.5.3 -------------- next part -------------- From f83616c145d5d14d125c663f9ac4e31cff4af81b Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 15 Oct 2014 16:21:53 +0200 Subject: [PATCH 132/132] extdom: remove unused dependency to libsss_idmap --- daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am | 3 --- daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h | 2 -- 2 files changed, 5 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am index 7099a988878e2bc0cf840eab0b14fa9f40805a51..0008476796f5b20f62f2c32e7b291b787fa7a6fc 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am @@ -15,7 +15,6 @@ AM_CPPFLAGS = \ -DDATADIR=\""$(datadir)"\" \ $(LDAP_CFLAGS) \ $(WARN_CFLAGS) \ - $(SSSIDMAP_CFLAGS) \ $(SSSNSSIDMAP_CFLAGS) \ $(NULL) @@ -33,7 +32,6 @@ libipa_extdom_extop_la_LDFLAGS = -avoid-version libipa_extdom_extop_la_LIBADD = \ $(LDAP_LIBS) \ - $(SSSIDMAP_LIBS) \ $(SSSNSSIDMAP_LIBS) \ $(NULL) @@ -54,7 +52,6 @@ extdom_tests_LDADD = \ $(CHECK_LIBS) \ $(LDAP_LIBS) \ $(DIRSRV_LIBS) \ - $(SSSIDMAP_LIBS) \ $(SSSNSSIDMAP_LIBS) \ $(NULL) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h index 90f8390d871a698dc00ef56c41be0749eaa13424..56ca5009b1aa427f6c059b78ac392c768e461e2e 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -60,7 +60,6 @@ #include #include -#include #include #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" @@ -157,7 +156,6 @@ struct domain_info { char *flat_name; char *sid; char *guid; - struct sss_idmap_ctx *idmap_ctx; }; struct pwd_grp { -- 1.8.5.3 From mkosek at redhat.com Fri Oct 17 10:03:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 12:03:19 +0200 Subject: [Freeipa-devel] [PATCH] 485 Remove changetype attribute from update plugin Message-ID: <5440E967.4010906@redhat.com> The attribute addition had no effect, but it should not be there. Pushed as a one liner to: master: 588e7bc899c23af2633a3820a34b7c4545c0b27a ipa-4-1: 2e388552959d80e8fa89545695a16d3a48050a5e ipa-4-0: 889bf4ac7a0e06adebaaacb211d9b84e11129ac3 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-485-remove-changetype-attribute-from-update-plugin.patch Type: text/x-patch Size: 839 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 17 10:05:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 12:05:43 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1413496413.3525.4.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> <5436BC59.2090008@redhat.com> <1413313274.6617.12.camel@redhat.com> <543E209F.9020709@redhat.com> <5440165F.8050902@redhat.com> <1413496413.3525.4.camel@redhat.com> Message-ID: <5440E9F7.9090901@redhat.com> On 10/16/2014 11:53 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-16 at 21:02 +0200, Martin Kosek wrote: >> On 10/15/2014 09:22 AM, Martin Kosek wrote: >>> On 10/14/2014 09:01 PM, Nathaniel McCallum wrote: >>>> On Thu, 2014-10-09 at 18:48 +0200, thierry bordaz wrote: >>>>> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: >>>>> >>>>>> On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: >>>>>>> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: >>>>>>> >>>>>>>> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: >>>>>>>>> On Wed, 08 Oct 2014 15:53:39 -0400 >>>>>>>>> Nathaniel McCallum wrote: >>>>>>>>> >>>>>>>>>> As I understand my code, all servers will have csnD. Some servers will >>>>>>>>>> have valueB and others will have valueD, but valueB == valueD. >>>>>>>>>> >>>>>>>>>> We *never* discard a CSN. We only discard the counter/watermark mods >>>>>>>>>> in the replication operation. >>>>>>>>> What Thierry is saying is that the individual attributes in the entry >>>>>>>>> have associate the last CSN that modified them. Because you remove the >>>>>>>>> mods when ValueD == ValueB the counter attribute will not have the >>>>>>>>> associated CSN changed. But it doesn't really matter because the plugin >>>>>>>>> will always keep things consistent. >>>>>>>> Attached is a new version. It removes this optimization. If server X has >>>>>>>> valueB/csnB and receives valueD/csnD and valueB == valueD, the >>>>>>>> replication will be applied without any modification. However, if valueB >>>>>>>>> valueD and csnD > csnB, the counter mods will still be stripped. >>>>>>>> It also collapses the error check from betxnpre to bepre now that we >>>>>>>> have a fix for https://fedorahosted.org/389/ticket/47919 committed. The >>>>>>>> betxnpre functions are completely removed. Also, a dependency on 389 >>>>>>>> 1.3.3.4 (not yet released) is added. >>>>>>>> >>>>>>>> Nathaniel >>>>>>> Hello Nathaniel, >>>>>>> >>>>>>> For me the code is fine. Ack. >>>>>> New attached patch. >>>>>> >>>>>>> I have two minor comments: >>>>>>> * in preop_mod, when a direct update moves the counter >>>>>>> backward you send UNWILLING to perform with a message. >>>>>>> The message is allocated with slapi_ch_smprintf, you >>>>>>> may free it with slapi_ch_free_string (rather than >>>>>>> 'free'). >>>>>> Fixed. >>>>>> >>>>>>> * About this message, for example when you have these >>>>>>> MODS (I admit they make no sens): >>>>>>> >>>>>>> changetype: modify >>>>>>> ipatokenHOTPcounter: MOD_DELETE >>>>>>> - >>>>>>> ipatokenHOTPcounter: MOD_INCREMENT >>>>>>> >>>>>>> The returned message will be "Will not decrement >>>>>>> ipatokenHOTPcounter", because 'simulate' will return >>>>>>> 'COUNTER_UNSET+1'. >>>>>>> Is it the message you expected ? >>>>>> I changed the logic in simulate(). Please review it. >>>>>> >>>>>> Nathaniel >>>>>> >>>>> Hello Nathaniel, >>>>> >>>>> >>>>> The patch is ok for me. Ack. >>>> >>>> Since the ACK, the upstream 389 fix actually landed in 1.3.3.5. This >>>> patch changes nothing except the dependency version. I have tested it >>>> against the 1.3.3.5 build. >>>> >>>> Nathaniel >>> >>> Great! As soon as the new build land in Fedora 21 (and we add it to our Copr), >>> the patch can be pushed. >>> >>> Martin >> >> Ok, 1.3.3.5 is in koji and our Copr repo. > > +1 > >> I almost pushed the patch, but I just >> spotted you forgot to solve the upgrades - so NACK. > > You asked me to do that in another patch, not this one. :) I know, but that does not change the fact it is still missing :-) > >> "cn=IPA OTP Counter,cn=plugins,cn=config" plugin configuration also needs to be >> added in some update file. > > So I'm generally confused then. If we have to add the plugin config to > an update file, why bother creating > daemons/ipa-slapi-plugins/ipa-otp-counter/otp-counter-conf.ldif or > modifying ipaserver/install/dsinstance.py at all? Should these changes > be removed? Good question. Most LDAP update related changes are added to update plugins only. But plugin registration seemed to be still on 2 places, like 'cn=IPA Range-Check,cn=plugins,cn=config' registration. Up to you/additional developer discussion. Martin From dkupka at redhat.com Fri Oct 17 10:42:32 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 17 Oct 2014 12:42:32 +0200 Subject: [Freeipa-devel] [PATCHES] 354-356 Check LDAP instead of local configuration to see if IPA CA is enabled In-Reply-To: <5440D02A.7080403@redhat.com> References: <543BCA0E.8040208@redhat.com> <5440D02A.7080403@redhat.com> Message-ID: <5440F298.3000604@redhat.com> On 10/17/2014 10:15 AM, Jan Cholasta wrote: > Dne 13.10.2014 v 14:48 Jan Cholasta napsal(a): >> Hi, >> >> the attached patches fix . >> >> Honza > > Rebased on top of current ipa-4-1, patches attached. Works for me, ACK. It would be nice to also start tracking certificates when IPA is CA-ful. But it can be done later, ticket: https://fedorahosted.org/freeipa/ticket/4644 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- David Kupka From mkosek at redhat.com Fri Oct 17 10:56:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 12:56:09 +0200 Subject: [Freeipa-devel] [PATCHES] 354-356 Check LDAP instead of local configuration to see if IPA CA is enabled In-Reply-To: <5440F298.3000604@redhat.com> References: <543BCA0E.8040208@redhat.com> <5440D02A.7080403@redhat.com> <5440F298.3000604@redhat.com> Message-ID: <5440F5C9.2060905@redhat.com> On 10/17/2014 12:42 PM, David Kupka wrote: > On 10/17/2014 10:15 AM, Jan Cholasta wrote: >> Dne 13.10.2014 v 14:48 Jan Cholasta napsal(a): >>> Hi, >>> >>> the attached patches fix . >>> >>> Honza >> >> Rebased on top of current ipa-4-1, patches attached. > > Works for me, ACK. > It would be nice to also start tracking certificates when IPA is CA-ful. But it > can be done later, ticket: https://fedorahosted.org/freeipa/ticket/4644 Pushed to: master: 608851d3f86a9082b394c30fe0c7a7b33d43f363 ipa-4-1: 5303e6324efb24c7529caaea68c3d985087e2053 Martin From pvoborni at redhat.com Fri Oct 17 11:29:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Oct 2014 13:29:56 +0200 Subject: [Freeipa-devel] [PATCH] 778 dns: fix privileges' memberof during dns install Message-ID: <5440FDB4.3060907@redhat.com> Permissions with member attrs pointing to privileges are created before the privileges. Run memberof plugin task to fix other ends of the relationships. https://fedorahosted.org/freeipa/ticket/4637 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0778-dns-fix-privileges-memberof-during-dns-install.patch Type: text/x-patch Size: 2155 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 17 11:48:16 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Oct 2014 13:48:16 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <5440DC28.40904@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> <543F8ED7.8010806@redhat.com> <543F95AC.1090700@redhat.com> <543FFA48.8090504@redhat.com> <54400E4B.8010308@redhat.com> <5440DC28.40904@redhat.com> Message-ID: <54410200.6080609@redhat.com> On 17.10.2014 11:06, Jan Cholasta wrote: > Dne 16.10.2014 v 20:28 Martin Kosek napsal(a): >> On 10/16/2014 07:03 PM, Petr Vobornik wrote: >>> On 16.10.2014 11:53, Jan Cholasta wrote: >>>> Dne 16.10.2014 v 11:24 Petr Vobornik napsal(a): >>>>> On 16.10.2014 09:54, Jan Cholasta wrote: >>>>>> Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): >>>>>>> On 8.10.2014 18:51, Petr Vobornik wrote: >>>>>>>> On 1.10.2014 18:15, Petr Vobornik wrote: >>>>>>>>> Hello list, >>>>>>>>> >>>>>>>>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>>>>>>>> >>>>>>>> >>>>>>>> New revisions of 761 and 763 with updated API and ACIs: >>> >>> Given: >>> >>>> Given the implementation, I see you can't remove it from >>> snip >>>> OK, you are obviously not responsible for this mess, so let's go with >>>> it. >>> snip >>>> ugly hacks though.)> >>> snip >>>>>> I'm not particularly happy about the '_subtype' option bussiness, >>>>>> but at >>>>>> least it's not invasive, so I guess it's OK. >>>>>> >>>>>> Note that I still think this API sucks and we should instead go >>>>>> with the >>>>>> generic member-like attribute approach, or take our time to design it >>>>>> properly so that it fits in the framework (no time in 4.1) instead of >>>>>> making it a hacky Franken-API like it is now. >>>>>> >>> >>> and a discussion with Honza >>> >>> I've attached alternative versions of this patch - based on 761-1 with >>> API as >>> follows: >>> >>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR >>> ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR >>> ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR >>> >>> ipa service-allow-retrieve-keytab PRINCIPAL --users=STR --groups STR >>> ipa service-disallow-retrieve-keytab PRINCIPAL --users=STR --groups >>> STR >>> ipa service-allow-create-keytab PRINCIPAL --users=STR --groups STR >>> ipa service-disallow-create-keytab PRINCIPAL --users=STR --groups STR >>> >>> and updated ACIs >>> >>> Both approaches have their own drawbacks. >> >> Given the discussion we had, I think I can live with this version too, >> especially if it makes the API or the code less hackier than with the >> API version I proposed. >> >> So if Honza ACKs the code, I am fine with this API version. > > Patch 761: > > ACK on the approach. > > The commands do not show failed members in CLI, to fix this, add: > > Str('ipaallowedtoperform_read_keys', > label=_('Failed allowed to retrieve keytab'), > ), > Str('ipaallowedtoperform_write_keys', > label=_('Failed allowed to create keytab'), > ), > > to the global output param lists in service and host plugins. (Feel free > to fix the label to your liking.) Added > > > Patch 763: > > ACK. > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0761-7-keytab-manipulation-permission-management.patch Type: text/x-patch Size: 33279 bytes Desc: not available URL: From jcholast at redhat.com Fri Oct 17 11:52:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 17 Oct 2014 13:52:30 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <54410200.6080609@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> <543F8ED7.8010806@redhat.com> <543F95AC.1090700@redhat.com> <543FFA48.8090504@redhat.com> <54400E4B.8010308@redhat.com> <5440DC28.40904@redhat.com> <54410200.6080609@redhat.com> Message-ID: <544102FE.2060004@redhat.com> Dne 17.10.2014 v 13:48 Petr Vobornik napsal(a): > On 17.10.2014 11:06, Jan Cholasta wrote: >> Dne 16.10.2014 v 20:28 Martin Kosek napsal(a): >>> On 10/16/2014 07:03 PM, Petr Vobornik wrote: >>>> On 16.10.2014 11:53, Jan Cholasta wrote: >>>>> Dne 16.10.2014 v 11:24 Petr Vobornik napsal(a): >>>>>> On 16.10.2014 09:54, Jan Cholasta wrote: >>>>>>> Dne 13.10.2014 v 12:42 Petr Vobornik napsal(a): >>>>>>>> On 8.10.2014 18:51, Petr Vobornik wrote: >>>>>>>>> On 1.10.2014 18:15, Petr Vobornik wrote: >>>>>>>>>> Hello list, >>>>>>>>>> >>>>>>>>>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>>>>>>>>> >>>>>>>>> >>>>>>>>> New revisions of 761 and 763 with updated API and ACIs: >>>> >>>> Given: >>>> >>>>> Given the implementation, I see you can't remove it from >>>> snip >>>>> OK, you are obviously not responsible for this mess, so let's go with >>>>> it. >>>> snip >>>>> ugly hacks though.)> >>>> snip >>>>>>> I'm not particularly happy about the '_subtype' option bussiness, >>>>>>> but at >>>>>>> least it's not invasive, so I guess it's OK. >>>>>>> >>>>>>> Note that I still think this API sucks and we should instead go >>>>>>> with the >>>>>>> generic member-like attribute approach, or take our time to >>>>>>> design it >>>>>>> properly so that it fits in the framework (no time in 4.1) >>>>>>> instead of >>>>>>> making it a hacky Franken-API like it is now. >>>>>>> >>>> >>>> and a discussion with Honza >>>> >>>> I've attached alternative versions of this patch - based on 761-1 with >>>> API as >>>> follows: >>>> >>>> ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR >>>> ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR >>>> ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR >>>> ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR >>>> >>>> ipa service-allow-retrieve-keytab PRINCIPAL --users=STR --groups STR >>>> ipa service-disallow-retrieve-keytab PRINCIPAL --users=STR --groups >>>> STR >>>> ipa service-allow-create-keytab PRINCIPAL --users=STR --groups STR >>>> ipa service-disallow-create-keytab PRINCIPAL --users=STR --groups >>>> STR >>>> >>>> and updated ACIs >>>> >>>> Both approaches have their own drawbacks. >>> >>> Given the discussion we had, I think I can live with this version too, >>> especially if it makes the API or the code less hackier than with the >>> API version I proposed. >>> >>> So if Honza ACKs the code, I am fine with this API version. >> >> Patch 761: >> >> ACK on the approach. >> >> The commands do not show failed members in CLI, to fix this, add: >> >> Str('ipaallowedtoperform_read_keys', >> label=_('Failed allowed to retrieve keytab'), >> ), >> Str('ipaallowedtoperform_write_keys', >> label=_('Failed allowed to create keytab'), >> ), >> >> to the global output param lists in service and host plugins. (Feel free >> to fix the label to your liking.) > > Added Thanks, ACK. -- Jan Cholasta From mkosek at redhat.com Fri Oct 17 12:11:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 14:11:38 +0200 Subject: [Freeipa-devel] [PATCH] 778 dns: fix privileges' memberof during dns install In-Reply-To: <5440FDB4.3060907@redhat.com> References: <5440FDB4.3060907@redhat.com> Message-ID: <5441077A.2030108@redhat.com> On 10/17/2014 01:29 PM, Petr Vobornik wrote: > Permissions with member attrs pointing to privileges are created before the > privileges. > > Run memberof plugin task to fix other ends of the relationships. > > https://fedorahosted.org/freeipa/ticket/4637 This works fine, thanks. ACK. Pushed to: master: 6f81217c18a416dcbd23360ad3d7f3fea0174fc0 ipa-4-1: 895f350ebf5f002a8ba5aff3d521640b12aa3cde ipa-4-0: 5c9aec36050e790a503ecd6e2c50aead0efa511b Martin From pvoborni at redhat.com Fri Oct 17 12:12:54 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Oct 2014 14:12:54 +0200 Subject: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management In-Reply-To: <544102FE.2060004@redhat.com> References: <542C289A.6040301@redhat.com> <54356B81.4020505@redhat.com> <543BACA2.4070506@redhat.com> <543F79D1.6050705@redhat.com> <543F8ED7.8010806@redhat.com> <543F95AC.1090700@redhat.com> <543FFA48.8090504@redhat.com> <54400E4B.8010308@redhat.com> <5440DC28.40904@redhat.com> <54410200.6080609@redhat.com> <544102FE.2060004@redhat.com> Message-ID: <544107C6.6030308@redhat.com> On 17.10.2014 13:52, Jan Cholasta wrote: > > Thanks, ACK. > rebased due to version change and pushed to: master: * 59ee6314afc7f0f7735ab1349caa970f0f00d78a keytab manipulation permission management * b69a8dad2ebd98516d36b1470fa27c0819b8a985 tests: management of keytab permissions ipa-4-1: * 9cfcb03c704309b972e4737e0a7a7a245dfa7923 keytab manipulation permission management * 7313ed4f9eb55aa58daf42b2605fd5c238b83ac4 tests: management of keytab permissions -- Petr Vobornik From mkosek at redhat.com Fri Oct 17 12:29:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 14:29:08 +0200 Subject: [Freeipa-devel] [PATCH] 766 idviews: error out if appling Default Trust View on hosts In-Reply-To: <5437C690.50308@redhat.com> References: <5437C690.50308@redhat.com> Message-ID: <54410B94.8020104@redhat.com> On 10/10/2014 01:44 PM, Petr Vobornik wrote: > CLI part of: > > https://fedorahosted.org/freeipa/ticket/4615 Works fine, ACK. Pushed to: master: 49fde3b047e63a549774a3354138102608855d77 ipa-4-1: 47811d1ccfd96bc4bc39bb649b91eb54286aefd6 Martin From ssorce at redhat.com Fri Oct 17 12:52:36 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 17 Oct 2014 08:52:36 -0400 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <544022BB.3040305@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> <544003AA.7020805@redhat.com> <54400812.1010101@redhat.com> <544010C9.3080607@redhat.com> <20141016153249.5f42824d@willson.usersys.redhat.com> <544022BB.3040305@redhat.com> Message-ID: <20141017085236.62da0f00@willson.usersys.redhat.com> On Thu, 16 Oct 2014 21:55:39 +0200 Petr Spacek wrote: > On 16.10.2014 21:32, Simo Sorce wrote: > > On Thu, 16 Oct 2014 20:39:05 +0200 > > Martin Kosek wrote: > > > >> On 10/16/2014 08:01 PM, Petr Spacek wrote: > >> .... > >>>> 1) > >>>> > >>>> I'm not sure if failing on DNSSEC-disabled forwarders by default > >>>> is a good idea. Perhaps there could be some auto-detection code? > >>>> Something along the lines of: > >>>> > >>>> if forwarders_support_dnssec: > >>>> if not options.no_dnssec_validation: > >>>> enable_dnssec_in_ipa() > >>>> else: > >>>> print "WARNING: DNSSEC will not be enabled" > >>> > >>> We have discussed this with Martin > >> > >> ... Martin Basti/Martin2... Given there are more Martins in the > >> team, you should be more specific :-) > >> > >>> and the intent is to tell people that their > >>> infrastructure is broken and has to be fixed - sooner is better. > >>> > >>> There is an option --no-dnssec-validation for people who like > >>> broken infrastructure. > >> > >> Broken infrastructure is rather strong word for the situation when > >> just DNSSEC is not configured (it may work for the customer > >> otherwise). "Infrastructure does not follow most up to date > >> standards" may be more precise. > >> > >> From my POV, this may be too strict. People may already use > >> ipa-server-install in their scripts and it suddenly requiring new > >> option may be seen as breakage. > >> > >> So maybe it would be better to just print big fat warning including > >> [yes|no] question to continue during ipa-server-install and just > >> print warning in unattended mode (and disable DNSEC validation) > >> > >> We can always be more strict in next release. CCing Simo and Rob in > >> case they have different opinions. > > > > My opinion is that DNSSEC is too new to make it required by default > > in any way. > Sure, the standard is only 9.5 years old (RFC 4033). With this course > we will be stuck with insecure DNS forever, like with with SSL 3.0 :-) It's newer than the IPv6 one IIRC :) > > For the first release it should be completely optional and opt in. > > Once we sort out the initial hurdles we can slowly add warnings and > > what not and at some point in the future switch the defaults and > > start complaining. > I'm afraid that nobody will notice it if it is completely disabled ... So be it. > > We have to assume that most forwarders will be broken, so perhaps > > the > That is the reason why there is detection & warning. > > Please note that 'fixing' the issue is typically just about adding > line "dnssec-enabled yes;" to named.conf on the "broken" forwarder > (which is default even in RHEL 6 BTW). > > Biggest problem is to convince admin to add the line to the config > file, it is not a technical problem. You are assuming the forwarder is bind on RHEL, that's a bad assumptions. Also the admin doing the FreeIPA install in many cases is not a Network admin, so he may have no way to act on the DNS configuration fast (or ever). > > correct course of action if someone decides to try DNSSEC and the > > forwarders do not support it is to give a fat warning and disable > > DNSSEC for non-managed zones. > > It is not possible to do DNSSEC validation only for part of the tree > *unless you manually install trust anchors to validators*. I know, but the FreeIPA DNS server can reach to root zone to do the validation for it's own managed zones, if the trust path is completely broken as root zones are unreachable w/o forwarders then we should just disable DNSSEC completely with a big warning. > Keep in mind that validator has to be able to build chain of trust > from name-under-validation to nearest trust anchor, i.e. typically to > DNS root. See above. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Fri Oct 17 13:36:26 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Oct 2014 15:36:26 +0200 Subject: [Freeipa-devel] [PATCH] 764 webui: management of keytab permissions In-Reply-To: <54356BEF.2080600@redhat.com> References: <542C289A.6040301@redhat.com> <542EAECA.4050104@redhat.com> <54356BEF.2080600@redhat.com> Message-ID: <54411B5A.1070409@redhat.com> On 8.10.2014 18:53, Petr Vobornik wrote: > On 3.10.2014 16:12, Petr Vobornik wrote: >> On 1.10.2014 18:15, Petr Vobornik wrote: >>> Hello list, >>> >>> Patch for: https://fedorahosted.org/freeipa/ticket/4419 >>> >> >> Web UI for 4419. Depends on patch 761 (parent thread). >> > > New version which works with 761-2. > > The content was moved to details facet (based on UXD feedback). > Server part has been pushed. Version which matches its API attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0764-2-webui-management-of-keytab-permissions.patch Type: text/x-patch Size: 13938 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 17 13:47:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 15:47:15 +0200 Subject: [Freeipa-devel] [PATCH] 772 webui: add new iduseroverride fields In-Reply-To: <543802EC.4060408@redhat.com> References: <543802EC.4060408@redhat.com> Message-ID: <54411DE3.80102@redhat.com> On 10/10/2014 06:01 PM, Petr Vobornik wrote: > - add gecos, gidnumber, loginshell, sshkeys fields > > depends on ab's 160-165. > > Point for discussion: > Before this patch, all fields were included in adder dialog and were listed on > a search pages. > > Now: > * Search page lacks: gecos, gidnumber, loginshell, sshkeys fields > * Adder dialog lacks: sshkeys > > For reference, other fields are: ipaanchoruuid, description, uid, uidnumber, > homedirectory > > We can't show every field on a search page. Is there a field among the missing > ones, which is more important and should be added to a search page? Works fine, ACK! Please just add https://fedorahosted.org/freeipa/ticket/4617 to commit description before pushing. Also make sure you rebase it on master :-) Martin From mkosek at redhat.com Fri Oct 17 13:54:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 17 Oct 2014 15:54:37 +0200 Subject: [Freeipa-devel] [PATCH] 741 webui: add link to OTP token app In-Reply-To: <53EB83B3.704@redhat.com> References: <53E0F417.8050204@redhat.com> <53EB83B3.704@redhat.com> Message-ID: <54411F9D.2020409@redhat.com> On 08/13/2014 05:26 PM, Endi Sukma Dewata wrote: > > On 8/5/2014 10:11 AM, Petr Vobornik wrote: >> - display info message which points user to FreeOTP project page >> - the link or the text can be easily changed by a plugin if needed >> >> https://fedorahosted.org/freeipa/ticket/4469 >> >> Notes: >> - the design can be a subject of discussion. >> - the FreeOTP project page [1] is not very end-user friendly but serves the >> purpose >> - it's not fully configurable, as decided at today's meeting, but a very >> simple plugin can hide or modify the message >> >> [1] https://fedorahosted.org/freeotp/ > > ACK. > I saw no update - we still do not have any better URL than the fedorahosted one. And this link is better than no link, so I want to push this patch. Pushed to: master: 43d359387392bb659b471380c129999bb8aebb3e ipa-4-1: bb8740aec6a8758fda737c8218b2350e445028d9 Martin From pvoborni at redhat.com Fri Oct 17 14:00:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Oct 2014 16:00:14 +0200 Subject: [Freeipa-devel] [PATCH] 772 webui: add new iduseroverride fields In-Reply-To: <54411DE3.80102@redhat.com> References: <543802EC.4060408@redhat.com> <54411DE3.80102@redhat.com> Message-ID: <544120EE.7050804@redhat.com> On 17.10.2014 15:47, Martin Kosek wrote: > On 10/10/2014 06:01 PM, Petr Vobornik wrote: >> - add gecos, gidnumber, loginshell, sshkeys fields >> >> depends on ab's 160-165. >> >> Point for discussion: >> Before this patch, all fields were included in adder dialog and were listed on >> a search pages. >> >> Now: >> * Search page lacks: gecos, gidnumber, loginshell, sshkeys fields >> * Adder dialog lacks: sshkeys >> >> For reference, other fields are: ipaanchoruuid, description, uid, uidnumber, >> homedirectory >> >> We can't show every field on a search page. Is there a field among the missing >> ones, which is more important and should be added to a search page? > > Works fine, ACK! > > Please just add > > https://fedorahosted.org/freeipa/ticket/4617 > > to commit description before pushing. Also make sure you rebase it on master :-) > > Martin > Pushed to: master: 0a924603d08bb39c51b7365c8a4cbe6cda77c8bf ipa-4-1: ace4beca7543bf57315dd723351f1eb99a5f146f -- Petr Vobornik From pvoborni at redhat.com Fri Oct 17 14:19:06 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Oct 2014 16:19:06 +0200 Subject: [Freeipa-devel] FreeIPA 4.0.4 In-Reply-To: <543F84AE.5010407@redhat.com> References: <543F84AE.5010407@redhat.com> Message-ID: <5441255A.10909@redhat.com> On 16.10.2014 10:41, Martin Kosek wrote: > Hello all! > > I think we have all the bits and pieces ready to release next stabilization > release of FreeIPA 4.0 - FreeIPA 4.0.4! There were a lot of bug fixes or minor > enhancements, let us offer it for others to use. > > I created the first version of release notes on the wiki, updates welcome: > > http://www.freeipa.org/page/Releases/4.0.4 > > Does anybody know any issue preventing us from releasing it? If yes, please let > me know. > > Also, who wants to be the Release Man for this version? :-) > I'll do it. With https://fedorahosted.org/freeipa/ticket/4637 fixed we are ready for the release of 4.0.4 -- Petr Vobornik From npmccallum at redhat.com Fri Oct 17 16:03:00 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 17 Oct 2014 12:03:00 -0400 Subject: [Freeipa-devel] [PATCH 0071] Display token type when viewing token In-Reply-To: <5440DA77.20306@redhat.com> References: <1413390721.6617.20.camel@redhat.com> <543FE5D2.5080808@redhat.com> <1413495441.3525.2.camel@redhat.com> <5440DA77.20306@redhat.com> Message-ID: <1413561780.4610.1.camel@redhat.com> On Fri, 2014-10-17 at 10:59 +0200, Martin Kosek wrote: > On 10/16/2014 11:37 PM, Nathaniel McCallum wrote: > > On Thu, 2014-10-16 at 17:35 +0200, Martin Kosek wrote: > >> On 10/15/2014 06:32 PM, Nathaniel McCallum wrote: > >>> When viewing a token from the CLI or UI, the type of the token > >>> should be displayed. > >>> > >>> https://fedorahosted.org/freeipa/ticket/4563 > >> > >> Adding objectclass to default_attributes is unprecedented and something we > >> should not do before release. It would also put objectclass attribute in > >> default otptoken-* operations. > >> > >> What I would do in this case is to > >> - keep default_attributes as is > >> - add 'objectclass' to attrs_list in pre_callback > >> - do whatever you already do with it in post_callback > >> - remove the objectclass if it was not called for explicitly, e.g.: > >> > >> if not options.get('all', False) or options.get('pkey_only', False): > >> entry_attrs.pop('objectclass', None) > >> > >> This approach is used for example in idrange.py so I would stick with it (I am > >> not saying it is pretty, I am just saying our API should give consistent output). > > > > Fixed and tested. > > > > Works fine in CLI, though I found couple more issues: > > 1) In type you return "HOTP" or "TOTP" while on the input you accept lowercased > versions - is that OK? > > # ipa otptoken-add --type=TOTP --owner=fbar barbar > ipa: ERROR: invalid 'type': must be one of 'totp', 'hotp' > > It just did not seem consistent to me. It was an oversight. In an ideal world, we'd have a case-insensitive StrEnum type. For now, this patch accepts either fully lowercase or fully uppercase. Display is always uppercase. > 2) You are suddenly adding camelcased attribute, compared to other places: > > + attrs_list.append("objectClass") Argh. Fixed. > 3) I do not see the OTP token type in Web UI OTP token view - is it just me or > is it really missing? I think it is just you. The token type shows on the token details page, not in the overview list of all tokens. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0071.2-Display-token-type-when-viewing-token.patch Type: text/x-patch Size: 5935 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 17 17:18:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 17 Oct 2014 13:18:35 -0400 Subject: [Freeipa-devel] [PATCH 0073] Configure IPA OTP Last Token plugin on upgrade Message-ID: <1413566315.4610.6.camel@redhat.com> While working on the OTP Counter plugin I realized that the OTP Last Token plugin never gets configured during upgrades. This patch fixes this problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0073-Configure-IPA-OTP-Last-Token-plugin-on-upgrade.patch Type: text/x-patch Size: 4400 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 17 17:22:20 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 17 Oct 2014 13:22:20 -0400 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <5440E9F7.9090901@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <54198DA3.5090603@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> <5436BC59.2090008@redhat.com> <1413313274.6617.12.camel@redhat.com> <543E209F.9020709@redhat.com> <5440165F.8050902@redhat.com> <1413496413.3525.4.camel@redhat.com> <5440E9F7.9090901@redhat.com> Message-ID: <1413566540.4610.7.camel@redhat.com> On Fri, 2014-10-17 at 12:05 +0200, Martin Kosek wrote: > On 10/16/2014 11:53 PM, Nathaniel McCallum wrote: > > On Thu, 2014-10-16 at 21:02 +0200, Martin Kosek wrote: > >> On 10/15/2014 09:22 AM, Martin Kosek wrote: > >>> On 10/14/2014 09:01 PM, Nathaniel McCallum wrote: > >>>> On Thu, 2014-10-09 at 18:48 +0200, thierry bordaz wrote: > >>>>> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: > >>>>> > >>>>>> On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: > >>>>>>> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: > >>>>>>> > >>>>>>>> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: > >>>>>>>>> On Wed, 08 Oct 2014 15:53:39 -0400 > >>>>>>>>> Nathaniel McCallum wrote: > >>>>>>>>> > >>>>>>>>>> As I understand my code, all servers will have csnD. Some servers will > >>>>>>>>>> have valueB and others will have valueD, but valueB == valueD. > >>>>>>>>>> > >>>>>>>>>> We *never* discard a CSN. We only discard the counter/watermark mods > >>>>>>>>>> in the replication operation. > >>>>>>>>> What Thierry is saying is that the individual attributes in the entry > >>>>>>>>> have associate the last CSN that modified them. Because you remove the > >>>>>>>>> mods when ValueD == ValueB the counter attribute will not have the > >>>>>>>>> associated CSN changed. But it doesn't really matter because the plugin > >>>>>>>>> will always keep things consistent. > >>>>>>>> Attached is a new version. It removes this optimization. If server X has > >>>>>>>> valueB/csnB and receives valueD/csnD and valueB == valueD, the > >>>>>>>> replication will be applied without any modification. However, if valueB > >>>>>>>>> valueD and csnD > csnB, the counter mods will still be stripped. > >>>>>>>> It also collapses the error check from betxnpre to bepre now that we > >>>>>>>> have a fix for https://fedorahosted.org/389/ticket/47919 committed. The > >>>>>>>> betxnpre functions are completely removed. Also, a dependency on 389 > >>>>>>>> 1.3.3.4 (not yet released) is added. > >>>>>>>> > >>>>>>>> Nathaniel > >>>>>>> Hello Nathaniel, > >>>>>>> > >>>>>>> For me the code is fine. Ack. > >>>>>> New attached patch. > >>>>>> > >>>>>>> I have two minor comments: > >>>>>>> * in preop_mod, when a direct update moves the counter > >>>>>>> backward you send UNWILLING to perform with a message. > >>>>>>> The message is allocated with slapi_ch_smprintf, you > >>>>>>> may free it with slapi_ch_free_string (rather than > >>>>>>> 'free'). > >>>>>> Fixed. > >>>>>> > >>>>>>> * About this message, for example when you have these > >>>>>>> MODS (I admit they make no sens): > >>>>>>> > >>>>>>> changetype: modify > >>>>>>> ipatokenHOTPcounter: MOD_DELETE > >>>>>>> - > >>>>>>> ipatokenHOTPcounter: MOD_INCREMENT > >>>>>>> > >>>>>>> The returned message will be "Will not decrement > >>>>>>> ipatokenHOTPcounter", because 'simulate' will return > >>>>>>> 'COUNTER_UNSET+1'. > >>>>>>> Is it the message you expected ? > >>>>>> I changed the logic in simulate(). Please review it. > >>>>>> > >>>>>> Nathaniel > >>>>>> > >>>>> Hello Nathaniel, > >>>>> > >>>>> > >>>>> The patch is ok for me. Ack. > >>>> > >>>> Since the ACK, the upstream 389 fix actually landed in 1.3.3.5. This > >>>> patch changes nothing except the dependency version. I have tested it > >>>> against the 1.3.3.5 build. > >>>> > >>>> Nathaniel > >>> > >>> Great! As soon as the new build land in Fedora 21 (and we add it to our Copr), > >>> the patch can be pushed. > >>> > >>> Martin > >> > >> Ok, 1.3.3.5 is in koji and our Copr repo. > > > > +1 > > > >> I almost pushed the patch, but I just > >> spotted you forgot to solve the upgrades - so NACK. > > > > You asked me to do that in another patch, not this one. :) > > I know, but that does not change the fact it is still missing :-) > > > > >> "cn=IPA OTP Counter,cn=plugins,cn=config" plugin configuration also needs to be > >> added in some update file. > > > > So I'm generally confused then. If we have to add the plugin config to > > an update file, why bother creating > > daemons/ipa-slapi-plugins/ipa-otp-counter/otp-counter-conf.ldif or > > modifying ipaserver/install/dsinstance.py at all? Should these changes > > be removed? > > Good question. Most LDAP update related changes are added to update plugins > only. But plugin registration seemed to be still on 2 places, like 'cn=IPA > Range-Check,cn=plugins,cn=config' registration. > > Up to you/additional developer discussion. Fixed. Also note that the same problem was present in the OTP Last Token plugin (committed for 4.0). I have made a patch which fixes this as well: https://www.redhat.com/archives/freeipa-devel/2014-October/msg00358.html Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0064.9-Create-ipa-otp-counter-389DS-plugin.patch Type: text/x-patch Size: 33289 bytes Desc: not available URL: From edewata at redhat.com Fri Oct 17 17:54:25 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 17 Oct 2014 12:54:25 -0500 Subject: [Freeipa-devel] [PATCH] 764 webui: management of keytab permissions In-Reply-To: <54411B5A.1070409@redhat.com> References: <542C289A.6040301@redhat.com> <542EAECA.4050104@redhat.com> <54356BEF.2080600@redhat.com> <54411B5A.1070409@redhat.com> Message-ID: <544157D1.5030000@redhat.com> On 10/17/2014 8:36 AM, Petr Vobornik wrote: > Server part has been pushed. Version which matches its API attached. ACK. -- Endi S. Dewata From edewata at redhat.com Fri Oct 17 19:03:37 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 17 Oct 2014 14:03:37 -0500 Subject: [Freeipa-devel] [PATCH] 765 webui: allow --force in dnszone-mod and dnsrecord-add In-Reply-To: <542ED352.6020806@redhat.com> References: <542ED352.6020806@redhat.com> Message-ID: <54416809.10705@redhat.com> On 10/3/2014 11:48 AM, Petr Vobornik wrote: > Allow to use --force when changing authoritative nameserver address in > DNS zone. > > Same for dnsrecord-add for NS record. > > https://fedorahosted.org/freeipa/ticket/4573 ACK, just some minor issues: 1. The 'Check DNS' button might be interpreted as 'check the DNS without updating the DNS zone' but in fact it also updates the DNS zone. I'd suggest using a regular 'Update' button, but add a 'Force' checkbox. 2. A 'Force' checkbox would be more consistent with other dialog boxes than 'Skip DNS check' checkbox. Also, there might be other checks being done, not just DNS check. 3. When the authoritative nameserver is updated I get this message: semantic of '--name-server' option was changed: the option is used only for setting up the SOA MNAME attribute. To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] @ --ns-rec=nameserver'. I think the message shouldn't be displayed because it's irrelevant to the UI, a bit too long to read, and not enough time to read it before it disappears. 4. Server issue. I don't see a --force option in the dnsrecord-add help message. > Note: dnsrecord-mod doesn't support --force option to skip dns > resolution when changing NS record. Question is whether it should be > added, or if 'edit' button should be hidden in web ui to force > dnsrecord-add + dnsrecord-del combo instead of dnsrecord-mod, or if it's > good as is. > Note2: -add + -del combo has better UX than -del + -add if there is only > one value in the dns record. I think if we're keeping the dnsrecord-mod CLI it should have a --force option too regardless whether the UI uses -mod or -add/del. Once that's added, the Edit dialog should provide a checkbox for that too. The Edit dialog in DNS records is useful to edit records that consist of multiple fields (e.g. MX, SRV), so I think we should keep that, but internally it could be implemented either using -add/del or -mod, whichever works better. -- Endi S. Dewata From redhatrises at gmail.com Fri Oct 17 19:18:56 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 17 Oct 2014 13:18:56 -0600 Subject: [Freeipa-devel] [PATCH] 482 Update contributors In-Reply-To: <5422B9C0.3030904@redhat.com> References: <5422B9C0.3030904@redhat.com> Message-ID: Not sure I can do this, but ACK. Gabe On Wed, Sep 24, 2014 at 6:32 AM, Martin Kosek wrote: > Add missing developers contributing to project git. Cancel "Past and > Occcasional" section and merge the people in the right categories. > > Update .mailmap so that the Developer list can be easily re-generated. > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Fri Oct 17 20:51:28 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 17 Oct 2014 15:51:28 -0500 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <5437C6BB.7030109@redhat.com> References: <5437C6BB.7030109@redhat.com> Message-ID: <54418150.2000102@redhat.com> On 10/10/2014 6:44 AM, Petr Vobornik wrote: > Web UI part of: > > https://fedorahosted.org/freeipa/ticket/4615 > > Patch 767 is a little refactoring needed for $pre_op(as plain object) > work as intended even with instantiated objects + fixes a bug where > Evented objects were not considered a framework object. > > Patch 768 switches tabs so we can hide it later > > Patch 769 hides the tab > > PAtch 770 is not really needed(would like to hear options whether to > include it). It's in effect only if user somehow manages to open > 'Applies to hosts' facet for 'Default trust view'. Maybe redirection > would be better - if we need to act. For some reason I don't see the Default Trust View in the database/CLI/UI with a brand new server installation. Alexander said he will investigate on Monday. The patches seem to be fine, I don't have any objections, feel free to push. The missing Default Trust View is most likely unrelated to UI. -- Endi S. Dewata From edewata at redhat.com Fri Oct 17 20:51:35 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 17 Oct 2014 15:51:35 -0500 Subject: [Freeipa-devel] [PATCH] 771 webui: do not offer ipa users to Default Trust View In-Reply-To: <5437C6C1.9070007@redhat.com> References: <5437C6C1.9070007@redhat.com> Message-ID: <54418157.1080807@redhat.com> On 10/10/2014 6:45 AM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/4616 This patch does not apply. Does it depend on another patch? -- Endi S. Dewata From pvoborni at redhat.com Fri Oct 17 21:55:57 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Oct 2014 23:55:57 +0200 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <54418150.2000102@redhat.com> References: <5437C6BB.7030109@redhat.com> <54418150.2000102@redhat.com> Message-ID: <5441906D.9030002@redhat.com> On 17.10.2014 22:51, Endi Sukma Dewata wrote: > On 10/10/2014 6:44 AM, Petr Vobornik wrote: >> Web UI part of: >> >> https://fedorahosted.org/freeipa/ticket/4615 >> >> Patch 767 is a little refactoring needed for $pre_op(as plain object) >> work as intended even with instantiated objects + fixes a bug where >> Evented objects were not considered a framework object. >> >> Patch 768 switches tabs so we can hide it later >> >> Patch 769 hides the tab >> >> PAtch 770 is not really needed(would like to hear options whether to >> include it). It's in effect only if user somehow manages to open >> 'Applies to hosts' facet for 'Default trust view'. Maybe redirection >> would be better - if we need to act. > > For some reason I don't see the Default Trust View in the > database/CLI/UI with a brand new server installation. Alexander said he > will investigate on Monday. > > The patches seem to be fine, I don't have any objections, feel free to > push. The missing Default Trust View is most likely unrelated to UI. > It should be added when you run ipa-adtrust-install. -- Petr Vobornik From tjaalton at ubuntu.com Sat Oct 18 15:39:03 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sat, 18 Oct 2014 18:39:03 +0300 Subject: [Freeipa-devel] Dogtag 10.2.0 is now in Debian Message-ID: <54428997.8060306@ubuntu.com> Hi! I'm happy to announce that Dogtag (version 10.2.0) has finally entered Debian unstable repository this week. Assuming there won't be any nasty surprises, the next stable release ("Jessie") will include it. Many thanks to Ade Lee who did the first pass of packaging the long chain of dependencies, up to and including RESTEasy. and next week there should be another announcement.. -- t From tjaalton at ubuntu.com Sat Oct 18 15:42:38 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sat, 18 Oct 2014 18:42:38 +0300 Subject: [Freeipa-devel] Dogtag 10.2.0 is now in Debian In-Reply-To: <54428997.8060306@ubuntu.com> References: <54428997.8060306@ubuntu.com> Message-ID: <54428A6E.8010406@ubuntu.com> On 18.10.2014 18:39, Timo Aaltonen wrote: > > Hi! > > I'm happy to announce that Dogtag (version 10.2.0) has finally entered > Debian unstable repository this week. Assuming there won't be any nasty > surprises, the next stable release ("Jessie") will include it. Many > thanks to Ade Lee who did the first pass of packaging the long chain of > dependencies, up to and including RESTEasy. forgot the link https://packages.qa.debian.org/d/dogtag-pki.html there's a small update coming early next week -- t From ftweedal at redhat.com Sun Oct 19 02:10:08 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Sun, 19 Oct 2014 12:10:08 +1000 Subject: [Freeipa-devel] [Pki-devel] Dogtag 10.2.0 is now in Debian In-Reply-To: <54428A6E.8010406@ubuntu.com> References: <54428997.8060306@ubuntu.com> <54428A6E.8010406@ubuntu.com> Message-ID: <20141019021008.GV5346@dhcp-40-8.bne.redhat.com> On Sat, Oct 18, 2014 at 06:42:38PM +0300, Timo Aaltonen wrote: > On 18.10.2014 18:39, Timo Aaltonen wrote: > > > > Hi! > > > > I'm happy to announce that Dogtag (version 10.2.0) has finally entered > > Debian unstable repository this week. Assuming there won't be any nasty > > surprises, the next stable release ("Jessie") will include it. Many > > thanks to Ade Lee who did the first pass of packaging the long chain of > > dependencies, up to and including RESTEasy. > > forgot the link > https://packages.qa.debian.org/d/dogtag-pki.html > > there's a small update coming early next week > Great! Thanks for all your work, Timo. Fraser > -- > t > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From pvoborni at redhat.com Sun Oct 19 13:22:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Sun, 19 Oct 2014 15:22:19 +0200 Subject: [Freeipa-devel] [PATCH] 771 webui: do not offer ipa users to Default Trust View In-Reply-To: <54418157.1080807@redhat.com> References: <5437C6C1.9070007@redhat.com> <54418157.1080807@redhat.com> Message-ID: <5443BB0B.70403@redhat.com> On 17.10.2014 22:51, Endi Sukma Dewata wrote: > On 10/10/2014 6:45 AM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/4616 > > This patch does not apply. Does it depend on another patch? > rebased version attached. Should be applicable on master, ipa-4-1 and patchset 767-770. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0771-1-webui-do-not-offer-ipa-users-to-Default-Trust-View.patch Type: text/x-patch Size: 7508 bytes Desc: not available URL: From jhrozek at redhat.com Sun Oct 19 20:04:29 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 19 Oct 2014 22:04:29 +0200 Subject: [Freeipa-devel] [PATCH] 131-132 extdom: add support for sss_nss_getorigbyname() In-Reply-To: <20141017095344.GA9734@localhost.localdomain> References: <20141017095344.GA9734@localhost.localdomain> Message-ID: <20141019200429.GB10559@hendrix.redhat.com> On Fri, Oct 17, 2014 at 11:53:44AM +0200, Sumit Bose wrote: > Hi, > > the first patch replaces sss_nss_getsidbyname() by > sss_nss_getorigbyname() for the new version of the extdom interface. > The new call returns more data about the original object and allows the > IPA client to have the same information about the object in the SSSD > cache as the IPA servers. > > The second patch just removes an obsolete dependency. > > bye, > Sumit Hi, I was unable to send the patches through Coverity, the RH server seems to be having issues. I'll wait until tomorrow, if the problems persist, we'll just skip Coverity and fix any potential problems post-push. > From 928c04c35601b7bc1c57c1320e4a746abc35e947 Mon Sep 17 00:00:00 2001 > From: Sumit Bose > Date: Fri, 10 Oct 2014 10:56:37 +0200 > Subject: [PATCH 131/132] extdom: add support for sss_nss_getorigbyname() [...] > @@ -576,13 +613,14 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, > enum sss_id_type id_type; > size_t buf_len; > char *buf = NULL; > + struct sss_nss_kv *kv_list; Please set kv_list to NULL here, you're freeing the pointer unconditionally in the done handler, but in some cases (request_type == REQ_SIMPLE) kv_list is not set at all. > > ret = get_buffer(&buf_len, &buf); > if (ret != LDAP_SUCCESS) { > return ret; > } > > - if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { > + if (request_type == REQ_SIMPLE) { > ret = sss_nss_getsidbyid(gid, &sid_str, &id_type); > if (ret != 0 || id_type != SSS_ID_TYPE_GID) { > if (ret == ENOENT) { > @@ -592,9 +630,7 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, > } > goto done; > } > - } > > - if (request_type == REQ_SIMPLE) { > ret = pack_ber_sid(sid_str, berval); > } else { > ret = getgrgid_r(gid, &grp, buf, buf_len, &grp_result); > @@ -607,13 +643,27 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, > goto done; > } > > + if (request_type == REQ_FULL_WITH_GROUPS) { > + ret = sss_nss_getorigbyname(grp.gr_name, &kv_list, &id_type); > + if (ret != 0 || !(id_type == SSS_ID_TYPE_GID > + || id_type == SSS_ID_TYPE_BOTH)) { > + if (ret == ENOENT) { > + ret = LDAP_NO_SUCH_OBJECT; > + } else { > + ret = LDAP_OPERATIONS_ERROR; > + } > + goto done; > + } > + } > + > ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP > : RESP_GROUP_MEMBERS), > domain_name, grp.gr_name, grp.gr_gid, > - grp.gr_mem, sid_str, berval); > + grp.gr_mem, kv_list, berval); > } > > done: > + sss_nss_free_kv(kv_list); > free(sid_str); > free(buf); > return ret; > @@ -634,6 +684,7 @@ static int handle_sid_request(enum request_types request_type, const char *sid, > size_t buf_len; > char *buf = NULL; > enum sss_id_type id_type; > + struct sss_nss_kv *kv_list; Also please set kv_list to NULL here... > > ret = sss_nss_getnamebysid(sid, &fq_name, &id_type); > if (ret != 0) { [...] > @@ -733,6 +811,7 @@ static int handle_name_request(enum request_types request_type, > enum sss_id_type id_type; > size_t buf_len; > char *buf = NULL; > + struct sss_nss_kv *kv_list; ...and here. > > ret = asprintf(&fq_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR, > domain_name); The rest of the patch looks good to me. > From f83616c145d5d14d125c663f9ac4e31cff4af81b Mon Sep 17 00:00:00 2001 > From: Sumit Bose > Date: Wed, 15 Oct 2014 16:21:53 +0200 > Subject: [PATCH 132/132] extdom: remove unused dependency to libsss_idmap ACK From jhrozek at redhat.com Sun Oct 19 20:37:00 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 19 Oct 2014 22:37:00 +0200 Subject: [Freeipa-devel] [PATCH] slapi-nis: normalize memberUid search filter term for AD users In-Reply-To: <20141009110116.GP2328@redhat.com> References: <20141009110116.GP2328@redhat.com> Message-ID: <20141019203700.GC10559@hendrix.redhat.com> On Thu, Oct 09, 2014 at 02:01:16PM +0300, Alexander Bokovoy wrote: > Hi, > > memberUid attribute has case-sensitive comparison defined but when we > construct memberUid for AD users (coming through SSSD), they are > normalized to lower case. Interestingly enough, 'uid' attribute has > case-insensitive comparison. > > Work around the issue by low-casing the memberUid search term value when > it is a fully-qualified name (user at domain), meaning we do ask for a SSSD > user. > > This is the patch on top of my ID views support patch. > > https://bugzilla.redhat.com/show_bug.cgi?id=1130131 > -- > / Alexander Bokovoy The code reads good to me and passed some basic sanity testing..however, I'be been unable to reproduce the issue, so I'm not sure this counts as a full ACK... From mbasti at redhat.com Mon Oct 20 01:08:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 20 Oct 2014 03:08:56 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview In-Reply-To: <5440D4BB.5040604@redhat.com> References: <54369446.6000207@redhat.com> <5437880E.5010002@redhat.com> <543FEB5D.5020402@redhat.com> <544003AA.7020805@redhat.com> <54400812.1010101@redhat.com> <5440CE97.2020300@redhat.com> <5440D4BB.5040604@redhat.com> Message-ID: <544460A8.7080808@redhat.com> On 17/10/14 10:35, Petr Spacek wrote: > On 17.10.2014 10:08, Jan Cholasta wrote: >> Dne 16.10.2014 v 20:01 Petr Spacek napsal(a): >>> On 16.10.2014 19:43, Jan Cholasta wrote: >>>> Dne 16.10.2014 v 17:59 Martin Basti napsal(a): >>>>> On 10/10/14 09:17, Martin Kosek wrote: >>>>>> On 10/09/2014 03:57 PM, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> it would be great if people could look at current state of DNSSEC >>>>>>> patches for >>>>>>> FreeIPA. >>>>>>> >>>>>>> It consist of several relatively independent parts: >>>>>>> - python-pkcs#11 interface written by Martin Basti: >>>>>>> https://github.com/spacekpe/freeipa-pkcs11 >>>>>>> >>>>>>> - DNSSEC daemons written by me: >>>>>>> https://github.com/spacekpe/ipadnssecd >>>>>>> >>>>>>> - FreeIPA integration written by Martin Basti: >>>>>>> https://github.com/bastiak/freeipa/tree/dnssec >>>>> Here is updated repo with installers, please review: >>>>> https://github.com/bastiak/freeipa/tree/dnssec-4 >>>>> branch dnssec-4 >>>>> >>>>> TODO: integrate ipadnssecd daemons and pkcs11 helper, when finished >>> >>> ... >>> >>>> 3) >>>> >>>> Not something you can fix in this commit, but shouldn't >>>> ipa-ods-exporter be >>>> named ipa-odsexportd, so that the naming is consistent with the rest >>>> of our >>>> daemons? >>> >>> Side note: ipa-ods-exporter is not a daemon :-) It is single-shot >>> binary >>> activated via socket. It is replacement for "ODS signer" and uses the >>> same protocol. >>> >>> Anyway, I don't care much. Feel free pick a new name and let me know. >> >> Nevermind, I thought it was a daemon. >> >>> >>>> 2) >>>> >>>> Why do you use the default /etc/softhsm2.conf file, instead of >>>> using e.g. >>>> /etc/ipa/dnssec/softhsm2.conf and passing it to SoftHSM in the >>>> SOFTHSM2_CONF >>>> environment variable? >>> >>> I don't like the idea. The same library is used from named and >>> ods-enforcerd so we would have to modify environment variables for all >>> of them and do some monkey patching in /etc/systemd. >>> >>> AFAIK current ipactl/framework is sooo clever so it deletes service >>> files related to all services "managed" by IPA if they are located in >>> /etc/systemd. As a result we don't have any way how to override values >>> supplies by other packages now. >> >> IMO if we can have a private instance of something we should have it. To >> configure named properly, you just have to add a line with >> "SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf" to /etc/sysconfig/named. > > Ok, I did not realize that we don't actually need systemd unit > overrides. We need to do the same with /etc/sysconfig/ods and unit > files for ipa-dnskeysynd and ipa-ods-exporter. > >>>> 4) >>>> >>>> I think /etc/ipa/softhsm_pin_so should be moved to >>>> /etc/ipa/dnssec/softhsm_pin_so. >>> >>> Is it a good idea to store both PINs on the same spot? >>> softhsm_pin_so is >>> not necessary at run-time so it can be readable only by root:root. >> >> What do you mean by "the same spot"? > > Nevermind, I can't read. > Hello, the latest version: https://github.com/bastiak/freeipa/tree/dnssec-9 -- Martin Basti From edewata at redhat.com Mon Oct 20 05:51:11 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 20 Oct 2014 00:51:11 -0500 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <5441906D.9030002@redhat.com> References: <5437C6BB.7030109@redhat.com> <54418150.2000102@redhat.com> <5441906D.9030002@redhat.com> Message-ID: <5444A2CF.2060609@redhat.com> On 10/17/2014 4:55 PM, Petr Vobornik wrote: > On 17.10.2014 22:51, Endi Sukma Dewata wrote: >> On 10/10/2014 6:44 AM, Petr Vobornik wrote: >>> Web UI part of: >>> >>> https://fedorahosted.org/freeipa/ticket/4615 >>> >>> Patch 767 is a little refactoring needed for $pre_op(as plain object) >>> work as intended even with instantiated objects + fixes a bug where >>> Evented objects were not considered a framework object. >>> >>> Patch 768 switches tabs so we can hide it later >>> >>> Patch 769 hides the tab >>> >>> PAtch 770 is not really needed(would like to hear options whether to >>> include it). It's in effect only if user somehow manages to open >>> 'Applies to hosts' facet for 'Default trust view'. Maybe redirection >>> would be better - if we need to act. >> >> For some reason I don't see the Default Trust View in the >> database/CLI/UI with a brand new server installation. Alexander said he >> will investigate on Monday. >> >> The patches seem to be fine, I don't have any objections, feel free to >> push. The missing Default Trust View is most likely unrelated to UI. > > It should be added when you run ipa-adtrust-install. OK, that fixed it. Some comments: 1. Shouldn't the Default Trust View entry be added during the initial installation? Although it's unlikely to conflict with user-defined entries, it's kind of strange to add a 'built-in' entry after the initial installation. 2. The description field in the Settings page for Default Trust View should be read-only since the entry cannot be modified. 3. The Delete action in the Settings page for Default Trust View should not exist since the entry cannot be deleted. Probably the Actions drop-down list can be disabled. 4. I think this was discussed before, but I'm just not sure what the plan is. The current facet tab titles seem to be redundant since we already have facet group headers that say " overrides/applies to". Are we going to change "User/Group ID overrides" into "Users/Groups" and "Applied to hosts" into "Hosts"? No major issue. ACK. -- Endi S. Dewata From edewata at redhat.com Mon Oct 20 05:51:15 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 20 Oct 2014 00:51:15 -0500 Subject: [Freeipa-devel] [PATCH] 771 webui: do not offer ipa users to Default Trust View In-Reply-To: <5443BB0B.70403@redhat.com> References: <5437C6C1.9070007@redhat.com> <54418157.1080807@redhat.com> <5443BB0B.70403@redhat.com> Message-ID: <5444A2D3.4000700@redhat.com> On 10/19/2014 8:22 AM, Petr Vobornik wrote: > On 17.10.2014 22:51, Endi Sukma Dewata wrote: >> On 10/10/2014 6:45 AM, Petr Vobornik wrote: >>> https://fedorahosted.org/freeipa/ticket/4616 >> >> This patch does not apply. Does it depend on another patch? >> > > rebased version attached. Should be applicable on master, ipa-4-1 and > patchset 767-770. ACK. -- Endi S. Dewata From abokovoy at redhat.com Mon Oct 20 06:09:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Oct 2014 09:09:51 +0300 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <5444A2CF.2060609@redhat.com> References: <5437C6BB.7030109@redhat.com> <54418150.2000102@redhat.com> <5441906D.9030002@redhat.com> <5444A2CF.2060609@redhat.com> Message-ID: <20141020060951.GN5446@redhat.com> On Mon, 20 Oct 2014, Endi Sukma Dewata wrote: >On 10/17/2014 4:55 PM, Petr Vobornik wrote: >>On 17.10.2014 22:51, Endi Sukma Dewata wrote: >>>On 10/10/2014 6:44 AM, Petr Vobornik wrote: >>>>Web UI part of: >>>> >>>>https://fedorahosted.org/freeipa/ticket/4615 >>>> >>>>Patch 767 is a little refactoring needed for $pre_op(as plain object) >>>>work as intended even with instantiated objects + fixes a bug where >>>>Evented objects were not considered a framework object. >>>> >>>>Patch 768 switches tabs so we can hide it later >>>> >>>>Patch 769 hides the tab >>>> >>>>PAtch 770 is not really needed(would like to hear options whether to >>>>include it). It's in effect only if user somehow manages to open >>>>'Applies to hosts' facet for 'Default trust view'. Maybe redirection >>>>would be better - if we need to act. >>> >>>For some reason I don't see the Default Trust View in the >>>database/CLI/UI with a brand new server installation. Alexander said he >>>will investigate on Monday. >>> >>>The patches seem to be fine, I don't have any objections, feel free to >>>push. The missing Default Trust View is most likely unrelated to UI. >> >>It should be added when you run ipa-adtrust-install. > >OK, that fixed it. Some comments: > >1. Shouldn't the Default Trust View entry be added during the initial >installation? Although it's unlikely to conflict with user-defined >entries, it's kind of strange to add a 'built-in' entry after the >initial installation. It only can contain entries from the trusted domains. Adding it before we can serve trusted domains, i.e. before ipa-adtrust-install, makes it more complicated as users will not be able to add overrides to it. On the other hand, users will not be able to add entries there until actual trust is created so may be adding it as part of default configuration, even before ipa-adtrust-install isn't a big issue at all, if we would provide proper help/hint message. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Oct 20 06:13:44 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Oct 2014 09:13:44 +0300 Subject: [Freeipa-devel] [PATCH] slapi-nis: normalize memberUid search filter term for AD users In-Reply-To: <20141019203700.GC10559@hendrix.redhat.com> References: <20141009110116.GP2328@redhat.com> <20141019203700.GC10559@hendrix.redhat.com> Message-ID: <20141020061344.GO5446@redhat.com> On Sun, 19 Oct 2014, Jakub Hrozek wrote: >On Thu, Oct 09, 2014 at 02:01:16PM +0300, Alexander Bokovoy wrote: >> Hi, >> >> memberUid attribute has case-sensitive comparison defined but when we >> construct memberUid for AD users (coming through SSSD), they are >> normalized to lower case. Interestingly enough, 'uid' attribute has >> case-insensitive comparison. >> >> Work around the issue by low-casing the memberUid search term value when >> it is a fully-qualified name (user at domain), meaning we do ask for a SSSD >> user. >> >> This is the patch on top of my ID views support patch. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1130131 >> -- >> / Alexander Bokovoy > >The code reads good to me and passed some basic sanity testing..however, >I'be been unable to reproduce the issue, so I'm not sure this counts as >a full ACK... Thanks. I've already pushed the patch to slapi-nis and released 0.54 last week. To reproduce the issue you just need to have an AD group with an AD user searched in the compat tree with '(&(objectclass=posixgroup)(cn=Domain Admins at AD.DOMAIN))' and then search by memberUid with a case different from what is there, i.e. '(&(objectclass=posixgroup)(memberUid=Administrator at AD.DOMAIN))' -- given that memberUid will be set to a normalized name, administrator at ad.domain, the search will fail because memberUid comparison rule is case-sensitive in RFC2307 schema. -- / Alexander Bokovoy From mkosek at redhat.com Mon Oct 20 06:19:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 08:19:05 +0200 Subject: [Freeipa-devel] [PATCH] 482 Update contributors In-Reply-To: References: <5422B9C0.3030904@redhat.com> Message-ID: <5444A959.7040109@redhat.com> On 10/17/2014 09:18 PM, Gabe Alford wrote: > Not sure I can do this, but ACK. > > Gabe > > On Wed, Sep 24, 2014 at 6:32 AM, Martin Kosek wrote: > >> Add missing developers contributing to project git. Cancel "Past and >> Occcasional" section and merge the people in the right categories. >> >> Update .mailmap so that the Developer list can be easily re-generated. If you feel confident in some FreeIPA area, then you can obviously try and do the review! Thanks for ACKing this change though. I was mostly waiting before pushing it to see if there is some resistance, but apparently there is none. Pushed to: master: e296137853547cf62e7dc15476449a3b2f8d5a06 ipa-4-1: 3e94aee790b3272222d99ea27e9b305be887e982 Martin From mkosek at redhat.com Mon Oct 20 06:47:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 08:47:00 +0200 Subject: [Freeipa-devel] Dogtag 10.2.0 is now in Debian In-Reply-To: <54428A6E.8010406@ubuntu.com> References: <54428997.8060306@ubuntu.com> <54428A6E.8010406@ubuntu.com> Message-ID: <5444AFE4.2070103@redhat.com> On 10/18/2014 05:42 PM, Timo Aaltonen wrote: > On 18.10.2014 18:39, Timo Aaltonen wrote: >> >> Hi! >> >> I'm happy to announce that Dogtag (version 10.2.0) has finally entered >> Debian unstable repository this week. Assuming there won't be any nasty >> surprises, the next stable release ("Jessie") will include it. Many >> thanks to Ade Lee who did the first pass of packaging the long chain of >> dependencies, up to and including RESTEasy. > > forgot the link > https://packages.qa.debian.org/d/dogtag-pki.html > > there's a small update coming early next week > Thanks Timo for your great work! With Dogtag in Debian, we are getting wery close to including FreeIPA as well - looking forward to this day :-) As usual, let us know if you hit problems with porting FreeIPA there or extending our platform-independent code. Thanks, Martin From mkosek at redhat.com Mon Oct 20 08:13:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 10:13:17 +0200 Subject: [Freeipa-devel] [PATCH 0071] Display token type when viewing token In-Reply-To: <1413561780.4610.1.camel@redhat.com> References: <1413390721.6617.20.camel@redhat.com> <543FE5D2.5080808@redhat.com> <1413495441.3525.2.camel@redhat.com> <5440DA77.20306@redhat.com> <1413561780.4610.1.camel@redhat.com> Message-ID: <5444C41D.7090200@redhat.com> On 10/17/2014 06:03 PM, Nathaniel McCallum wrote: > On Fri, 2014-10-17 at 10:59 +0200, Martin Kosek wrote: >> On 10/16/2014 11:37 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-10-16 at 17:35 +0200, Martin Kosek wrote: >>>> On 10/15/2014 06:32 PM, Nathaniel McCallum wrote: >>>>> When viewing a token from the CLI or UI, the type of the token >>>>> should be displayed. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4563 >>>> >>>> Adding objectclass to default_attributes is unprecedented and something we >>>> should not do before release. It would also put objectclass attribute in >>>> default otptoken-* operations. >>>> >>>> What I would do in this case is to >>>> - keep default_attributes as is >>>> - add 'objectclass' to attrs_list in pre_callback >>>> - do whatever you already do with it in post_callback >>>> - remove the objectclass if it was not called for explicitly, e.g.: >>>> >>>> if not options.get('all', False) or options.get('pkey_only', False): >>>> entry_attrs.pop('objectclass', None) >>>> >>>> This approach is used for example in idrange.py so I would stick with it (I am >>>> not saying it is pretty, I am just saying our API should give consistent output). >>> >>> Fixed and tested. >>> >> >> Works fine in CLI, though I found couple more issues: >> >> 1) In type you return "HOTP" or "TOTP" while on the input you accept lowercased >> versions - is that OK? >> >> # ipa otptoken-add --type=TOTP --owner=fbar barbar >> ipa: ERROR: invalid 'type': must be one of 'totp', 'hotp' >> >> It just did not seem consistent to me. > > It was an oversight. In an ideal world, we'd have a case-insensitive > StrEnum type. For now, this patch accepts either fully lowercase or > fully uppercase. Display is always uppercase. > >> 2) You are suddenly adding camelcased attribute, compared to other places: >> >> + attrs_list.append("objectClass") > > Argh. Fixed. > >> 3) I do not see the OTP token type in Web UI OTP token view - is it just me or >> is it really missing? > > I think it is just you. The token type shows on the token details page, > not in the overview list of all tokens. Yeah, I found out it was just a bad Web UI build. All the issues are fixed. You just forgot to regenerate API.txt to get extended StrEnum, so I did it for you. ACK. Pushed to: master: 560606a9910b5f289cedbf341ea5a2cbd011aee2 ipa-4-1: 23878c36bbe7943b662e4c9f9dd438c083730c8f Martin From pvoborni at redhat.com Mon Oct 20 08:15:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 20 Oct 2014 10:15:14 +0200 Subject: [Freeipa-devel] [PATCH] 764 webui: management of keytab permissions In-Reply-To: <544157D1.5030000@redhat.com> References: <542C289A.6040301@redhat.com> <542EAECA.4050104@redhat.com> <54356BEF.2080600@redhat.com> <54411B5A.1070409@redhat.com> <544157D1.5030000@redhat.com> Message-ID: <5444C492.1020302@redhat.com> On 17.10.2014 19:54, Endi Sukma Dewata wrote: > On 10/17/2014 8:36 AM, Petr Vobornik wrote: >> Server part has been pushed. Version which matches its API attached. > > ACK. > Pushed to: master: d8f05d88414217c57aba0abbd43d1623fba477f8 ipa-4-1: 905238fbeef3730e9db5fbea540e4d0b416f52e5 -- Petr Vobornik From mkosek at redhat.com Mon Oct 20 08:22:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 10:22:12 +0200 Subject: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin In-Reply-To: <1413566540.4610.7.camel@redhat.com> References: <1410807911.4238.6.camel@redhat.com> <1411148369.18665.1.camel@redhat.com> <1411157743.18665.12.camel@redhat.com> <541CAD5E.3070008@redhat.com> <1411241988.3483.2.camel@redhat.com> <20140920173307.32e76f95@willson.usersys.redhat.com> <1411353227.3483.11.camel@redhat.com> <20140922093205.67d082c9@willson.usersys.redhat.com> <1412015453.18502.7.camel@redhat.com> <542EE264.5040308@redhat.com> <1412697608.3308.1.camel@redhat.com> <5435589C.8040701@redhat.com> <1412789453.9441.1.camel@redhat.com> <54359462.5080409@redhat.com> <1412798019.9441.8.camel@redhat.com> <20141008171923.6cf5eb65@willson.usersys.redhat.com> <1412806535.9441.18.camel@redhat.com> <543658E4.3010103@redhat.com> <1412869874.3262.2.camel@redhat.com> <5436BC59.2090008@redhat.com> <1413313274.6617.12.camel@redhat.com> <543E209F.9020709@redhat.com> <5440165F.8050902@redhat.com> <1413496413.3525.4.camel@redhat.com> <5440E9F7.9090901@redhat.com> <1413566540.4610.7.camel@redh! at.com> Message-ID: <5444C634.1050803@redhat.com> On 10/17/2014 07:22 PM, Nathaniel McCallum wrote: > On Fri, 2014-10-17 at 12:05 +0200, Martin Kosek wrote: >> On 10/16/2014 11:53 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-10-16 at 21:02 +0200, Martin Kosek wrote: >>>> On 10/15/2014 09:22 AM, Martin Kosek wrote: >>>>> On 10/14/2014 09:01 PM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-10-09 at 18:48 +0200, thierry bordaz wrote: >>>>>>> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: >>>>>>> >>>>>>>> On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: >>>>>>>>> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: >>>>>>>>> >>>>>>>>>> On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: >>>>>>>>>>> On Wed, 08 Oct 2014 15:53:39 -0400 >>>>>>>>>>> Nathaniel McCallum wrote: >>>>>>>>>>> >>>>>>>>>>>> As I understand my code, all servers will have csnD. Some servers will >>>>>>>>>>>> have valueB and others will have valueD, but valueB == valueD. >>>>>>>>>>>> >>>>>>>>>>>> We *never* discard a CSN. We only discard the counter/watermark mods >>>>>>>>>>>> in the replication operation. >>>>>>>>>>> What Thierry is saying is that the individual attributes in the entry >>>>>>>>>>> have associate the last CSN that modified them. Because you remove the >>>>>>>>>>> mods when ValueD == ValueB the counter attribute will not have the >>>>>>>>>>> associated CSN changed. But it doesn't really matter because the plugin >>>>>>>>>>> will always keep things consistent. >>>>>>>>>> Attached is a new version. It removes this optimization. If server X has >>>>>>>>>> valueB/csnB and receives valueD/csnD and valueB == valueD, the >>>>>>>>>> replication will be applied without any modification. However, if valueB >>>>>>>>>>> valueD and csnD > csnB, the counter mods will still be stripped. >>>>>>>>>> It also collapses the error check from betxnpre to bepre now that we >>>>>>>>>> have a fix for https://fedorahosted.org/389/ticket/47919 committed. The >>>>>>>>>> betxnpre functions are completely removed. Also, a dependency on 389 >>>>>>>>>> 1.3.3.4 (not yet released) is added. >>>>>>>>>> >>>>>>>>>> Nathaniel >>>>>>>>> Hello Nathaniel, >>>>>>>>> >>>>>>>>> For me the code is fine. Ack. >>>>>>>> New attached patch. >>>>>>>> >>>>>>>>> I have two minor comments: >>>>>>>>> * in preop_mod, when a direct update moves the counter >>>>>>>>> backward you send UNWILLING to perform with a message. >>>>>>>>> The message is allocated with slapi_ch_smprintf, you >>>>>>>>> may free it with slapi_ch_free_string (rather than >>>>>>>>> 'free'). >>>>>>>> Fixed. >>>>>>>> >>>>>>>>> * About this message, for example when you have these >>>>>>>>> MODS (I admit they make no sens): >>>>>>>>> >>>>>>>>> changetype: modify >>>>>>>>> ipatokenHOTPcounter: MOD_DELETE >>>>>>>>> - >>>>>>>>> ipatokenHOTPcounter: MOD_INCREMENT >>>>>>>>> >>>>>>>>> The returned message will be "Will not decrement >>>>>>>>> ipatokenHOTPcounter", because 'simulate' will return >>>>>>>>> 'COUNTER_UNSET+1'. >>>>>>>>> Is it the message you expected ? >>>>>>>> I changed the logic in simulate(). Please review it. >>>>>>>> >>>>>>>> Nathaniel >>>>>>>> >>>>>>> Hello Nathaniel, >>>>>>> >>>>>>> >>>>>>> The patch is ok for me. Ack. >>>>>> >>>>>> Since the ACK, the upstream 389 fix actually landed in 1.3.3.5. This >>>>>> patch changes nothing except the dependency version. I have tested it >>>>>> against the 1.3.3.5 build. >>>>>> >>>>>> Nathaniel >>>>> >>>>> Great! As soon as the new build land in Fedora 21 (and we add it to our Copr), >>>>> the patch can be pushed. >>>>> >>>>> Martin >>>> >>>> Ok, 1.3.3.5 is in koji and our Copr repo. >>> >>> +1 >>> >>>> I almost pushed the patch, but I just >>>> spotted you forgot to solve the upgrades - so NACK. >>> >>> You asked me to do that in another patch, not this one. :) >> >> I know, but that does not change the fact it is still missing :-) >> >>> >>>> "cn=IPA OTP Counter,cn=plugins,cn=config" plugin configuration also needs to be >>>> added in some update file. >>> >>> So I'm generally confused then. If we have to add the plugin config to >>> an update file, why bother creating >>> daemons/ipa-slapi-plugins/ipa-otp-counter/otp-counter-conf.ldif or >>> modifying ipaserver/install/dsinstance.py at all? Should these changes >>> be removed? >> >> Good question. Most LDAP update related changes are added to update plugins >> only. But plugin registration seemed to be still on 2 places, like 'cn=IPA >> Range-Check,cn=plugins,cn=config' registration. >> >> Up to you/additional developer discussion. > > Fixed. > > Also note that the same problem was present in the OTP Last Token plugin > (committed for 4.0). I have made a patch which fixes this as well: > > https://www.redhat.com/archives/freeipa-devel/2014-October/msg00358.html > > Nathaniel > Thanks, upgrade part works for me, ACK for that. Pushed to: master: 41bf0ba9403962140a75b28e0b279248ec101a0a ipa-4-1: 2f8dc3b6cc6cdee8230afe50cce694a762010b37 Martin From mkosek at redhat.com Mon Oct 20 08:23:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 10:23:03 +0200 Subject: [Freeipa-devel] [PATCH 0073] Configure IPA OTP Last Token plugin on upgrade In-Reply-To: <1413566315.4610.6.camel@redhat.com> References: <1413566315.4610.6.camel@redhat.com> Message-ID: <5444C667.1080900@redhat.com> On 10/17/2014 07:18 PM, Nathaniel McCallum wrote: > While working on the OTP Counter plugin I realized that the OTP Last > Token plugin never gets configured during upgrades. This patch fixes > this problem. Good catch! Works fine, ACK. Pushed to: master: 68825e7ac6e074ee62bc3787a718ae78ef29a88e ipa-4-1: 424b0999c8cfe7d6f1ad605f7db32ba069061475 ipa-4-0: 3ba4b4354c12a99536b43c28ef9a41adf7e3cde5 Martin From sbose at redhat.com Mon Oct 20 08:43:07 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 20 Oct 2014 10:43:07 +0200 Subject: [Freeipa-devel] [PATCH] 131-132 extdom: add support for sss_nss_getorigbyname() In-Reply-To: <20141019200429.GB10559@hendrix.redhat.com> References: <20141017095344.GA9734@localhost.localdomain> <20141019200429.GB10559@hendrix.redhat.com> Message-ID: <20141020084307.GE9734@localhost.localdomain> On Sun, Oct 19, 2014 at 10:04:29PM +0200, Jakub Hrozek wrote: > On Fri, Oct 17, 2014 at 11:53:44AM +0200, Sumit Bose wrote: > > Hi, > > > > the first patch replaces sss_nss_getsidbyname() by > > sss_nss_getorigbyname() for the new version of the extdom interface. > > The new call returns more data about the original object and allows the > > IPA client to have the same information about the object in the SSSD > > cache as the IPA servers. > > > > The second patch just removes an obsolete dependency. > > > > bye, > > Sumit > > Hi, > > I was unable to send the patches through Coverity, the RH server seems > to be having issues. I'll wait until tomorrow, if the problems persist, > we'll just skip Coverity and fix any potential problems post-push. > > > From 928c04c35601b7bc1c57c1320e4a746abc35e947 Mon Sep 17 00:00:00 2001 > > From: Sumit Bose > > Date: Fri, 10 Oct 2014 10:56:37 +0200 > > Subject: [PATCH 131/132] extdom: add support for sss_nss_getorigbyname() > > [...] > > > @@ -576,13 +613,14 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, > > enum sss_id_type id_type; > > size_t buf_len; > > char *buf = NULL; > > + struct sss_nss_kv *kv_list; > > Please set kv_list to NULL here, you're freeing the pointer > unconditionally in the done handler, but in some cases (request_type == > REQ_SIMPLE) kv_list is not set at all. Thank you for the review. I fixed it here and at the two other places. Since sss_nss_getorigbyname() will only be available in the upcoming SSSD release I added 'BuildRequires: libsss_nss_idmap-devel >= 1.12.2' to freeipa.spec.in. New version attached. bye, Sumit -------------- next part -------------- From a11f42dec7dc1aa1b8b4aef11fa24ce3dc60a109 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 10 Oct 2014 10:56:37 +0200 Subject: [PATCH 131/132] extdom: add support for sss_nss_getorigbyname() --- .../ipa-extdom-extop/ipa_extdom_common.c | 167 +++++++++++++++++---- freeipa.spec.in | 2 +- 2 files changed, 136 insertions(+), 33 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index d1d214ae769946a89ffe1702382e5db70035fdac..df04347e3d36b33ca0a4ea2391f60d97b75a97bf 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -254,6 +254,34 @@ static int get_user_grouplist(const char *name, gid_t gid, return LDAP_SUCCESS; } +static int add_kv_list(BerElement *ber, struct sss_nss_kv *kv_list) +{ + size_t c; + int ret; + const char *single_value_string_array[] = {NULL, NULL}; + + ret = ber_printf(ber,"{"); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + for (c = 0; kv_list[c].key != NULL; c++) { + single_value_string_array[0] = kv_list[c].value; + ret = ber_printf(ber,"{s{v}}", kv_list[c].key, + single_value_string_array); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + } + + ret = ber_printf(ber,"}"); + if (ret == -1) { + return LDAP_OPERATIONS_ERROR; + } + + return LDAP_SUCCESS; +} + static int pack_ber_sid(const char *sid, struct berval **berval) { BerElement *ber = NULL; @@ -285,7 +313,7 @@ static int pack_ber_user(enum response_types response_type, const char *domain_name, const char *user_name, uid_t uid, gid_t gid, const char *gecos, const char *homedir, - const char *shell, const char *sid_str, + const char *shell, struct sss_nss_kv *kv_list, struct berval **berval) { BerElement *ber = NULL; @@ -299,7 +327,6 @@ static int pack_ber_user(enum response_types response_type, size_t c; char *locat; char *short_user_name = NULL; - const char *single_value_string_array[] = {NULL, NULL}; short_user_name = strdup(user_name); if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { @@ -370,12 +397,11 @@ static int pack_ber_user(enum response_types response_type, goto done; } - single_value_string_array[0] = sid_str; - ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, - single_value_string_array); - if (ret == -1) { - ret = LDAP_OPERATIONS_ERROR; - goto done; + if (kv_list != NULL) { + ret = add_kv_list(ber, kv_list); + if (ret != LDAP_SUCCESS) { + goto done; + } } } @@ -402,7 +428,7 @@ done: static int pack_ber_group(enum response_types response_type, const char *domain_name, const char *group_name, - gid_t gid, char **members, const char *sid_str, + gid_t gid, char **members, struct sss_nss_kv *kv_list, struct berval **berval) { BerElement *ber = NULL; @@ -410,7 +436,6 @@ static int pack_ber_group(enum response_types response_type, size_t c; char *locat; char *short_group_name = NULL; - const char *single_value_string_array[] = {NULL, NULL}; short_group_name = strdup(group_name); if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { @@ -455,12 +480,11 @@ static int pack_ber_group(enum response_types response_type, goto done; } - single_value_string_array[0] = sid_str; - ret = ber_printf(ber,"{{s{v}}}", SSSD_SYSDB_SID_STR, - single_value_string_array); - if (ret == -1) { - ret = LDAP_OPERATIONS_ERROR; - goto done; + if (kv_list != NULL) { + ret = add_kv_list(ber, kv_list); + if (ret != LDAP_SUCCESS) { + goto done; + } } } @@ -521,13 +545,14 @@ static int handle_uid_request(enum request_types request_type, uid_t uid, enum sss_id_type id_type; size_t buf_len; char *buf = NULL; + struct sss_nss_kv *kv_list = NULL; ret = get_buffer(&buf_len, &buf); if (ret != LDAP_SUCCESS) { return ret; } - if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + if (request_type == REQ_SIMPLE) { ret = sss_nss_getsidbyid(uid, &sid_str, &id_type); if (ret != 0 || !(id_type == SSS_ID_TYPE_UID || id_type == SSS_ID_TYPE_BOTH)) { @@ -538,9 +563,7 @@ static int handle_uid_request(enum request_types request_type, uid_t uid, } goto done; } - } - if (request_type == REQ_SIMPLE) { ret = pack_ber_sid(sid_str, berval); } else { ret = getpwuid_r(uid, &pwd, buf, buf_len, &pwd_result); @@ -553,14 +576,28 @@ static int handle_uid_request(enum request_types request_type, uid_t uid, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(pwd.pw_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER : RESP_USER_GROUPLIST), domain_name, pwd.pw_name, pwd.pw_uid, pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, - pwd.pw_shell, sid_str, berval); + pwd.pw_shell, kv_list, berval); } done: + sss_nss_free_kv(kv_list); free(sid_str); free(buf); return ret; @@ -576,13 +613,14 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, enum sss_id_type id_type; size_t buf_len; char *buf = NULL; + struct sss_nss_kv *kv_list = NULL; ret = get_buffer(&buf_len, &buf); if (ret != LDAP_SUCCESS) { return ret; } - if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + if (request_type == REQ_SIMPLE) { ret = sss_nss_getsidbyid(gid, &sid_str, &id_type); if (ret != 0 || id_type != SSS_ID_TYPE_GID) { if (ret == ENOENT) { @@ -592,9 +630,7 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, } goto done; } - } - if (request_type == REQ_SIMPLE) { ret = pack_ber_sid(sid_str, berval); } else { ret = getgrgid_r(gid, &grp, buf, buf_len, &grp_result); @@ -607,13 +643,27 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(grp.gr_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_GID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP : RESP_GROUP_MEMBERS), domain_name, grp.gr_name, grp.gr_gid, - grp.gr_mem, sid_str, berval); + grp.gr_mem, kv_list, berval); } done: + sss_nss_free_kv(kv_list); free(sid_str); free(buf); return ret; @@ -634,6 +684,7 @@ static int handle_sid_request(enum request_types request_type, const char *sid, size_t buf_len; char *buf = NULL; enum sss_id_type id_type; + struct sss_nss_kv *kv_list = NULL; ret = sss_nss_getnamebysid(sid, &fq_name, &id_type); if (ret != 0) { @@ -682,11 +733,24 @@ static int handle_sid_request(enum request_types request_type, const char *sid, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(pwd.pw_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER : RESP_USER_GROUPLIST), domain_name, pwd.pw_name, pwd.pw_uid, pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, - pwd.pw_shell, sid, berval); + pwd.pw_shell, kv_list, berval); break; case SSS_ID_TYPE_GID: ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); @@ -700,10 +764,23 @@ static int handle_sid_request(enum request_types request_type, const char *sid, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(grp.gr_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_GID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP : RESP_GROUP_MEMBERS), domain_name, grp.gr_name, grp.gr_gid, - grp.gr_mem, sid, berval); + grp.gr_mem, kv_list, berval); break; default: ret = LDAP_OPERATIONS_ERROR; @@ -711,6 +788,7 @@ static int handle_sid_request(enum request_types request_type, const char *sid, } done: + sss_nss_free_kv(kv_list); free(fq_name); free(object_name); free(domain_name); @@ -733,6 +811,7 @@ static int handle_name_request(enum request_types request_type, enum sss_id_type id_type; size_t buf_len; char *buf = NULL; + struct sss_nss_kv *kv_list = NULL; ret = asprintf(&fq_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR, domain_name); @@ -743,7 +822,7 @@ static int handle_name_request(enum request_types request_type, goto done; } - if (request_type == REQ_SIMPLE || request_type == REQ_FULL_WITH_GROUPS) { + if (request_type == REQ_SIMPLE) { ret = sss_nss_getsidbyname(fq_name, &sid_str, &id_type); if (ret != 0) { if (ret == ENOENT) { @@ -751,11 +830,9 @@ static int handle_name_request(enum request_types request_type, } else { ret = LDAP_OPERATIONS_ERROR; } - goto done; + goto done; } - } - if (request_type == REQ_SIMPLE) { ret = pack_ber_sid(sid_str, berval); } else { ret = get_buffer(&buf_len, &buf); @@ -772,11 +849,23 @@ static int handle_name_request(enum request_types request_type, } if (pwd_result != NULL) { + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(pwd.pw_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_UID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } ret = pack_ber_user((request_type == REQ_FULL ? RESP_USER : RESP_USER_GROUPLIST), domain_name, pwd.pw_name, pwd.pw_uid, pwd.pw_gid, pwd.pw_gecos, pwd.pw_dir, - pwd.pw_shell, sid_str, berval); + pwd.pw_shell, kv_list, berval); } else { /* no user entry found */ ret = getgrnam_r(fq_name, &grp, buf, buf_len, &grp_result); if (ret != 0) { @@ -789,14 +878,28 @@ static int handle_name_request(enum request_types request_type, goto done; } + if (request_type == REQ_FULL_WITH_GROUPS) { + ret = sss_nss_getorigbyname(grp.gr_name, &kv_list, &id_type); + if (ret != 0 || !(id_type == SSS_ID_TYPE_GID + || id_type == SSS_ID_TYPE_BOTH)) { + if (ret == ENOENT) { + ret = LDAP_NO_SUCH_OBJECT; + } else { + ret = LDAP_OPERATIONS_ERROR; + } + goto done; + } + } + ret = pack_ber_group((request_type == REQ_FULL ? RESP_GROUP : RESP_GROUP_MEMBERS), domain_name, grp.gr_name, grp.gr_gid, - grp.gr_mem, sid_str, berval); + grp.gr_mem, kv_list, berval); } } done: + sss_nss_free_kv(kv_list); free(fq_name); free(sid_str); free(buf); diff --git a/freeipa.spec.in b/freeipa.spec.in index e310203727acfd25e4f2402fdcdb6333c3151cc0..5ac79a051f5b9aa1288f07bb96fed77b283a560f 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -79,7 +79,7 @@ BuildRequires: python-dns >= 1.11.1 BuildRequires: m2crypto BuildRequires: check BuildRequires: libsss_idmap-devel -BuildRequires: libsss_nss_idmap-devel +BuildRequires: libsss_nss_idmap-devel >= 1.12.2 BuildRequires: java-headless BuildRequires: rhino BuildRequires: libverto-devel -- 1.8.5.3 -------------- next part -------------- From 1b37cf1b0b66f3dfd7aa44f99b61b5eaf7e746ec Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 15 Oct 2014 16:21:53 +0200 Subject: [PATCH 132/132] extdom: remove unused dependency to libsss_idmap --- daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am | 3 --- daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h | 2 -- 2 files changed, 5 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am index 7099a988878e2bc0cf840eab0b14fa9f40805a51..0008476796f5b20f62f2c32e7b291b787fa7a6fc 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am @@ -15,7 +15,6 @@ AM_CPPFLAGS = \ -DDATADIR=\""$(datadir)"\" \ $(LDAP_CFLAGS) \ $(WARN_CFLAGS) \ - $(SSSIDMAP_CFLAGS) \ $(SSSNSSIDMAP_CFLAGS) \ $(NULL) @@ -33,7 +32,6 @@ libipa_extdom_extop_la_LDFLAGS = -avoid-version libipa_extdom_extop_la_LIBADD = \ $(LDAP_LIBS) \ - $(SSSIDMAP_LIBS) \ $(SSSNSSIDMAP_LIBS) \ $(NULL) @@ -54,7 +52,6 @@ extdom_tests_LDADD = \ $(CHECK_LIBS) \ $(LDAP_LIBS) \ $(DIRSRV_LIBS) \ - $(SSSIDMAP_LIBS) \ $(SSSNSSIDMAP_LIBS) \ $(NULL) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h index 90f8390d871a698dc00ef56c41be0749eaa13424..56ca5009b1aa427f6c059b78ac392c768e461e2e 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h @@ -60,7 +60,6 @@ #include #include -#include #include #define EXOP_EXTDOM_OID "2.16.840.1.113730.3.8.10.4" @@ -157,7 +156,6 @@ struct domain_info { char *flat_name; char *sid; char *guid; - struct sss_idmap_ctx *idmap_ctx; }; struct pwd_grp { -- 1.8.5.3 From tscherf at redhat.com Mon Oct 20 09:57:24 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Mon, 20 Oct 2014 11:57:24 +0200 Subject: [Freeipa-devel] [PATCH 0001] migrate-ds: Fix to exclude attrs with uppercase characters from migration Message-ID: <20141020095724.GM27642@tscherf.redhat.com> -------------- next part -------------- >From 6dd24dc6f08f01997bf3d7ccc06d77a7fd239e61 Mon Sep 17 00:00:00 2001 From: Thorsten Scherf Date: Mon, 20 Oct 2014 11:47:18 +0200 Subject: [PATCH] Fix entry_attr case to make migrate-ds work again Migration of a OpenLDAP based directory to FreeIPA with some objectclasses removed failed because of --user-ignore-attribute didn't work. Fixed that by making LDAPEntry object entry_attry lowercased. https://fedorahosted.org/freeipa/ticket/4620 --- ipalib/plugins/migration.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/migration.py b/ipalib/plugins/migration.py index 6b630a464f0be163e82de95afe3a74b22889574b..2500186d26d16d14b7b87dd6902ea385a40ca87b 100644 --- a/ipalib/plugins/migration.py +++ b/ipalib/plugins/migration.py @@ -197,7 +197,7 @@ def _pre_migrate_user(ldap, pkey, dn, entry_attrs, failed, config, ctx, **kwargs # do not migrate all attributes for attr in entry_attrs.keys(): - if attr in attr_blacklist: + if attr.lower() in attr_blacklist: del entry_attrs[attr] # do not migrate all object classes -- 1.9.3 From pvoborni at redhat.com Mon Oct 20 10:06:38 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 20 Oct 2014 12:06:38 +0200 Subject: [Freeipa-devel] [PATCH] 765 webui: allow --force in dnszone-mod and dnsrecord-add In-Reply-To: <54416809.10705@redhat.com> References: <542ED352.6020806@redhat.com> <54416809.10705@redhat.com> Message-ID: <5444DEAE.70304@redhat.com> On 17.10.2014 21:03, Endi Sukma Dewata wrote: > On 10/3/2014 11:48 AM, Petr Vobornik wrote: >> Allow to use --force when changing authoritative nameserver address in >> DNS zone. >> >> Same for dnsrecord-add for NS record. >> >> https://fedorahosted.org/freeipa/ticket/4573 > > ACK, just some minor issues: Pushed to: master: 741c31c2b428cf979db6a9d7cd91f88e5f247fb4 ipa-4-1: 502bf5671306b873c36e12bc88139bb5a42f8657 > > 1. The 'Check DNS' button might be interpreted as 'check the DNS without > updating the DNS zone' but in fact it also updates the DNS zone. I'd > suggest using a regular 'Update' button, but add a 'Force' checkbox. > > 2. A 'Force' checkbox would be more consistent with other dialog boxes > than 'Skip DNS check' checkbox. Also, there might be other checks being > done, not just DNS check. The same behavior is in Realm Domains update. https://fedorahosted.org/freeipa/ticket/4648 > > 3. When the authoritative nameserver is updated I get this message: > > semantic of '--name-server' option was changed: the option is used > only for setting up the SOA MNAME attribute. > > To edit NS record(s) in zone apex, use command 'dnsrecord-mod [zone] > @ --ns-rec=nameserver'. > > I think the message shouldn't be displayed because it's irrelevant to > the UI, a bit too long to read, and not enough time to read it before it > disappears. Overall I agree. But it's not completely irrelevant since the main message: "behavior has changed" is there. The CLI commands shouldn't be there. https://fedorahosted.org/freeipa/ticket/4647 > > 4. Server issue. I don't see a --force option in the dnsrecord-add help > message. I wonder why --force in dnsrecord-add has 'no_option' flag. > >> Note: dnsrecord-mod doesn't support --force option to skip dns >> resolution when changing NS record. Question is whether it should be >> added, or if 'edit' button should be hidden in web ui to force >> dnsrecord-add + dnsrecord-del combo instead of dnsrecord-mod, or if it's >> good as is. >> Note2: -add + -del combo has better UX than -del + -add if there is only >> one value in the dns record. > > I think if we're keeping the dnsrecord-mod CLI it should have a --force > option too regardless whether the UI uses -mod or -add/del. Once that's > added, the Edit dialog should provide a checkbox for that too. > > The Edit dialog in DNS records is useful to edit records that consist of > multiple fields (e.g. MX, SRV), so I think we should keep that, but > internally it could be implemented either using -add/del or -mod, > whichever works better. > I also think that dnsrecord-mod should have --force option. -- Petr Vobornik From tbabej at redhat.com Mon Oct 20 10:19:22 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Oct 2014 12:19:22 +0200 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <20141020060951.GN5446@redhat.com> References: <5437C6BB.7030109@redhat.com> <54418150.2000102@redhat.com> <5441906D.9030002@redhat.com> <5444A2CF.2060609@redhat.com> <20141020060951.GN5446@redhat.com> Message-ID: <5444E1AA.10000@redhat.com> On 10/20/2014 08:09 AM, Alexander Bokovoy wrote: > On Mon, 20 Oct 2014, Endi Sukma Dewata wrote: >> On 10/17/2014 4:55 PM, Petr Vobornik wrote: >>> On 17.10.2014 22:51, Endi Sukma Dewata wrote: >>>> On 10/10/2014 6:44 AM, Petr Vobornik wrote: >>>>> Web UI part of: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4615 >>>>> >>>>> Patch 767 is a little refactoring needed for $pre_op(as plain object) >>>>> work as intended even with instantiated objects + fixes a bug where >>>>> Evented objects were not considered a framework object. >>>>> >>>>> Patch 768 switches tabs so we can hide it later >>>>> >>>>> Patch 769 hides the tab >>>>> >>>>> PAtch 770 is not really needed(would like to hear options whether to >>>>> include it). It's in effect only if user somehow manages to open >>>>> 'Applies to hosts' facet for 'Default trust view'. Maybe redirection >>>>> would be better - if we need to act. >>>> >>>> For some reason I don't see the Default Trust View in the >>>> database/CLI/UI with a brand new server installation. Alexander >>>> said he >>>> will investigate on Monday. >>>> >>>> The patches seem to be fine, I don't have any objections, feel free to >>>> push. The missing Default Trust View is most likely unrelated to UI. >>> >>> It should be added when you run ipa-adtrust-install. >> >> OK, that fixed it. Some comments: >> >> 1. Shouldn't the Default Trust View entry be added during the initial >> installation? Although it's unlikely to conflict with user-defined >> entries, it's kind of strange to add a 'built-in' entry after the >> initial installation. > It only can contain entries from the trusted domains. Adding it before > we can serve trusted domains, i.e. before ipa-adtrust-install, makes > it more complicated as users will not be able to add overrides to it. > > On the other hand, users will not be able to add entries there until > actual trust is created so may be adding it as part of default > configuration, even before ipa-adtrust-install isn't a big issue at all, > if we would provide proper help/hint message. > I think the reasoning behind adding it as part of adtrust-install was the following scenario, which can happen for IPA installs without adtrust component. 1.) User installs IPA 2.) Tries to override some IPA users 3.) Sees "Default Trust View" and is confused, since he has no trusts or no AD in his environment We actually add more built-in entries during the adtrust-install, e.g. "Default SMB group". -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pvoborni at redhat.com Mon Oct 20 10:26:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 20 Oct 2014 12:26:27 +0200 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <5444A2CF.2060609@redhat.com> References: <5437C6BB.7030109@redhat.com> <54418150.2000102@redhat.com> <5441906D.9030002@redhat.com> <5444A2CF.2060609@redhat.com> Message-ID: <5444E353.8020809@redhat.com> On 20.10.2014 07:51, Endi Sukma Dewata wrote: > On 10/17/2014 4:55 PM, Petr Vobornik wrote: >> On 17.10.2014 22:51, Endi Sukma Dewata wrote: >>> On 10/10/2014 6:44 AM, Petr Vobornik wrote: >>>> Web UI part of: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4615 >>>> > > 2. The description field in the Settings page for Default Trust View > should be read-only since the entry cannot be modified. > > 3. The Delete action in the Settings page for Default Trust View should > not exist since the entry cannot be deleted. Probably the Actions > drop-down list can be disabled. wrt #2, #3, I wish that one day it will be reflected in attributelevelrights and entrylevelrights. Or rather API equivalents since these two are very LDAP specific. > > 4. I think this was discussed before, but I'm just not sure what the > plan is. The current facet tab titles seem to be redundant since we > already have facet group headers that say " overrides/applies > to". Are we going to change "User/Group ID overrides" into > "Users/Groups" and "Applied to hosts" into "Hosts"? Neglection from my part. The tab labels were not changed after adding of tab group label. https://fedorahosted.org/freeipa/ticket/4650 > > No major issue. ACK. > Pushed to master: * 896d47c92f9e7f8322456b68b767bf78f0897b0a webui: make Evented a part of base IPA.object * 2e27f1ee69761b147fba50337424acabfd065a93 webui: change order of idview's facet groups * d3f46d4e78cd871b4ab951d57ce309cd9997bea1 webui: hide applied to hosts tab for Default Trust View * 01a9e7ef9e58e14fdb362bdd61b22d667d773052 webui: hide (un)apply buttons for Default Trust View ipa-4-1: * b05f39510cf38f837fa2ae64ff13692b19f4895e webui: make Evented a part of base IPA.object * 2046470be501af10c5901838b9fc6fba93017d38 webui: change order of idview's facet groups * 04a3dad96d60a422cf11486bf788262931d00c2f webui: hide applied to hosts tab for Default Trust View * 3485c6e689eb93184704287b678dbe07135cc46f webui: hide (un)apply buttons for Default Trust View -- Petr Vobornik From pvoborni at redhat.com Mon Oct 20 10:29:51 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 20 Oct 2014 12:29:51 +0200 Subject: [Freeipa-devel] [PATCH] 771 webui: do not offer ipa users to Default Trust View In-Reply-To: <5444A2D3.4000700@redhat.com> References: <5437C6C1.9070007@redhat.com> <54418157.1080807@redhat.com> <5443BB0B.70403@redhat.com> <5444A2D3.4000700@redhat.com> Message-ID: <5444E41F.2050401@redhat.com> On 20.10.2014 07:51, Endi Sukma Dewata wrote: > On 10/19/2014 8:22 AM, Petr Vobornik wrote: >> On 17.10.2014 22:51, Endi Sukma Dewata wrote: >>> On 10/10/2014 6:45 AM, Petr Vobornik wrote: >>>> https://fedorahosted.org/freeipa/ticket/4616 >>> >>> This patch does not apply. Does it depend on another patch? >>> >> >> rebased version attached. Should be applicable on master, ipa-4-1 and >> patchset 767-770. > > ACK. > Pushed to: master: df1ed11b480834a1b35c99299195482452350ded ipa-4-1: 34fb9f02ef9cd0aa650c2f2b95cd76ee69854824 -- Petr Vobornik From abokovoy at redhat.com Mon Oct 20 10:30:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Oct 2014 13:30:34 +0300 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <5444E1AA.10000@redhat.com> References: <5437C6BB.7030109@redhat.com> <54418150.2000102@redhat.com> <5441906D.9030002@redhat.com> <5444A2CF.2060609@redhat.com> <20141020060951.GN5446@redhat.com> <5444E1AA.10000@redhat.com> Message-ID: <20141020103034.GQ5446@redhat.com> On Mon, 20 Oct 2014, Tomas Babej wrote: > >On 10/20/2014 08:09 AM, Alexander Bokovoy wrote: >> On Mon, 20 Oct 2014, Endi Sukma Dewata wrote: >>> On 10/17/2014 4:55 PM, Petr Vobornik wrote: >>>> On 17.10.2014 22:51, Endi Sukma Dewata wrote: >>>>> On 10/10/2014 6:44 AM, Petr Vobornik wrote: >>>>>> Web UI part of: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4615 >>>>>> >>>>>> Patch 767 is a little refactoring needed for $pre_op(as plain object) >>>>>> work as intended even with instantiated objects + fixes a bug where >>>>>> Evented objects were not considered a framework object. >>>>>> >>>>>> Patch 768 switches tabs so we can hide it later >>>>>> >>>>>> Patch 769 hides the tab >>>>>> >>>>>> PAtch 770 is not really needed(would like to hear options whether to >>>>>> include it). It's in effect only if user somehow manages to open >>>>>> 'Applies to hosts' facet for 'Default trust view'. Maybe redirection >>>>>> would be better - if we need to act. >>>>> >>>>> For some reason I don't see the Default Trust View in the >>>>> database/CLI/UI with a brand new server installation. Alexander >>>>> said he >>>>> will investigate on Monday. >>>>> >>>>> The patches seem to be fine, I don't have any objections, feel free to >>>>> push. The missing Default Trust View is most likely unrelated to UI. >>>> >>>> It should be added when you run ipa-adtrust-install. >>> >>> OK, that fixed it. Some comments: >>> >>> 1. Shouldn't the Default Trust View entry be added during the initial >>> installation? Although it's unlikely to conflict with user-defined >>> entries, it's kind of strange to add a 'built-in' entry after the >>> initial installation. >> It only can contain entries from the trusted domains. Adding it before >> we can serve trusted domains, i.e. before ipa-adtrust-install, makes >> it more complicated as users will not be able to add overrides to it. >> >> On the other hand, users will not be able to add entries there until >> actual trust is created so may be adding it as part of default >> configuration, even before ipa-adtrust-install isn't a big issue at all, >> if we would provide proper help/hint message. >> > >I think the reasoning behind adding it as part of adtrust-install was >the following scenario, which can happen for IPA installs without >adtrust component. > >1.) User installs IPA >2.) Tries to override some IPA users >3.) Sees "Default Trust View" and is confused, since he has no trusts or >no AD in his environment Even after ipa-adtrust-install run you would still not be able to resolve AD users unless trust is added. It does not mean we should move creating 'Default Trust View' to the first trust. What about filtering out 'Default Trust View' if no trusts are in place? This would be a bit problematic for the case when you had trusts and deleted them and currently have none of them but overrides are in place, but at least it would be consistent -- you don't see default view and you are not able to add there anything. However, it raises another question: if no trusts exist right now but there are some AD user overrides in any view, how would we display them? We cannot resolve SIDs to names at this point so overrides will look ugly anyway. We can use ipaOriginalUid for users but we don't have anything like that for groups. >We actually add more built-in entries during the adtrust-install, e.g. >"Default SMB group". We don't use these entries in the UI, so they don't create any specific issue. -- / Alexander Bokovoy From tbabej at redhat.com Mon Oct 20 10:46:02 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Oct 2014 12:46:02 +0200 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <20141020103034.GQ5446@redhat.com> References: <5437C6BB.7030109@redhat.com> <54418150.2000102@redhat.com> <5441906D.9030002@redhat.com> <5444A2CF.2060609@redhat.com> <20141020060951.GN5446@redhat.com> <5444E1AA.10000@redhat.com> <20141020103034.GQ5446@redhat.com> Message-ID: <5444E7EA.2020701@redhat.com> On 10/20/2014 12:30 PM, Alexander Bokovoy wrote: > On Mon, 20 Oct 2014, Tomas Babej wrote: >> >> On 10/20/2014 08:09 AM, Alexander Bokovoy wrote: >>> On Mon, 20 Oct 2014, Endi Sukma Dewata wrote: >>>> On 10/17/2014 4:55 PM, Petr Vobornik wrote: >>>>> On 17.10.2014 22:51, Endi Sukma Dewata wrote: >>>>>> On 10/10/2014 6:44 AM, Petr Vobornik wrote: >>>>>>> Web UI part of: >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4615 >>>>>>> >>>>>>> Patch 767 is a little refactoring needed for $pre_op(as plain >>>>>>> object) >>>>>>> work as intended even with instantiated objects + fixes a bug where >>>>>>> Evented objects were not considered a framework object. >>>>>>> >>>>>>> Patch 768 switches tabs so we can hide it later >>>>>>> >>>>>>> Patch 769 hides the tab >>>>>>> >>>>>>> PAtch 770 is not really needed(would like to hear options >>>>>>> whether to >>>>>>> include it). It's in effect only if user somehow manages to open >>>>>>> 'Applies to hosts' facet for 'Default trust view'. Maybe >>>>>>> redirection >>>>>>> would be better - if we need to act. >>>>>> >>>>>> For some reason I don't see the Default Trust View in the >>>>>> database/CLI/UI with a brand new server installation. Alexander >>>>>> said he >>>>>> will investigate on Monday. >>>>>> >>>>>> The patches seem to be fine, I don't have any objections, feel >>>>>> free to >>>>>> push. The missing Default Trust View is most likely unrelated to UI. >>>>> >>>>> It should be added when you run ipa-adtrust-install. >>>> >>>> OK, that fixed it. Some comments: >>>> >>>> 1. Shouldn't the Default Trust View entry be added during the initial >>>> installation? Although it's unlikely to conflict with user-defined >>>> entries, it's kind of strange to add a 'built-in' entry after the >>>> initial installation. >>> It only can contain entries from the trusted domains. Adding it before >>> we can serve trusted domains, i.e. before ipa-adtrust-install, makes >>> it more complicated as users will not be able to add overrides to it. >>> >>> On the other hand, users will not be able to add entries there until >>> actual trust is created so may be adding it as part of default >>> configuration, even before ipa-adtrust-install isn't a big issue at >>> all, >>> if we would provide proper help/hint message. >>> >> >> I think the reasoning behind adding it as part of adtrust-install was >> the following scenario, which can happen for IPA installs without >> adtrust component. >> >> 1.) User installs IPA >> 2.) Tries to override some IPA users >> 3.) Sees "Default Trust View" and is confused, since he has no trusts or >> no AD in his environment > Even after ipa-adtrust-install run you would still not be able to > resolve AD users unless trust is added. It does not mean we should move > creating 'Default Trust View' to the first trust. > > What about filtering out 'Default Trust View' if no trusts are in place? > This would be a bit problematic for the case when you had trusts and > deleted them and currently have none of them but overrides are in place, > but at least it would be consistent -- you don't see default view and > you are not able to add there anything. > > However, it raises another question: if no trusts exist right now but > there are some AD user overrides in any view, how would we display them? > We cannot resolve SIDs to names at this point so overrides will look > ugly anyway. We can use ipaOriginalUid for users but we don't have > anything like that for groups. I think we should fail in the trust-del if there are any overrides tied to this particular trust, unless --forced (which should be used only for recreation of the trust). Currently, we rely on resolving the user/group name to do any operation on the ID override, so having the trust removed, you'd have to use LDAP directly to remove the entries. > >> We actually add more built-in entries during the adtrust-install, e.g. >> "Default SMB group". > We don't use these entries in the UI, so they don't create any specific > issue. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From abokovoy at redhat.com Mon Oct 20 10:51:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Oct 2014 13:51:49 +0300 Subject: [Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View In-Reply-To: <5444E7EA.2020701@redhat.com> References: <5437C6BB.7030109@redhat.com> <54418150.2000102@redhat.com> <5441906D.9030002@redhat.com> <5444A2CF.2060609@redhat.com> <20141020060951.GN5446@redhat.com> <5444E1AA.10000@redhat.com> <20141020103034.GQ5446@redhat.com> <5444E7EA.2020701@redhat.com> Message-ID: <20141020105149.GR5446@redhat.com> On Mon, 20 Oct 2014, Tomas Babej wrote: >> What about filtering out 'Default Trust View' if no trusts are in place? >> This would be a bit problematic for the case when you had trusts and >> deleted them and currently have none of them but overrides are in place, >> but at least it would be consistent -- you don't see default view and >> you are not able to add there anything. >> >> However, it raises another question: if no trusts exist right now but >> there are some AD user overrides in any view, how would we display them? >> We cannot resolve SIDs to names at this point so overrides will look >> ugly anyway. We can use ipaOriginalUid for users but we don't have >> anything like that for groups. > >I think we should fail in the trust-del if there are any overrides tied >to this particular trust, unless --forced (which should be used only for >recreation of the trust). I'd love to see a mass-removal tool per trusted domain then. Also, removing trust does not mean overrides become invalid, only that they become not editable or visible. They will not be enforced because trust is not in place anyway. >Currently, we rely on resolving the user/group name to do any operation >on the ID override, so having the trust removed, you'd have to use LDAP >directly to remove the entries. It should be fine to remove the trust, just that our code should be able to deal with domain SIDs for mass removal of ID overrides. -- / Alexander Bokovoy From tbabej at redhat.com Mon Oct 20 11:17:06 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Oct 2014 13:17:06 +0200 Subject: [Freeipa-devel] [PATCH 0284] Bump 4.2 development version to 4.1.99 Message-ID: <5444EF32.9040601@redhat.com> Hi, we need to bump the version in master since 389-ds-base already conflicts with FreeIPA < 4.0.3. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0284-Bump-4.2-development-version-to-4.1.99.patch Type: text/x-patch Size: 805 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 20 11:22:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 13:22:45 +0200 Subject: [Freeipa-devel] [PATCH 0284] Bump 4.2 development version to 4.1.99 In-Reply-To: <5444EF32.9040601@redhat.com> References: <5444EF32.9040601@redhat.com> Message-ID: <5444F085.9030009@redhat.com> On 10/20/2014 01:17 PM, Tomas Babej wrote: > Hi, > > we need to bump the version in master since 389-ds-base already > conflicts with FreeIPA < 4.0.3. Right. ACK for the master branch. Petr Spacek had a good idea of also including timestamp, but this is for future. Martin From tbabej at redhat.com Mon Oct 20 11:41:54 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Oct 2014 13:41:54 +0200 Subject: [Freeipa-devel] [PATCH 0284] Bump 4.2 development version to 4.1.99 In-Reply-To: <5444F085.9030009@redhat.com> References: <5444EF32.9040601@redhat.com> <5444F085.9030009@redhat.com> Message-ID: <5444F502.3030701@redhat.com> On 10/20/2014 01:22 PM, Martin Kosek wrote: > On 10/20/2014 01:17 PM, Tomas Babej wrote: >> Hi, >> >> we need to bump the version in master since 389-ds-base already >> conflicts with FreeIPA < 4.0.3. > Right. ACK for the master branch. > > Petr Spacek had a good idea of also including timestamp, but this is for future. > > Martin Thanks! Pushed to master: 1cc11ebf53e811f15e855fa209df30f9eb8f83f0 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mbasti at redhat.com Mon Oct 20 11:48:30 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 20 Oct 2014 13:48:30 +0200 Subject: [Freeipa-devel] [PATCH 0134] Remove ipaContainer, ipaOrderedContainer Message-ID: <5444F68E.5080508@redhat.com> https://fedorahosted.org/freeipa/ticket/4646 Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0134-Remove-ipaContainer-ipaOrderedContainer-objectclass.patch Type: text/x-patch Size: 8189 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 20 11:59:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 13:59:34 +0200 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations Message-ID: <5444F926.1070508@redhat.com> Gentlemen, We are getting very close to FreeIPA 4.1 release, so let us follow the usual drill :-) 1) Here is the WIP release notes, updates welcome: http://www.freeipa.org/page/Releases/4.1.0 2) I am looking for tickets /patches that are a must for 4.1 and that are not yet tracked in Trac "FreeIPA 4.1" milestone. 3) I am looking for a Release Man for this release. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From jhrozek at redhat.com Mon Oct 20 13:30:35 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 20 Oct 2014 15:30:35 +0200 Subject: [Freeipa-devel] [PATCH] 131-132 extdom: add support for sss_nss_getorigbyname() In-Reply-To: <20141020084307.GE9734@localhost.localdomain> References: <20141017095344.GA9734@localhost.localdomain> <20141019200429.GB10559@hendrix.redhat.com> <20141020084307.GE9734@localhost.localdomain> Message-ID: <20141020133035.GK10559@hendrix.redhat.com> On Mon, Oct 20, 2014 at 10:43:07AM +0200, Sumit Bose wrote: > On Sun, Oct 19, 2014 at 10:04:29PM +0200, Jakub Hrozek wrote: > > On Fri, Oct 17, 2014 at 11:53:44AM +0200, Sumit Bose wrote: > > > Hi, > > > > > > the first patch replaces sss_nss_getsidbyname() by > > > sss_nss_getorigbyname() for the new version of the extdom interface. > > > The new call returns more data about the original object and allows the > > > IPA client to have the same information about the object in the SSSD > > > cache as the IPA servers. > > > > > > The second patch just removes an obsolete dependency. > > > > > > bye, > > > Sumit > > > > Hi, > > > > I was unable to send the patches through Coverity, the RH server seems > > to be having issues. I'll wait until tomorrow, if the problems persist, > > we'll just skip Coverity and fix any potential problems post-push. > > > > > From 928c04c35601b7bc1c57c1320e4a746abc35e947 Mon Sep 17 00:00:00 2001 > > > From: Sumit Bose > > > Date: Fri, 10 Oct 2014 10:56:37 +0200 > > > Subject: [PATCH 131/132] extdom: add support for sss_nss_getorigbyname() > > > > [...] > > > > > @@ -576,13 +613,14 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, > > > enum sss_id_type id_type; > > > size_t buf_len; > > > char *buf = NULL; > > > + struct sss_nss_kv *kv_list; > > > > Please set kv_list to NULL here, you're freeing the pointer > > unconditionally in the done handler, but in some cases (request_type == > > REQ_SIMPLE) kv_list is not set at all. > > Thank you for the review. I fixed it here and at the two other places. Thanks. > Since sss_nss_getorigbyname() will only be available in the upcoming > SSSD release I added 'BuildRequires: libsss_nss_idmap-devel >= 1.12.2' > to freeipa.spec.in. oops, nice catch, that's what I get for building from source.. > > New version attached. ACK! I found an unrelated SSSD bug, but this patch is fine. From mkosek at redhat.com Mon Oct 20 13:49:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 15:49:32 +0200 Subject: [Freeipa-devel] [PATCH] 131-132 extdom: add support for sss_nss_getorigbyname() In-Reply-To: <20141020133035.GK10559@hendrix.redhat.com> References: <20141017095344.GA9734@localhost.localdomain> <20141019200429.GB10559@hendrix.redhat.com> <20141020084307.GE9734@localhost.localdomain> <20141020133035.GK10559@hendrix.redhat.com> Message-ID: <544512EC.9080401@redhat.com> On 10/20/2014 03:30 PM, Jakub Hrozek wrote: > On Mon, Oct 20, 2014 at 10:43:07AM +0200, Sumit Bose wrote: >> On Sun, Oct 19, 2014 at 10:04:29PM +0200, Jakub Hrozek wrote: >>> On Fri, Oct 17, 2014 at 11:53:44AM +0200, Sumit Bose wrote: >>>> Hi, >>>> >>>> the first patch replaces sss_nss_getsidbyname() by >>>> sss_nss_getorigbyname() for the new version of the extdom interface. >>>> The new call returns more data about the original object and allows the >>>> IPA client to have the same information about the object in the SSSD >>>> cache as the IPA servers. >>>> >>>> The second patch just removes an obsolete dependency. >>>> >>>> bye, >>>> Sumit >>> >>> Hi, >>> >>> I was unable to send the patches through Coverity, the RH server seems >>> to be having issues. I'll wait until tomorrow, if the problems persist, >>> we'll just skip Coverity and fix any potential problems post-push. >>> >>>> From 928c04c35601b7bc1c57c1320e4a746abc35e947 Mon Sep 17 00:00:00 2001 >>>> From: Sumit Bose >>>> Date: Fri, 10 Oct 2014 10:56:37 +0200 >>>> Subject: [PATCH 131/132] extdom: add support for sss_nss_getorigbyname() >>> >>> [...] >>> >>>> @@ -576,13 +613,14 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, >>>> enum sss_id_type id_type; >>>> size_t buf_len; >>>> char *buf = NULL; >>>> + struct sss_nss_kv *kv_list; >>> >>> Please set kv_list to NULL here, you're freeing the pointer >>> unconditionally in the done handler, but in some cases (request_type == >>> REQ_SIMPLE) kv_list is not set at all. >> >> Thank you for the review. I fixed it here and at the two other places. > > Thanks. > >> Since sss_nss_getorigbyname() will only be available in the upcoming >> SSSD release I added 'BuildRequires: libsss_nss_idmap-devel >= 1.12.2' >> to freeipa.spec.in. > > oops, nice catch, that's what I get for building from source.. > >> >> New version attached. > > ACK! I found an unrelated SSSD bug, but this patch is fine. Thanks! But we should wait with pushing until the Requires is at least in mkosek/freeipa Copr so that other 4.1 development builds are not broken. Martin From pvoborni at redhat.com Mon Oct 20 13:58:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 20 Oct 2014 15:58:27 +0200 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <5444F926.1070508@redhat.com> References: <5444F926.1070508@redhat.com> Message-ID: <54451503.1030204@redhat.com> On 20.10.2014 13:59, Martin Kosek wrote: > Gentlemen, > > We are getting very close to FreeIPA 4.1 release, so let us follow the usual > drill :-) > > 1) Here is the WIP release notes, updates welcome: > http://www.freeipa.org/page/Releases/4.1.0 > > 2) I am looking for tickets /patches that are a must for 4.1 and that are not > yet tracked in Trac "FreeIPA 4.1" milestone. > > 3) I am looking for a Release Man for this release. That would be also me. The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to be usable on F20). 4.0.4 will not land in Fedora and will be available only in new copr repo. Proposed name: mkosek/freeipa-4-0 -- Petr Vobornik From jpazdziora at redhat.com Mon Oct 20 14:00:02 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 20 Oct 2014 16:00:02 +0200 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <54451503.1030204@redhat.com> References: <5444F926.1070508@redhat.com> <54451503.1030204@redhat.com> Message-ID: <20141020140002.GN5577@redhat.com> On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote: > > The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will > go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to > be usable on F20). And RHEL 7 / CentOS 7? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Mon Oct 20 14:08:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 16:08:30 +0200 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <20141020140002.GN5577@redhat.com> References: <5444F926.1070508@redhat.com> <54451503.1030204@redhat.com> <20141020140002.GN5577@redhat.com> Message-ID: <5445175E.3090905@redhat.com> On 10/20/2014 04:00 PM, Jan Pazdziora wrote: > On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote: >> >> The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will >> go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo (to >> be usable on F20). > > And RHEL 7 / CentOS 7? For now, I would only maintain RHEL/CentOS 7.0 compatibility for main "mkosek/freeipa" repo. Maintaining all the requirements is a burden I would prefer not to also introduce for all the freeipa-x-y Copr repos mostly useful for people porting to other distros or for our Jenkins CI runs. Martin From tbabej at redhat.com Mon Oct 20 14:49:22 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 20 Oct 2014 16:49:22 +0200 Subject: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys In-Reply-To: <543BA61F.2060303@redhat.com> References: <20141010083936.GZ2328@redhat.com> <5437DB32.2030907@redhat.com> <20141010133645.GC2328@redhat.com> <5437E820.1090303@redhat.com> <20141010143818.GE2328@redhat.com> <5437FE5B.8010708@redhat.com> <20141010155633.GF2328@redhat.com> <543BA61F.2060303@redhat.com> Message-ID: <544520F2.70302@redhat.com> On 10/13/2014 12:14 PM, Petr Vobornik wrote: > On 10.10.2014 17:56, Alexander Bokovoy wrote: >> On Fri, 10 Oct 2014, Petr Vobornik wrote: >>>> One more update for patch 0161, Petr noticed we need to call super >>>> post_callback() too. >>>> >>> >>> idoverrideuser_find callback causes internal error. I've attached new >>> version of the patch which fixes it. Basically it's this change: >>> >>> >>> If you are OK with it, then ACK for patches 160, 161-3, 162-1, 164 and >>> 165. >> I'm fine with your patch, copy/paste error, thanks for fixing it. >> >> > > also ACK for 163. > > patch 159 still needs review. > > pushed to: > > master: > * 63be2ee9f0296e1366c77258929c7ce2dad53154 Support overridding user > shell in ID views > * ca42d3469a6f83376d33b08d7bb4b43c2e93d604 Allow user overrides to > specify SSH public keys > * b50524b10c82ed7931a2e84dbb029e8909aa8f3f Allow user overrides to > specify GID of the user > * 5ec23ccb5f1d21c6e6c56650c18d1b4296d59ac9 Allow override of gecos > field in ID views > * 6637449ad2d8885f6df43b4098f09289c7405129 Update API version for ID > views support > * 9fcc9a0163b7f485deae2fd000ae0ab554f9bb72 Require slapi-nis 0.54 or > later for ID views support > > ipa-4-1: > * 8a8d2e71f384bfa50477042cb8e82f14237caa7c Support overridding user > shell in ID views > * ad6d019b4784853c59fb2a38c5de149b02640841 Allow user overrides to > specify SSH public keys > * 240d93bd80a3fdc9f67640f74380eb748ffff43c Allow user overrides to > specify GID of the user > * aa0f5d35c5221e1d8ae270d354ff21d173b3194e Allow override of gecos > field in ID views > * 79c0b31c72a8d8db676f3a621371983e5d9cdf53 Update API version for ID > views support > * a4798c78372a66545d338b809afb45b5f9ada94d Require slapi-nis 0.54 or > later for ID views support ACK for 159, works fine in my testing. Pushed to: master: bd98ab035665e9ed913b9c0efd11c7685f2034f3 ipa-4-1: 50f46fdeddc7f6d8529e2342614fa569b8d4d541 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mkosek at redhat.com Mon Oct 20 14:59:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 16:59:14 +0200 Subject: [Freeipa-devel] [PATCH 0134] Remove ipaContainer, ipaOrderedContainer In-Reply-To: <5444F68E.5080508@redhat.com> References: <5444F68E.5080508@redhat.com> Message-ID: <54452342.2020002@redhat.com> On 10/20/2014 01:48 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4646 > Patch attached > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. Pushed to: master: c655b7bf76db93f53548d59c525d9b56304ec63a ipa-4-1: 1b7bc35b03082f3d3487e3267b1bce69bba71a60 Martin From mbasti at redhat.com Mon Oct 20 15:21:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 20 Oct 2014 17:21:15 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support Message-ID: <5445286B.5020502@redhat.com> Hello! Hold your hats, DNSSEC patches are here. Martin^2, Petr^2 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0117.2-Add-mask-unmask-methods-for-service.patch Type: text/x-patch Size: 3370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0135-DNSSEC-dependencies.patch Type: text/x-patch Size: 2742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0136-DNSSEC-schema.patch Type: text/x-patch Size: 20857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0137-DNSSEC-add-ipapk11helper-module.patch Type: text/x-patch Size: 88198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0138-DNSSEC-DNS-key-synchronization-daemon.patch Type: text/x-patch Size: 25316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0139-DNSSEC-opendnssec-services.patch Type: text/x-patch Size: 28185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0140-DNSSEC-platform-and-service-variables.patch Type: text/x-patch Size: 16107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0141-DNSSEC-validate-forwarders.patch Type: text/x-patch Size: 16523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0142-DNSSEC-modify-named-service-to-support-dnssec.patch Type: text/x-patch Size: 6255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0143-DNSSEC-installation.patch Type: text/x-patch Size: 8684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0144-DNSSEC-uninstallation.patch Type: text/x-patch Size: 4906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0145-DNSSEC-upgrading.patch Type: text/x-patch Size: 4727 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0146-DNSSEC-ACI.patch Type: text/x-patch Size: 8999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0147-DNSSEC-add-ipa-dnssec-daemons.patch Type: text/x-patch Size: 91244 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0148-DNSSEC-add-files-to-backup.patch Type: text/x-patch Size: 1968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0149-DNSSEC-change-link-to-ipa-page.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 20 15:21:39 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 20 Oct 2014 17:21:39 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support Message-ID: <54452883.3090309@redhat.com> Hello! Hold your hats, DNSSEC patches are here. Martin^2, Petr^2 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0117.2-Add-mask-unmask-methods-for-service.patch Type: text/x-patch Size: 3370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0135-DNSSEC-dependencies.patch Type: text/x-patch Size: 2742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0136-DNSSEC-schema.patch Type: text/x-patch Size: 20857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0137-DNSSEC-add-ipapk11helper-module.patch Type: text/x-patch Size: 88198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0138-DNSSEC-DNS-key-synchronization-daemon.patch Type: text/x-patch Size: 25316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0139-DNSSEC-opendnssec-services.patch Type: text/x-patch Size: 28185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0140-DNSSEC-platform-and-service-variables.patch Type: text/x-patch Size: 16107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0141-DNSSEC-validate-forwarders.patch Type: text/x-patch Size: 16523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0142-DNSSEC-modify-named-service-to-support-dnssec.patch Type: text/x-patch Size: 6255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0143-DNSSEC-installation.patch Type: text/x-patch Size: 8684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0144-DNSSEC-uninstallation.patch Type: text/x-patch Size: 4906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0145-DNSSEC-upgrading.patch Type: text/x-patch Size: 4727 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0146-DNSSEC-ACI.patch Type: text/x-patch Size: 8999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0147-DNSSEC-add-ipa-dnssec-daemons.patch Type: text/x-patch Size: 91244 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0148-DNSSEC-add-files-to-backup.patch Type: text/x-patch Size: 1968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0149-DNSSEC-change-link-to-ipa-page.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 20 15:24:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 20 Oct 2014 17:24:05 +0200 Subject: [Freeipa-devel] FreeIPA 4.1 release preparations In-Reply-To: <5444F926.1070508@redhat.com> References: <5444F926.1070508@redhat.com> Message-ID: <54452915.8070708@redhat.com> On 10/20/2014 01:59 PM, Martin Kosek wrote: > Gentlemen, > > We are getting very close to FreeIPA 4.1 release, so let us follow the usual > drill :-) > > 1) Here is the WIP release notes, updates welcome: > http://www.freeipa.org/page/Releases/4.1.0 > > 2) I am looking for tickets /patches that are a must for 4.1 and that are not > yet tracked in Trac "FreeIPA 4.1" milestone. > > 3) I am looking for a Release Man for this release. > SSSD is almost released, DNSSEC patches are also very close to be finalized. So please yell if you see other blockers for 4.1 release we can fix before tomorrow deadline. Otherwise we will get the ball rolling! Martin From pspacek at redhat.com Mon Oct 20 15:37:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 20 Oct 2014 17:37:39 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <5445286B.5020502@redhat.com> References: <5445286B.5020502@redhat.com> Message-ID: <54452C43.7050703@redhat.com> On 20.10.2014 17:21, Martin Basti wrote: > Hello! Hold your hats, DNSSEC patches are here. > > Martin^2, Petr^2 For testing you will need following package: http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 From me, functional self-ACK :-) -- Petr^2 Spacek From jcholast at redhat.com Mon Oct 20 16:28:56 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 20 Oct 2014 18:28:56 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <54452C43.7050703@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> Message-ID: <54453848.3080002@redhat.com> Hi, Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): > On 20.10.2014 17:21, Martin Basti wrote: >> Hello! Hold your hats, DNSSEC patches are here. >> >> Martin^2, Petr^2 > > For testing you will need following package: > http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 > > From me, functional self-ACK :-) > Patch 117: 1) As we discussed off-line, this code is wrong and a ticket should be opened to fix it to properly handle service files conflicting with the mask command: + if instance_name != "": + srv_tgt = os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, instance_name) + # remove instance file or link before masking + if os.path.islink(srv_tgt): + os.unlink(srv_tgt) Patch 137: 1) There are some whitespace errors: Applying: DNSSEC: add ipapk11helper module /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: trailing whitespace. * /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: trailing whitespace. * /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: trailing whitespace. * /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: trailing whitespace. * /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: trailing whitespace. * warning: squelched 3 whitespace errors warning: 8 lines add whitespace errors. Patch 138: 1) There is a whitespace error: Applying: DNSSEC: DNS key synchronization daemon /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: new blank line at EOF. + warning: 1 line adds whitespace errors. Patch 140: 1) Unless there is a dnssec_keys ipalib plugins, I don't think there should be container_dnssec_keys. Use "DN(('cn', 'keys'), ('cn', 'sec'), api.env.container_dns, ...)" instead of "DN(api.env.container_dnssec_keys, ...)". 2) The masking method definitions in PlatformService should be moved to patch 117. 3) The changes in dnskeysyncinstance.py, odsexportedinstance.py and opendnssecinstance.py should be moved to patches 138 and 139. Patch 147: 1) There are some whitespace errors: Applying: DNSSEC: add ipa dnssec daemons /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: trailing whitespace. # synchronize metadata about master keys in LDAP /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: trailing whitespace. /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: trailing whitespace. /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: new blank line at EOF. + /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: new blank line at EOF. + warning: squelched 1 whitespace error warning: 6 lines add whitespace errors. Honza -- Jan Cholasta From pvoborni at redhat.com Mon Oct 20 17:22:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 20 Oct 2014 19:22:22 +0200 Subject: [Freeipa-devel] [PATCH] 779 webui: do not show closed dialog Message-ID: <544544CE.8050606@redhat.com> Fixes issues when dialog is not removed from `IPA.opened_dialogs` registry when dialog.close() is called while the dialog is not shown, i.e., while other dialog is shown. Without it, the dialog is could be incorrectly displayed. New dialog's property `opened` handles whether dialog is intended to be opened. How to test: Add new host with IP address outside of managed reverse zones to get error 4304. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0779-webui-do-not-show-closed-dialog.patch Type: text/x-patch Size: 2355 bytes Desc: not available URL: From pvoborni at redhat.com Mon Oct 20 17:22:50 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 20 Oct 2014 19:22:50 +0200 Subject: [Freeipa-devel] [PATCH] 780 webui: update combobox input on list click Message-ID: <544544EA.3060703@redhat.com> Change event of combobox is not triggered when there is only one value. Calling it's handler even for option's 'click' event makes sure that value of input gets always updated. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0780-webui-update-combobox-input-on-list-click.patch Type: text/x-patch Size: 1728 bytes Desc: not available URL: From abokovoy at redhat.com Mon Oct 20 18:25:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Oct 2014 21:25:48 +0300 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects Message-ID: <20141020182548.GT5446@redhat.com> Hi! This patch is for ipa-4-1 branch to enable uniqueness plugin for uid attribute for entries with objectclass posixAccount. We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for posixAccounts it worked due to our design of a flat tree: as uid attribute is part of the DN, renaming user entries enforces uniqueness as MODRDN will fail if entry with the same uid already exists. However, it is not enough for ID views -- we should be able to allow ID view overrides for the same uid across multiple views and we should be able to protect uid uniqueness more generally too. Implementation is done via update plugin that checks for existing uid uniqueness plugin and if it is missing, it will be added. If plugin exists, its configuration will be updated. I haven't added update specific to git master where staging subtree is added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet have the staging subtree. Currently master has broken setup for uid uniqueness plugin that doesn't actually work anyway so it will be easier to add upgrade over properly configured entry. https://fedorahosted.org/freeipa/ticket/4636 -- / Alexander Bokovoy -------------- next part -------------- From 65c13474d25f3a3315103dcdeb2d00b9690095fc Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 20 Oct 2014 21:01:33 +0300 Subject: [PATCH] updater: enable uid uniqueness plugin for posixAccounts https://fedorahosted.org/freeipa/ticket/4636 --- ipaserver/install/plugins/update_uniqueness.py | 114 +++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 ipaserver/install/plugins/update_uniqueness.py diff --git a/ipaserver/install/plugins/update_uniqueness.py b/ipaserver/install/plugins/update_uniqueness.py new file mode 100644 index 0000000..80f051f --- /dev/null +++ b/ipaserver/install/plugins/update_uniqueness.py @@ -0,0 +1,114 @@ +# Authors: +# Alexander Bokovoy +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# 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 PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +from ipaserver.install.plugins import MIDDLE +from ipaserver.install.plugins.baseupdate import PostUpdate +from ipalib import api, errors +from ipapython.dn import DN +from ipapython.ipa_log_manager import * + + +class update_uid_uniqueness(PostUpdate): + """ + Create plugin configuration to ensure uid uniqueness + """ + order = MIDDLE + + uid_uniqueness_dn = DN(('cn', 'uid uniqueness'), ('cn', 'plugins'), ('cn', 'config')) + + uid_uniqueness_template = { + 'objectClass' : ["top", "nsSlapdPlugin", "extensibleObject"], + 'cn' : 'uid uniqueness', + 'nsslapd-pluginPath' : 'libattr-unique-plugin', + 'nsslapd-pluginInitfunc' : 'NSUniqueAttr_Init', + 'nsslapd-pluginType' : 'betxnpreoperation', + 'nsslapd-pluginEnabled' : 'on', + 'uniqueness-attribute-name' : 'uid', + 'uniqueness-subtrees' : 'dc=example,dc=com', + 'uniqueness-across-all-subtrees': 'off', + 'uniqueness-subtree-entries-oc' : 'posixAccount', + 'nsslapd-plugin-depends-on-type': 'database', + 'nsslapd-pluginId' : 'none', + 'nsslapd-pluginVersion' : 'none', + 'nsslapd-pluginVendor' : 'none', + 'nsslapd-pluginDescription' : 'none', + } + + def execute(self, **options): + ldap = self.obj.backend + + config_dn = DN(('cn','config')) + search_filter = ("(&(objectclass=nsslapdplugin)" + "(nsslapd-pluginpath=libattr-unique-plugin)" + "(nsslapd-pluginInitfunc=NSUniqueAttr_Init)" + "(!(nsslapd-pluginenabled=off))" + "(|(uniqueness-attribute-name=uid)(nsslapd-plugarg0=uid)))") + root_logger.debug("update_uid_uniqueness: search for existing uid uniqueness " + "configuration") + + try: + (entries, truncated) = ldap.find_entries(search_filter, ['*'], config_dn, + time_limit=0, size_limit=0) + except errors.NotFound: + # add entry + entries = [] + except errors.ExecutionError, e: + root_logger.error("update_uid_uniqueness: cannot retrieve " + "list of uniqueness plugin instances: %s", e) + return (False, False, []) + + if len(entries) > 1: + root_logger.error("update_uid_uniqueness: found more than one uid " + "uniqueness plugin definition: %s", [str(x.dn) for x in entries]) + return (False, False, []) + + error = False + if len(entries) == 0: + root_logger.debug("update_uid_uniqueness: adding new uid uniqueness " + "plugin definition") + uid_uniqueness_plugin_attrs = dict(self.uid_uniqueness_template) + uid_uniqueness_plugin_attrs['uniqueness-subtrees'] = api.env.basedn + uid_uniqueness_plugin = ldap.make_entry(self.uid_uniqueness_dn, uid_uniqueness_plugin_attrs) + + try: + ldap.add_entry(uid_uniqueness_plugin) + except errors.ExecutionError, e: + root_logger.debug("update_uid_uniqueness: cannot " + "create uid uniqueness plugin entry: %s", e) + error = True + else: + root_logger.debug("update_uid_uniqueness: updating existing uid uniqueness " + "plugin definition") + uid_uniqueness_plugin_attrs = dict(self.uid_uniqueness_template) + uid_uniqueness_plugin_attrs['uniqueness-subtrees'] = api.env.basedn + uid_uniqueness_plugin = ldap.make_entry(entries[0].dn, uid_uniqueness_plugin_attrs) + + try: + ldap.update_entry(uid_uniqueness_plugin) + except errors.ExecutionError, e: + root_logger.debug("update_uid_uniqueness: cannot " + "update uid uniqueness plugin entry: %s", e) + error = True + + if error: + root_logger.error("update_uid_uniqueness: error(s)" + "detected during plugin update") + return (True, False, []) + +api.register(update_uid_uniqueness) -- 2.1.0 From edewata at redhat.com Mon Oct 20 20:07:24 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 20 Oct 2014 15:07:24 -0500 Subject: [Freeipa-devel] [PATCH] 779 webui: do not show closed dialog In-Reply-To: <544544CE.8050606@redhat.com> References: <544544CE.8050606@redhat.com> Message-ID: <54456B7C.1010203@redhat.com> On 10/20/2014 12:22 PM, Petr Vobornik wrote: > Fixes issues when dialog is not removed from `IPA.opened_dialogs` > registry when dialog.close() is called while the dialog is not shown, > i.e., while other dialog is shown. Without it, the dialog is could be > incorrectly displayed. > > New dialog's property `opened` handles whether dialog is intended to be > opened. > > How to test: > > Add new host with IP address outside of managed reverse zones to get > error 4304. Didn't have a chance to test it, but the code looks fine. ACK. Perhaps the 'opened' property can be renamed to 'enabled' or something like that to avoid confusions with 'is_shown'. -- Endi S. Dewata From edewata at redhat.com Mon Oct 20 20:07:28 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 20 Oct 2014 15:07:28 -0500 Subject: [Freeipa-devel] [PATCH] 780 webui: update combobox input on list click In-Reply-To: <544544EA.3060703@redhat.com> References: <544544EA.3060703@redhat.com> Message-ID: <54456B80.2080708@redhat.com> On 10/20/2014 12:22 PM, Petr Vobornik wrote: > Change event of combobox is not triggered when there is only one value. > Calling it's handler even for option's 'click' event makes sure that > value of input gets always updated. ACK. -- Endi S. Dewata From mbasti at redhat.com Mon Oct 20 21:40:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 20 Oct 2014 23:40:21 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <54453848.3080002@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> Message-ID: <54458145.5020304@redhat.com> On 20/10/14 18:28, Jan Cholasta wrote: > Hi, > > Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): >> On 20.10.2014 17:21, Martin Basti wrote: >>> Hello! Hold your hats, DNSSEC patches are here. >>> >>> Martin^2, Petr^2 >> >> For testing you will need following package: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 >> >> From me, functional self-ACK :-) >> > > Patch 117: > > 1) > > As we discussed off-line, this code is wrong and a ticket should be > opened to fix it to properly handle service files conflicting with the > mask command: > > + if instance_name != "": > + srv_tgt = os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, > instance_name) > + # remove instance file or link before masking > + if os.path.islink(srv_tgt): > + os.unlink(srv_tgt) > > > Patch 137: > > 1) > > There are some whitespace errors: > > Applying: DNSSEC: add ipapk11helper module > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: > trailing whitespace. > * > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: > trailing whitespace. > * > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: > trailing whitespace. > * > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: > trailing whitespace. > * > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: > trailing whitespace. > * > warning: squelched 3 whitespace errors > warning: 8 lines add whitespace errors. > > > Patch 138: > > 1) > > There is a whitespace error: > > Applying: DNSSEC: DNS key synchronization daemon > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: new > blank line at EOF. > + > warning: 1 line adds whitespace errors. > > > Patch 140: > > 1) > > Unless there is a dnssec_keys ipalib plugins, I don't think there > should be container_dnssec_keys. Use "DN(('cn', 'keys'), ('cn', > 'sec'), api.env.container_dns, ...)" instead of > "DN(api.env.container_dnssec_keys, ...)". > > > 2) > > The masking method definitions in PlatformService should be moved to > patch 117. > > > 3) > > The changes in dnskeysyncinstance.py, odsexportedinstance.py and > opendnssecinstance.py should be moved to patches 138 and 139. > > > Patch 147: > > 1) > > There are some whitespace errors: > > Applying: DNSSEC: add ipa dnssec daemons > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: > trailing whitespace. > # synchronize metadata about master keys in LDAP > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: > trailing whitespace. > > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: > trailing whitespace. > > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: new > blank line at EOF. > + > /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: new > blank line at EOF. > + > warning: squelched 1 whitespace error > warning: 6 lines add whitespace errors. > > > Honza > Whitespaces fixed, mask, and dnssec_container issues move to 4.1.1 please. But we have schema conflict: [20/Oct/2014:04:48:40 -0400] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-IPA-EXAMPLE/schema/71idviews.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - object class ipaOverrideTarget: The name does not match the OID "2.16.840.1.113730.3.8.12.34". Another object class is already using the name or OID. git grep -n "2.16.840.1.113730.3.8.12.34" install/share/60basev3.ldif:79:objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect storage for encoded key material' SUP top AUXILIARY MUST ( ipaSecretKeyRef ) X-... install/share/71idviews.ldif:8:objectClasses: (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) Updated patches atached. "2.16.840.1.113730.3.8.12.35" is not used, I change it in patch mbasti-0150 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0117.3-Add-mask-unmask-methods-for-service.patch Type: text/x-patch Size: 3857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0135.2-DNSSEC-dependencies.patch Type: text/x-patch Size: 2742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0136.2-DNSSEC-schema.patch Type: text/x-patch Size: 20857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0137.2-DNSSEC-add-ipapk11helper-module.patch Type: text/x-patch Size: 87377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0138.2-DNSSEC-DNS-key-synchronization-daemon.patch Type: text/x-patch Size: 24598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0139.2-DNSSEC-opendnssec-services.patch Type: text/x-patch Size: 25999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0140.2-DNSSEC-platform-paths-and-services.patch Type: text/x-patch Size: 12139 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0141.2-DNSSEC-validate-forwarders.patch Type: text/x-patch Size: 16523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0142.2-DNSSEC-modify-named-service-to-support-dnssec.patch Type: text/x-patch Size: 6255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0143.2-DNSSEC-installation.patch Type: text/x-patch Size: 8684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0144.2-DNSSEC-uninstallation.patch Type: text/x-patch Size: 4906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0145.2-DNSSEC-upgrading.patch Type: text/x-patch Size: 4727 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0146.2-DNSSEC-ACI.patch Type: text/x-patch Size: 8999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0147.2-DNSSEC-add-ipa-dnssec-daemons.patch Type: text/x-patch Size: 92073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0148.2-DNSSEC-add-files-to-backup.patch Type: text/x-patch Size: 1968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0149.2-DNSSEC-change-link-to-ipa-page.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0150-DNSSEC-fix-schema-OID-conflict.patch Type: text/x-patch Size: 1561 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 21 06:32:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 08:32:55 +0200 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <20141020182548.GT5446@redhat.com> References: <20141020182548.GT5446@redhat.com> Message-ID: <5445FE17.3030603@redhat.com> On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: > Hi! > > This patch is for ipa-4-1 branch to enable uniqueness plugin for uid > attribute for entries with objectclass posixAccount. > > We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for > posixAccounts it worked due to our design of a flat tree: as uid attribute is > part of the DN, renaming user entries > enforces uniqueness as MODRDN will fail if entry with the same uid > already exists. > > However, it is not enough for ID views -- we should be able to allow > ID view overrides for the same uid across multiple views and we should > be able to protect uid uniqueness more generally too. > > Implementation is done via update plugin that checks for existing uid > uniqueness plugin and if it is missing, it will be added. If plugin > exists, its configuration will be updated. > > I haven't added update specific to git master where staging subtree is > added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet > have the staging subtree. Currently master has broken setup for uid > uniqueness plugin that doesn't actually work anyway so it will be easier > to add upgrade over properly configured entry. > > https://fedorahosted.org/freeipa/ticket/4636 Hi Alexander, Thanks for the patch! However, I am personally not very confident with merging it right before 4.1 release, I thought it will be a simple update definition while this is a complex upgrade script which needs to be properly tested. I would rather wait for 4.1.x, especially given it does not block any 4.1 major feature in any way. Martin From jcholast at redhat.com Tue Oct 21 06:33:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 21 Oct 2014 08:33:33 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <54458145.5020304@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> Message-ID: <5445FE3D.2030004@redhat.com> Dne 20.10.2014 v 23:40 Martin Basti napsal(a): > On 20/10/14 18:28, Jan Cholasta wrote: >> Hi, >> >> Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): >>> On 20.10.2014 17:21, Martin Basti wrote: >>>> Hello! Hold your hats, DNSSEC patches are here. >>>> >>>> Martin^2, Petr^2 >>> >>> For testing you will need following package: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 >>> >>> From me, functional self-ACK :-) >>> >> >> Patch 117: >> >> 1) >> >> As we discussed off-line, this code is wrong and a ticket should be >> opened to fix it to properly handle service files conflicting with the >> mask command: >> >> + if instance_name != "": >> + srv_tgt = os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, >> instance_name) >> + # remove instance file or link before masking >> + if os.path.islink(srv_tgt): >> + os.unlink(srv_tgt) >> >> >> Patch 137: >> >> 1) >> >> There are some whitespace errors: >> >> Applying: DNSSEC: add ipapk11helper module >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: >> trailing whitespace. >> * >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: >> trailing whitespace. >> * >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: >> trailing whitespace. >> * >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: >> trailing whitespace. >> * >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: >> trailing whitespace. >> * >> warning: squelched 3 whitespace errors >> warning: 8 lines add whitespace errors. >> >> >> Patch 138: >> >> 1) >> >> There is a whitespace error: >> >> Applying: DNSSEC: DNS key synchronization daemon >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: new >> blank line at EOF. >> + >> warning: 1 line adds whitespace errors. >> >> >> Patch 140: >> >> 1) >> >> Unless there is a dnssec_keys ipalib plugins, I don't think there >> should be container_dnssec_keys. Use "DN(('cn', 'keys'), ('cn', >> 'sec'), api.env.container_dns, ...)" instead of >> "DN(api.env.container_dnssec_keys, ...)". >> >> >> 2) >> >> The masking method definitions in PlatformService should be moved to >> patch 117. >> >> >> 3) >> >> The changes in dnskeysyncinstance.py, odsexportedinstance.py and >> opendnssecinstance.py should be moved to patches 138 and 139. >> >> >> Patch 147: >> >> 1) >> >> There are some whitespace errors: >> >> Applying: DNSSEC: add ipa dnssec daemons >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: >> trailing whitespace. >> # synchronize metadata about master keys in LDAP >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: >> trailing whitespace. >> >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: >> trailing whitespace. >> >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: new >> blank line at EOF. >> + >> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: new >> blank line at EOF. >> + >> warning: squelched 1 whitespace error >> warning: 6 lines add whitespace errors. >> >> >> Honza >> > Whitespaces fixed, > mask, and dnssec_container issues move to 4.1.1 please. mask ACK, container NACK - I don't think we want to introduce a new configuration option and deprecate it right away and it's a change in just 3 lines of code. > > But we have schema conflict: > > [20/Oct/2014:04:48:40 -0400] dse_read_one_file - The entry cn=schema in > file /etc/dirsrv/slapd-IPA-EXAMPLE/schema/71idviews.ldif (lineno: 1) is > invalid, error code 20 (Type or value exists) - object class > ipaOverrideTarget: The name does not match the OID > "2.16.840.1.113730.3.8.12.34". Another object class is already using the > name or OID. > > git grep -n "2.16.840.1.113730.3.8.12.34" > install/share/60basev3.ldif:79:objectClasses: > (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect > storage for encoded key material' SUP top AUXILIARY MUST ( > ipaSecretKeyRef ) X-... > > install/share/71idviews.ldif:8:objectClasses: > (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL > MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) > > Updated patches atached. > "2.16.840.1.113730.3.8.12.35" is not used, I change it in patch mbasti-0150 NACK on patch 150, 2.16.840.1.113730.3.8.12.34 was reserved for ipaSecretKeyRefObject, there is no reserved OID for ipaOverrideTarget, so it's ipaOverrideTarget which should be fixed. -- Jan Cholasta From abokovoy at redhat.com Tue Oct 21 06:41:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Oct 2014 09:41:48 +0300 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <5445FE17.3030603@redhat.com> References: <20141020182548.GT5446@redhat.com> <5445FE17.3030603@redhat.com> Message-ID: <20141021064148.GX5446@redhat.com> On Tue, 21 Oct 2014, Martin Kosek wrote: >On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: >> Hi! >> >> This patch is for ipa-4-1 branch to enable uniqueness plugin for uid >> attribute for entries with objectclass posixAccount. >> >> We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for >> posixAccounts it worked due to our design of a flat tree: as uid attribute is >> part of the DN, renaming user entries >> enforces uniqueness as MODRDN will fail if entry with the same uid >> already exists. >> >> However, it is not enough for ID views -- we should be able to allow >> ID view overrides for the same uid across multiple views and we should >> be able to protect uid uniqueness more generally too. >> >> Implementation is done via update plugin that checks for existing uid >> uniqueness plugin and if it is missing, it will be added. If plugin >> exists, its configuration will be updated. >> >> I haven't added update specific to git master where staging subtree is >> added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet >> have the staging subtree. Currently master has broken setup for uid >> uniqueness plugin that doesn't actually work anyway so it will be easier >> to add upgrade over properly configured entry. >> >> https://fedorahosted.org/freeipa/ticket/4636 > >Hi Alexander, > >Thanks for the patch! However, I am personally not very confident with merging >it right before 4.1 release, I thought it will be a simple update definition >while this is a complex upgrade script which needs to be properly tested. > >I would rather wait for 4.1.x, especially given it does not block any 4.1 major >feature in any way. I disagree on it for multiple reasons and one of them is that 'a simple update definition' is not right here. Attribute uniqueness plugin supports three different types of setting its own arguments. These types aren't mixable, you have to do switch from one to another. That's why update plugin is the correct approach here. The update plugin I've wrote is very simple by itself. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Oct 21 06:45:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Oct 2014 09:45:01 +0300 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <5445FE3D.2030004@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> Message-ID: <20141021064501.GY5446@redhat.com> On Tue, 21 Oct 2014, Jan Cholasta wrote: >Dne 20.10.2014 v 23:40 Martin Basti napsal(a): >>On 20/10/14 18:28, Jan Cholasta wrote: >>>Hi, >>> >>>Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): >>>>On 20.10.2014 17:21, Martin Basti wrote: >>>>>Hello! Hold your hats, DNSSEC patches are here. >>>>> >>>>>Martin^2, Petr^2 >>>> >>>>For testing you will need following package: >>>>http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 >>>> >>>> From me, functional self-ACK :-) >>>> >>> >>>Patch 117: >>> >>>1) >>> >>>As we discussed off-line, this code is wrong and a ticket should be >>>opened to fix it to properly handle service files conflicting with the >>>mask command: >>> >>>+ if instance_name != "": >>>+ srv_tgt = os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, >>>instance_name) >>>+ # remove instance file or link before masking >>>+ if os.path.islink(srv_tgt): >>>+ os.unlink(srv_tgt) >>> >>> >>>Patch 137: >>> >>>1) >>> >>>There are some whitespace errors: >>> >>>Applying: DNSSEC: add ipapk11helper module >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: >>>trailing whitespace. >>> * >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: >>>trailing whitespace. >>> * >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: >>>trailing whitespace. >>> * >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: >>>trailing whitespace. >>> * >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: >>>trailing whitespace. >>> * >>>warning: squelched 3 whitespace errors >>>warning: 8 lines add whitespace errors. >>> >>> >>>Patch 138: >>> >>>1) >>> >>>There is a whitespace error: >>> >>>Applying: DNSSEC: DNS key synchronization daemon >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: new >>>blank line at EOF. >>>+ >>>warning: 1 line adds whitespace errors. >>> >>> >>>Patch 140: >>> >>>1) >>> >>>Unless there is a dnssec_keys ipalib plugins, I don't think there >>>should be container_dnssec_keys. Use "DN(('cn', 'keys'), ('cn', >>>'sec'), api.env.container_dns, ...)" instead of >>>"DN(api.env.container_dnssec_keys, ...)". >>> >>> >>>2) >>> >>>The masking method definitions in PlatformService should be moved to >>>patch 117. >>> >>> >>>3) >>> >>>The changes in dnskeysyncinstance.py, odsexportedinstance.py and >>>opendnssecinstance.py should be moved to patches 138 and 139. >>> >>> >>>Patch 147: >>> >>>1) >>> >>>There are some whitespace errors: >>> >>>Applying: DNSSEC: add ipa dnssec daemons >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: >>>trailing whitespace. >>> # synchronize metadata about master keys in LDAP >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: >>>trailing whitespace. >>> >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: >>>trailing whitespace. >>> >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: new >>>blank line at EOF. >>>+ >>>/home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: new >>>blank line at EOF. >>>+ >>>warning: squelched 1 whitespace error >>>warning: 6 lines add whitespace errors. >>> >>> >>>Honza >>> >>Whitespaces fixed, >> mask, and dnssec_container issues move to 4.1.1 please. > >mask ACK, container NACK - I don't think we want to introduce a new >configuration option and deprecate it right away and it's a change in >just 3 lines of code. > >> >>But we have schema conflict: >> >>[20/Oct/2014:04:48:40 -0400] dse_read_one_file - The entry cn=schema in >>file /etc/dirsrv/slapd-IPA-EXAMPLE/schema/71idviews.ldif (lineno: 1) is >>invalid, error code 20 (Type or value exists) - object class >>ipaOverrideTarget: The name does not match the OID >>"2.16.840.1.113730.3.8.12.34". Another object class is already using the >>name or OID. >> >>git grep -n "2.16.840.1.113730.3.8.12.34" >>install/share/60basev3.ldif:79:objectClasses: >>(2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect >>storage for encoded key material' SUP top AUXILIARY MUST ( >>ipaSecretKeyRef ) X-... >> >>install/share/71idviews.ldif:8:objectClasses: >>(2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL >>MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) >> >>Updated patches atached. >>"2.16.840.1.113730.3.8.12.35" is not used, I change it in patch mbasti-0150 > >NACK on patch 150, 2.16.840.1.113730.3.8.12.34 was reserved for >ipaSecretKeyRefObject, there is no reserved OID for ipaOverrideTarget, >so it's ipaOverrideTarget which should be fixed. We were meaning to reserve .34 for ipaOverrideTarget for long time. As ipaOverrideTarget is already in git, it makes sense to change dnssec OIDs instead. Yes, we've got to step over each other's toes but that's life. I've already have slapi-nis 0.54 released which relies on ipaOverrideTarget definition. -- / Alexander Bokovoy From jcholast at redhat.com Tue Oct 21 06:50:54 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 21 Oct 2014 08:50:54 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <20141021064501.GY5446@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> Message-ID: <5446024E.8010605@redhat.com> Dne 21.10.2014 v 08:45 Alexander Bokovoy napsal(a): > On Tue, 21 Oct 2014, Jan Cholasta wrote: >> Dne 20.10.2014 v 23:40 Martin Basti napsal(a): >>> On 20/10/14 18:28, Jan Cholasta wrote: >>>> Hi, >>>> >>>> Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): >>>>> On 20.10.2014 17:21, Martin Basti wrote: >>>>>> Hello! Hold your hats, DNSSEC patches are here. >>>>>> >>>>>> Martin^2, Petr^2 >>>>> >>>>> For testing you will need following package: >>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 >>>>> >>>>> From me, functional self-ACK :-) >>>>> >>>> >>>> Patch 117: >>>> >>>> 1) >>>> >>>> As we discussed off-line, this code is wrong and a ticket should be >>>> opened to fix it to properly handle service files conflicting with the >>>> mask command: >>>> >>>> + if instance_name != "": >>>> + srv_tgt = os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, >>>> instance_name) >>>> + # remove instance file or link before masking >>>> + if os.path.islink(srv_tgt): >>>> + os.unlink(srv_tgt) >>>> >>>> >>>> Patch 137: >>>> >>>> 1) >>>> >>>> There are some whitespace errors: >>>> >>>> Applying: DNSSEC: add ipapk11helper module >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: >>>> trailing whitespace. >>>> * >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: >>>> trailing whitespace. >>>> * >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: >>>> trailing whitespace. >>>> * >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: >>>> trailing whitespace. >>>> * >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: >>>> trailing whitespace. >>>> * >>>> warning: squelched 3 whitespace errors >>>> warning: 8 lines add whitespace errors. >>>> >>>> >>>> Patch 138: >>>> >>>> 1) >>>> >>>> There is a whitespace error: >>>> >>>> Applying: DNSSEC: DNS key synchronization daemon >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: new >>>> blank line at EOF. >>>> + >>>> warning: 1 line adds whitespace errors. >>>> >>>> >>>> Patch 140: >>>> >>>> 1) >>>> >>>> Unless there is a dnssec_keys ipalib plugins, I don't think there >>>> should be container_dnssec_keys. Use "DN(('cn', 'keys'), ('cn', >>>> 'sec'), api.env.container_dns, ...)" instead of >>>> "DN(api.env.container_dnssec_keys, ...)". >>>> >>>> >>>> 2) >>>> >>>> The masking method definitions in PlatformService should be moved to >>>> patch 117. >>>> >>>> >>>> 3) >>>> >>>> The changes in dnskeysyncinstance.py, odsexportedinstance.py and >>>> opendnssecinstance.py should be moved to patches 138 and 139. >>>> >>>> >>>> Patch 147: >>>> >>>> 1) >>>> >>>> There are some whitespace errors: >>>> >>>> Applying: DNSSEC: add ipa dnssec daemons >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: >>>> trailing whitespace. >>>> # synchronize metadata about master keys in LDAP >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: >>>> trailing whitespace. >>>> >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: >>>> trailing whitespace. >>>> >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: new >>>> blank line at EOF. >>>> + >>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: new >>>> blank line at EOF. >>>> + >>>> warning: squelched 1 whitespace error >>>> warning: 6 lines add whitespace errors. >>>> >>>> >>>> Honza >>>> >>> Whitespaces fixed, >>> mask, and dnssec_container issues move to 4.1.1 please. >> >> mask ACK, container NACK - I don't think we want to introduce a new >> configuration option and deprecate it right away and it's a change in >> just 3 lines of code. >> >>> >>> But we have schema conflict: >>> >>> [20/Oct/2014:04:48:40 -0400] dse_read_one_file - The entry cn=schema in >>> file /etc/dirsrv/slapd-IPA-EXAMPLE/schema/71idviews.ldif (lineno: 1) is >>> invalid, error code 20 (Type or value exists) - object class >>> ipaOverrideTarget: The name does not match the OID >>> "2.16.840.1.113730.3.8.12.34". Another object class is already using the >>> name or OID. >>> >>> git grep -n "2.16.840.1.113730.3.8.12.34" >>> install/share/60basev3.ldif:79:objectClasses: >>> (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect >>> storage for encoded key material' SUP top AUXILIARY MUST ( >>> ipaSecretKeyRef ) X-... >>> >>> install/share/71idviews.ldif:8:objectClasses: >>> (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL >>> MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) >>> >>> Updated patches atached. >>> "2.16.840.1.113730.3.8.12.35" is not used, I change it in patch >>> mbasti-0150 >> >> NACK on patch 150, 2.16.840.1.113730.3.8.12.34 was reserved for >> ipaSecretKeyRefObject, there is no reserved OID for ipaOverrideTarget, >> so it's ipaOverrideTarget which should be fixed. > We were meaning to reserve .34 for ipaOverrideTarget for long time. As > ipaOverrideTarget is already in git, it makes sense to change dnssec > OIDs instead. Yes, we've got to step over each other's toes but that's > life. I've already have slapi-nis 0.54 released which relies on > ipaOverrideTarget definition. That's unreleased code and it surely does not rely on it's OID, does it? It's *your* mess and *you* should clean it up. That's life. -- Jan Cholasta From tscherf at redhat.com Tue Oct 21 07:12:47 2014 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 21 Oct 2014 09:12:47 +0200 Subject: [Freeipa-devel] [PATCH 0001] migrate-ds: Fix to exclude attrs with uppercase characters from migration In-Reply-To: <20141020095724.GM27642@tscherf.redhat.com> References: <20141020095724.GM27642@tscherf.redhat.com> Message-ID: <20141021071247.GP27642@tscherf.redhat.com> Just realized that I sent the email without body. Mea culpa. Here we go: Fix entry_attr case to make migrate-ds work again Migration of a OpenLDAP based directory to FreeIPA with some objectclasses removed failed because of --user-ignore-attribute didn't work. Fixed that by making LDAPEntry object entry_attry lowercased. https://fedorahosted.org/freeipa/ticket/4620 On [Mon, 20.10.2014 11:57], Thorsten Scherf wrote: > >>From 6dd24dc6f08f01997bf3d7ccc06d77a7fd239e61 Mon Sep 17 00:00:00 2001 >From: Thorsten Scherf >Date: Mon, 20 Oct 2014 11:47:18 +0200 >Subject: [PATCH] Fix entry_attr case to make migrate-ds work again > >Migration of a OpenLDAP based directory to FreeIPA with some objectclasses >removed failed because of --user-ignore-attribute didn't work. Fixed that by >making LDAPEntry object entry_attry lowercased. > >https://fedorahosted.org/freeipa/ticket/4620 >--- > ipalib/plugins/migration.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/ipalib/plugins/migration.py b/ipalib/plugins/migration.py >index 6b630a464f0be163e82de95afe3a74b22889574b..2500186d26d16d14b7b87dd6902ea385a40ca87b 100644 >--- a/ipalib/plugins/migration.py >+++ b/ipalib/plugins/migration.py >@@ -197,7 +197,7 @@ def _pre_migrate_user(ldap, pkey, dn, entry_attrs, failed, config, ctx, **kwargs > > # do not migrate all attributes > for attr in entry_attrs.keys(): >- if attr in attr_blacklist: >+ if attr.lower() in attr_blacklist: > del entry_attrs[attr] > > # do not migrate all object classes >-- >1.9.3 > >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From jcholast at redhat.com Tue Oct 21 07:13:08 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 21 Oct 2014 09:13:08 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <5445FE3D.2030004@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> Message-ID: <54460784.2060605@redhat.com> Dne 21.10.2014 v 08:33 Jan Cholasta napsal(a): > Dne 20.10.2014 v 23:40 Martin Basti napsal(a): >> On 20/10/14 18:28, Jan Cholasta wrote: >>> Hi, >>> >>> Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): >>>> On 20.10.2014 17:21, Martin Basti wrote: >>>>> Hello! Hold your hats, DNSSEC patches are here. >>>>> >>>>> Martin^2, Petr^2 >>>> >>>> For testing you will need following package: >>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 >>>> >>>> From me, functional self-ACK :-) >>>> >>> >>> Patch 117: >>> >>> 1) >>> >>> As we discussed off-line, this code is wrong and a ticket should be >>> opened to fix it to properly handle service files conflicting with the >>> mask command: >>> >>> + if instance_name != "": >>> + srv_tgt = os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, >>> instance_name) >>> + # remove instance file or link before masking >>> + if os.path.islink(srv_tgt): >>> + os.unlink(srv_tgt) >>> >>> >>> Patch 137: >>> >>> 1) >>> >>> There are some whitespace errors: >>> >>> Applying: DNSSEC: add ipapk11helper module >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: >>> trailing whitespace. >>> * >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: >>> trailing whitespace. >>> * >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: >>> trailing whitespace. >>> * >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: >>> trailing whitespace. >>> * >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: >>> trailing whitespace. >>> * >>> warning: squelched 3 whitespace errors >>> warning: 8 lines add whitespace errors. >>> >>> >>> Patch 138: >>> >>> 1) >>> >>> There is a whitespace error: >>> >>> Applying: DNSSEC: DNS key synchronization daemon >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: new >>> blank line at EOF. >>> + >>> warning: 1 line adds whitespace errors. >>> >>> >>> Patch 140: >>> >>> 1) >>> >>> Unless there is a dnssec_keys ipalib plugins, I don't think there >>> should be container_dnssec_keys. Use "DN(('cn', 'keys'), ('cn', >>> 'sec'), api.env.container_dns, ...)" instead of >>> "DN(api.env.container_dnssec_keys, ...)". >>> >>> >>> 2) >>> >>> The masking method definitions in PlatformService should be moved to >>> patch 117. >>> >>> >>> 3) >>> >>> The changes in dnskeysyncinstance.py, odsexportedinstance.py and >>> opendnssecinstance.py should be moved to patches 138 and 139. >>> >>> >>> Patch 147: >>> >>> 1) >>> >>> There are some whitespace errors: >>> >>> Applying: DNSSEC: add ipa dnssec daemons >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: >>> trailing whitespace. >>> # synchronize metadata about master keys in LDAP >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: >>> trailing whitespace. >>> >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: >>> trailing whitespace. >>> >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: new >>> blank line at EOF. >>> + >>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: new >>> blank line at EOF. >>> + >>> warning: squelched 1 whitespace error >>> warning: 6 lines add whitespace errors. >>> >>> >>> Honza >>> >> Whitespaces fixed, >> mask, and dnssec_container issues move to 4.1.1 please. > > mask ACK, container NACK - I don't think we want to introduce a new > configuration option and deprecate it right away and it's a change in > just 3 lines of code. Patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-357-DNSSEC-remove-container_dnssec_keys.patch Type: text/x-patch Size: 2324 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 21 07:27:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 09:27:29 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <5446024E.8010605@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> <5446024E.8010605@redhat.com> Message-ID: <54460AE1.3000301@redhat.com> On 10/21/2014 08:50 AM, Jan Cholasta wrote: > Dne 21.10.2014 v 08:45 Alexander Bokovoy napsal(a): >> On Tue, 21 Oct 2014, Jan Cholasta wrote: >>> Dne 20.10.2014 v 23:40 Martin Basti napsal(a): >>>> On 20/10/14 18:28, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): >>>>>> On 20.10.2014 17:21, Martin Basti wrote: >>>>>>> Hello! Hold your hats, DNSSEC patches are here. >>>>>>> >>>>>>> Martin^2, Petr^2 >>>>>> >>>>>> For testing you will need following package: >>>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 >>>>>> >>>>>> From me, functional self-ACK :-) >>>>>> >>>>> >>>>> Patch 117: >>>>> >>>>> 1) >>>>> >>>>> As we discussed off-line, this code is wrong and a ticket should be >>>>> opened to fix it to properly handle service files conflicting with the >>>>> mask command: >>>>> >>>>> + if instance_name != "": >>>>> + srv_tgt = os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, >>>>> instance_name) >>>>> + # remove instance file or link before masking >>>>> + if os.path.islink(srv_tgt): >>>>> + os.unlink(srv_tgt) >>>>> >>>>> >>>>> Patch 137: >>>>> >>>>> 1) >>>>> >>>>> There are some whitespace errors: >>>>> >>>>> Applying: DNSSEC: add ipapk11helper module >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: >>>>> trailing whitespace. >>>>> * >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: >>>>> trailing whitespace. >>>>> * >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: >>>>> trailing whitespace. >>>>> * >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: >>>>> trailing whitespace. >>>>> * >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: >>>>> trailing whitespace. >>>>> * >>>>> warning: squelched 3 whitespace errors >>>>> warning: 8 lines add whitespace errors. >>>>> >>>>> >>>>> Patch 138: >>>>> >>>>> 1) >>>>> >>>>> There is a whitespace error: >>>>> >>>>> Applying: DNSSEC: DNS key synchronization daemon >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: new >>>>> blank line at EOF. >>>>> + >>>>> warning: 1 line adds whitespace errors. >>>>> >>>>> >>>>> Patch 140: >>>>> >>>>> 1) >>>>> >>>>> Unless there is a dnssec_keys ipalib plugins, I don't think there >>>>> should be container_dnssec_keys. Use "DN(('cn', 'keys'), ('cn', >>>>> 'sec'), api.env.container_dns, ...)" instead of >>>>> "DN(api.env.container_dnssec_keys, ...)". >>>>> >>>>> >>>>> 2) >>>>> >>>>> The masking method definitions in PlatformService should be moved to >>>>> patch 117. >>>>> >>>>> >>>>> 3) >>>>> >>>>> The changes in dnskeysyncinstance.py, odsexportedinstance.py and >>>>> opendnssecinstance.py should be moved to patches 138 and 139. >>>>> >>>>> >>>>> Patch 147: >>>>> >>>>> 1) >>>>> >>>>> There are some whitespace errors: >>>>> >>>>> Applying: DNSSEC: add ipa dnssec daemons >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: >>>>> trailing whitespace. >>>>> # synchronize metadata about master keys in LDAP >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: >>>>> trailing whitespace. >>>>> >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: >>>>> trailing whitespace. >>>>> >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: new >>>>> blank line at EOF. >>>>> + >>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: new >>>>> blank line at EOF. >>>>> + >>>>> warning: squelched 1 whitespace error >>>>> warning: 6 lines add whitespace errors. >>>>> >>>>> >>>>> Honza >>>>> >>>> Whitespaces fixed, >>>> mask, and dnssec_container issues move to 4.1.1 please. >>> >>> mask ACK, container NACK - I don't think we want to introduce a new >>> configuration option and deprecate it right away and it's a change in >>> just 3 lines of code. >>> >>>> >>>> But we have schema conflict: >>>> >>>> [20/Oct/2014:04:48:40 -0400] dse_read_one_file - The entry cn=schema in >>>> file /etc/dirsrv/slapd-IPA-EXAMPLE/schema/71idviews.ldif (lineno: 1) is >>>> invalid, error code 20 (Type or value exists) - object class >>>> ipaOverrideTarget: The name does not match the OID >>>> "2.16.840.1.113730.3.8.12.34". Another object class is already using the >>>> name or OID. >>>> >>>> git grep -n "2.16.840.1.113730.3.8.12.34" >>>> install/share/60basev3.ldif:79:objectClasses: >>>> (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect >>>> storage for encoded key material' SUP top AUXILIARY MUST ( >>>> ipaSecretKeyRef ) X-... >>>> >>>> install/share/71idviews.ldif:8:objectClasses: >>>> (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL >>>> MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) >>>> >>>> Updated patches atached. >>>> "2.16.840.1.113730.3.8.12.35" is not used, I change it in patch >>>> mbasti-0150 >>> >>> NACK on patch 150, 2.16.840.1.113730.3.8.12.34 was reserved for >>> ipaSecretKeyRefObject, there is no reserved OID for ipaOverrideTarget, >>> so it's ipaOverrideTarget which should be fixed. >> We were meaning to reserve .34 for ipaOverrideTarget for long time. As >> ipaOverrideTarget is already in git, it makes sense to change dnssec >> OIDs instead. Yes, we've got to step over each other's toes but that's >> life. I've already have slapi-nis 0.54 released which relies on >> ipaOverrideTarget definition. > > That's unreleased code and it surely does not rely on it's OID, does it? > > It's *your* mess and *you* should clean it up. That's life. If the code was released, I would give +1 for Alexander as we really cannot changed *released* OIDs. But this is not the case so I think that fixing the OID that was not properly registered is a good practice. Martin From abokovoy at redhat.com Tue Oct 21 07:50:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Oct 2014 10:50:37 +0300 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <54460AE1.3000301@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> <5446024E.8010605@redhat.com> <54460AE1.3000301@redhat.com> Message-ID: <20141021075037.GZ5446@redhat.com> On Tue, 21 Oct 2014, Martin Kosek wrote: >On 10/21/2014 08:50 AM, Jan Cholasta wrote: >> Dne 21.10.2014 v 08:45 Alexander Bokovoy napsal(a): >>> On Tue, 21 Oct 2014, Jan Cholasta wrote: >>>> Dne 20.10.2014 v 23:40 Martin Basti napsal(a): >>>>> On 20/10/14 18:28, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): >>>>>>> On 20.10.2014 17:21, Martin Basti wrote: >>>>>>>> Hello! Hold your hats, DNSSEC patches are here. >>>>>>>> >>>>>>>> Martin^2, Petr^2 >>>>>>> >>>>>>> For testing you will need following package: >>>>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 >>>>>>> >>>>>>> From me, functional self-ACK :-) >>>>>>> >>>>>> >>>>>> Patch 117: >>>>>> >>>>>> 1) >>>>>> >>>>>> As we discussed off-line, this code is wrong and a ticket should be >>>>>> opened to fix it to properly handle service files conflicting with the >>>>>> mask command: >>>>>> >>>>>> + if instance_name != "": >>>>>> + srv_tgt = os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, >>>>>> instance_name) >>>>>> + # remove instance file or link before masking >>>>>> + if os.path.islink(srv_tgt): >>>>>> + os.unlink(srv_tgt) >>>>>> >>>>>> >>>>>> Patch 137: >>>>>> >>>>>> 1) >>>>>> >>>>>> There are some whitespace errors: >>>>>> >>>>>> Applying: DNSSEC: add ipapk11helper module >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: >>>>>> trailing whitespace. >>>>>> * >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: >>>>>> trailing whitespace. >>>>>> * >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: >>>>>> trailing whitespace. >>>>>> * >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: >>>>>> trailing whitespace. >>>>>> * >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: >>>>>> trailing whitespace. >>>>>> * >>>>>> warning: squelched 3 whitespace errors >>>>>> warning: 8 lines add whitespace errors. >>>>>> >>>>>> >>>>>> Patch 138: >>>>>> >>>>>> 1) >>>>>> >>>>>> There is a whitespace error: >>>>>> >>>>>> Applying: DNSSEC: DNS key synchronization daemon >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: new >>>>>> blank line at EOF. >>>>>> + >>>>>> warning: 1 line adds whitespace errors. >>>>>> >>>>>> >>>>>> Patch 140: >>>>>> >>>>>> 1) >>>>>> >>>>>> Unless there is a dnssec_keys ipalib plugins, I don't think there >>>>>> should be container_dnssec_keys. Use "DN(('cn', 'keys'), ('cn', >>>>>> 'sec'), api.env.container_dns, ...)" instead of >>>>>> "DN(api.env.container_dnssec_keys, ...)". >>>>>> >>>>>> >>>>>> 2) >>>>>> >>>>>> The masking method definitions in PlatformService should be moved to >>>>>> patch 117. >>>>>> >>>>>> >>>>>> 3) >>>>>> >>>>>> The changes in dnskeysyncinstance.py, odsexportedinstance.py and >>>>>> opendnssecinstance.py should be moved to patches 138 and 139. >>>>>> >>>>>> >>>>>> Patch 147: >>>>>> >>>>>> 1) >>>>>> >>>>>> There are some whitespace errors: >>>>>> >>>>>> Applying: DNSSEC: add ipa dnssec daemons >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: >>>>>> trailing whitespace. >>>>>> # synchronize metadata about master keys in LDAP >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: >>>>>> trailing whitespace. >>>>>> >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: >>>>>> trailing whitespace. >>>>>> >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: new >>>>>> blank line at EOF. >>>>>> + >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: new >>>>>> blank line at EOF. >>>>>> + >>>>>> warning: squelched 1 whitespace error >>>>>> warning: 6 lines add whitespace errors. >>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>> Whitespaces fixed, >>>>> mask, and dnssec_container issues move to 4.1.1 please. >>>> >>>> mask ACK, container NACK - I don't think we want to introduce a new >>>> configuration option and deprecate it right away and it's a change in >>>> just 3 lines of code. >>>> >>>>> >>>>> But we have schema conflict: >>>>> >>>>> [20/Oct/2014:04:48:40 -0400] dse_read_one_file - The entry cn=schema in >>>>> file /etc/dirsrv/slapd-IPA-EXAMPLE/schema/71idviews.ldif (lineno: 1) is >>>>> invalid, error code 20 (Type or value exists) - object class >>>>> ipaOverrideTarget: The name does not match the OID >>>>> "2.16.840.1.113730.3.8.12.34". Another object class is already using the >>>>> name or OID. >>>>> >>>>> git grep -n "2.16.840.1.113730.3.8.12.34" >>>>> install/share/60basev3.ldif:79:objectClasses: >>>>> (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC 'Indirect >>>>> storage for encoded key material' SUP top AUXILIARY MUST ( >>>>> ipaSecretKeyRef ) X-... >>>>> >>>>> install/share/71idviews.ldif:8:objectClasses: >>>>> (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top STRUCTURAL >>>>> MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) >>>>> >>>>> Updated patches atached. >>>>> "2.16.840.1.113730.3.8.12.35" is not used, I change it in patch >>>>> mbasti-0150 >>>> >>>> NACK on patch 150, 2.16.840.1.113730.3.8.12.34 was reserved for >>>> ipaSecretKeyRefObject, there is no reserved OID for ipaOverrideTarget, >>>> so it's ipaOverrideTarget which should be fixed. >>> We were meaning to reserve .34 for ipaOverrideTarget for long time. As >>> ipaOverrideTarget is already in git, it makes sense to change dnssec >>> OIDs instead. Yes, we've got to step over each other's toes but that's >>> life. I've already have slapi-nis 0.54 released which relies on >>> ipaOverrideTarget definition. >> >> That's unreleased code and it surely does not rely on it's OID, does it? >> >> It's *your* mess and *you* should clean it up. That's life. > >If the code was released, I would give +1 for Alexander as we really cannot >changed *released* OIDs. > >But this is not the case so I think that fixing the OID that was not properly >registered is a good practice. I did push a one-liner to master and ipa-4-1 that changes OID to .35. You will need to do full reinstall if you had ipa-4-1 or git master installed with the previous change. -- / Alexander Bokovoy From mkosek at redhat.com Tue Oct 21 08:19:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 10:19:11 +0200 Subject: [Freeipa-devel] [PATCH] 131-132 extdom: add support for sss_nss_getorigbyname() In-Reply-To: <544512EC.9080401@redhat.com> References: <20141017095344.GA9734@localhost.localdomain> <20141019200429.GB10559@hendrix.redhat.com> <20141020084307.GE9734@localhost.localdomain> <20141020133035.GK10559@hendrix.redhat.com> <544512EC.9080401@redhat.com> Message-ID: <544616FF.6050205@redhat.com> On 10/20/2014 03:49 PM, Martin Kosek wrote: > On 10/20/2014 03:30 PM, Jakub Hrozek wrote: >> On Mon, Oct 20, 2014 at 10:43:07AM +0200, Sumit Bose wrote: >>> On Sun, Oct 19, 2014 at 10:04:29PM +0200, Jakub Hrozek wrote: >>>> On Fri, Oct 17, 2014 at 11:53:44AM +0200, Sumit Bose wrote: >>>>> Hi, >>>>> >>>>> the first patch replaces sss_nss_getsidbyname() by >>>>> sss_nss_getorigbyname() for the new version of the extdom interface. >>>>> The new call returns more data about the original object and allows the >>>>> IPA client to have the same information about the object in the SSSD >>>>> cache as the IPA servers. >>>>> >>>>> The second patch just removes an obsolete dependency. >>>>> >>>>> bye, >>>>> Sumit >>>> >>>> Hi, >>>> >>>> I was unable to send the patches through Coverity, the RH server seems >>>> to be having issues. I'll wait until tomorrow, if the problems persist, >>>> we'll just skip Coverity and fix any potential problems post-push. >>>> >>>>> From 928c04c35601b7bc1c57c1320e4a746abc35e947 Mon Sep 17 00:00:00 2001 >>>>> From: Sumit Bose >>>>> Date: Fri, 10 Oct 2014 10:56:37 +0200 >>>>> Subject: [PATCH 131/132] extdom: add support for sss_nss_getorigbyname() >>>> >>>> [...] >>>> >>>>> @@ -576,13 +613,14 @@ static int handle_gid_request(enum request_types request_type, gid_t gid, >>>>> enum sss_id_type id_type; >>>>> size_t buf_len; >>>>> char *buf = NULL; >>>>> + struct sss_nss_kv *kv_list; >>>> >>>> Please set kv_list to NULL here, you're freeing the pointer >>>> unconditionally in the done handler, but in some cases (request_type == >>>> REQ_SIMPLE) kv_list is not set at all. >>> >>> Thank you for the review. I fixed it here and at the two other places. >> >> Thanks. >> >>> Since sss_nss_getorigbyname() will only be available in the upcoming >>> SSSD release I added 'BuildRequires: libsss_nss_idmap-devel >= 1.12.2' >>> to freeipa.spec.in. >> >> oops, nice catch, that's what I get for building from source.. >> >>> >>> New version attached. >> >> ACK! I found an unrelated SSSD bug, but this patch is fine. > > Thanks! But we should wait with pushing until the Requires is at least in > mkosek/freeipa Copr so that other 4.1 development builds are not broken. > > Martin Pushed to: master: 43f8de0c7661c4cc6102bed905535a6143e77995 ipa-4-1: 99b10e506720dc7b3c76fc011352af90b7660b48 Martin From tbabej at redhat.com Tue Oct 21 08:28:41 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 21 Oct 2014 10:28:41 +0200 Subject: [Freeipa-devel] [PATCH 0285] spec: Bump SSSD requires to 1.12.2 Message-ID: <54461939.2090207@redhat.com> Hi, this bumps the required SSSD version for the upcoming release. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0285-spec-Bump-SSSD-requires-to-1.12.2.patch Type: text/x-patch Size: 718 bytes Desc: not available URL: From pvoborni at redhat.com Tue Oct 21 08:31:16 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 21 Oct 2014 10:31:16 +0200 Subject: [Freeipa-devel] [PATCH] 779 webui: do not show closed dialog In-Reply-To: <54456B7C.1010203@redhat.com> References: <544544CE.8050606@redhat.com> <54456B7C.1010203@redhat.com> Message-ID: <544619D4.9090201@redhat.com> On 20.10.2014 22:07, Endi Sukma Dewata wrote: > On 10/20/2014 12:22 PM, Petr Vobornik wrote: >> Fixes issues when dialog is not removed from `IPA.opened_dialogs` >> registry when dialog.close() is called while the dialog is not shown, >> i.e., while other dialog is shown. Without it, the dialog is could be >> incorrectly displayed. >> >> New dialog's property `opened` handles whether dialog is intended to be >> opened. >> >> How to test: >> >> Add new host with IP address outside of managed reverse zones to get >> error 4304. > > Didn't have a chance to test it, but the code looks fine. ACK. > Perhaps the 'opened' property can be renamed to 'enabled' or something > like that to avoid confusions with 'is_shown'. > I've added ticket to commit message: https://fedorahosted.org/freeipa/ticket/4656 Pushed to: master: 41a7d0bf472b21018715eedf0b4c56ccbeace1f1 ipa-4-1: d3de9c0ca1844a99b1d54952f6b4355e8c8188f8 -- Petr Vobornik From pvoborni at redhat.com Tue Oct 21 08:33:40 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 21 Oct 2014 10:33:40 +0200 Subject: [Freeipa-devel] [PATCH] 780 webui: update combobox input on list click In-Reply-To: <54456B80.2080708@redhat.com> References: <544544EA.3060703@redhat.com> <54456B80.2080708@redhat.com> Message-ID: <54461A64.9030007@redhat.com> On 20.10.2014 22:07, Endi Sukma Dewata wrote: > On 10/20/2014 12:22 PM, Petr Vobornik wrote: >> Change event of combobox is not triggered when there is only one value. >> Calling it's handler even for option's 'click' event makes sure that >> value of input gets always updated. > > ACK. > added ticket: https://fedorahosted.org/freeipa/ticket/4655 Pushed to: master: 34d3f99aae7783c4c91c29b427d412a7a85d2647 ipa-4-1: 905367334260336c33f2ae8caf5a4a2f6596094a -- Petr Vobornik From mbasti at redhat.com Tue Oct 21 08:57:24 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 21 Oct 2014 10:57:24 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <20141021075037.GZ5446@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> <5446024E.8010605@redhat.com> <54460AE1.3000301@redhat.com> <20141021075037.GZ5446@redhat.com> Message-ID: <54461FF4.3070204@redhat.com> IPA-4-1 patches attached jcholast-357 patch should be applied last If there is no objections I will rebase to master branch after ack -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-357-DNSSEC-remove-container_dnssec_keys.patch Type: text/x-patch Size: 2323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0117.3-Add-mask-unmask-methods-for-service.patch Type: text/x-patch Size: 3857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0135.3-DNSSEC-dependencies.patch Type: text/x-patch Size: 2742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0136.3-DNSSEC-schema.patch Type: text/x-patch Size: 20857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0137.3-DNSSEC-add-ipapk11helper-module.patch Type: text/x-patch Size: 87377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0138.3-DNSSEC-DNS-key-synchronization-daemon.patch Type: text/x-patch Size: 24598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0139.3-DNSSEC-opendnssec-services.patch Type: text/x-patch Size: 25999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0140.3-DNSSEC-platform-paths-and-services.patch Type: text/x-patch Size: 12139 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0141.3-DNSSEC-validate-forwarders.patch Type: text/x-patch Size: 16471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0142.3-DNSSEC-modify-named-service-to-support-dnssec.patch Type: text/x-patch Size: 6255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0143.3-DNSSEC-installation.patch Type: text/x-patch Size: 8684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0144.3-DNSSEC-uninstallation.patch Type: text/x-patch Size: 4906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0145.3-DNSSEC-upgrading.patch Type: text/x-patch Size: 4727 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0146.3-DNSSEC-ACI.patch Type: text/x-patch Size: 8999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0147.3-DNSSEC-add-ipa-dnssec-daemons.patch Type: text/x-patch Size: 92073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0148.3-DNSSEC-add-files-to-backup.patch Type: text/x-patch Size: 1968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0149.3-DNSSEC-change-link-to-ipa-page.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 21 09:18:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 11:18:38 +0200 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <20141021064148.GX5446@redhat.com> References: <20141020182548.GT5446@redhat.com> <5445FE17.3030603@redhat.com> <20141021064148.GX5446@redhat.com> Message-ID: <544624EE.1030703@redhat.com> On 10/21/2014 08:41 AM, Alexander Bokovoy wrote: > On Tue, 21 Oct 2014, Martin Kosek wrote: >> On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: >>> Hi! >>> >>> This patch is for ipa-4-1 branch to enable uniqueness plugin for uid >>> attribute for entries with objectclass posixAccount. >>> >>> We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for >>> posixAccounts it worked due to our design of a flat tree: as uid attribute is >>> part of the DN, renaming user entries >>> enforces uniqueness as MODRDN will fail if entry with the same uid >>> already exists. >>> >>> However, it is not enough for ID views -- we should be able to allow >>> ID view overrides for the same uid across multiple views and we should >>> be able to protect uid uniqueness more generally too. >>> >>> Implementation is done via update plugin that checks for existing uid >>> uniqueness plugin and if it is missing, it will be added. If plugin >>> exists, its configuration will be updated. >>> >>> I haven't added update specific to git master where staging subtree is >>> added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet >>> have the staging subtree. Currently master has broken setup for uid >>> uniqueness plugin that doesn't actually work anyway so it will be easier >>> to add upgrade over properly configured entry. >>> >>> https://fedorahosted.org/freeipa/ticket/4636 >> >> Hi Alexander, >> >> Thanks for the patch! However, I am personally not very confident with merging >> it right before 4.1 release, I thought it will be a simple update definition >> while this is a complex upgrade script which needs to be properly tested. >> >> I would rather wait for 4.1.x, especially given it does not block any 4.1 major >> feature in any way. > I disagree on it for multiple reasons and one of them is that 'a simple > update definition' is not right here. Attribute uniqueness plugin > supports three different types of setting its own arguments. These types > aren't mixable, you have to do switch from one to another. That's why > update plugin is the correct approach here. > > The update plugin I've wrote is very simple by itself. Ok, reviewing the patch now. I found 2 issues: 1) It is missing in plugins' Makefile.am so it won't be built properly 2) Instead of + if len(entries) == 0: use + if entries: 3) I think we should force "uid uniqueness" plugin creation in all cases so that we can expect it is there in future and for example do simple updates for it. So if existing active UID uniqueness is there, should we just remove uid from it's list of watched attributes, give warning and add our own controlled plugin? I am just trying to get rid of clashes with custom user configuration. 4) Because of 3), when I enabled "attribute uniqueness" plugin before upgrade, it did a strange franken-update and now I have an update plugin with DN "cn=attribute uniqueness,cn=plugins,cn=config" but "cn: uid uniqueness: inside. (BTW these concerns is where my simplicity expectations came from ;-) Martin From tbordaz at redhat.com Tue Oct 21 09:18:58 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 21 Oct 2014 11:18:58 +0200 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <20141020182548.GT5446@redhat.com> References: <20141020182548.GT5446@redhat.com> Message-ID: <54462502.1090505@redhat.com> On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: > Hi! > > This patch is for ipa-4-1 branch to enable uniqueness plugin for uid > attribute for entries with objectclass posixAccount. > > We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for > posixAccounts it worked due to our design of a flat tree: as uid > attribute is part of the DN, renaming user entries > enforces uniqueness as MODRDN will fail if entry with the same uid > already exists. > > However, it is not enough for ID views -- we should be able to allow > ID view overrides for the same uid across multiple views and we should > be able to protect uid uniqueness more generally too. > > Implementation is done via update plugin that checks for existing uid > uniqueness plugin and if it is missing, it will be added. If plugin > exists, its configuration will be updated. > > I haven't added update specific to git master where staging subtree is > added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet > have the staging subtree. Currently master has broken setup for uid > uniqueness plugin that doesn't actually work anyway so it will be easier > to add upgrade over properly configured entry. > > https://fedorahosted.org/freeipa/ticket/4636 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hello Alexander, In case the DS instance has an already enabled uniqueness 'uid' plugin. I wonder if there is a risk if the configuration of the plugin contains former attributes like nsslapd-pluginarg0. My understanding is that ldap.update_entry will keep those former attributes and add new config attribute like uniqueness-across-all-subtrees. If this is the case, DS will incorrectly configure the plugin because it does not support mixed configuration style. In that case it will consider only former attributes. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Oct 21 09:23:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Oct 2014 12:23:03 +0300 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <54462502.1090505@redhat.com> References: <20141020182548.GT5446@redhat.com> <54462502.1090505@redhat.com> Message-ID: <20141021092303.GB5446@redhat.com> On Tue, 21 Oct 2014, thierry bordaz wrote: >On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: >>Hi! >> >>This patch is for ipa-4-1 branch to enable uniqueness plugin for uid >>attribute for entries with objectclass posixAccount. >> >>We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for >>posixAccounts it worked due to our design of a flat tree: as uid >>attribute is part of the DN, renaming user entries >>enforces uniqueness as MODRDN will fail if entry with the same uid >>already exists. >> >>However, it is not enough for ID views -- we should be able to allow >>ID view overrides for the same uid across multiple views and we should >>be able to protect uid uniqueness more generally too. >> >>Implementation is done via update plugin that checks for existing uid >>uniqueness plugin and if it is missing, it will be added. If plugin >>exists, its configuration will be updated. >> >>I haven't added update specific to git master where staging subtree is >>added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet >>have the staging subtree. Currently master has broken setup for uid >>uniqueness plugin that doesn't actually work anyway so it will be easier >>to add upgrade over properly configured entry. >> >>https://fedorahosted.org/freeipa/ticket/4636 >> >> >> >>_______________________________________________ >>Freeipa-devel mailing list >>Freeipa-devel at redhat.com >>https://www.redhat.com/mailman/listinfo/freeipa-devel >Hello Alexander, > > In case the DS instance has an already enabled uniqueness 'uid' plugin. > I wonder if there is a risk if the configuration of the plugin > contains former attributes like nsslapd-pluginarg0. > My understanding is that ldap.update_entry will keep those former > attributes and add new config attribute like > uniqueness-across-all-subtrees. > If this is the case, DS will incorrectly configure the plugin > because it does not support mixed configuration style. > In that case it will consider only former attributes. Yes, this is why I'm saying the support for it will be added with a patch to master. We don't have uid uniqueness enabled in anything prior FreeIPA 4.1 and the code in git master is the only place where wrong config could come. I want to establish clear base from which the conversion will come. > -- / Alexander Bokovoy From abokovoy at redhat.com Tue Oct 21 09:35:25 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Oct 2014 12:35:25 +0300 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <544624EE.1030703@redhat.com> References: <20141020182548.GT5446@redhat.com> <5445FE17.3030603@redhat.com> <20141021064148.GX5446@redhat.com> <544624EE.1030703@redhat.com> Message-ID: <20141021093525.GC5446@redhat.com> On Tue, 21 Oct 2014, Martin Kosek wrote: >On 10/21/2014 08:41 AM, Alexander Bokovoy wrote: >> On Tue, 21 Oct 2014, Martin Kosek wrote: >>> On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> This patch is for ipa-4-1 branch to enable uniqueness plugin for uid >>>> attribute for entries with objectclass posixAccount. >>>> >>>> We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for >>>> posixAccounts it worked due to our design of a flat tree: as uid attribute is >>>> part of the DN, renaming user entries >>>> enforces uniqueness as MODRDN will fail if entry with the same uid >>>> already exists. >>>> >>>> However, it is not enough for ID views -- we should be able to allow >>>> ID view overrides for the same uid across multiple views and we should >>>> be able to protect uid uniqueness more generally too. >>>> >>>> Implementation is done via update plugin that checks for existing uid >>>> uniqueness plugin and if it is missing, it will be added. If plugin >>>> exists, its configuration will be updated. >>>> >>>> I haven't added update specific to git master where staging subtree is >>>> added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet >>>> have the staging subtree. Currently master has broken setup for uid >>>> uniqueness plugin that doesn't actually work anyway so it will be easier >>>> to add upgrade over properly configured entry. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4636 >>> >>> Hi Alexander, >>> >>> Thanks for the patch! However, I am personally not very confident with merging >>> it right before 4.1 release, I thought it will be a simple update definition >>> while this is a complex upgrade script which needs to be properly tested. >>> >>> I would rather wait for 4.1.x, especially given it does not block any 4.1 major >>> feature in any way. >> I disagree on it for multiple reasons and one of them is that 'a simple >> update definition' is not right here. Attribute uniqueness plugin >> supports three different types of setting its own arguments. These types >> aren't mixable, you have to do switch from one to another. That's why >> update plugin is the correct approach here. >> >> The update plugin I've wrote is very simple by itself. > >Ok, reviewing the patch now. I found 2 issues: > >1) It is missing in plugins' Makefile.am so it won't be built properly > >2) Instead of >+ if len(entries) == 0: >use >+ if entries: You mean 'if not entries:'? Will fix. >3) I think we should force "uid uniqueness" plugin creation in all cases so >that we can expect it is there in future and for example do simple updates for it. It does enforce it creating already. The only case that is not handled right now is the case of already existing multiple uid uniqueness plugin instances which I explicitly want to handle in git master and then merge back to 4.1 as a backport -- we only have any chance to encounter this case with current git master. >So if existing active UID uniqueness is there, should we just remove uid from >it's list of watched attributes, give warning and add our own controlled plugin? No. There could be multiple uid uniqueness plugin instances, looking for different subtrees, potentially with different top level object classes and different object class filtering. >I am just trying to get rid of clashes with custom user configuration. I understand that, I'll handle it in git master version. Right now we didn't set up any of uid uniqueness and chances touching any custom configuration like that are low, looking into my experience with existing deployments. >4) Because of 3), when I enabled "attribute uniqueness" plugin before upgrade, >it did a strange franken-update and now I have an update plugin with DN >"cn=attribute uniqueness,cn=plugins,cn=config" but "cn: uid uniqueness: inside. Good catch. I'll fix this part. >(BTW these concerns is where my simplicity expectations came from ;-) Note that now you realize the whole deal is not that simple as you thought. ;) New patch attached. -- / Alexander Bokovoy -------------- next part -------------- From 0d5529634b16b948f997dc9855e0036b6be14595 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 20 Oct 2014 21:01:33 +0300 Subject: [PATCH] updater: enable uid uniqueness plugin for posixAccounts https://fedorahosted.org/freeipa/ticket/4636 --- ipaserver/install/plugins/update_uniqueness.py | 115 +++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 ipaserver/install/plugins/update_uniqueness.py diff --git a/ipaserver/install/plugins/update_uniqueness.py b/ipaserver/install/plugins/update_uniqueness.py new file mode 100644 index 0000000..a1b4638 --- /dev/null +++ b/ipaserver/install/plugins/update_uniqueness.py @@ -0,0 +1,115 @@ +# Authors: +# Alexander Bokovoy +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# 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 PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +from ipaserver.install.plugins import MIDDLE +from ipaserver.install.plugins.baseupdate import PostUpdate +from ipalib import api, errors +from ipapython.dn import DN +from ipapython.ipa_log_manager import * + + +class update_uid_uniqueness(PostUpdate): + """ + Create plugin configuration to ensure uid uniqueness + """ + order = MIDDLE + + uid_uniqueness_dn = DN(('cn', 'uid uniqueness'), ('cn', 'plugins'), ('cn', 'config')) + + uid_uniqueness_template = { + 'objectClass' : ["top", "nsSlapdPlugin", "extensibleObject"], + 'cn' : 'uid uniqueness', + 'nsslapd-pluginPath' : 'libattr-unique-plugin', + 'nsslapd-pluginInitfunc' : 'NSUniqueAttr_Init', + 'nsslapd-pluginType' : 'betxnpreoperation', + 'nsslapd-pluginEnabled' : 'on', + 'uniqueness-attribute-name' : 'uid', + 'uniqueness-subtrees' : 'dc=example,dc=com', + 'uniqueness-across-all-subtrees': 'off', + 'uniqueness-subtree-entries-oc' : 'posixAccount', + 'nsslapd-plugin-depends-on-type': 'database', + 'nsslapd-pluginId' : 'none', + 'nsslapd-pluginVersion' : 'none', + 'nsslapd-pluginVendor' : 'none', + 'nsslapd-pluginDescription' : 'none', + } + + def execute(self, **options): + ldap = self.obj.backend + + config_dn = DN(('cn','config')) + search_filter = ("(&(objectclass=nsslapdplugin)" + "(nsslapd-pluginpath=libattr-unique-plugin)" + "(nsslapd-pluginInitfunc=NSUniqueAttr_Init)" + "(!(nsslapd-pluginenabled=off))" + "(|(uniqueness-attribute-name=uid)(nsslapd-plugarg0=uid)))") + root_logger.debug("update_uid_uniqueness: search for existing uid uniqueness " + "configuration") + + try: + (entries, truncated) = ldap.find_entries(search_filter, ['*'], config_dn, + time_limit=0, size_limit=0) + except errors.NotFound: + # add entry + entries = [] + except errors.ExecutionError, e: + root_logger.error("update_uid_uniqueness: cannot retrieve " + "list of uniqueness plugin instances: %s", e) + return (False, False, []) + + if len(entries) > 1: + root_logger.error("update_uid_uniqueness: found more than one uid " + "uniqueness plugin definition: %s", [str(x.dn) for x in entries]) + return (False, False, []) + + error = False + if not entries: + root_logger.debug("update_uid_uniqueness: adding new uid uniqueness " + "plugin definition") + uid_uniqueness_plugin_attrs = dict(self.uid_uniqueness_template) + uid_uniqueness_plugin_attrs['uniqueness-subtrees'] = api.env.basedn + uid_uniqueness_plugin = ldap.make_entry(self.uid_uniqueness_dn, uid_uniqueness_plugin_attrs) + + try: + ldap.add_entry(uid_uniqueness_plugin) + except errors.ExecutionError, e: + root_logger.debug("update_uid_uniqueness: cannot " + "create uid uniqueness plugin entry: %s", e) + error = True + else: + root_logger.debug("update_uid_uniqueness: updating existing uid uniqueness " + "plugin definition") + uid_uniqueness_plugin_attrs = dict(self.uid_uniqueness_template) + uid_uniqueness_plugin_attrs['uniqueness-subtrees'] = api.env.basedn + uid_uniqueness_plugin_attrs['cn'] = entries[0]['cn'] + uid_uniqueness_plugin = ldap.make_entry(entries[0].dn, uid_uniqueness_plugin_attrs) + + try: + ldap.update_entry(uid_uniqueness_plugin) + except errors.ExecutionError, e: + root_logger.debug("update_uid_uniqueness: cannot " + "update uid uniqueness plugin entry: %s", e) + error = True + + if error: + root_logger.error("update_uid_uniqueness: error(s)" + "detected during plugin update") + return (True, False, []) + +api.register(update_uid_uniqueness) -- 2.1.0 From dkupka at redhat.com Tue Oct 21 10:14:52 2014 From: dkupka at redhat.com (David Kupka) Date: Tue, 21 Oct 2014 12:14:52 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <54461FF4.3070204@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> <5446024E.8010605@redhat.com> <54460AE1.3000301@redhat.com> <20141021075037.GZ5446@redhat.com> <54461FF4.3070204@redhat.com> Message-ID: <5446321C.2010005@redhat.com> On 10/21/2014 10:57 AM, Martin Basti wrote: > > > IPA-4-1 patches attached > > jcholast-357 patch should be applied last > > If there is no objections I will rebase to master branch after ack > > Works good for me but I didn't read the code. ACK for functionality. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- David Kupka From mkosek at redhat.com Tue Oct 21 10:20:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 12:20:54 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <5446321C.2010005@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> <5446024E.8010605@redhat.com> <54460AE1.3000301@redhat.com> <20141021075037.GZ5446@redhat.com> <54461FF4.3070204@redhat.com> <5446321C.2010005@redhat.com> Message-ID: <54463386.9050809@redhat.com> On 10/21/2014 12:14 PM, David Kupka wrote: > On 10/21/2014 10:57 AM, Martin Basti wrote: >> >> >> IPA-4-1 patches attached >> >> jcholast-357 patch should be applied last >> >> If there is no objections I will rebase to master branch after ack >> >> > > Works good for me but I didn't read the code. ACK for functionality. Honza also gave me an offline ACK for his way to lunch :-) So: Pushed to ipa-4-1: b84fc92fd7321ed249d0d7fc4d5bd29c111536fd MartinB, please also provide rebase for master branch. Martin From mbasti at redhat.com Tue Oct 21 10:21:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 21 Oct 2014 12:21:01 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <5446321C.2010005@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> <5446024E.8010605@redhat.com> <54460AE1.3000301@redhat.com> <20141021075037.GZ5446@redhat.com> <54461FF4.3070204@redhat.com> <5446321C.2010005@redhat.com> Message-ID: <5446338D.3090003@redhat.com> On 21/10/14 12:14, David Kupka wrote: > On 10/21/2014 10:57 AM, Martin Basti wrote: >> >> >> IPA-4-1 patches attached >> >> jcholast-357 patch should be applied last >> >> If there is no objections I will rebase to master branch after ack >> >> > > Works good for me but I didn't read the code. ACK for functionality. > >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Patches for master branch atached As before jcholast patch last -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-357-DNSSEC-remove-container_dnssec_keys.patch Type: text/x-patch Size: 2323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0117.3-Add-mask-unmask-methods-for-service.patch Type: text/x-patch Size: 3857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0135.3-DNSSEC-dependencies.patch Type: text/x-patch Size: 2742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0136.3-DNSSEC-schema.patch Type: text/x-patch Size: 20857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0137.3-DNSSEC-add-ipapk11helper-module.patch Type: text/x-patch Size: 87377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0138.3-DNSSEC-DNS-key-synchronization-daemon.patch Type: text/x-patch Size: 24598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0139.3-DNSSEC-opendnssec-services.patch Type: text/x-patch Size: 25999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0140.3-DNSSEC-platform-paths-and-services.patch Type: text/x-patch Size: 12077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0141.3-DNSSEC-validate-forwarders.patch Type: text/x-patch Size: 16471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0142.3-DNSSEC-modify-named-service-to-support-dnssec.patch Type: text/x-patch Size: 6255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0143.3-DNSSEC-installation.patch Type: text/x-patch Size: 8649 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0144.3-DNSSEC-uninstallation.patch Type: text/x-patch Size: 4831 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0145.3-DNSSEC-upgrading.patch Type: text/x-patch Size: 4727 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0146.3-DNSSEC-ACI.patch Type: text/x-patch Size: 8999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0147.3-DNSSEC-add-ipa-dnssec-daemons.patch Type: text/x-patch Size: 92073 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0148.3-DNSSEC-add-files-to-backup.patch Type: text/x-patch Size: 1968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0149.3-DNSSEC-change-link-to-ipa-page.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 21 10:27:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 12:27:40 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <5446338D.3090003@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> <5446024E.8010605@redhat.com> <54460AE1.3000301@redhat.com> <20141021075037.GZ5446@redhat.com> <54461FF4.3070204@redhat.com> <5446321C.2010005@redhat.com> <5446338D.3090003@redhat.com> Message-ID: <5446351C.3040708@redhat.com> On 10/21/2014 12:21 PM, Martin Basti wrote: > On 21/10/14 12:14, David Kupka wrote: >> On 10/21/2014 10:57 AM, Martin Basti wrote: >>> >>> >>> IPA-4-1 patches attached >>> >>> jcholast-357 patch should be applied last >>> >>> If there is no objections I will rebase to master branch after ack >>> >>> >> >> Works good for me but I didn't read the code. ACK for functionality. >> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> > Patches for master branch atached > As before jcholast patch last > You were faster than me :-) Pushed to master: 10725033c66cfd89340dcc95085cf1daaa18b4c0 Thanks! Martin From abokovoy at redhat.com Tue Oct 21 10:41:19 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Oct 2014 13:41:19 +0300 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <20141021093525.GC5446@redhat.com> References: <20141020182548.GT5446@redhat.com> <5445FE17.3030603@redhat.com> <20141021064148.GX5446@redhat.com> <544624EE.1030703@redhat.com> <20141021093525.GC5446@redhat.com> Message-ID: <20141021104119.GE5446@redhat.com> On Tue, 21 Oct 2014, Alexander Bokovoy wrote: > On Tue, 21 Oct 2014, Martin Kosek wrote: >> On 10/21/2014 08:41 AM, Alexander Bokovoy wrote: >>> On Tue, 21 Oct 2014, Martin Kosek wrote: >>>> On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: >>>>> Hi! >>>>> >>>>> This patch is for ipa-4-1 branch to enable uniqueness plugin for uid >>>>> attribute for entries with objectclass posixAccount. >>>>> >>>>> We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for >>>>> posixAccounts it worked due to our design of a flat tree: as uid attribute is >>>>> part of the DN, renaming user entries >>>>> enforces uniqueness as MODRDN will fail if entry with the same uid >>>>> already exists. >>>>> >>>>> However, it is not enough for ID views -- we should be able to allow >>>>> ID view overrides for the same uid across multiple views and we should >>>>> be able to protect uid uniqueness more generally too. >>>>> >>>>> Implementation is done via update plugin that checks for existing uid >>>>> uniqueness plugin and if it is missing, it will be added. If plugin >>>>> exists, its configuration will be updated. >>>>> >>>>> I haven't added update specific to git master where staging subtree is >>>>> added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet >>>>> have the staging subtree. Currently master has broken setup for uid >>>>> uniqueness plugin that doesn't actually work anyway so it will be easier >>>>> to add upgrade over properly configured entry. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4636 >>>> >>>> Hi Alexander, >>>> >>>> Thanks for the patch! However, I am personally not very confident with merging >>>> it right before 4.1 release, I thought it will be a simple update definition >>>> while this is a complex upgrade script which needs to be properly tested. >>>> >>>> I would rather wait for 4.1.x, especially given it does not block any 4.1 major >>>> feature in any way. >>> I disagree on it for multiple reasons and one of them is that 'a simple >>> update definition' is not right here. Attribute uniqueness plugin >>> supports three different types of setting its own arguments. These types >>> aren't mixable, you have to do switch from one to another. That's why >>> update plugin is the correct approach here. >>> >>> The update plugin I've wrote is very simple by itself. >> >> Ok, reviewing the patch now. I found 2 issues: >> >> 1) It is missing in plugins' Makefile.am so it won't be built properly >> >> 2) Instead of >> + if len(entries) == 0: >> use >> + if entries: > You mean 'if not entries:'? Will fix. > > >> 3) I think we should force "uid uniqueness" plugin creation in all cases so >> that we can expect it is there in future and for example do simple updates for it. > It does enforce it creating already. The only case that is not handled > right now is the case of already existing multiple uid uniqueness > plugin instances which I explicitly want to handle in git master and > then merge back to 4.1 as a backport -- we only have any chance to > encounter this case with current git master. > >> So if existing active UID uniqueness is there, should we just remove uid from >> it's list of watched attributes, give warning and add our own controlled plugin? > No. There could be multiple uid uniqueness plugin instances, looking for > different subtrees, potentially with different top level object classes > and different object class filtering. > >> I am just trying to get rid of clashes with custom user configuration. > I understand that, I'll handle it in git master version. Right now we > didn't set up any of uid uniqueness and chances touching any custom > configuration like that are low, looking into my experience with > existing deployments. > > >> 4) Because of 3), when I enabled "attribute uniqueness" plugin before upgrade, >> it did a strange franken-update and now I have an update plugin with DN >> "cn=attribute uniqueness,cn=plugins,cn=config" but "cn: uid uniqueness: inside. > Good catch. I'll fix this part. > >> (BTW these concerns is where my simplicity expectations came from ;-) > Note that now you realize the whole deal is not that simple as you > thought. ;) > > New patch attached. Missed Makefile.am part. -- / Alexander Bokovoy -------------- next part -------------- From 7951e57ca52d38497b0a87610685f173ebb558a3 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 20 Oct 2014 21:01:33 +0300 Subject: [PATCH] updater: enable uid uniqueness plugin for posixAccounts https://fedorahosted.org/freeipa/ticket/4636 --- ipaserver/install/plugins/Makefile.am | 1 + ipaserver/install/plugins/update_uniqueness.py | 115 +++++++++++++++++++++++++ 2 files changed, 116 insertions(+) create mode 100644 ipaserver/install/plugins/update_uniqueness.py diff --git a/ipaserver/install/plugins/Makefile.am b/ipaserver/install/plugins/Makefile.am index 7cf0495..635877d 100644 --- a/ipaserver/install/plugins/Makefile.am +++ b/ipaserver/install/plugins/Makefile.am @@ -12,6 +12,7 @@ app_PYTHON = \ update_anonymous_aci.py \ update_pacs.py \ ca_renewal_master.py \ + update_uniqueness.py \ $(NULL) EXTRA_DIST = \ diff --git a/ipaserver/install/plugins/update_uniqueness.py b/ipaserver/install/plugins/update_uniqueness.py new file mode 100644 index 0000000..a1b4638 --- /dev/null +++ b/ipaserver/install/plugins/update_uniqueness.py @@ -0,0 +1,115 @@ +# Authors: +# Alexander Bokovoy +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# 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 PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +from ipaserver.install.plugins import MIDDLE +from ipaserver.install.plugins.baseupdate import PostUpdate +from ipalib import api, errors +from ipapython.dn import DN +from ipapython.ipa_log_manager import * + + +class update_uid_uniqueness(PostUpdate): + """ + Create plugin configuration to ensure uid uniqueness + """ + order = MIDDLE + + uid_uniqueness_dn = DN(('cn', 'uid uniqueness'), ('cn', 'plugins'), ('cn', 'config')) + + uid_uniqueness_template = { + 'objectClass' : ["top", "nsSlapdPlugin", "extensibleObject"], + 'cn' : 'uid uniqueness', + 'nsslapd-pluginPath' : 'libattr-unique-plugin', + 'nsslapd-pluginInitfunc' : 'NSUniqueAttr_Init', + 'nsslapd-pluginType' : 'betxnpreoperation', + 'nsslapd-pluginEnabled' : 'on', + 'uniqueness-attribute-name' : 'uid', + 'uniqueness-subtrees' : 'dc=example,dc=com', + 'uniqueness-across-all-subtrees': 'off', + 'uniqueness-subtree-entries-oc' : 'posixAccount', + 'nsslapd-plugin-depends-on-type': 'database', + 'nsslapd-pluginId' : 'none', + 'nsslapd-pluginVersion' : 'none', + 'nsslapd-pluginVendor' : 'none', + 'nsslapd-pluginDescription' : 'none', + } + + def execute(self, **options): + ldap = self.obj.backend + + config_dn = DN(('cn','config')) + search_filter = ("(&(objectclass=nsslapdplugin)" + "(nsslapd-pluginpath=libattr-unique-plugin)" + "(nsslapd-pluginInitfunc=NSUniqueAttr_Init)" + "(!(nsslapd-pluginenabled=off))" + "(|(uniqueness-attribute-name=uid)(nsslapd-plugarg0=uid)))") + root_logger.debug("update_uid_uniqueness: search for existing uid uniqueness " + "configuration") + + try: + (entries, truncated) = ldap.find_entries(search_filter, ['*'], config_dn, + time_limit=0, size_limit=0) + except errors.NotFound: + # add entry + entries = [] + except errors.ExecutionError, e: + root_logger.error("update_uid_uniqueness: cannot retrieve " + "list of uniqueness plugin instances: %s", e) + return (False, False, []) + + if len(entries) > 1: + root_logger.error("update_uid_uniqueness: found more than one uid " + "uniqueness plugin definition: %s", [str(x.dn) for x in entries]) + return (False, False, []) + + error = False + if not entries: + root_logger.debug("update_uid_uniqueness: adding new uid uniqueness " + "plugin definition") + uid_uniqueness_plugin_attrs = dict(self.uid_uniqueness_template) + uid_uniqueness_plugin_attrs['uniqueness-subtrees'] = api.env.basedn + uid_uniqueness_plugin = ldap.make_entry(self.uid_uniqueness_dn, uid_uniqueness_plugin_attrs) + + try: + ldap.add_entry(uid_uniqueness_plugin) + except errors.ExecutionError, e: + root_logger.debug("update_uid_uniqueness: cannot " + "create uid uniqueness plugin entry: %s", e) + error = True + else: + root_logger.debug("update_uid_uniqueness: updating existing uid uniqueness " + "plugin definition") + uid_uniqueness_plugin_attrs = dict(self.uid_uniqueness_template) + uid_uniqueness_plugin_attrs['uniqueness-subtrees'] = api.env.basedn + uid_uniqueness_plugin_attrs['cn'] = entries[0]['cn'] + uid_uniqueness_plugin = ldap.make_entry(entries[0].dn, uid_uniqueness_plugin_attrs) + + try: + ldap.update_entry(uid_uniqueness_plugin) + except errors.ExecutionError, e: + root_logger.debug("update_uid_uniqueness: cannot " + "update uid uniqueness plugin entry: %s", e) + error = True + + if error: + root_logger.error("update_uid_uniqueness: error(s)" + "detected during plugin update") + return (True, False, []) + +api.register(update_uid_uniqueness) -- 2.1.0 From mkosek at redhat.com Tue Oct 21 11:10:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 13:10:38 +0200 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <20141021104119.GE5446@redhat.com> References: <20141020182548.GT5446@redhat.com> <5445FE17.3030603@redhat.com> <20141021064148.GX5446@redhat.com> <544624EE.1030703@redhat.com> <20141021093525.GC5446@redhat.com> <20141021104119.GE5446@redhat.com> Message-ID: <54463F2E.8090105@redhat.com> On 10/21/2014 12:41 PM, Alexander Bokovoy wrote: > On Tue, 21 Oct 2014, Alexander Bokovoy wrote: >> On Tue, 21 Oct 2014, Martin Kosek wrote: >>> On 10/21/2014 08:41 AM, Alexander Bokovoy wrote: >>>> On Tue, 21 Oct 2014, Martin Kosek wrote: >>>>> On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: >>>>>> Hi! >>>>>> >>>>>> This patch is for ipa-4-1 branch to enable uniqueness plugin for uid >>>>>> attribute for entries with objectclass posixAccount. >>>>>> >>>>>> We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for >>>>>> posixAccounts it worked due to our design of a flat tree: as uid >>>>>> attribute is >>>>>> part of the DN, renaming user entries >>>>>> enforces uniqueness as MODRDN will fail if entry with the same uid >>>>>> already exists. >>>>>> >>>>>> However, it is not enough for ID views -- we should be able to allow >>>>>> ID view overrides for the same uid across multiple views and we should >>>>>> be able to protect uid uniqueness more generally too. >>>>>> >>>>>> Implementation is done via update plugin that checks for existing uid >>>>>> uniqueness plugin and if it is missing, it will be added. If plugin >>>>>> exists, its configuration will be updated. >>>>>> >>>>>> I haven't added update specific to git master where staging subtree is >>>>>> added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet >>>>>> have the staging subtree. Currently master has broken setup for uid >>>>>> uniqueness plugin that doesn't actually work anyway so it will be easier >>>>>> to add upgrade over properly configured entry. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4636 >>>>> >>>>> Hi Alexander, >>>>> >>>>> Thanks for the patch! However, I am personally not very confident with >>>>> merging >>>>> it right before 4.1 release, I thought it will be a simple update definition >>>>> while this is a complex upgrade script which needs to be properly tested. >>>>> >>>>> I would rather wait for 4.1.x, especially given it does not block any 4.1 >>>>> major >>>>> feature in any way. >>>> I disagree on it for multiple reasons and one of them is that 'a simple >>>> update definition' is not right here. Attribute uniqueness plugin >>>> supports three different types of setting its own arguments. These types >>>> aren't mixable, you have to do switch from one to another. That's why >>>> update plugin is the correct approach here. >>>> >>>> The update plugin I've wrote is very simple by itself. >>> >>> Ok, reviewing the patch now. I found 2 issues: >>> >>> 1) It is missing in plugins' Makefile.am so it won't be built properly >>> >>> 2) Instead of >>> + if len(entries) == 0: >>> use >>> + if entries: >> You mean 'if not entries:'? Will fix. >> >> >>> 3) I think we should force "uid uniqueness" plugin creation in all cases so >>> that we can expect it is there in future and for example do simple updates >>> for it. >> It does enforce it creating already. The only case that is not handled >> right now is the case of already existing multiple uid uniqueness >> plugin instances which I explicitly want to handle in git master and >> then merge back to 4.1 as a backport -- we only have any chance to >> encounter this case with current git master. >> >>> So if existing active UID uniqueness is there, should we just remove uid from >>> it's list of watched attributes, give warning and add our own controlled >>> plugin? >> No. There could be multiple uid uniqueness plugin instances, looking for >> different subtrees, potentially with different top level object classes >> and different object class filtering. >> >>> I am just trying to get rid of clashes with custom user configuration. >> I understand that, I'll handle it in git master version. Right now we >> didn't set up any of uid uniqueness and chances touching any custom >> configuration like that are low, looking into my experience with >> existing deployments. >> >> >>> 4) Because of 3), when I enabled "attribute uniqueness" plugin before upgrade, >>> it did a strange franken-update and now I have an update plugin with DN >>> "cn=attribute uniqueness,cn=plugins,cn=config" but "cn: uid uniqueness: inside. >> Good catch. I'll fix this part. >> >>> (BTW these concerns is where my simplicity expectations came from ;-) >> Note that now you realize the whole deal is not that simple as you >> thought. ;) >> >> New patch attached. > Missed Makefile.am part. > The + if not entries: path works looks ok. However, I am still concerned about the situation when you detect existing UID plugin. You basically create a new LDAP entry with the same DN and then try to overwrite the original one. I do not think this is how the LDAP framework works. Petr/Honza, is it? I thought the right way for this branch would be to just update selected attributes of the LDAPEntry read from LDAP (entries[0] in your case) and then call ldap.update_entry(). This way, the entry gets just partially updated, for example nsslapd-pluginVersion stays the same. BTW, I do not think that + 'nsslapd-pluginId' : 'none', + 'nsslapd-pluginVersion' : 'none', + 'nsslapd-pluginVendor' : 'none', + 'nsslapd-pluginDescription' : 'none', should be left to be none even in the first branch. Given this is the last patch we are waiting for before 4.1 release, I still think we should reconsider moving it to 4.1.1, given the issues. Martin From pviktori at redhat.com Tue Oct 21 11:11:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 21 Oct 2014 13:11:22 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <5445286B.5020502@redhat.com> References: <5445286B.5020502@redhat.com> Message-ID: <54463F5A.8010206@redhat.com> On 10/20/2014 05:21 PM, Martin Basti wrote: > Hello! Hold your hats, DNSSEC patches are here. > > Martin^2, Petr^2 > New compiler warnings: library.c:72: ISO C forbids conversion of object pointer to function pointer type [-Wpedantic] p11helper.c:500: passing argument 1 of 'loadLibrary' discards 'const' qualifier from pointer target type [enabled by default] p11helper.c:1667: pointer targets in passing argument 3 of 'PyString_AsStringAndSize' differ in signedness [-Wpointer-sign] Should I file a ticket for these? -- Petr? From jcholast at redhat.com Tue Oct 21 11:28:49 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 21 Oct 2014 13:28:49 +0200 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <54463F2E.8090105@redhat.com> References: <20141020182548.GT5446@redhat.com> <5445FE17.3030603@redhat.com> <20141021064148.GX5446@redhat.com> <544624EE.1030703@redhat.com> <20141021093525.GC5446@redhat.com> <20141021104119.GE5446@redhat.com> <54463F2E.8090105@redhat.com> Message-ID: <54464371.5070207@redhat.com> Dne 21.10.2014 v 13:10 Martin Kosek napsal(a): > On 10/21/2014 12:41 PM, Alexander Bokovoy wrote: >> On Tue, 21 Oct 2014, Alexander Bokovoy wrote: >>> On Tue, 21 Oct 2014, Martin Kosek wrote: >>>> On 10/21/2014 08:41 AM, Alexander Bokovoy wrote: >>>>> On Tue, 21 Oct 2014, Martin Kosek wrote: >>>>>> On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: >>>>>>> Hi! >>>>>>> >>>>>>> This patch is for ipa-4-1 branch to enable uniqueness plugin for uid >>>>>>> attribute for entries with objectclass posixAccount. >>>>>>> >>>>>>> We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for >>>>>>> posixAccounts it worked due to our design of a flat tree: as uid >>>>>>> attribute is >>>>>>> part of the DN, renaming user entries >>>>>>> enforces uniqueness as MODRDN will fail if entry with the same uid >>>>>>> already exists. >>>>>>> >>>>>>> However, it is not enough for ID views -- we should be able to allow >>>>>>> ID view overrides for the same uid across multiple views and we should >>>>>>> be able to protect uid uniqueness more generally too. >>>>>>> >>>>>>> Implementation is done via update plugin that checks for existing uid >>>>>>> uniqueness plugin and if it is missing, it will be added. If plugin >>>>>>> exists, its configuration will be updated. >>>>>>> >>>>>>> I haven't added update specific to git master where staging subtree is >>>>>>> added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet >>>>>>> have the staging subtree. Currently master has broken setup for uid >>>>>>> uniqueness plugin that doesn't actually work anyway so it will be easier >>>>>>> to add upgrade over properly configured entry. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4636 >>>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> Thanks for the patch! However, I am personally not very confident with >>>>>> merging >>>>>> it right before 4.1 release, I thought it will be a simple update definition >>>>>> while this is a complex upgrade script which needs to be properly tested. >>>>>> >>>>>> I would rather wait for 4.1.x, especially given it does not block any 4.1 >>>>>> major >>>>>> feature in any way. >>>>> I disagree on it for multiple reasons and one of them is that 'a simple >>>>> update definition' is not right here. Attribute uniqueness plugin >>>>> supports three different types of setting its own arguments. These types >>>>> aren't mixable, you have to do switch from one to another. That's why >>>>> update plugin is the correct approach here. >>>>> >>>>> The update plugin I've wrote is very simple by itself. >>>> >>>> Ok, reviewing the patch now. I found 2 issues: >>>> >>>> 1) It is missing in plugins' Makefile.am so it won't be built properly >>>> >>>> 2) Instead of >>>> + if len(entries) == 0: >>>> use >>>> + if entries: >>> You mean 'if not entries:'? Will fix. >>> >>> >>>> 3) I think we should force "uid uniqueness" plugin creation in all cases so >>>> that we can expect it is there in future and for example do simple updates >>>> for it. >>> It does enforce it creating already. The only case that is not handled >>> right now is the case of already existing multiple uid uniqueness >>> plugin instances which I explicitly want to handle in git master and >>> then merge back to 4.1 as a backport -- we only have any chance to >>> encounter this case with current git master. >>> >>>> So if existing active UID uniqueness is there, should we just remove uid from >>>> it's list of watched attributes, give warning and add our own controlled >>>> plugin? >>> No. There could be multiple uid uniqueness plugin instances, looking for >>> different subtrees, potentially with different top level object classes >>> and different object class filtering. >>> >>>> I am just trying to get rid of clashes with custom user configuration. >>> I understand that, I'll handle it in git master version. Right now we >>> didn't set up any of uid uniqueness and chances touching any custom >>> configuration like that are low, looking into my experience with >>> existing deployments. >>> >>> >>>> 4) Because of 3), when I enabled "attribute uniqueness" plugin before upgrade, >>>> it did a strange franken-update and now I have an update plugin with DN >>>> "cn=attribute uniqueness,cn=plugins,cn=config" but "cn: uid uniqueness: inside. >>> Good catch. I'll fix this part. >>> >>>> (BTW these concerns is where my simplicity expectations came from ;-) >>> Note that now you realize the whole deal is not that simple as you >>> thought. ;) >>> >>> New patch attached. >> Missed Makefile.am part. >> > > The > + if not entries: > path works looks ok. > > However, I am still concerned about the situation when you detect existing UID > plugin. > > You basically create a new LDAP entry with the same DN and then try to > overwrite the original one. I do not think this is how the LDAP framework > works. Petr/Honza, is it? It will work, but updating the old entry object and calling update_entry on it would be nicer. The difference is that with the current approach, the generated modlist will contain MOD_REPLACE for every attribute in the entry, whereas updating the original entry will result in a modlist with MOD_ADD/MOD_DELETE only for the attributes which were actually modified. -- Jan Cholasta From mkosek at redhat.com Tue Oct 21 11:51:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 13:51:04 +0200 Subject: [Freeipa-devel] [PATCH, 4.1] 0166 updater: enable uid uniqueness plugin for posixAccount objects In-Reply-To: <54464371.5070207@redhat.com> References: <20141020182548.GT5446@redhat.com> <5445FE17.3030603@redhat.com> <20141021064148.GX5446@redhat.com> <544624EE.1030703@redhat.com> <20141021093525.GC5446@redhat.com> <20141021104119.GE5446@redhat.com> <54463F2E.8090105@redhat.com> <54464371.5070207@redhat.com> Message-ID: <544648A8.4020206@redhat.com> On 10/21/2014 01:28 PM, Jan Cholasta wrote: > Dne 21.10.2014 v 13:10 Martin Kosek napsal(a): >> On 10/21/2014 12:41 PM, Alexander Bokovoy wrote: >>> On Tue, 21 Oct 2014, Alexander Bokovoy wrote: >>>> On Tue, 21 Oct 2014, Martin Kosek wrote: >>>>> On 10/21/2014 08:41 AM, Alexander Bokovoy wrote: >>>>>> On Tue, 21 Oct 2014, Martin Kosek wrote: >>>>>>> On 10/20/2014 08:25 PM, Alexander Bokovoy wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> This patch is for ipa-4-1 branch to enable uniqueness plugin for uid >>>>>>>> attribute for entries with objectclass posixAccount. >>>>>>>> >>>>>>>> We don't have uid uniqueness enforced in FreeIPA < 4.1 yet but for >>>>>>>> posixAccounts it worked due to our design of a flat tree: as uid >>>>>>>> attribute is >>>>>>>> part of the DN, renaming user entries >>>>>>>> enforces uniqueness as MODRDN will fail if entry with the same uid >>>>>>>> already exists. >>>>>>>> >>>>>>>> However, it is not enough for ID views -- we should be able to allow >>>>>>>> ID view overrides for the same uid across multiple views and we should >>>>>>>> be able to protect uid uniqueness more generally too. >>>>>>>> >>>>>>>> Implementation is done via update plugin that checks for existing uid >>>>>>>> uniqueness plugin and if it is missing, it will be added. If plugin >>>>>>>> exists, its configuration will be updated. >>>>>>>> >>>>>>>> I haven't added update specific to git master where staging subtree is >>>>>>>> added but I'll do that after FreeIPA 4.1 release as in 4.1 we don't yet >>>>>>>> have the staging subtree. Currently master has broken setup for uid >>>>>>>> uniqueness plugin that doesn't actually work anyway so it will be easier >>>>>>>> to add upgrade over properly configured entry. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4636 >>>>>>> >>>>>>> Hi Alexander, >>>>>>> >>>>>>> Thanks for the patch! However, I am personally not very confident with >>>>>>> merging >>>>>>> it right before 4.1 release, I thought it will be a simple update >>>>>>> definition >>>>>>> while this is a complex upgrade script which needs to be properly tested. >>>>>>> >>>>>>> I would rather wait for 4.1.x, especially given it does not block any 4.1 >>>>>>> major >>>>>>> feature in any way. >>>>>> I disagree on it for multiple reasons and one of them is that 'a simple >>>>>> update definition' is not right here. Attribute uniqueness plugin >>>>>> supports three different types of setting its own arguments. These types >>>>>> aren't mixable, you have to do switch from one to another. That's why >>>>>> update plugin is the correct approach here. >>>>>> >>>>>> The update plugin I've wrote is very simple by itself. >>>>> >>>>> Ok, reviewing the patch now. I found 2 issues: >>>>> >>>>> 1) It is missing in plugins' Makefile.am so it won't be built properly >>>>> >>>>> 2) Instead of >>>>> + if len(entries) == 0: >>>>> use >>>>> + if entries: >>>> You mean 'if not entries:'? Will fix. >>>> >>>> >>>>> 3) I think we should force "uid uniqueness" plugin creation in all cases so >>>>> that we can expect it is there in future and for example do simple updates >>>>> for it. >>>> It does enforce it creating already. The only case that is not handled >>>> right now is the case of already existing multiple uid uniqueness >>>> plugin instances which I explicitly want to handle in git master and >>>> then merge back to 4.1 as a backport -- we only have any chance to >>>> encounter this case with current git master. >>>> >>>>> So if existing active UID uniqueness is there, should we just remove uid from >>>>> it's list of watched attributes, give warning and add our own controlled >>>>> plugin? >>>> No. There could be multiple uid uniqueness plugin instances, looking for >>>> different subtrees, potentially with different top level object classes >>>> and different object class filtering. >>>> >>>>> I am just trying to get rid of clashes with custom user configuration. >>>> I understand that, I'll handle it in git master version. Right now we >>>> didn't set up any of uid uniqueness and chances touching any custom >>>> configuration like that are low, looking into my experience with >>>> existing deployments. >>>> >>>> >>>>> 4) Because of 3), when I enabled "attribute uniqueness" plugin before >>>>> upgrade, >>>>> it did a strange franken-update and now I have an update plugin with DN >>>>> "cn=attribute uniqueness,cn=plugins,cn=config" but "cn: uid uniqueness: >>>>> inside. >>>> Good catch. I'll fix this part. >>>> >>>>> (BTW these concerns is where my simplicity expectations came from ;-) >>>> Note that now you realize the whole deal is not that simple as you >>>> thought. ;) >>>> >>>> New patch attached. >>> Missed Makefile.am part. >>> >> >> The >> + if not entries: >> path works looks ok. >> >> However, I am still concerned about the situation when you detect existing UID >> plugin. >> >> You basically create a new LDAP entry with the same DN and then try to >> overwrite the original one. I do not think this is how the LDAP framework >> works. Petr/Honza, is it? > > It will work, but updating the old entry object and calling update_entry on it > would be nicer. > > The difference is that with the current approach, the generated modlist will > contain MOD_REPLACE for every attribute in the entry, whereas updating the > original entry will result in a modlist with MOD_ADD/MOD_DELETE only for the > attributes which were actually modified. Ok. I also found out that the attributes I objected about are controlled by DS, so there is no problem with the none values. ACK then. Pushed to: master: eb4d559f3ba0f22e4ea00311df4b9471b187c6b3 ipa-4-1: 2bc287479e728e342a7a5ca4af2757931b257d02 Martin From mbasti at redhat.com Tue Oct 21 12:03:34 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 21 Oct 2014 14:03:34 +0200 Subject: [Freeipa-devel] [PATCH 0151] Fix DNS validation Message-ID: <54464B96.1000003@redhat.com> Blocker for ipa-4-1 Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0151-fix-forwarder-validation-errors.patch Type: text/x-patch Size: 3583 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 21 12:09:31 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 21 Oct 2014 14:09:31 +0200 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <54463F5A.8010206@redhat.com> References: <5445286B.5020502@redhat.com> <54463F5A.8010206@redhat.com> Message-ID: <54464CFB.6020007@redhat.com> On 21.10.2014 13:11, Petr Viktorin wrote: > On 10/20/2014 05:21 PM, Martin Basti wrote: >> Hello! Hold your hats, DNSSEC patches are here. >> >> Martin^2, Petr^2 >> > > New compiler warnings: > > library.c:72: ISO C forbids conversion of object pointer to function pointer > type [-Wpedantic] > > p11helper.c:500: passing argument 1 of 'loadLibrary' discards 'const' > qualifier from pointer target type [enabled by default] > > p11helper.c:1667: pointer targets in passing argument 3 of > 'PyString_AsStringAndSize' differ in signedness [-Wpointer-sign] > > > Should I file a ticket for these? We have it already: https://fedorahosted.org/freeipa/ticket/4657 -- Petr^2 Spacek From mbasti at redhat.com Tue Oct 21 12:18:09 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 21 Oct 2014 14:18:09 +0200 Subject: [Freeipa-devel] [PATCH 0152] Fix DNSSEC restored value Message-ID: <54464F01.8040402@redhat.com> Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0152-fix-DNSSEC-restore-named-state.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 21 12:18:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 14:18:29 +0200 Subject: [Freeipa-devel] [PATCH 0151] Fix DNS validation In-Reply-To: <54464B96.1000003@redhat.com> References: <54464B96.1000003@redhat.com> Message-ID: <54464F15.4040705@redhat.com> On 10/21/2014 02:03 PM, Martin Basti wrote: > Blocker for ipa-4-1 This and the uninstall issue I found: # ipa-server-install --uninstall --unattended Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unconfiguring CA Unconfiguring named Unconfiguring web server Unconfiguring krb5kdc Unconfiguring kadmin Unconfiguring directory server Unconfiguring smb Unconfiguring ipa_memcached Unconfiguring ipa-otpd ipa : ERROR Some installation state for named has not been restored, see /var/lib/ipa/sysrestore/sysrestore.state ipa : ERROR Some installation state has not been restored. This may cause re-installation to fail. It should be safe to remove /var/lib/ipa/sysrestore/sysrestore.state but it may mean your system hasn't be restored to its pre-installation state. # cat /var/lib/ipa/sysrestore/sysrestore.state [named] named-regular-running = False named-regular-enabled = False Martin From mbasti at redhat.com Tue Oct 21 12:19:12 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 21 Oct 2014 14:19:12 +0200 Subject: [Freeipa-devel] [PATCH 0151] Fix DNS validation In-Reply-To: <54464F15.4040705@redhat.com> References: <54464B96.1000003@redhat.com> <54464F15.4040705@redhat.com> Message-ID: <54464F40.1040202@redhat.com> On 21/10/14 14:18, Martin Kosek wrote: > On 10/21/2014 02:03 PM, Martin Basti wrote: >> Blocker for ipa-4-1 > This and the uninstall issue I found: > > > # ipa-server-install --uninstall --unattended > Shutting down all IPA services > Removing IPA client configuration > Unconfiguring ntpd > Unconfiguring CA > Unconfiguring named > Unconfiguring web server > Unconfiguring krb5kdc > Unconfiguring kadmin > Unconfiguring directory server > Unconfiguring smb > Unconfiguring ipa_memcached > Unconfiguring ipa-otpd > ipa : ERROR Some installation state for named has not been restored, > see /var/lib/ipa/sysrestore/sysrestore.state > ipa : ERROR Some installation state has not been restored. > This may cause re-installation to fail. > It should be safe to remove /var/lib/ipa/sysrestore/sysrestore.state but it may > mean your system hasn't be restored to its pre-installation state. > > > # cat /var/lib/ipa/sysrestore/sysrestore.state > [named] > named-regular-running = False > named-regular-enabled = False > > > Martin I sent patch 152 -- Martin Basti From abokovoy at redhat.com Tue Oct 21 13:02:38 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Oct 2014 16:02:38 +0300 Subject: [Freeipa-devel] [PATCH] 0167: default to TLSv1.0/1.1 for IPA server side Message-ID: <20141021130238.GF5446@redhat.com> Hi! See the commit message for the details. -- / Alexander Bokovoy -------------- next part -------------- From c01dd6af8054dbc1f7ff753be64084f5f5ba797c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 21 Oct 2014 15:59:04 +0300 Subject: [PATCH 2/2] Default to use TLSv1.0 and TLSv1.1 on the IPA server side We only will be changing the setting on the install. For modifying existing configurations please follow instructions at https://access.redhat.com/solutions/1232413 --- ipaserver/install/httpinstance.py | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ipaserver/install/httpinstance.py b/ipaserver/install/httpinstance.py index e340347..14efa5b 100644 --- a/ipaserver/install/httpinstance.py +++ b/ipaserver/install/httpinstance.py @@ -115,6 +115,7 @@ class HTTPInstance(service.Service): self.step("setting mod_nss port to 443", self.__set_mod_nss_port) + self.step("setting mod_nss protocol list to TLSv1.0 and TLSv1.1", self.__set_mod_nss_protocol) self.step("setting mod_nss password file", self.__set_mod_nss_passwordfile) self.step("enabling mod_nss renegotiate", self.enable_mod_nss_renegotiate) self.step("adding URL rewriting rules", self.__add_include) @@ -204,6 +205,9 @@ class HTTPInstance(service.Service): def __set_mod_nss_nickname(self, nickname): installutils.set_directive(paths.HTTPD_NSS_CONF, 'NSSNickname', nickname) + def __set_mod_nss_protocol(self): + installutils.set_directive(paths.HTTPD_NSS_CONF, 'NSSProtocol', 'TLSv1.0,TLSv1.1', False) + def enable_mod_nss_renegotiate(self): installutils.set_directive(paths.HTTPD_NSS_CONF, 'NSSRenegotiation', 'on', False) installutils.set_directive(paths.HTTPD_NSS_CONF, 'NSSRequireSafeNegotiation', 'on', False) -- 2.1.0 From ssorce at redhat.com Tue Oct 21 13:15:42 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 21 Oct 2014 09:15:42 -0400 Subject: [Freeipa-devel] [PATCHES 0117, 0135-0149] DNSSEC support In-Reply-To: <20141021075037.GZ5446@redhat.com> References: <5445286B.5020502@redhat.com> <54452C43.7050703@redhat.com> <54453848.3080002@redhat.com> <54458145.5020304@redhat.com> <5445FE3D.2030004@redhat.com> <20141021064501.GY5446@redhat.com> <5446024E.8010605@redhat.com> <54460AE1.3000301@redhat.com> <20141021075037.GZ5446@redhat.com> Message-ID: <20141021091542.7dab13a9@willson.usersys.redhat.com> On Tue, 21 Oct 2014 10:50:37 +0300 Alexander Bokovoy wrote: > On Tue, 21 Oct 2014, Martin Kosek wrote: > >On 10/21/2014 08:50 AM, Jan Cholasta wrote: > >> Dne 21.10.2014 v 08:45 Alexander Bokovoy napsal(a): > >>> On Tue, 21 Oct 2014, Jan Cholasta wrote: > >>>> Dne 20.10.2014 v 23:40 Martin Basti napsal(a): > >>>>> On 20/10/14 18:28, Jan Cholasta wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Dne 20.10.2014 v 17:37 Petr Spacek napsal(a): > >>>>>>> On 20.10.2014 17:21, Martin Basti wrote: > >>>>>>>> Hello! Hold your hats, DNSSEC patches are here. > >>>>>>>> > >>>>>>>> Martin^2, Petr^2 > >>>>>>> > >>>>>>> For testing you will need following package: > >>>>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7915293 > >>>>>>> > >>>>>>> From me, functional self-ACK :-) > >>>>>>> > >>>>>> > >>>>>> Patch 117: > >>>>>> > >>>>>> 1) > >>>>>> > >>>>>> As we discussed off-line, this code is wrong and a ticket > >>>>>> should be opened to fix it to properly handle service files > >>>>>> conflicting with the mask command: > >>>>>> > >>>>>> + if instance_name != "": > >>>>>> + srv_tgt = > >>>>>> os.path.join(paths.ETC_SYSTEMD_SYSTEM_DIR, instance_name) > >>>>>> + # remove instance file or link before masking > >>>>>> + if os.path.islink(srv_tgt): > >>>>>> + os.unlink(srv_tgt) > >>>>>> > >>>>>> > >>>>>> Patch 137: > >>>>>> > >>>>>> 1) > >>>>>> > >>>>>> There are some whitespace errors: > >>>>>> > >>>>>> Applying: DNSSEC: add ipapk11helper module > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:95: > >>>>>> trailing whitespace. > >>>>>> * > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:100: > >>>>>> trailing whitespace. > >>>>>> * > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:105: > >>>>>> trailing whitespace. > >>>>>> * > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:203: > >>>>>> trailing whitespace. > >>>>>> * > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:208: > >>>>>> trailing whitespace. > >>>>>> * > >>>>>> warning: squelched 3 whitespace errors > >>>>>> warning: 8 lines add whitespace errors. > >>>>>> > >>>>>> > >>>>>> Patch 138: > >>>>>> > >>>>>> 1) > >>>>>> > >>>>>> There is a whitespace error: > >>>>>> > >>>>>> Applying: DNSSEC: DNS key synchronization daemon > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:54: > >>>>>> new blank line at EOF. > >>>>>> + > >>>>>> warning: 1 line adds whitespace errors. > >>>>>> > >>>>>> > >>>>>> Patch 140: > >>>>>> > >>>>>> 1) > >>>>>> > >>>>>> Unless there is a dnssec_keys ipalib plugins, I don't think > >>>>>> there should be container_dnssec_keys. Use "DN(('cn', 'keys'), > >>>>>> ('cn', 'sec'), api.env.container_dns, ...)" instead of > >>>>>> "DN(api.env.container_dnssec_keys, ...)". > >>>>>> > >>>>>> > >>>>>> 2) > >>>>>> > >>>>>> The masking method definitions in PlatformService should be > >>>>>> moved to patch 117. > >>>>>> > >>>>>> > >>>>>> 3) > >>>>>> > >>>>>> The changes in dnskeysyncinstance.py, odsexportedinstance.py > >>>>>> and opendnssecinstance.py should be moved to patches 138 and > >>>>>> 139. > >>>>>> > >>>>>> > >>>>>> Patch 147: > >>>>>> > >>>>>> 1) > >>>>>> > >>>>>> There are some whitespace errors: > >>>>>> > >>>>>> Applying: DNSSEC: add ipa dnssec daemons > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:135: > >>>>>> trailing whitespace. > >>>>>> # synchronize metadata about master keys in LDAP > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1228: > >>>>>> trailing whitespace. > >>>>>> > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1291: > >>>>>> trailing whitespace. > >>>>>> > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:873: > >>>>>> new blank line at EOF. > >>>>>> + > >>>>>> /home/jcholast/FreeIPA/git/freeipa/.git/rebase-apply/patch:1126: > >>>>>> new blank line at EOF. > >>>>>> + > >>>>>> warning: squelched 1 whitespace error > >>>>>> warning: 6 lines add whitespace errors. > >>>>>> > >>>>>> > >>>>>> Honza > >>>>>> > >>>>> Whitespaces fixed, > >>>>> mask, and dnssec_container issues move to 4.1.1 please. > >>>> > >>>> mask ACK, container NACK - I don't think we want to introduce a > >>>> new configuration option and deprecate it right away and it's a > >>>> change in just 3 lines of code. > >>>> > >>>>> > >>>>> But we have schema conflict: > >>>>> > >>>>> [20/Oct/2014:04:48:40 -0400] dse_read_one_file - The entry > >>>>> cn=schema in > >>>>> file /etc/dirsrv/slapd-IPA-EXAMPLE/schema/71idviews.ldif > >>>>> (lineno: 1) is invalid, error code 20 (Type or value exists) - > >>>>> object class ipaOverrideTarget: The name does not match the OID > >>>>> "2.16.840.1.113730.3.8.12.34". Another object class is already > >>>>> using the name or OID. > >>>>> > >>>>> git grep -n "2.16.840.1.113730.3.8.12.34" > >>>>> install/share/60basev3.ldif:79:objectClasses: > >>>>> (2.16.840.1.113730.3.8.12.34 NAME 'ipaSecretKeyRefObject' DESC > >>>>> 'Indirect storage for encoded key material' SUP top AUXILIARY > >>>>> MUST ( ipaSecretKeyRef ) X-... > >>>>> > >>>>> install/share/71idviews.ldif:8:objectClasses: > >>>>> (2.16.840.1.113730.3.8.12.34 NAME 'ipaOverrideTarget' SUP top > >>>>> STRUCTURAL MUST ( ipaAnchorUUID ) X-ORIGIN 'IPA v4' ) > >>>>> > >>>>> Updated patches atached. > >>>>> "2.16.840.1.113730.3.8.12.35" is not used, I change it in patch > >>>>> mbasti-0150 > >>>> > >>>> NACK on patch 150, 2.16.840.1.113730.3.8.12.34 was reserved for > >>>> ipaSecretKeyRefObject, there is no reserved OID for > >>>> ipaOverrideTarget, so it's ipaOverrideTarget which should be > >>>> fixed. > >>> We were meaning to reserve .34 for ipaOverrideTarget for long > >>> time. As ipaOverrideTarget is already in git, it makes sense to > >>> change dnssec OIDs instead. Yes, we've got to step over each > >>> other's toes but that's life. I've already have slapi-nis 0.54 > >>> released which relies on ipaOverrideTarget definition. > >> > >> That's unreleased code and it surely does not rely on it's OID, > >> does it? > >> > >> It's *your* mess and *you* should clean it up. That's life. > > > >If the code was released, I would give +1 for Alexander as we really > >cannot changed *released* OIDs. > > > >But this is not the case so I think that fixing the OID that was not > >properly registered is a good practice. > I did push a one-liner to master and ipa-4-1 that changes OID to .35. > > You will need to do full reinstall if you had ipa-4-1 or git master > installed with the previous change. If it a test server just stop DS, and manually edit the schema file to correct the OID :) Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Oct 21 13:45:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 21 Oct 2014 15:45:10 +0200 Subject: [Freeipa-devel] [PATCH 0151] Fix DNS validation In-Reply-To: <54464F40.1040202@redhat.com> References: <54464B96.1000003@redhat.com> <54464F15.4040705@redhat.com> <54464F40.1040202@redhat.com> Message-ID: <54466366.4020108@redhat.com> On 21.10.2014 14:19, Martin Basti wrote: > On 21/10/14 14:18, Martin Kosek wrote: >> On 10/21/2014 02:03 PM, Martin Basti wrote: >>> Blocker for ipa-4-1 >> This and the uninstall issue I found: >> >> >> # ipa-server-install --uninstall --unattended >> Shutting down all IPA services >> Removing IPA client configuration >> Unconfiguring ntpd >> Unconfiguring CA >> Unconfiguring named >> Unconfiguring web server >> Unconfiguring krb5kdc >> Unconfiguring kadmin >> Unconfiguring directory server >> Unconfiguring smb >> Unconfiguring ipa_memcached >> Unconfiguring ipa-otpd >> ipa : ERROR Some installation state for named has not been restored, >> see /var/lib/ipa/sysrestore/sysrestore.state >> ipa : ERROR Some installation state has not been restored. >> This may cause re-installation to fail. >> It should be safe to remove /var/lib/ipa/sysrestore/sysrestore.state but it may >> mean your system hasn't be restored to its pre-installation state. >> >> >> # cat /var/lib/ipa/sysrestore/sysrestore.state >> [named] >> named-regular-running = False >> named-regular-enabled = False >> >> >> Martin > I sent patch 152 ACK -- Petr^2 Spacek From pspacek at redhat.com Tue Oct 21 13:45:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 21 Oct 2014 15:45:32 +0200 Subject: [Freeipa-devel] [PATCH 0152] Fix DNSSEC restored value In-Reply-To: <54464F01.8040402@redhat.com> References: <54464F01.8040402@redhat.com> Message-ID: <5446637C.3020407@redhat.com> On 21.10.2014 14:18, Martin Basti wrote: > Patch attached ACK -- Petr^2 Spacek From pvoborni at redhat.com Tue Oct 21 13:53:36 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 21 Oct 2014 15:53:36 +0200 Subject: [Freeipa-devel] [PATCH 0152] Fix DNSSEC restored value In-Reply-To: <5446637C.3020407@redhat.com> References: <54464F01.8040402@redhat.com> <5446637C.3020407@redhat.com> Message-ID: <54466560.6000203@redhat.com> On 21.10.2014 15:45, Petr Spacek wrote: > On 21.10.2014 14:18, Martin Basti wrote: >> Patch attached > > ACK > Pushed to: master: 3eec7e1f53f298d752204f6268b8228ebb1ef55e ipa-4-1: 27290bf32d722e4494feb7a235b52ebfeb5c1023 -- Petr Vobornik From mkosek at redhat.com Tue Oct 21 13:54:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 21 Oct 2014 15:54:50 +0200 Subject: [Freeipa-devel] [PATCH] 0167: default to TLSv1.0/1.1 for IPA server side In-Reply-To: <20141021130238.GF5446@redhat.com> References: <20141021130238.GF5446@redhat.com> Message-ID: <544665AA.4070504@redhat.com> On 10/21/2014 03:02 PM, Alexander Bokovoy wrote: > Hi! > > See the commit message for the details. Works for me. I tested client from Fedora or RHEL-6 and it worked fine. ACK! Pushed to: master: 20761f7fcd86dbfad53af78bce2bd3892dfe8232 ipa-4-1: 77b5a81da8f777c65e7a21823a29598804f64cf9 ipa-4-0: c44bdeb7713d4d8b8b74690cc16fd40f48f9c115 Martin From pvoborni at redhat.com Tue Oct 21 13:56:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 21 Oct 2014 15:56:39 +0200 Subject: [Freeipa-devel] [PATCH 0151] Fix DNS validation In-Reply-To: <54466366.4020108@redhat.com> References: <54464B96.1000003@redhat.com> <54464F15.4040705@redhat.com> <54464F40.1040202@redhat.com> <54466366.4020108@redhat.com> Message-ID: <54466617.60300@redhat.com> On 21.10.2014 15:45, Petr Spacek wrote: > On 21.10.2014 14:19, Martin Basti wrote: >> On 21/10/14 14:18, Martin Kosek wrote: >>> On 10/21/2014 02:03 PM, Martin Basti wrote: >>>> Blocker for ipa-4-1 >>> This and the uninstall issue I found: >>> >>> >>> # ipa-server-install --uninstall --unattended >>> Shutting down all IPA services >>> Removing IPA client configuration >>> Unconfiguring ntpd >>> Unconfiguring CA >>> Unconfiguring named >>> Unconfiguring web server >>> Unconfiguring krb5kdc >>> Unconfiguring kadmin >>> Unconfiguring directory server >>> Unconfiguring smb >>> Unconfiguring ipa_memcached >>> Unconfiguring ipa-otpd >>> ipa : ERROR Some installation state for named has not been >>> restored, >>> see /var/lib/ipa/sysrestore/sysrestore.state >>> ipa : ERROR Some installation state has not been restored. >>> This may cause re-installation to fail. >>> It should be safe to remove /var/lib/ipa/sysrestore/sysrestore.state >>> but it may >>> mean your system hasn't be restored to its pre-installation state. >>> >>> >>> # cat /var/lib/ipa/sysrestore/sysrestore.state >>> [named] >>> named-regular-running = False >>> named-regular-enabled = False >>> >>> >>> Martin >> I sent patch 152 > > ACK > Pushed to: master: 5e1172f560f4a63ed8398f326c158e9c8c1f91a8 ipa-4-1: 04816e7654fb5119c9f62b4ad16b03113fce81a8 -- Petr Vobornik From tjaalton at ubuntu.com Tue Oct 21 15:36:52 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 21 Oct 2014 18:36:52 +0300 Subject: [Freeipa-devel] issues with Debian port Message-ID: <54467D94.4060309@ubuntu.com> On 20.10.2014 09:47, Martin Kosek wrote: > As usual, let us know if you hit problems with porting FreeIPA there or > extending our platform-independent code. Right, so I've hit a blocker issue I'm not so sure about.. client install will fail with: 2014-10-21T08:29:30Z INFO trying https://sid.tyrell/ipa/json 2014-10-21T08:29:30Z DEBUG Created connection context.rpcclient 2014-10-21T08:29:30Z DEBUG Try RPC connection 2014-10-21T08:29:30Z INFO Forwarding 'ping' to json server 'https://sid.tyrell/ipa/json' 2014-10-21T08:29:30Z ERROR Cannot connect to the server due to generic error: error marshalling data for XML-RPC transport: argument 2 must be string or None, not int I see that 3.3.x still used the old xml method and that worked just fine. Guess I could patch things to use xmlclient again.. Also, I'm reusing the RedHatService() stuff for services that have native systemd jobs, but in the later phases of install (and during uninstall) ipactl is trying to (re)start 'dirsv at .service' and not 'dirsrv at REALM.service' like in the dirsrv phase.. any hints here would be welcome as well. Otherwise I'll just use DebianSysvService() for dirsrv too.. -- t From jcholast at redhat.com Wed Oct 22 09:28:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 22 Oct 2014 11:28:32 +0200 Subject: [Freeipa-devel] [PATCH] 358 Do not check if port 8443 is available in step 2 of external CA install Message-ID: <544778C0.9010406@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-358-Do-not-check-if-port-8443-is-available-in-step-2-of-.patch Type: text/x-patch Size: 1770 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 22 10:27:10 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 22 Oct 2014 12:27:10 +0200 Subject: [Freeipa-devel] [PATCH] 781 build: increase java stack size for all arches Message-ID: <5447867E.9050704@redhat.com> Gradually new arches which need a bigger stack size for web ui build appear. It's safer to increase the stack size for every architecture and avoid possible future issues. Reason: build fail on armv7hl -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0781-build-increase-java-stack-size-for-all-arches.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 22 11:12:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 22 Oct 2014 13:12:55 +0200 Subject: [Freeipa-devel] [PATCH] 781 build: increase java stack size for all arches In-Reply-To: <5447867E.9050704@redhat.com> References: <5447867E.9050704@redhat.com> Message-ID: <54479137.5000908@redhat.com> On 10/22/2014 12:27 PM, Petr Vobornik wrote: > Gradually new arches which need a bigger stack size for web ui build appear. > It's safer to increase the stack size for every architecture and avoid possible > future issues. > > Reason: build fail on armv7hl ACK from me if it really fixes the problem on ARM and does not break other arch builds. I am now not sure why we did not make this setting default in the first place... Martin From pspacek at redhat.com Wed Oct 22 11:16:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 22 Oct 2014 13:16:34 +0200 Subject: [Freeipa-devel] isolated pkcs11 module In-Reply-To: <1413383086.1780.5.camel@dhcp-2-127.brq.redhat.com> References: <1413383086.1780.5.camel@dhcp-2-127.brq.redhat.com> Message-ID: <54479212.1000703@redhat.com> Hello, On 15.10.2014 16:24, Nikos Mavrogiannopoulos wrote: > Hi, > Concerning: https://bugs.freedesktop.org/show_bug.cgi?id=51949#c3 > What are your requirements? We currently have working code (but not yet > merged) for an isolated security module via p11-kit. Our requirements > are to protect private keys by keeping them outside a process' boundary. FreeIPA has the same requirement in this regard + couple more. > The main target is to run softhsm (v2) in an isolated mode. If we can This was our plan too :-) > combine efforts would be nice. Definitely! The original intent was to design LDAP-backed PKCS#11 module which will be used for CA certificate distribution to clients. E.g. SSSD would download the CA certificates managed by FreeIPA to client and expose them via PKCS#11 to p11-kit. We hope that this would allow almost seamless CA roll-over. This is in scope of https://fedorahosted.org/freeipa/ticket/4322 Later we found out that DNSSEC support in FreeIPA needs to distribute and share private keys among all FreeIPA DNS servers. It seems that LDAP-backed PKCS#11 backend could be used for the same purpose. The idea how it can be done in secure way is described on: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#Keydistribution We did not get to coding it yet but the very rough idea was to wrap local SoftHSM instance and use SSSD to do two-way synchronization between local HSM and LDAP-backend. It certainly could be extended to handle user credentials too (SSH private keys or passwords in GNOME keyring?). Jan Cholasta (CCed) can add more details, he is the main architect of this solution :-) -- Petr^2 Spacek From dkupka at redhat.com Wed Oct 22 11:30:55 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 22 Oct 2014 13:30:55 +0200 Subject: [Freeipa-devel] [PATCH] 358 Do not check if port 8443 is available in step 2 of external CA install In-Reply-To: <544778C0.9010406@redhat.com> References: <544778C0.9010406@redhat.com> Message-ID: <5447956F.2050101@redhat.com> On 10/22/2014 11:28 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. -- David Kupka From pvoborni at redhat.com Wed Oct 22 11:56:02 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 22 Oct 2014 13:56:02 +0200 Subject: [Freeipa-devel] [PATCH] 781 build: increase java stack size for all arches In-Reply-To: <54479137.5000908@redhat.com> References: <5447867E.9050704@redhat.com> <54479137.5000908@redhat.com> Message-ID: <54479B52.3030007@redhat.com> On 22.10.2014 13:12, Martin Kosek wrote: > On 10/22/2014 12:27 PM, Petr Vobornik wrote: >> Gradually new arches which need a bigger stack size for web ui build appear. >> It's safer to increase the stack size for every architecture and avoid possible >> future issues. >> >> Reason: build fail on armv7hl > > ACK from me if it really fixes the problem on ARM and does not break other arch > builds. failed build: http://koji.fedoraproject.org/koji/taskinfo?taskID=7927120 successful scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=7928725 > > I am now not sure why we did not make this setting default in the first place... IIRC, one of the reason was that at the beginning it was only for two arches. But the very first patch has something similar, but not configurable through a env. variable. Pushed to: ipa-4-0: 4ac55bf52ff0d6817a130bd7d9bc65415c359bec ipa-4-1: 1300f82b9ce9c42b5314e018fa4989990af6218b master: 09808c92c001ba8a6d5705e719d63430eeeb3ecb -- Petr Vobornik From jcholast at redhat.com Wed Oct 22 11:57:57 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 22 Oct 2014 13:57:57 +0200 Subject: [Freeipa-devel] [PATCH] 358 Do not check if port 8443 is available in step 2 of external CA install In-Reply-To: <5447956F.2050101@redhat.com> References: <544778C0.9010406@redhat.com> <5447956F.2050101@redhat.com> Message-ID: <54479BC5.2010505@redhat.com> Dne 22.10.2014 v 13:30 David Kupka napsal(a): > On 10/22/2014 11:28 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Works for me, ACK. Thanks. See attachment for ipa-4-0 version of the patch. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-358-Do-not-check-if-port-8443-is-available-in-step-2-of--ipa-4-0.patch Type: text/x-patch Size: 1271 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 22 12:22:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 22 Oct 2014 14:22:30 +0200 Subject: [Freeipa-devel] [PATCH] 358 Do not check if port 8443 is available in step 2 of external CA install In-Reply-To: <54479BC5.2010505@redhat.com> References: <544778C0.9010406@redhat.com> <5447956F.2050101@redhat.com> <54479BC5.2010505@redhat.com> Message-ID: <5447A186.8000401@redhat.com> On 22.10.2014 13:57, Jan Cholasta wrote: > Dne 22.10.2014 v 13:30 David Kupka napsal(a): >> On 10/22/2014 11:28 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >>> >>> >> Works for me, ACK. > > Thanks. > > See attachment for ipa-4-0 version of the patch. > Looks good. Pushed to: ipa-4-0: 3cb982bc010216c7613de67ea537ba0dbe8d8342 ipa-4-1: e22cf5bafc4c862a16bd8ac0b950c7547b048ae9 master: 50e66337340ae8f9c243658b58409de4e911d1c4 -- Petr Vobornik From edewata at redhat.com Wed Oct 22 14:15:47 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 22 Oct 2014 09:15:47 -0500 Subject: [Freeipa-devel] [PATCH] 354 Modififed NSSConnection not to shutdown existing database. Message-ID: <5447BC13.6010500@redhat.com> The NSSConnection class has been modified not to shutdown the existing NSS database if the database is already opened to establish an SSL connection, or is already opened by another code that uses an NSS database without establishing an SSL connection such as vault CLIs. Ticket #4638 -- Endi S. Dewata -------------- next part -------------- From d7b05ef151a59e6828b537ac2077d05b74b25903 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 16 Sep 2014 20:11:35 -0400 Subject: [PATCH] Modififed NSSConnection not to shutdown existing database. The NSSConnection class has been modified not to shutdown the existing NSS database if the database is already opened to establish an SSL connection, or is already opened by another code that uses an NSS database without establishing an SSL connection such as vault CLIs. Ticket #4638 --- ipalib/rpc.py | 34 +++++++++++++++++++--------------- ipapython/nsslib.py | 35 +++++++++++++++++++++++------------ 2 files changed, 42 insertions(+), 27 deletions(-) diff --git a/ipalib/rpc.py b/ipalib/rpc.py index 5934f0c26e4b7c0a44adbab978c1f9b319d72e9f..001b7f1ca06edadfc7aad635d9d564e517008a63 100644 --- a/ipalib/rpc.py +++ b/ipalib/rpc.py @@ -63,6 +63,7 @@ from ipaplatform.paths import paths from ipapython.cookie import Cookie from ipapython.dnsutil import DNSName from ipalib.text import _ +import ipapython.nsslib from ipapython.nsslib import NSSHTTPS, NSSConnection from ipalib.krb_utils import KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, KRB5KRB_AP_ERR_TKT_EXPIRED, \ KRB5_FCC_PERM, KRB5_FCC_NOFILE, KRB5_CC_FORMAT, KRB5_REALM_CANT_RESOLVE @@ -450,14 +451,10 @@ class LanguageAwareTransport(MultiProtocolTransport): class SSLTransport(LanguageAwareTransport): """Handles an HTTPS transaction to an XML-RPC server.""" - def __nss_initialized(self, dbdir): + def get_connection_dbdir(self): """ - If there is another connections open it may have already - initialized NSS. This is likely to lead to an NSS shutdown - failure. One way to mitigate this is to tell NSS to not - initialize if it has already been done in another open connection. - - Returns True if another connection is using the same db. + If there is a connections open it may have already initialized + NSS database. Return the database location used by the connection. """ for value in context.__dict__.values(): if not isinstance(value, Connection): @@ -466,25 +463,32 @@ class SSLTransport(LanguageAwareTransport): getattr(value.conn, '_ServerProxy__transport', None), SSLTransport): continue - if hasattr(value.conn._ServerProxy__transport, 'dbdir') and \ - value.conn._ServerProxy__transport.dbdir == dbdir: - return True - return False + if hasattr(value.conn._ServerProxy__transport, 'dbdir'): + return value.conn._ServerProxy__transport.dbdir + return None def make_connection(self, host): host, self._extra_headers, x509 = self.get_host_info(host) # Python 2.7 changed the internal class used in xmlrpclib from # HTTP to HTTPConnection. We need to use the proper subclass - # If we an existing connection exists using the same NSS database - # there is no need to re-initialize. Pass thsi into the NSS - # connection creator. if sys.version_info >= (2, 7): if self._connection and host == self._connection[0]: return self._connection[1] dbdir = getattr(context, 'nss_dir', paths.IPA_NSSDB_DIR) - no_init = self.__nss_initialized(dbdir) + connection_dbdir = self.get_connection_dbdir() + + if connection_dbdir: + # If an existing connection is already using the same NSS + # database there is no need to re-initialize. + no_init = dbdir == connection_dbdir + + else: + # If the NSS database is already being used there is no + # need to re-initialize. + no_init = dbdir == ipapython.nsslib.current_dbdir + if sys.version_info < (2, 7): conn = NSSHTTPS(host, 443, dbdir=dbdir, no_init=no_init) else: diff --git a/ipapython/nsslib.py b/ipapython/nsslib.py index 93b0c56fcff4fc69841a6823aae8f694c1f76ff0..1452a2a5844a5fb017d4408aadf56f7fcfc7fa25 100644 --- a/ipapython/nsslib.py +++ b/ipapython/nsslib.py @@ -31,6 +31,9 @@ import nss.ssl as ssl import nss.error as error from ipaplatform.paths import paths +# NSS database currently open +current_dbdir = None + def auth_certificate_callback(sock, check_sig, is_server, certdb): cert_is_valid = False @@ -184,19 +187,27 @@ class NSSConnection(httplib.HTTPConnection, NSSAddressFamilyFallback): httplib.HTTPConnection.__init__(self, host, port, strict) NSSAddressFamilyFallback.__init__(self, family) - if not dbdir: - raise RuntimeError("dbdir is required") - root_logger.debug('%s init %s', self.__class__.__name__, host) - if not no_init and nss.nss_is_initialized(): - # close any open NSS database and use the new one - ssl.clear_session_cache() - try: - nss.nss_shutdown() - except NSPRError, e: - if e.errno != error.SEC_ERROR_NOT_INITIALIZED: - raise e - nss.nss_init(dbdir) + + # If initialization is requested, initialize the new database. + if not no_init: + + if nss.nss_is_initialized(): + ssl.clear_session_cache() + try: + nss.nss_shutdown() + except NSPRError, e: + if e.errno != error.SEC_ERROR_NOT_INITIALIZED: + raise e + + if not dbdir: + raise RuntimeError("dbdir is required") + + nss.nss_init(dbdir) + + global current_dbdir + current_dbdir = dbdir + ssl.set_domestic_policy() nss.set_password_callback(self.password_callback) -- 1.9.0 From edewata at redhat.com Wed Oct 22 14:34:36 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 22 Oct 2014 09:34:36 -0500 Subject: [Freeipa-devel] [PATCH] 352 Fixed KRA backend. In-Reply-To: <543F4294.1080001@redhat.com> References: <543F4294.1080001@redhat.com> Message-ID: <5447C07C.4000800@redhat.com> On 10/15/2014 10:59 PM, Endi Sukma Dewata wrote: > The KRA backend has been simplified since most of the tasks have > been moved somewhere else. The transport certificate will be > installed on the client, and it is not needed by KRA backend. The > KRA agent's PEM certificate is now generated during installation > due to permission issue. The kra_host() for now is removed since > the current ldap_enable() cannot register the KRA service, so it > is using the kra_host environment variable. > > The KRA installer has been modified to use Dogtag's CLI go create > KRA agent and setup the client authentication. > > The proxy settings have been updated to include KRA's URLs. > > The certs.install_pem_from_p12() has been updated to generate the > proper client certificate using the -clcerts option and also take > a password file. > > Some constants have been renamed for clarity. The DOGTAG_AGENT_P12 > has been renamed to DOGTAG_ADMIN_P12 since file actually contains > the Dogtag admin's certificate and private key and it can be used > to access both CA and KRA. The DOGTAG_AGENT_PEM has been renamed > to KRA_AGENT_PEM since it can only be used for KRA. > > Ticket #3872 New patch attached. It's identical to the previous one except I changed the ticket number to #4503. -- Endi S. Dewata -------------- next part -------------- >From a3e5c4f872fade7e88f954452a64c310ba4ae380 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Wed, 1 Oct 2014 14:59:46 -0400 Subject: [PATCH] Fixed KRA backend. The KRA backend has been simplified since most of the tasks have been moved somewhere else. The transport certificate will be installed on the client, and it is not needed by KRA backend. The KRA agent's PEM certificate is now generated during installation due to permission issue. The kra_host() for now is removed since the current ldap_enable() cannot register the KRA service, so it is using the kra_host environment variable. The KRA installer has been modified to use Dogtag's CLI go create KRA agent and setup the client authentication. The proxy settings have been updated to include KRA's URLs. The certs.install_pem_from_p12() has been updated to generate the proper client certificate using the -clcerts option and also take a password file. Some constants have been renamed for clarity. The DOGTAG_AGENT_P12 has been renamed to DOGTAG_ADMIN_P12 since file actually contains the Dogtag admin's certificate and private key and it can be used to access both CA and KRA. The DOGTAG_AGENT_PEM has been renamed to KRA_AGENT_PEM since it can only be used for KRA. Ticket #4503 --- install/conf/ipa-pki-proxy.conf | 2 +- ipaplatform/base/paths.py | 4 +- ipaserver/install/cainstance.py | 4 +- ipaserver/install/certs.py | 10 ++-- ipaserver/install/ipa_backup.py | 3 +- ipaserver/install/krainstance.py | 83 ++++++++++++++++++++++++--- ipaserver/plugins/dogtag.py | 120 +++++---------------------------------- 7 files changed, 100 insertions(+), 126 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 2370b4d7a7467a7e47c0d223915e018c9a009e83..5d21156848f3b5ddf14c42d92a26a30a9f94af36 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -19,7 +19,7 @@ ProxyRequests Off # matches for agent port and eeca port - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://localhost:$DOGTAG_PORT diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index bbe6eed76ccb3c5f325fd368694ac6a2afbb72f0..01505594a7af926c860f867b817bd397c54efff5 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -138,8 +138,8 @@ class BasePathNamespace(object): HOME_DIR = "/home" ROOT_IPA_CACHE = "/root/.ipa_cache" ROOT_PKI = "/root/.pki" - DOGTAG_AGENT_P12 = "/root/ca-agent.p12" - DOGTAG_AGENT_PEM = "/etc/httpd/alias/agent.pem" + DOGTAG_ADMIN_P12 = "/root/ca-agent.p12" + KRA_AGENT_PEM = "/etc/httpd/alias/kra-agent.pem" CACERT_P12 = "/root/cacert.p12" ROOT_IPA_CSR = "/root/ipa.csr" ROOT_TMP_CA_P12 = "/root/tmp-ca.p12" diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 1ae39639ac9702651851e6c3964faa69788db31e..fe95201517a577b9f6dba7642afe09b4eef2328d 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -514,7 +514,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_admin_nickname", "ipa-ca-agent") config.set("CA", "pki_admin_subject_dn", str(DN(('cn', 'ipa-ca-agent'), self.subject_base))) - config.set("CA", "pki_client_admin_cert_p12", paths.DOGTAG_AGENT_P12) + config.set("CA", "pki_client_admin_cert_p12", paths.DOGTAG_ADMIN_P12) # Directory server config.set("CA", "pki_ds_ldap_port", str(self.ds_port)) @@ -979,7 +979,7 @@ class CAInstance(DogtagInstance): try: ipautil.run([paths.PK12UTIL, "-n", "ipa-ca-agent", - "-o", paths.DOGTAG_AGENT_P12, + "-o", paths.DOGTAG_ADMIN_P12, "-d", self.agent_db, "-k", pwd_name, "-w", pwd_name]) diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index 5399a0fa566c6f7df81a9d1e347f6ac99e5188c9..d1e58da722126d0381787e13b9112d595dfc2cc7 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -637,11 +637,13 @@ class CertDB(object): self.create_pin_file() self.export_ca_cert(nickname, False) - def install_pem_from_p12(self, p12_fname, p12_passwd, pem_fname): - pwd = ipautil.write_tmp_file(p12_passwd) - ipautil.run([paths.OPENSSL, "pkcs12", "-nodes", + def install_pem_from_p12(self, p12_fname, p12_passwd, pem_fname, pwd_fname=None): + if p12_passwd: + pwd = ipautil.write_tmp_file(p12_passwd) + pwd_fname = pwd.name + ipautil.run([paths.OPENSSL, "pkcs12", "-clcerts", "-nodes", "-in", p12_fname, "-out", pem_fname, - "-passin", "file:" + pwd.name]) + "-passin", "file:" + pwd_fname]) def publish_ca_cert(self, location): shutil.copy(self.cacert_fname, location) diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py index 014b49bb63579227c12a8380cfb630a0bd6c677a..ed9139576f511c4c0989675d3e5b0d356584d893 100644 --- a/ipaserver/install/ipa_backup.py +++ b/ipaserver/install/ipa_backup.py @@ -158,7 +158,8 @@ class Backup(admintool.AdminTool): paths.NTP_CONF, paths.SMB_CONF, paths.SAMBA_KEYTAB, - paths.DOGTAG_AGENT_P12, + paths.DOGTAG_ADMIN_P12, + paths.KRA_AGENT_PEM, paths.CACERT_P12, paths.KRB5KDC_KDC_CONF, paths.SYSTEMD_IPA_SERVICE, diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index 1af1c0f721cd9b0df7c6134798494d507e2ba07c..7c1bded4173420a7e8f0ebfe40fe7e12ba0476c4 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -169,7 +169,7 @@ class KRAInstance(DogtagInstance): str(DN(('cn', 'ipa-ca-agent'), self.subject_base))) config.set("KRA", "pki_import_admin_cert", "True") config.set("KRA", "pki_admin_cert_file", paths.ADMIN_CERT_PATH) - config.set("KRA", "pki_client_admin_cert_p12", paths.DOGTAG_AGENT_P12) + config.set("KRA", "pki_client_admin_cert_p12", paths.DOGTAG_ADMIN_P12) # Directory server config.set("KRA", "pki_ds_ldap_port", str(self.ds_port)) @@ -259,16 +259,81 @@ class KRAInstance(DogtagInstance): """ Add RA agent created for CA to KRA agent group. """ - conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) - conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) - entry_dn = DN(('uid', "ipara"), ('ou', 'People'), ('o', 'ipaca')) - dn = DN(('cn', 'Data Recovery Manager Agents'), ('ou', 'groups'), - self.basedn) - modlist = [(0, 'uniqueMember', '%s' % entry_dn)] - conn.modify_s(dn, modlist) + # import CA certificate into temporary security database + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-import", + "--pkcs12", paths.KRACERT_P12, + "--pkcs12-password", self.admin_password] + ipautil.run(args) - conn.unbind() + # trust CA certificate + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-mod", "Certificate Authority - %s" % api.env.realm, + "--trust", "CT,c,"] + ipautil.run(args) + + # import Dogtag admin certificate into temporary security database + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-import", + "--pkcs12", paths.DOGTAG_ADMIN_P12, + "--pkcs12-password", self.admin_password] + ipautil.run(args) + + # as Dogtag admin, create ipakra user in KRA + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-add", "ipakra", + "--fullName", "IPA KRA User"] + ipautil.run(args) + + # as Dogtag admin, add ipakra into KRA agents group + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-membership-add", "ipakra", "Data Recovery Manager Agents"] + ipautil.run(args) + + # assign ipaCert to ipakra + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + # export ipaCert without private key + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--cert", filename] + ipautil.run(args) + + # as Dogtag admin, upload and assign ipaCert to ipakra + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-cert-add", "ipakra", + "--input", filename] + ipautil.run(args) + + finally: + os.remove(filename) + + # export ipaCert with private key for client authentication + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--client-cert", paths.KRA_AGENT_PEM] + ipautil.run(args) @staticmethod def update_cert_config(nickname, cert, dogtag_constants=None): diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 0e141a45c290b84d65b15b8c2c638577a3a39363..b6d216e6626ef3e62c7d4f6227b76213ae9d85c3 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1890,122 +1890,28 @@ class kra(Backend): """ def __init__(self, kra_port=443): - if api.env.in_tree: - self.sec_dir = os.path.join(api.env.dot_ipa, 'alias') - pwd_file = os.path.join(self.sec_dir, '.pwd') - self.pem_file = os.path.join(self.sec_dir, ".pemfile") - else: - self.sec_dir = paths.HTTPD_ALIAS_DIR - pwd_file = paths.ALIAS_PWDFILE_TXT - self.pem_file = paths.DOGTAG_AGENT_PEM self.kra_port = kra_port - self.transport_nick = "IPA KRA Transport Cert" - self.password = "" - with open(pwd_file, "r") as f: - self.password = f.readline().strip() - self.keyclient = None super(kra, self).__init__() - def _create_pem_file(self): - """ Create PEM file used by KRA plugin for authentication. + def get_client(self): - This function reads the IPA HTTPD database and extracts the - Dogtag agent certificate and keys into a PKCS#12 temporary file. - The PKCS#12 file is then converted into PEM format so that it - can be used by python-requests to authenticate to the KRA. + if not api.env.enable_kra: + return None - :return: None - """ - (p12_pwd_fd, p12_pwd_fname) = tempfile.mkstemp() - (p12_fd, p12_fname) = tempfile.mkstemp() + crypto = cryptoutil.NSSCryptoProvider( + paths.HTTPD_ALIAS_DIR, + password_file=paths.ALIAS_PWDFILE_TXT) - try: - os.write(p12_pwd_fd, self.password) - os.close(p12_pwd_fd) - os.close(p12_fd) + connection = PKIConnection( + 'https', + api.env.kra_host, + str(self.kra_port), + 'kra') - certdb = CertDB(api.env.realm) - certdb.export_pkcs12(p12_fname, p12_pwd_fname, "ipaCert") + connection.set_authentication_cert(paths.KRA_AGENT_PEM) - certdb.install_pem_from_p12(p12_fname, self.password, self.pem_file) - except: - self.debug("Error when creating PEM file for KRA operations") - raise - finally: - os.remove(p12_fname) - os.remove(p12_pwd_fname) - - def _transport_cert_present(self): - """ Check if the client certDB contains the KRA transport certificate - :return: True/False - """ - # certutil -L -d db_dir -n cert_nick - certdb = CertDB(api.env.realm) - return certdb.has_nickname(self.transport_nick) - - def _setup(self): - """ Do initial setup and crypto initialization of the KRA client - - Creates a PEM file containing the KRA agent cert/keys to be used for - authentication to the KRA (if it does not already exist), Sets up a - connection to the KRA and initializes an NSS certificate database to - store the transport certificate, Retrieves the transport certificate - if it is not already present. - """ - #set up pem file if not present - if not os.path.exists(self.pem_file): - self._create_pem_file() - - # set up connection - connection = PKIConnection('https', - self.kra_host, - str(self.kra_port), - 'kra') - connection.set_authentication_cert(self.pem_file) - - crypto = cryptoutil.NSSCryptoProvider(self.sec_dir, self.password) - - #create kraclient - kraclient = KRAClient(connection, crypto) - - # get transport cert if needed - if not self._transport_cert_present(): - transport_cert = kraclient.system_certs.get_transport_cert() - crypto.import_cert(self.transport_nick, transport_cert, "u,u,u") - - crypto.initialize() - - self.keyclient = kraclient.keys - self.keyclient.set_transport_cert(self.transport_nick) - - @cachedproperty - def kra_host(self): - """ - :return: host - as str - - Select our KRA host. - """ - ldap2 = self.api.Backend.ldap2 - if host_has_service(api.env.kra_host, ldap2, "kra"): - return api.env.kra_host - if api.env.host != api.env.kra_host: - if host_has_service(api.env.host, ldap2, "kra"): - return api.env.host - host = select_any_master(ldap2, "kra") - if host: - return host - else: - return api.env.kra_host - - def get_keyclient(self): - """Return a keyclient to perform key archival and retrieval. - :return: pki.key.keyclient - """ - if self.keyclient is None: - self._setup() - return self.keyclient + return KRAClient(connection, crypto) api.register(kra) -- 1.9.0 From tbabej at redhat.com Wed Oct 22 17:39:44 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 22 Oct 2014 19:39:44 +0200 Subject: [Freeipa-devel] [PATCH] 773-777 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type In-Reply-To: <543E6685.8000704@redhat.com> References: <543E6685.8000704@redhat.com> Message-ID: <5447EBE0.4080203@redhat.com> Hi, thank you for the patches, comments inline. On 10/15/2014 02:20 PM, Petr Vobornik wrote: > ticket: https://fedorahosted.org/freeipa/ticket/4221 > > == [PATCH] 773 ranges: prohibit setting --rid-base with > ipa-trust-ad-posix type == > > We should not allow setting --rid-base for ranges of > ipa-trust-ad-posix since we do not perform any RID -> UID/GID mappings > for these ranges (objects have UID/GID set in AD). Thus, setting RID > base makes no sense. > > Since ipaBaseRID is a MUST in ipaTrustedADDomainRange object class, > value '0' is allowed and used internally for 'ipa-trust-ad-posix' > range type. We probably don't want to display the first RID if it is 0 and the type is ad-posix. This occurs in idrange-find: [tbabej at vm-043 labtool]$ ipa idrange-find ---------------- 2 ranges matched ---------------- Range name: DOM043.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range First Posix ID of the range: 514800000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range Range name: TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range First Posix ID of the range: 10000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 Range type: Active Directory trust range with POSIX attributes ---------------------------- Number of entries returned 2 ---------------------------- And also idrange-show: [tbabej at vm-043 labtool]$ ipa idrange-show TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range Range name: TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range First Posix ID of the range: 10000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 Range type: Active Directory trust range with POSIX attributes > > No schema change is done. > > == [PATCH] 774 unittests: baserid for ipa-ad-trust-posix idranges == Looks good. > > == [PATCH] 775 ldapupdater: set baserid to 0 for ipa-ad-trust-posix > ranges == Can you use the paged_search=True in find_entries instead of having a infinite loop? It would make this code quite cleaner. > > New updater plugin which sets baserid to 0 for ranges with type > ipa-ad-trust-posix > > https://fedorahosted.org/freeipa/ticket/4221 > > == [PATCH] 776 idrange: include raw range type in output == > > iparangetype output is a localized human-readable value which is not > suitable for machine-based API consumers > > Solved by new iparangetyperaw output attribute which contains > iparangetype's raw value > > Note: I don't like this approach. It would be better to return just > the raw value a do the transformation in clients. But we do have a > precedent: > http://www.redhat.com/archives/freeipa-devel/2012-January/msg00190.html I am not happy about it either.. I guess we could create a capability for this, but it would probably be a overkill. > > == [PATCH] 777 webui: prohibit setting rid base with > ipa-trust-ad-posix type == > > Base RID is no longer editable for ipa-trust-ad-posix range type > > Adder dialog: > - Range type selector was moved up because it affects a field above it > > Details page: > - Only fields relevant to range's type are visible > > Looks fine. On a related note, I added a new ticket https://fedorahosted.org/freeipa/ticket/4661 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Oct 22 20:04:37 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 22 Oct 2014 15:04:37 -0500 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. In-Reply-To: <544034B2.5010609@redhat.com> References: <543F429C.2040006@redhat.com> <544034B2.5010609@redhat.com> Message-ID: <54480DD5.10504@redhat.com> On 10/16/2014 4:12 PM, Endi Sukma Dewata wrote: > On 10/15/2014 10:59 PM, Endi Sukma Dewata wrote: >> The NSSConnection class has to be modified not to shutdown existing >> database because some of the vault clients (e.g. vault-archive and >> vault-retrieve) also use a database to encrypt/decrypt the secret. > > The problem is described in more detail in this ticket: > https://fedorahosted.org/freeipa/ticket/4638 > > The changes to the NSSConnection in the first patch caused the > installation to fail. Attached is a new patch that uses the solution > proposed by jdennis. New patch attached. It's now using the correct OID's for the schema. It also has been rebased on top of #352-1 and #354. -- Endi S. Dewata -------------- next part -------------- >From 2284f5684149e9fdfb7cde13865fe28e265ff5a3 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 21 Oct 2014 10:57:08 -0400 Subject: [PATCH] Added initial vault implementation. This patch provides the initial vault implementation which allows the admin to create a vault, archive a secret, and retrieve the secret using a standard vault. It also included the initial LDAP schema. It currently has limitations including: - The vault only supports the standard vault type. - The vault can only be used by the admin user. - The transport certificate has to be installed manually. These limitations, other vault features, schema and ACL changes will be addressed in subsequent patches. Ticket #3872 --- API.txt | 160 ++++++++ VERSION | 4 +- install/share/60basev4.ldif | 3 + install/share/Makefile.am | 1 + install/share/copy-schema-to-ca.py | 1 + install/updates/40-vault.update | 27 ++ install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/user.py | 9 + ipalib/plugins/vault.py | 724 +++++++++++++++++++++++++++++++++++++ ipaserver/install/dsinstance.py | 1 + 12 files changed, 931 insertions(+), 2 deletions(-) create mode 100644 install/share/60basev4.ldif create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py diff --git a/API.txt b/API.txt index 0000491d7a76fd1d2d50208d314d1600839ce295..cfa6558fcf678e5915a90407da517f9a591a41bf 100644 --- a/API.txt +++ b/API.txt @@ -4475,6 +4475,166 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('in?', cli_name='in') +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret', attribute=True, cli_name='secret', multivalue=False, required=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_archive +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('encrypted_data?', cli_name='encrypted_data') +option: Str('in?', cli_name='in') +option: Bytes('nonce?', cli_name='nonce') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret?', cli_name='secret') +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,10,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Bytes('secret', attribute=True, autofill=False, cli_name='secret', multivalue=False, query=True, required=False) +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret', attribute=True, autofill=False, cli_name='secret', multivalue=False, required=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_retrieve +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('out?', cli_name='out') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_add +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vaultcontainer_find +args: 1,9,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vaultcontainer_mod +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/VERSION b/VERSION index b0d41e5e1ec59ddefbdcccf588b97bac2ff798ee..fe23eae5f349f4a2d40c3d3e55f6168a82b961b2 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=108 -# Last change: pvoborni - manage authorization of keytab operations +IPA_API_VERSION_MINOR=109 +# Last change: edewata - initial vault implementation diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif new file mode 100644 index 0000000000000000000000000000000000000000..97553d53938093c1b0ecba0826fc469d0d758c62 --- /dev/null +++ b/install/share/60basev4.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 878d8868bbbb4f774d378b1d2e886841e2b4b7e4..ec417b634aeb80be3a39f2b8e3410e68a1131ee0 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -14,6 +14,7 @@ app_DATA = \ 60ipaconfig.ldif \ 60basev2.ldif \ 60basev3.ldif \ + 60basev4.ldif \ 60ipadns.ldif \ 60ipapk11.ldif \ 61kerberos-ipav3.ldif \ diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py index fc53fe4cb52486cc618bec77aabe8283ad5eadbc..fb938d212f0f4ddd9a8250a362b89c29d3078efd 100755 --- a/install/share/copy-schema-to-ca.py +++ b/install/share/copy-schema-to-ca.py @@ -29,6 +29,7 @@ SCHEMA_FILENAMES = ( "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..59e5b629ce4e6c5acac06df78f02106afa6c859e --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,27 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: vaults +default: description: Root vault container + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: services +default: description: Services vault container + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: shared +default: description: Shared vault container + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: users +default: description: Users vault container diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 2bd877a0d89525a69ea2d09647499ab2311bb358..a127f91cbe03aa13ec90bd628eaa29b7a898c3b9 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -32,6 +32,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index 325414b64fdacd4d8df261588cfc9b7481923be1..f64e02b5cf2a949a3c0ea7c1702132a3a09c1c19 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -97,6 +97,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index e206289248dfe9ae79bd87271ff2c7672fb98b4f..928a996e35cf31d21e6e85e4ea31380ec9b2c2ce 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -22,6 +22,7 @@ from time import gmtime, strftime import string import posixpath import os +import traceback from ipalib import api, errors from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime @@ -889,6 +890,14 @@ class user_del(LDAPDelete): else: self.api.Command.otptoken_del(token) + # Delete user's private vault container. + try: + vaultcontainer_id = self.api.Object.vaultcontainer.get_private_id(owner) + (vaultcontainer_parent_id, vaultcontainer_name) = self.api.Object.vaultcontainer.split_id(vaultcontainer_id) + self.api.Command.vaultcontainer_del(vaultcontainer_name, parent=vaultcontainer_parent_id) + except errors.NotFound: + pass + return dn diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..c0e66621d1cf326b0bfb88565951d66cda3b9500 --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,724 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# 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 PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +import json +import os +import random +import shutil +import string +import tempfile + +import pki +import pki.account +import pki.crypto +import pki.key + +from ipalib import api, errors +from ipalib import Str, Bytes +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import * +from ipalib.plugins import baseldap +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipaplatform.paths import paths +import ipapython.nsslib + +__doc__ = _(""" +Vaults + +Manage vaults and vault containers. + +EXAMPLES: + + List private vaults: + ipa vault-find + + List shared vaults: + ipa vault-find --parent /shared + + Add a vault: + ipa vault-add MyVault + + Show a vault: + ipa vault-show MyVault + + Archive a secret: + ipa vault-archive MyVault --in secret.in + + Retrieve a secret: + ipa vault-retrieve MyVault --out secret.out + + Delete a vault: + ipa vault-del MyVault + + List private vault containers: + ipa vaultcontainer-find + + List top-level vault containers: + ipa vaultcontainer-find --parent / + + Add a vault container: + ipa vaultcontainer-add MyContainer + + Show a vault container: + ipa vaultcontainer-show MyContainer + + Delete a vault container: + ipa vaultcontainer-del MyContainer +""") + +register = Registry() +transport_cert_nickname = "KRA Transport Certificate" + + at register() +class vaultcontainer(LDAPObject): + """ + Vault container object. + """ + container_dn = api.env.container_vault + object_name = _('vault container') + object_name_plural = _('vault containers') + + object_class = ['ipaVaultContainer'] + default_attributes = [ + 'cn', 'description', + ] + search_display_attributes = [ + 'cn', 'description', + ] + + label = _('Vault Containers') + label_singular = _('Vault Container') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='container_name', + label=_('Container name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Container description'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + ) + + def get_private_id(self, username=None): + """ + Returns user's private container ID (i.e. /users//). + """ + + if not username: + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + + return u'/users/' + username + u'/' + + def normalize_id(self, id): + """ + Normalizes container ID. + """ + + # if ID is empty, return user's private container ID + if not id: + return self.get_private_id() + + # make sure ID ends with slash + if not id.endswith(u'/'): + id += u'/' + + # if it's an absolute ID, do nothing + if id.startswith(u'/'): + return id + + # otherwise, prepend with user's private container ID + return self.get_private_id() + id + + def split_id(self, id): + """ + Split a normalized container ID into (parent ID, container name) tuple. + """ + + # handle root ID + if id == u'/': + return (None, None) + + # split ID into parent ID, container name, and empty string + parts = id.rsplit(u'/', 2) + + # return parent ID and container name + return (parts[-3] + u'/', parts[-2]) + + def get_dn(self, *keys, **kwargs): + """ + Generate vault container DN. + """ + + id = keys[0] + dn = DN(self.container_dn, api.env.basedn) + + # if ID is not specified, return base DN + if not id: + return dn + + # for each name in the ID, prepend the base DN + for name in id.split(u'/'): + if name: + dn = DN(('cn', name), dn) + + return dn + + + at register() +class vaultcontainer_add(LDAPCreate): + __doc__ = _('Create a new vault container.') + + msg_summary = _('Added vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + + name = entry_attrs.get('cn') + parent_id = self.obj.normalize_id(options.get('parent')) + + # add parent container if it doesn't exist + try: + (grandparent_id, parent_name) = self.obj.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + id = parent_id + name + dn = self.obj.get_dn(id) + + return dn + + + at register() +class vaultcontainer_del(LDAPDelete): + __doc__ = _('Delete a vault container.') + + msg_summary = _('Deleted vault container "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_find(LDAPSearch): + __doc__ = _('Search for vault containers.') + + msg_summary = ngettext( + '%(count)d vault container matched', '%(count)d vault containers matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + + parent_id = self.obj.normalize_id(options.get('parent')) + base_dn = self.obj.get_dn(parent_id) + return (filter, base_dn, scope) + + + at register() +class vaultcontainer_mod(LDAPUpdate): + __doc__ = _('Modify a vault container.') + + msg_summary = _('Modified vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[1] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_show(LDAPRetrieve): + __doc__ = _('Display information about a vault container.') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vault(LDAPObject): + """ + Vault object. + """ + container_dn = api.env.container_vault + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', 'description', + ] + search_display_attributes = [ + 'cn', 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='vault_name', + label=_('Vault name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + Bytes('secret?', + cli_name='secret', + label=_('Secret'), + doc=_('Secret'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + ) + + def get_dn(self, *keys, **kwargs): + """ + Generate vault DN. + """ + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(kwargs.get('parent')) + parent_dn = api.Object.vaultcontainer.get_dn(parent_id) + dn = DN(('cn', name), parent_dn) + + return dn + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('in?', + cli_name='in', + doc=_('Input file containing the secret'), + ), + ) + + msg_summary = _('Added vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + + name = entry_attrs.get('cn') + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + + # add parent container if it doesn't exist + try: + (grandparent_id, parent_name) = api.Object.vaultcontainer.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + secret = options.get('secret') + file = options.get('in') + + # don't send these parameters to server + if 'secret' in options: + del options['secret'] + if 'in' in options: + del options['in'] + + if secret: + pass + + elif file: + with open(file) as f: + secret = f.read() + + # create the vault + response = super(vault_add, self).forward(*args, **options) + + # archive an empty secret + api.Command.vault_archive(vault_id, secret=secret) + + return response + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + msg_summary = _('Deleted vault "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + vault_id = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(vault_id, parent=parent_id) + + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa-' + vault_id + + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + return dn + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + msg_summary = ngettext( + '%(count)d vault matched', '%(count)d vaults matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + base_dn = api.Object.vaultcontainer.get_dn(parent_id) + return (filter, base_dn, scope) + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + msg_summary = _('Modified vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[1] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_archive(LDAPRetrieve): + __doc__ = _('Archive a secret into a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Bytes('secret?', + cli_name='secret', + doc=_('Secret to archive'), + ), + Str('in?', + cli_name='in', + doc=_('Input file containing the secret'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + Bytes('encrypted_data?', + cli_name='encrypted_data', + doc=_('Data encrypted with session key and encoded in base-64'), + ), + Bytes('nonce?', + cli_name='nonce', + doc=_('Nonce encrypted encoded in base-64'), + ), + ) + + msg_summary = _('Archived secret into vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + + vault_id = entry_attrs.get('cn')[0] + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa-' + vault_id + + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + encrypted_data = base64.b64decode(options['encrypted_data']) + nonce = base64.b64decode(options['nonce']) + + kra_client.keys.archive_encrypted_data( + client_key_id, + pki.key.KeyClient.PASS_PHRASE_TYPE, + encrypted_data, + wrapped_session_key, + "{1 2 840 113549 3 7}", + base64.encodestring(nonce), + ) + + kra_account.logout() + + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + secret = options.get('secret') + file = options.get('in') + + # don't send these parameters to server + if 'secret' in options: + del options['secret'] + if 'in' in options: + del options['in'] + + if secret: + pass + + elif file: + with open(file) as f: + secret = f.read() + + else: + secret = '' + + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + nonce = crypto.generate_nonce_iv() + session_key = crypto.generate_session_key() + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + encrypted_data = crypto.symmetric_wrap( + secret, + session_key, + nonce_iv=nonce + ) + + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + options['encrypted_data'] = base64.b64encode(encrypted_data) + options['nonce'] = base64.b64encode(nonce) + + return super(vault_archive, self).forward(*args, **options) + + + at register() +class vault_retrieve(LDAPRetrieve): + __doc__ = _('Retrieve a secret from a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Str('out?', + cli_name='out', + doc=_('Output file to store the secret'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + ) + + msg_summary = _('Retrieved secret from vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + + vault_id = entry_attrs.get('cn')[0] + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + + client_key_id = 'ipa-' + vault_id + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + key_client = kra_client.keys + key_info = key_client.get_active_key_info(client_key_id) + + key = key_client.retrieve_key( + key_info.get_key_id(), + wrapped_session_key) + + entry_attrs['encrypted_data'] = base64.b64encode(key.encrypted_data) + entry_attrs['nonce'] = base64.b64encode(key.nonce_data) + + kra_account.logout() + + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + session_key = crypto.generate_session_key() + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + + response = super(vault_retrieve, self).forward(*args, **options) + + encrypted_data = base64.b64decode(response['result']['encrypted_data']) + nonce = base64.b64decode(response['result']['nonce']) + + secret = crypto.symmetric_unwrap( + encrypted_data, + session_key, + nonce_iv=nonce) + + if file: + with open(file, 'w') as f: + f.write(secret) + + else: + response['result']['secret'] = unicode(secret) + + return response diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index d1569697cba7d7fb9f44a3b85afb643a42624f20..9fa736dcf635b286035b4438a6c342e64f09d1d6 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -56,6 +56,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipapk11.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", -- 1.9.0 From edewata at redhat.com Wed Oct 22 20:04:49 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 22 Oct 2014 15:04:49 -0500 Subject: [Freeipa-devel] [PATCH] 355 Added vault access control. Message-ID: <54480DE1.3070103@redhat.com> New LDAP ACIs have been added to allow users to create their own private vault container, to allow owners to manage vaults and containers, and to allow members to use the vaults. New CLIs have been added to manage the owner and member list. For archive and retrieve operations the access control has to be enforced by the plugins because the operations only affects KRA. The LDAP schema has been updated as well. Ticket #3872 This patch depends on #353-2. -- Endi S. Dewata -------------- next part -------------- From ccbfa01f40e2ac4c978e5ef0f1fbe167f96793a2 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 17 Oct 2014 12:05:34 -0400 Subject: [PATCH] Added vault access control. New LDAP ACIs have been added to allow users to create their own private vault container, to allow owners to manage vaults and containers, and to allow members to use the vaults. New CLIs have been added to manage the owner and member list. For archive and retrieve operations the access control has to be enforced by the plugins because the operations only affects KRA. The LDAP schema has been updated as well. Ticket #3872 --- API.txt | 134 +++++++++++++++++++++-- VERSION | 4 +- install/share/60basev4.ldif | 4 +- install/updates/40-vault.update | 7 ++ ipalib/plugins/vault.py | 233 +++++++++++++++++++++++++++++++++++++++- 5 files changed, 366 insertions(+), 16 deletions(-) diff --git a/API.txt b/API.txt index cfa6558fcf678e5915a90407da517f9a591a41bf..a46592ec9e82e618154bf09393c83d4b854315c5 100644 --- a/API.txt +++ b/API.txt @@ -4476,11 +4476,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add -args: 1,8,3 +args: 1,9,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('in?', cli_name='in') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4489,12 +4490,39 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault_add_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('encrypted_data?', cli_name='encrypted_data') option: Str('in?', cli_name='in') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Bytes('nonce?', cli_name='nonce') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4515,11 +4543,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vault_find -args: 1,10,4 +args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4532,12 +4561,13 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vault_mod -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4547,10 +4577,37 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_remove_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault_remove_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_retrieve -args: 1,7,3 +args: 1,8,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('out?', cli_name='out') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4561,9 +4618,10 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_show -args: 1,5,3 +args: 1,6,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4572,11 +4630,12 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vaultcontainer_add -args: 1,7,3 +args: 1,8,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') @@ -4584,6 +4643,32 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vaultcontainer_add_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vaultcontainer_add_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vaultcontainer_del args: 1,3,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) @@ -4594,11 +4679,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vaultcontainer_find -args: 1,9,4 +args: 1,10,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4610,12 +4696,13 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vaultcontainer_mod -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4624,11 +4711,38 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vaultcontainer_remove_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vaultcontainer_remove_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vaultcontainer_show -args: 1,5,3 +args: 1,6,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('version?', exclude='webui') diff --git a/VERSION b/VERSION index fe23eae5f349f4a2d40c3d3e55f6168a82b961b2..c471ed80af6a2c26be7fc89281ae60fac6c68577 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=109 -# Last change: edewata - initial vault implementation +IPA_API_VERSION_MINOR=110 +# Last change: edewata - added vault access control diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif index 97553d53938093c1b0ecba0826fc469d0d758c62..61590562ffa174134e10567be93c18ab437d8008 100644 --- a/install/share/60basev4.ldif +++ b/install/share/60basev4.ldif @@ -1,3 +1,3 @@ dn: cn=schema -objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) -objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.1' ) diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update index 59e5b629ce4e6c5acac06df78f02106afa6c859e..455d4719f612198890f8a914d3a13794a3b9ad75 100644 --- a/install/updates/40-vault.update +++ b/install/updates/40-vault.update @@ -4,6 +4,13 @@ default: objectClass: nsContainer default: objectClass: ipaVaultContainer default: cn: vaults default: description: Root vault container +default: aci: (target="ldap:///cn=*,cn=users,cn=vaults,$SUFFIX")(targetattr="*")(version 3.0; acl "Allow add macro dn"; allow (add) userdn = "ldap:///uid=($$attr.cn),cn=users,cn=accounts,$SUFFIX";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container members can access the container"; allow(read, search, compare) userattr="member#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container owners can modify the container"; allow(read, search, compare, write) userattr="owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container owners can manage sub-containers"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Container owners can manage vaults in the container"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault members can access the vault"; allow(read, search, compare) userattr="member#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault owners can modify the vault"; allow(read, search, compare, write) userattr="owner#USERDN";) dn: cn=services,cn=vaults,$SUFFIX default: objectClass: top diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index c0e66621d1cf326b0bfb88565951d66cda3b9500..95f96859235af1c477c8f5738a27571d64aabe3a 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -68,6 +68,18 @@ EXAMPLES: Delete a vault: ipa vault-del MyVault + Add a vault owner: + ipa vault-add-owner MyVault --users testuser + + Delete a vault owner: + ipa vault-remove-owner MyVault --users testuser + + Add a vault member: + ipa vault-add-member MyVault --users testuser + + Delete a vault member: + ipa vault-remove-member MyVault --users testuser + List private vault containers: ipa vaultcontainer-find @@ -82,6 +94,18 @@ EXAMPLES: Delete a vault container: ipa vaultcontainer-del MyContainer + + Add a vault container owner: + ipa vaultcontainer-add-owner MyContainer --users testuser + + Delete a vault container owner: + ipa vaultcontainer-remove-owner MyContainer --users testuser + + Add a vault container member: + ipa vaultcontainer-add-member MyContainer --users testuser + + Delete a vault container member: + ipa vaultcontainer-remove-member MyContainer --users testuser """) register = Registry() @@ -98,11 +122,15 @@ class vaultcontainer(LDAPObject): object_class = ['ipaVaultContainer'] default_attributes = [ - 'cn', 'description', + 'cn', 'description', 'owner', 'member', ] search_display_attributes = [ 'cn', 'description', ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } label = _('Vault Containers') label_singular = _('Vault Container') @@ -206,6 +234,11 @@ class vaultcontainer_add(LDAPCreate): name = entry_attrs.get('cn') parent_id = self.obj.normalize_id(options.get('parent')) + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + owner_dn = self.api.Object['user'].get_dn(username) + entry_attrs['owner'] = owner_dn + # add parent container if it doesn't exist try: (grandparent_id, parent_name) = self.obj.split_id(parent_id) @@ -293,6 +326,93 @@ class vaultcontainer_show(LDAPRetrieve): @register() +class vaultcontainer_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault container.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner added.', '%i owners added.') + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault container.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner removed.', '%i owners removed.') + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault container.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault container.') + + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() class vault(LDAPObject): """ Vault object. @@ -303,11 +423,15 @@ class vault(LDAPObject): object_class = ['ipaVault'] default_attributes = [ - 'cn', 'description', + 'cn', 'description', 'owner', 'member', ] search_display_attributes = [ 'cn', 'description', ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } label = _('Vaults') label_singular = _('Vault') @@ -371,6 +495,11 @@ class vault_add(LDAPCreate): parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) dn = self.obj.get_dn(name, parent=parent_id) + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + owner_dn = self.api.Object['user'].get_dn(username) + entry_attrs['owner'] = owner_dn + # add parent container if it doesn't exist try: (grandparent_id, parent_name) = api.Object.vaultcontainer.split_id(parent_id) @@ -541,6 +670,15 @@ class vault_archive(LDAPRetrieve): def post_callback(self, ldap, dn, entry_attrs, *keys, **options): vault_id = entry_attrs.get('cn')[0] + owners = entry_attrs.get('owner', []) + members = entry_attrs.get('member', []) + + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + user_dn = self.api.Object['user'].get_dn(username) + + if user_dn not in owners and user_dn not in members: + raise errors.ACIError(info=_("Insufficient access to vault '%s'.") % vault_id) kra_client = api.Backend.kra.get_client() @@ -656,6 +794,15 @@ class vault_retrieve(LDAPRetrieve): def post_callback(self, ldap, dn, entry_attrs, *keys, **options): vault_id = entry_attrs.get('cn')[0] + owners = entry_attrs.get('owner', []) + members = entry_attrs.get('member', []) + + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + user_dn = self.api.Object['user'].get_dn(username) + + if user_dn not in owners and user_dn not in members: + raise errors.ACIError(info=_("Insufficient access to vault '%s'.") % vault_id) wrapped_session_key = base64.b64decode(options['wrapped_session_key']) @@ -722,3 +869,85 @@ class vault_retrieve(LDAPRetrieve): response['result']['secret'] = unicode(secret) return response + + + at register() +class vault_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner added.', '%i owners added.') + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner removed.', '%i owners removed.') + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn -- 1.9.0 From edewata at redhat.com Wed Oct 22 20:06:08 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 22 Oct 2014 15:06:08 -0500 Subject: [Freeipa-devel] [PATCH] 356 Added command to retrieve vault transport certificate. Message-ID: <54480E30.8040905@redhat.com> A new command has been added to retrieve the vault transport certificate and optionally save it into a file. The vault archive and retrieve command has been modified to retrieve the transport certificate and store it locally for subsequent usage. This way it's no longer necessary to manually import the transport certificate into the client's NSS database. Ticket #3872 This patch depends on #355. -- Endi S. Dewata -------------- next part -------------- From abeda85904f7247f1f0d679a71a7094bb2cefe0c Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Wed, 22 Oct 2014 10:02:25 -0400 Subject: [PATCH] Added command to retrieve vault transport certificate. A new command has been added to retrieve the vault transport certificate and optionally save it into a file. The vault archive and retrieve command has been modified to retrieve the transport certificate and store it locally for subsequent usage. This way it's no longer necessary to manually import the transport certificate into the client's NSS database. Ticket #3872 --- API.txt | 5 +++ VERSION | 4 +-- ipalib/plugins/vault.py | 85 +++++++++++++++++++++++++++++++++++++++++++++++-- 3 files changed, 89 insertions(+), 5 deletions(-) diff --git a/API.txt b/API.txt index a46592ec9e82e618154bf09393c83d4b854315c5..95b86ce84f5bc9f1d879e561e07b0348d719c90e 100644 --- a/API.txt +++ b/API.txt @@ -4629,6 +4629,11 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_transport_cert +args: 0,2,1 +option: Str('out?', cli_name='out') +option: Str('version?', exclude='webui') +output: Output('result', None, None) command: vaultcontainer_add args: 1,8,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) diff --git a/VERSION b/VERSION index c471ed80af6a2c26be7fc89281ae60fac6c68577..d0ada131b700e93faa8c4946b811db36d76341a9 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=110 -# Last change: edewata - added vault access control +IPA_API_VERSION_MINOR=111 +# Last change: edewata - added vault transport certificate diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 95f96859235af1c477c8f5738a27571d64aabe3a..871c3e3a25c688a64ba0ecfde5ccbd50b47fbe01 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -24,6 +24,8 @@ import shutil import string import tempfile +import nss.nss as nss + import pki import pki.account import pki.crypto @@ -109,7 +111,7 @@ EXAMPLES: """) register = Registry() -transport_cert_nickname = "KRA Transport Certificate" +transport_cert_filename = "vault-transport.pem" @register() class vaultcontainer(LDAPObject): @@ -628,6 +630,63 @@ class vault_show(LDAPRetrieve): @register() +class vault_transport_cert(Command): + __doc__ = _('Retrieve vault transport certificate.') + + + # list of attributes we want exported to JSON + json_friendly_attributes = ( + 'takes_args', + ) + + takes_options = ( + Str('out?', + cli_name='out', + doc=_('Output file to store the transport certificate'), + ), + ) + + has_output_params = ( + Str('certificate', + label=_('Certificate'), + ), + ) + + def __json__(self): + json_dict = dict( + (a, getattr(self, a)) for a in self.json_friendly_attributes + ) + json_dict['takes_options'] = list(self.get_json_options()) + return json_dict + + def execute(self, *args, **options): + + kra_client = api.Backend.kra.get_client() + transport_cert = kra_client.system_certs.get_transport_cert() + return { + 'result': { + 'certificate': transport_cert.encoded + } + } + + def forward(self, *args, **options): + + file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + response = super(vault_transport_cert, self).forward(*args, **options) + + if file: + with open(file, 'w') as f: + f.write(response['result']['certificate']) + + return response + + + at register() class vault_archive(LDAPRetrieve): __doc__ = _('Archive a secret into a vault.') @@ -743,7 +802,17 @@ class vault_archive(LDAPRetrieve): nonce = crypto.generate_nonce_iv() session_key = crypto.generate_session_key() - nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + ipa_dir = os.path.join(os.path.expanduser('~'), '.ipa') + if not os.path.exists(ipa_dir): + os.makedirs(ipa_dir) + + transport_cert_path = os.path.join(ipa_dir, transport_cert_filename) + if not os.path.exists(transport_cert_path): + api.Command.vault_transport_cert(out=unicode(transport_cert_path)) + + transport_cert_der = nss.read_der_from_file(transport_cert_path, True) + nss_transport_cert = nss.Certificate(transport_cert_der) wrapped_session_key = crypto.asymmetric_wrap( session_key, @@ -842,7 +911,17 @@ class vault_retrieve(LDAPRetrieve): ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR session_key = crypto.generate_session_key() - nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + ipa_dir = os.path.join(os.path.expanduser('~'), '.ipa') + if not os.path.exists(ipa_dir): + os.makedirs(ipa_dir) + + transport_cert_path = os.path.join(ipa_dir, transport_cert_filename) + if not os.path.exists(transport_cert_path): + api.Command.vault_transport_cert(out=unicode(transport_cert_path)) + + transport_cert_der = nss.read_der_from_file(transport_cert_path, True) + nss_transport_cert = nss.Certificate(transport_cert_der) wrapped_session_key = crypto.asymmetric_wrap( session_key, -- 1.9.0 From mkosek at redhat.com Thu Oct 23 08:39:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 23 Oct 2014 10:39:23 +0200 Subject: [Freeipa-devel] [PATCH] 773-777 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type In-Reply-To: <5447EBE0.4080203@redhat.com> References: <543E6685.8000704@redhat.com> <5447EBE0.4080203@redhat.com> Message-ID: <5448BEBB.6030609@redhat.com> On 10/22/2014 07:39 PM, Tomas Babej wrote: > Hi, > > thank you for the patches, comments inline. > > > On 10/15/2014 02:20 PM, Petr Vobornik wrote: >> ticket: https://fedorahosted.org/freeipa/ticket/4221 >> >> == [PATCH] 773 ranges: prohibit setting --rid-base with >> ipa-trust-ad-posix type == >> >> We should not allow setting --rid-base for ranges of >> ipa-trust-ad-posix since we do not perform any RID -> UID/GID mappings >> for these ranges (objects have UID/GID set in AD). Thus, setting RID >> base makes no sense. >> >> Since ipaBaseRID is a MUST in ipaTrustedADDomainRange object class, >> value '0' is allowed and used internally for 'ipa-trust-ad-posix' >> range type. > > We probably don't want to display the first RID if it is 0 and the type > is ad-posix. This occurs in idrange-find: > > [tbabej at vm-043 labtool]$ ipa idrange-find > > ---------------- > 2 ranges matched > ---------------- > Range name: DOM043.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range > First Posix ID of the range: 514800000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 1000 > First RID of the secondary RID range: 100000000 > Range type: local domain range > > Range name: TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range > First Posix ID of the range: 10000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 0 > Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 > Range type: Active Directory trust range with POSIX attributes > > ---------------------------- > Number of entries returned 2 > ---------------------------- > > And also idrange-show: > > [tbabej at vm-043 labtool]$ ipa idrange-show TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range > Range name: TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range > First Posix ID of the range: 10000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 0 > Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 > Range type: Active Directory trust range with POSIX attributes > > >> >> No schema change is done. >> >> == [PATCH] 774 unittests: baserid for ipa-ad-trust-posix idranges == > > Looks good. > >> >> == [PATCH] 775 ldapupdater: set baserid to 0 for ipa-ad-trust-posix >> ranges == > > Can you use the paged_search=True in find_entries instead of having a > infinite loop? It would make this code quite cleaner. I also saw you did not update Makefile.am. > > >> >> New updater plugin which sets baserid to 0 for ranges with type >> ipa-ad-trust-posix >> >> https://fedorahosted.org/freeipa/ticket/4221 >> >> == [PATCH] 776 idrange: include raw range type in output == >> >> iparangetype output is a localized human-readable value which is not >> suitable for machine-based API consumers >> >> Solved by new iparangetyperaw output attribute which contains >> iparangetype's raw value >> >> Note: I don't like this approach. It would be better to return just >> the raw value a do the transformation in clients. But we do have a >> precedent: >> http://www.redhat.com/archives/freeipa-devel/2012-January/msg00190.html > > I am not happy about it either.. I guess we could create a capability > for this, but it would probably be a overkill. > > > >> >> == [PATCH] 777 webui: prohibit setting rid base with >> ipa-trust-ad-posix type == >> >> Base RID is no longer editable for ipa-trust-ad-posix range type >> >> Adder dialog: >> - Range type selector was moved up because it affects a field above it >> >> Details page: >> - Only fields relevant to range's type are visible >> >> > Looks fine. > > On a related note, I added a new ticket > https://fedorahosted.org/freeipa/ticket/4661 > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From pviktori at redhat.com Thu Oct 23 08:59:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 23 Oct 2014 10:59:02 +0200 Subject: [Freeipa-devel] [PATCH] 352 Fixed KRA backend. In-Reply-To: <5447C07C.4000800@redhat.com> References: <543F4294.1080001@redhat.com> <5447C07C.4000800@redhat.com> Message-ID: <5448C356.9040105@redhat.com> On 10/22/2014 04:34 PM, Endi Sukma Dewata wrote: > On 10/15/2014 10:59 PM, Endi Sukma Dewata wrote: >> The KRA backend has been simplified since most of the tasks have >> been moved somewhere else. The transport certificate will be >> installed on the client, and it is not needed by KRA backend. The >> KRA agent's PEM certificate is now generated during installation >> due to permission issue. The kra_host() for now is removed since >> the current ldap_enable() cannot register the KRA service, so it >> is using the kra_host environment variable. >> >> The KRA installer has been modified to use Dogtag's CLI go create >> KRA agent and setup the client authentication. >> >> The proxy settings have been updated to include KRA's URLs. >> >> The certs.install_pem_from_p12() has been updated to generate the >> proper client certificate using the -clcerts option and also take >> a password file. >> >> Some constants have been renamed for clarity. The DOGTAG_AGENT_P12 >> has been renamed to DOGTAG_ADMIN_P12 since file actually contains >> the Dogtag admin's certificate and private key and it can be used >> to access both CA and KRA. The DOGTAG_AGENT_PEM has been renamed >> to KRA_AGENT_PEM since it can only be used for KRA. >> >> Ticket #3872 > > New patch attached. It's identical to the previous one except I changed > the ticket number to #4503. In IPA we usually include the full ticket URL, not just the number. The build fails with a lint message: ************* Module ipaserver.plugins.dogtag ipaserver/plugins/dogtag.py:1903: [E1123(unexpected-keyword-arg), kra.get_client] Unexpected keyword argument 'password_file' in constructor call) ipaserver/plugins/dogtag.py:1903: [E1120(no-value-for-parameter), kra.get_client] No value for argument 'certdb_password' in constructor call) I have pki-base-10.2.0-3.fc21.noarch, where NSSCryptoProvider indeed takes password and not password_file. If a newer version is required you should put it in the spec. ipaserver.install.certs.CertDB.install_pem_from_p12: If p12_passwd is missing and pwd_fname is None, this will crash. Please document how the method should be called. And assert that exactly one of p12_passwd and pwd_fname is given. ipaserver.plugins.dogtag.kra.get_client: Should every caller check if this returns None? If not, raise an exception instead. If yes, at least mention it in a docstring. Typo in commit message: "modified to use Dogtag's CLI *go* create" -- Petr? From pvoborni at redhat.com Thu Oct 23 10:19:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 23 Oct 2014 12:19:18 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.1.0 Message-ID: <5448D626.4080405@redhat.com> The FreeIPA team is proud to announce FreeIPA v4.1.0! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1 == === Enhancements === * New concept of 'ID Views' allowing FreeIPA administrator to define or override POSIX attributes for users/groups coming from trusted domains. Such users then do not need to have POSIX attributes defined in the Active Directory to authenticate to FreeIPA clients. It also allows to assign particular view to selected hosts or hostgroups, thus allowing having a user / group with different POSIX attributes on different hosts. Per-host overrides should be used with extreme care! [http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust] * New tool ipa-cacert-manage to manually renew or change FreeIPA PKI CA certificate [http://www.freeipa.org/page/V4/CA_certificate_renewal] * DNSSEC Support * OTP authentication plugin now prevents multiple usage of token codes on a single FreeIPA server * DNS interface now supports adding DNS root zone (".") allowing admin to for example centrally override DNS root hints. * DNS zone adding interface was simplified - name server and it's IP address is no longer required. The list of authoritative name servers are read from LDAP * Seamless signing of FreeIPA CA us a subCA in Windows Certificate Services [https://fedorahosted.org/freeipa/ticket/4496] * New option --request-cert to optionally request host certificates on FreeIPA clients (to /etc/ipa/nssdb/) * CLI and Web UI for 'retrive keytab' and 'create keytab' authorization [http://www.freeipa.org/page/V4/Keytab_Retrieval_Management] * Services can now be assigned as members of RBAC roles * `ipa` command run with `-vv` option now prints JSON request and reply exchanged with the FreeIPA server. `-vvv` also prints HTTP communication. * Description attribute is no longer required (e.g. in groups, sudo command groups or others) given that it is also not required in schema. * Packages can be now built and installed on RHEL/CentOS 7.0 * ipa-replica-prepare now waits for the replica DNS record to be available to fix race conditions in automated test environments * Port 8443 is now checked before server installation to prevent failures in configuring PKI which uses the port === Bug fixes === * Server installers can now handle hosts with multiple IPv4 or IPv6 addresses * DNS zone interface no longer accepts `--class` option as it had no effect as FreeIPA DNS only supports 'IN' class. * ipa-ldap-upgrade restores Directory Server settings when upgrade fails * SSLv3.0 (CVE-2014-3566) ciphers are now disabled on new installations === DNSSEC Support === FreeIPA now automates basic key management for Domain Name System Security Extensions (DNSSEC) [http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Overview]. Before you start signing you DNS zones you have to install DNSSEC key master role to an existing FreeIPA DNS server using command: ipa-dns-install --dnssec-master It allows you to enable DNSSEC for particular DNS zone using command: ipa dnszone-mod zone.name.example. --dnssec=true This command will generate new zone keys, distribute keys to all FreeIPA DNS servers and configure all servers to independently sign the zone. Please keep in mind that it can take few minutes before all servers sign the zone. ==== Known Limitations ==== * User has to manually upload Delegation Signer (DS) record [http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Records] to parent DNS zone to establish chain of trust. * User has to manually confirm that DS record in parent zone was published otherwise Key Signing Key (KSK) [http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Key_management] will not be rotated. This confirmation has to be done on FreeIPA server with key master role using following command: sudo -u ods ods-ksmutil key ds-seen --zone zone.name.example. --keytag 12345 * Keytag can be obtained from dig output: dig +dnssec zone.name.example. DS * User is not notified about automated key rotation. This does not lower stability of the system because of `ds-seen` logic mentioned above. * Key and signing policy cannot be changed using FreeIPA tools. Currently it is stored in `/etc/opendnssec/kasp.xml` file on DNSSEC key master server. Manual changes to `kasp.xml` will be lost during next FreeIPA upgrade. * Only one FreeIPA server can have DNSSEC key master role: ** *Please plan carefully, current version does not allow you to easily move DNSSEC master role to a different server.* ** DNSSEC key management will not work when the key master is not running, i.e. DNSSEC keys will not be rotated according to the policy and keys for new zones will not be generated. == Known Issues == * Directory Server may deadlock in some situations (tracked in upstream ticket [https://fedorahosted.org/freeipa/ticket/4635]). * SSLv3.0 (CVE-2014-3566) ciphers are not disabled on upgrades. See CVE-2014-3566 and referred external articles on advise how to deal with this vulnerability. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.0 == Alexander Bokovoy (15): ipaserver/dcerpc.py: if search of a closest GC failed, try to find any GC ipaserver/dcerpc.py: make PDC discovery more robust ipaserver/dcerpc.py: Avoid hitting issue with transitive trusts on Windows Server prior to 2012 ipaserver/dcerpc.py: be more open to what domains can be seen through the forest trust ipaserver/dcerpc.py: Make sure trust is established only to forest root domain Support overridding user shell in ID views Allow user overrides to specify SSH public keys Allow user overrides to specify GID of the user Allow override of gecos field in ID views Update API version for ID views support Require slapi-nis 0.54 or later for ID views support Support idviews in compat tree Change ipaOverrideTarget OID to avoid conflict with DNSSEC feature updater: enable uid uniqueness plugin for posixAccounts Default to use TLSv1.0 and TLSv1.1 on the IPA server side Ana Krivokapi? (1): Remove internaldb password from password.conf David Kupka (20): Fix ipa-client-install --uninstall crash Always record that pkicreate has been executed. Improve password validity check. Fix group-remove-member crash when group is removed from a protected group test group: remove group from protected group. Verify otptoken timespan is valid Add record(s) to /etc/host when IPA is configured as DNS server. Use certmonger D-Bus API instead of messing with its files. Do not restart apache server when not necessary. Allow user to force Kerberos realm during installation. Fix typo causing ipa-upgradeconfig to fail. Add 'host' setting into default.conf configuration file on client. Fix description in man page. Detect and configure all usable IP addresses. Do not require description in UI. Fix example usage in ipa man page. Check that port 8443 is available when installing PKI. Set IPA CA for freeipa certificates. Stop dogtag when updating its configuration in ipa-upgradeconfig. Fix printing of reverse zones in ipa-dns-install. Fix typo causing certmonger is provided with wrong path to ipa-submit. Gabe Alford (5): Fix typos in dns.py Enable debug pid in smb.conf ipa trust-add command should be interactive Fix hardcoded lib dir in freeipa.spec Missing requires on python-dns in spec file Jakub Hrozek (1): CLIENT: Explicitly require python-backports-ssl_match_hostname Jan Cholasta (100): Check if /root/ipa.csr exists when installing server with external CA. Exclude attributelevelrights from --raw result processing in baseldap. Add function for checking if certificate is self-signed to ipalib.x509. Support CA certificate renewal in dogtag-ipa-ca-renew-agent. Allow IPA master hosts to update CA certificate in LDAP. Automatically update CA certificate in LDAP on renewal. Track CA certificate using dogtag-ipa-ca-renew-agent. Add method for setting CA renewal master in LDAP to CAInstance. Provide additional functions to ipapython.certmonger. Move external cert validation from ipa-server-install to installutils. Add method for verifying CA certificates to NSSDatabase. Add permissions for CA certificate renewal. Add CA certificate management tool ipa-cacert-manage. Alert user when externally signed CA is about to expire. Load sysupgrade.state on demand. Pick new CA renewal master when deleting a replica. Remove master ACIs when deleting a replica. Do not use ldapi in certificate renewal scripts. Check that renewed certificates coming from LDAP are actually renewed. Allow IPA master hosts to read and update IPA master information. Do not treat the IPA RA cert as CA cert in DS NSS database. Remove certificate "External CA cert" from /etc/pki/nssdb on client uninstall. Allow specifying trust flags in NSSDatabase and CertDB method trust_root_cert. Fix trust flags in HTTP and DS NSS databases. Add LDAP schema for wrapped cryptographic keys. Add LDAP schema for certificate store. Add container for certificate store. Configure attribute uniqueness for certificate store. Add permissions for certificate store. Add functions for extracting certificates fields in DER to ipalib.x509. Add function for extracting extended key usage from certs to ipalib.x509. Add certificate store module ipalib.certstore. Upload CA chain from DS NSS database to certificate store on server install. Upload CA chain from DS NSS database to certificate store on server update. Rename CertDB method add_cert to import_cert. Add new add_cert method for adding certificates to NSSDatabase and CertDB. Import CA certs from certificate store to DS NSS database on replica install. Import CA certs from certificate store to HTTP NSS database on server install. Upload renewed CA cert to certificate store on renewal. Refactor CA certificate fetching code in ipa-client-install. Support multiple CA certificates in /etc/ipa/ca.crt in ipa-client-install. Add function for writing list of certificates to a PEM file to ipalib.x509. Get CA certs for /etc/ipa/ca.crt from certificate store in ipa-client-install. Allow overriding NSS database path in RPCClient. Get CA certs for /etc/pki/nssdb from certificate store in ipa-client-install. Add functions for DER encoding certificate extensions to ipalib.x509. Get CA certs for system-wide store from cert store in ipa-client-install. Get up-to-date CA certificates from certificate store in ipa-replica-install. Add client certificate update tool ipa-certupdate. Export full CA chain to /etc/ipa/ca.crt in ipa-server-install. Allow multiple CA certificates in replica info files. Add new NSSDatabase method get_cert for getting certs from NSS databases. Allow changing chaining of the IPA CA certificate in ipa-cacert-manage. Update CS.cfg on IPA CA certificate chaining change in renew_ca_cert. Allow adding CA certificates to certificate store in ipa-cacert-manage. Allow upgrading CA-less to CA-full using ipa-ca-install. Update external CA cert in Dogtag NSS DB on IPA CA cert renewal. Enable NSS PKIX certificate path discovery and validation for Dogtag. Add test for baseldap.entry_to_dict. Fix parsing of long nicknames in certutil -L output. Convert external CA chain to PKCS#7 before passing it to pkispawn. Allow changing CA renewal master in ipa-csreplica-manage. Normalize external CA cert before passing it to pkispawn Make CA-less ipa-server-install option --root-ca-file optional. Backup CS.cfg before modifying it Use autobind when updating CA people entries during certificate renewal Fix certmonger code causing the ca_renewal_master update plugin to fail Allow RPM upgrade from ipa-* packages Include ipaplatform in client-only build Include the ipa command in client-only build Allow specifying signing algorithm of the IPA CA cert in ipa-server-install. Add NSSDatabase.import_files method for importing files in various formats External CA installer options usability fixes CA-less installer options usability fixes Allow choosing CA-less server certificates by name Do stricter validation of CA certificates Introduce NSS database /etc/ipa/nssdb Move NSSDatabase from ipaserver.certs to ipapython.certdb Add NSSDatabase.has_nickname for checking nickname presence in a NSS DB Use NSSDatabase instead of direct certutil calls in client code Use /etc/ipa/nssdb to get nicknames of IPA certs installed in /etc/pki/nssdb Check if IPA client is configured in ipa-certupdate Get server hostname from jsonrpc_uri in ipa-certupdate Remove ipa-ca.crt from systemwide CA store on client uninstall and cert update Fix certmonger.wait_for_request Fix certmonger search for the CA cert in ipa-certupdate and ipa-cacert-manage Add missing imports to ipapython.certdb Remove misleading authorization error message in cert-request with --add Split off generic Red Hat-like platform code from Fedora platform code Add RHEL platform module Support building RPMs for RHEL/CentOS 7.0 Support MS CS as the external CA in ipa-server-install and ipa-ca-install Allow specifying signing algorithm of the IPA CA cert in ipa-ca-install Fix CA cert validity check for CA-less and external CA installer options Fix certmonger.request_cert Add ipa-client-install switch --request-cert to request cert for the host Do not create ipa-pki-proxy.conf if CA is not configured in ipa-upgradeconfig Do not fix trust flags in the DS NSS DB in ipa-upgradeconfig Check LDAP instead of local configuration to see if IPA CA is enabled DNSSEC: remove container_dnssec_keys Ludwig Krispenz (2): Update SSL ciphers configured in 389-ds-base Ignore irrelevant subtrees in schema compat plugin Luk?? Slebodn?k (2): Fix warning: Using uninitialized value ld. Add missing break Martin Ba?ti (48): Fix DNS upgrade plugin should check if DNS container exists FIX: named_enable_dnssec should verify if DNS is installed Allow to add host if AAAA record exists Tests: host tests with dns Fix dnsrecord-mod raise error if last record attr is removed DNSSEC: fix DS record validation Tests: DNS dsrecord validation DNS fix NS record coexistence validator Test: DNS NS validation Fix DNS record rename test FIX DNS wildcard records (RFC4592) Tests: DNS wildcard records dnszone-remove-permission should raise error DNS: remove --class option WebUI: DNS: remove --class option FIX: ldap schmema updater needs correct ordering of the updates Fix DNS plugin to allow to add root zone DNS test: allow '.' as zone name Deprecation of --name-server and --ip-address option in DNS Add correct NS records during installation DNS: autofill admin email WebUI: DNS: Remove ip-address, admin-email options DNS tests: tests update to due to change in options Remove --ip-address, --name-server otpions from DNS help Refactoring of autobind, object_exists LDAP disable service DNS missing tests Fix ipactl service ordering Add missing attributes to named.conf Make named.conf template platform independent Remove ipaContainer, ipaOrderedContainer objectclass Add mask, unmask methods for service DNSSEC: dependencies DNSSEC: schema DNSSEC: add ipapk11helper module DNSSEC: DNS key synchronization daemon DNSSEC: opendnssec services DNSSEC: platform paths and services DNSSEC: validate forwarders DNSSEC: modify named service to support dnssec DNSSEC: installation DNSSEC: uninstallation DNSSEC: upgrading DNSSEC: ACI DNSSEC: add files to backup DNSSEC: change link to ipa page fix DNSSEC restore named state fix forwarder validation errors Martin Ko?ek (8): Do not require dogtag-pki-server-theme Allow hashed passwords in DS Do not crash client basedn discovery when SSF not met ipa-adtrust-install does not re-add member in adtrust agents group Sudorule RunAsUser should work with external groups Raise better error message for permission added to generated tree Remove changetype attribute from update plugin Update contributors Nathaniel McCallum (13): Fix login password expiration detection with OTP Update freeipa-server krb5-server dependency to 1.11.5-5 Fix ipa-getkeytab for pre-4.0 servers Add TOTP watermark support Ensure ipaUserAuthTypeClass when needed on user creation Update qrcode support for newer python-qrcode Use stack allocation when writing values during otp auth Move OTP synchronization step to after counter writeback Remove token ID from self-service UI Remove token vendor, model and serial defaults Display token type when viewing token Create ipa-otp-counter 389DS plugin Configure IPA OTP Last Token plugin on upgrade Petr Viktorin (34): baseldap: Return empty string when no effective rights are found ldap2 indirect membership processing: Use global limits if greater than per-query ones test_xmlrpc: Update tests Update API.txt test_ipagetkeytab: Fix assertion in negative test Support delegating RBAC roles to service principals service: Normalize service principal in get_dn freeipa.spec.in: Add python-backports-ssl_match_hostname to BuildRequires permission plugin: Make --target available in the CLI permission plugin: Improve description of the target option Add managed read permissions for compat tree Fix: Add managed read permissions for compat tree and operational attrs Update referential integrity config for DS 1.3.3 permission plugin: Auto-add operational atttributes to read permissions Allow deleting obsolete permissions; remove operational attribute permissions ipaserver.install: Consolidate system user creation ipa_restore: Split the services list backup,restore: Don't overwrite /etc/{passwd,group} ipa_backup: Log where the backup is be stored Add basic test for backup & restore Add test for backup/delete system users/restore JSON client: Log pretty-printed request and response with -vv or above test_permission_plugin: Check legacy permissions upgradeinstance: Restore listeners on failure ipa-replica-prepare: Wait for the DNS entry to be resolvable Move setting SELinux booleans to platform code ipa-restore: Set SELinux booleans when restoring ipaserver.install.service: Don't show error message on SystemExit(0) VERSION,Makefile: Rename "pre" to "alpha" Become IPA 4.1.0 Alpha 1 test_service_plugin: Do not lowercase memberof_role test_forced_client_reenrollment: Don't check for host certificates backup/restore: Add files from /etc/ipa/nssdb sudo integration test: Remove the local user test Petr Voborn?k (81): webui: capitalize labels of undo and undo all buttons webui: improve usability of attributes widget webui: add filter to attributes widget webui: optimize (re)creation of option widget webui: custom attr in attributes widget webui: attr widget: get list of possible attrs from ipapermdefaultattr webui: option_widget_base: sort options webui: reflect readonly state webui: fix add of input group class webui: show managed fields as readonly and not disabled webui: fix selection of empty value in a select widget webui: disable ipapermbindruletype if permission in a privilege webui: fix disabled state of service's PAC type baseldap: return 'none' attr level right as unicode string webui: support wildcard attribute level rights webui: fix nested items creation in dropdown list webui: internet explorer fixes webui: detach facet nodes webui: replace action_buttons with action_widget webui: remove remaining action-button-disabled occurrences webui: add bounce url to reset_password.html webui-ci: fix reset password check webui: better error reporting webui-ci: fix table widget add webui: display expired session notification in a more visible area webui: improved info msgs on login/token sync/reset pwd pages webui: login screen - improved button switching webui: rename tooltip to title webui: tooltip support webui: better authentication types description webui: convert widget.less indentation to spaces webui: improve rule table css webui: sshkey widget - usability fixes webui: disable batch action buttons by default webui: fix group type padding webui: extract complex pkey on Add and Edit webui: adjust behavior of bounce url webui: do not show login error when switching back from otp sync screen webui: switch associators if default doesn't work webui: notify psw change success only once webui: append network.negotiate-auth.trusted-uris install: create ff krb extension on every install, replica install and upgrade webui: add measurement unit to otp token time fields webui: better otp token type label webui: add token from user page webui: add i18n for the rest of QR code strings webui: display fields based on otp token type webui: better value-change reporting webui: widget initialization webui: hide empty fields and sections webui: hide non-readable fields webui: hide otp fields based on token type webui: fix regression in association facet preop webui-ci: case-insensitive record check webui: do not offer ipa-ad-winsync and ipa-ipa-trust range types webui: improve breadcrumb navigation webui: treat value as pkey in link widget webui: do not show internal facet name to user webui: allow to skip link widget link validation webui: add simple link column support webui: new ID views section webui: facet group labels for idview's facets webui: list only not-applied hosts in "apply to host" dialog webui: add link from host to idview webui-ci: adjust dnszone-add test to recent DNS changes dns: fix privileges' memberof during dns install keytab manipulation permission management tests: management of keytab permissions idviews: error out if appling Default Trust View on hosts webui: add link to OTP token app webui: add new iduseroverride fields webui: management of keytab permissions webui: allow --force in dnszone-mod and dnsrecord-add webui: make Evented a part of base IPA.object webui: change order of idview's facet groups webui: hide applied to hosts tab for Default Trust View webui: hide (un)apply buttons for Default Trust View webui: do not offer ipa users to Default Trust View webui: do not show closed dialog webui: update combobox input on list click Become IPA 4.1.0 Petr ?pa?ek (1): DNSSEC: add ipa dnssec daemons Rob Crittenden (1): No longer generate a machine certificate on client installs Stephen Gallagher (1): Change BuildRequires for Java Sumit Bose (4): ipa-kdb: fix unit tests extdom: add support for new version extdom: add support for sss_nss_getorigbyname() extdom: remove unused dependency to libsss_idmap Tom?? Babej (44): trusts: Validate missing trust secret properly ipatests: tasks: Fix dns configuration for trusts trusts: Make cn=adtrust agents sysaccount nestedgroup baseldap: Remove redundant search from LDAPAddReverseMember and LDAPRemoveReverseMember ipalib: idrange: Make non-implemented range types fail the validation ipatests: test_trust: Add test to cover lookup of trusdomains ipa-client-install: Do not add already configured sources to nsswitch.conf entries ipalib: host_del: Extend LDAPDelete's takes_options instead of overriding Set the default attributes for RootDSE baseldap: Properly handle the case of renaming object to the same name idviews: Add necessary schema for the ID views idviews: Create container for ID views under cn=accounts idviews: Add ipaAssignedIDVIew reference to the host object ipalib: Remove redundant and star imports from host plugin ipalib: PEP8 fixes for host plugin idviews: Create basic idview plugin structure idvies: Add managed permissions for idview and idoverride objects hostgroup: Add helper that returns all members of a hostgroup hostgroup: Remove redundant and star imports hostgroup: Selected PEP8 fixes for the hostgroup plugin idviews: Add ipa idview-apply and idview-unapply commands idviews: Extend idview-show command to display assigned idoverrides and hosts trusts: Add conversion from SID to object name idviews: Support specifying object names instead of raw anchors only idviews: Split the idoverride object into iduseroverride and idgroupoverride idviews: Split the idoverride commands into iduseroverride and idgroupoverride idviews: Alter idoverride methods to work with splitted objects idviews: Change format of IPA anchor to include domain idviews: Raise NotFound errors if object to override could not be found idviews: Resolve anchors to object names in idview-show ipatests: Add xmlrpc tests for idviews plugin idviews: Add ipaOriginalUid idviews: Update the referential plugin config to watch for ipaAssignedIDView idviews: Fix casing of ID Views to be consistent idviews: Make description optional for the ID View object idviews: Add Default Trust View as part of adtrustinstall idviews: Handle Default Trust View properly in the framework idviews: Make sure the dict.get method is not abused for MUST attributes idviews: Catch errors on unsuccessful AD object lookup when resolving object name to anchor idviews: Display the list of hosts when using --all idviews: Make sure only regular IPA objects are allowed to be overriden idviews: Create Default Trust View for upgraded servers idviews: Fix typo in upgrade handling of the Default Trust View spec: Bump SSSD requires to 1.12.2 -- Petr Vobornik From jcholast at redhat.com Thu Oct 23 11:18:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 23 Oct 2014 13:18:53 +0200 Subject: [Freeipa-devel] [PATCH] 356 Added command to retrieve vault transport certificate. In-Reply-To: <54480E30.8040905@redhat.com> References: <54480E30.8040905@redhat.com> Message-ID: <5448E41D.5030401@redhat.com> Hi, Dne 22.10.2014 v 22:06 Endi Sukma Dewata napsal(a): > A new command has been added to retrieve the vault transport > certificate and optionally save it into a file. The vault archive > and retrieve command has been modified to retrieve the transport > certificate and store it locally for subsequent usage. This way > it's no longer necessary to manually import the transport > certificate into the client's NSS database. As part of the CA certificate renewal feature in 4.1, I have added a LDAP certificate store to IPA, see . Currently it supports only CA certificates, but can be extended to support end entity certificates rather easily. If you use it for the vault transport certificate, it can be added to the client NSS database automatically on install. Honza -- Jan Cholasta From pspacek at redhat.com Thu Oct 23 12:15:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 23 Oct 2014 14:15:57 +0200 Subject: [Freeipa-devel] [PATCH 0020] Fix zone name to directory name conversion in BINDMgr Message-ID: <5448F17D.9080702@redhat.com> Hello, Fix zone name to directory name conversion in BINDMgr. https://fedorahosted.org/freeipa/ticket/4657 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0020-Fix-zone-name-to-directory-name-conversion-in-BINDMg.patch Type: text/x-patch Size: 2214 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 23 13:44:07 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Oct 2014 15:44:07 +0200 Subject: [Freeipa-devel] [PATCH 0020] Fix zone name to directory name conversion in BINDMgr In-Reply-To: <5448F17D.9080702@redhat.com> References: <5448F17D.9080702@redhat.com> Message-ID: <54490627.1070208@redhat.com> On 23/10/14 14:15, Petr Spacek wrote: > Hello, > > Fix zone name to directory name conversion in BINDMgr. > > https://fedorahosted.org/freeipa/ticket/4657 > ACK, signing the root zone works fine now -- Martin Basti From pviktori at redhat.com Thu Oct 23 14:01:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 23 Oct 2014 16:01:39 +0200 Subject: [Freeipa-devel] [PATCH 0001] migrate-ds: Fix to exclude attrs with uppercase characters from migration In-Reply-To: <20141021071247.GP27642@tscherf.redhat.com> References: <20141020095724.GM27642@tscherf.redhat.com> <20141021071247.GP27642@tscherf.redhat.com> Message-ID: <54490A43.1060801@redhat.com> On 10/21/2014 09:12 AM, Thorsten Scherf wrote: > Just realized that I sent the email without body. Mea culpa. Here we go: > > Fix entry_attr case to make migrate-ds work again > > Migration of a OpenLDAP based directory to FreeIPA with some objectclasses > removed failed because of --user-ignore-attribute didn't work. Fixed > that by > making LDAPEntry object entry_attry lowercased. > > https://fedorahosted.org/freeipa/ticket/4620 > > > On [Mon, 20.10.2014 11:57], Thorsten Scherf wrote: >> I don't see a guarantee that attr_blacklist's items will always be lowercase. Wouldn't lowercasing the blacklist be safer? Something like: attr_blacklist_set = {a.lower() for a in attr_blacklist} ... if attr.lower() in attr_blacklist_set A few lines down is the objectclass blacklist handling; I think it needs similar treatment. Looks like the code is duplicated in _pre_migrate_group; it would be nice to pull it out into a function and call it from both places. -- Petr? From pvoborni at redhat.com Thu Oct 23 15:22:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 23 Oct 2014 17:22:27 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.0.4 Message-ID: <54491D33.3030207@redhat.com> The FreeIPA team would like to announce FreeIPA v4.0.4 bugfix release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora 21 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.0/]. == Highlights in 4.0.4 == === Enhancements === * Packages can be now built and installed on RHEL/CentOS 7.0 * ipa-replica-prepare now waits for the replica DNS record to be available to fix race conditions in automated test environments * Port 8443 is now checked before server installation to prevent failures in configuring PKI which uses the port === Bug fixes === * Certmonger CAs are now set with correct path to ipa-submit which caused problems with new certificate submission * Directory Server again returns basic RootDSE attributes by default - namingContexts, supportedControl, supportedExtension, supportedLDAPVersion, supportedSASLMechanisms, vendorName, vendorVersion * "IPA OTP Last Token" plugin is now enabled also on upgraded FreeIPA servers before 4.0.0 * Better error message is provided if cert-request command fails for certificates with SAN * PKI|CA certificate renewal script (ca_renewal_master) triggered by certmonger could fail * sudorule-add-runasuser command now works with external users * "IPA" CA is now properly selected for Web Service and Directory Service certificates == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-ldap-updater --upgrade # ipa-upgradeconfig Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 3.3.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.0.3 == === Alexander Bokovoy (1) === * Default to use TLSv1.0 and TLSv1.1 on the IPA server side === David Kupka (5) === * Fix example usage in ipa man page. * Check that port 8443 is available when installing PKI. * Set IPA CA for freeipa certificates. * Stop dogtag when updating its configuration in ipa-upgradeconfig. * Fix typo causing certmonger is provided with wrong path to ipa-submit. === Gabe (1) === * Missing requires on python-dns in spec file === Jan Cholasta (9) === * Fix certmonger code causing the ca_renewal_master update plugin to fail * Allow RPM upgrade from ipa-* packages * Include ipaplatform in client-only build * Include the ipa command in client-only build * Remove misleading authorization error message in cert-request with --add * Split off generic Red Hat-like platform code from Fedora platform code * Add RHEL platform module * Support building RPMs for RHEL/CentOS 7.0 * Do not check if port 8443 is available in step 2 of external CA install === Ludwig Krispenz (1) === * Ignore irrelevant subtrees in schema compat plugin === Martin Basti (2) === * dnszone-remove-permission should raise error * Fix ipactl service ordering === Martin Kosek (2) === * Sudorule RunAsUser should work with external groups * Remove changetype attribute from update plugin === Nathaniel McCallum (1) === * Configure IPA OTP Last Token plugin on upgrade === Petr Viktorin (4) === * test_permission_plugin: Check legacy permissions * ipa-replica-prepare: Wait for the DNS entry to be resolvable * test_forced_client_reenrollment: Don't check for host certificates * sudo integration test: Remove the local user test === Petr Vobornik (4) === * webui-ci: case-insensitive record check * dns: fix privileges' memberof during dns install * build: increase java stack size for all arches * Become IPA 4.0.4 === Sumit Bose (1) === * ipa-kdb: fix unit tests === Tomas Babej (1) === * Set the default attributes for RootDSE -- Petr Vobornik From tjaalton at ubuntu.com Thu Oct 23 21:38:03 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Fri, 24 Oct 2014 00:38:03 +0300 Subject: [Freeipa-devel] issues with Debian port In-Reply-To: <54467D94.4060309@ubuntu.com> References: <54467D94.4060309@ubuntu.com> Message-ID: <5449753B.4020605@ubuntu.com> Some updates: - rebased to 4.0.4, thanks for the release :) - mod_nss issues got fixed, silly me.. On 21.10.2014 18:36, Timo Aaltonen wrote: > client install will fail with: > > 2014-10-21T08:29:30Z INFO trying https://sid.tyrell/ipa/json > 2014-10-21T08:29:30Z DEBUG Created connection context.rpcclient > 2014-10-21T08:29:30Z DEBUG Try RPC connection > 2014-10-21T08:29:30Z INFO Forwarding 'ping' to json server > 'https://sid.tyrell/ipa/json' > 2014-10-21T08:29:30Z ERROR Cannot connect to the server due to generic > error: error marshalling data for XML-RPC transport: argument 2 must be > string or None, not int This is because I hadn't ported a patch from the ubuntu branch which got applied some six months ago.. d'oh. The issue is that our pykerberos is newer, and needs this: diff --git a/ipalib/rpc.py b/ipalib/rpc.py index 81e7aa3..ce5f2a0 100644 --- a/ipalib/rpc.py +++ b/ipalib/rpc.py @@ -380,7 +380,7 @@ class KerbTransport(SSLTransport): service = "HTTP@" + host.split(':')[0] try: - (rc, vc) = kerberos.authGSSClientInit(service, self.flags) + (rc, vc) = kerberos.authGSSClientInit(service, gssflags=self.flags) except kerberos.GSSError, e: self._handle_exception(e) now client install on the server almost works, but only almost because.. > Also, I'm reusing the RedHatService() stuff for services that have > native systemd jobs, but in the later phases of install (and during > uninstall) ipactl is trying to (re)start 'dirsv at .service' and not > 'dirsrv at REALM.service' like in the dirsrv phase.. any hints here would > be welcome as well. Otherwise I'll just use DebianSysvService() for > dirsrv too.. ..this is still something I haven't figured out. Dirsrv restart after LDAP updates fail, so client install on the server will fail because it can't get SASL up. Something for tomorrow then.. still got until Sunday to get this fixed and uploaded and then accepted to unstable by ftpmasters, or it won't migrate to Jessie in time for the freeze. But that's an eternity! :) Oh and the web UI is blank when I try it. Does the client install fail have something to do with it? -- t From abokovoy at redhat.com Thu Oct 23 21:47:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Oct 2014 00:47:00 +0300 Subject: [Freeipa-devel] issues with Debian port In-Reply-To: <5449753B.4020605@ubuntu.com> References: <54467D94.4060309@ubuntu.com> <5449753B.4020605@ubuntu.com> Message-ID: <20141023214700.GL5446@redhat.com> On Fri, 24 Oct 2014, Timo Aaltonen wrote: > >Some updates: > >- rebased to 4.0.4, thanks for the release :) >- mod_nss issues got fixed, silly me.. > >On 21.10.2014 18:36, Timo Aaltonen wrote: >> client install will fail with: >> >> 2014-10-21T08:29:30Z INFO trying https://sid.tyrell/ipa/json >> 2014-10-21T08:29:30Z DEBUG Created connection context.rpcclient >> 2014-10-21T08:29:30Z DEBUG Try RPC connection >> 2014-10-21T08:29:30Z INFO Forwarding 'ping' to json server >> 'https://sid.tyrell/ipa/json' >> 2014-10-21T08:29:30Z ERROR Cannot connect to the server due to generic >> error: error marshalling data for XML-RPC transport: argument 2 must be >> string or None, not int > >This is because I hadn't ported a patch from the ubuntu branch which got >applied some six months ago.. d'oh. The issue is that our pykerberos is >newer, and needs this: > >diff --git a/ipalib/rpc.py b/ipalib/rpc.py >index 81e7aa3..ce5f2a0 100644 >--- a/ipalib/rpc.py >+++ b/ipalib/rpc.py >@@ -380,7 +380,7 @@ class KerbTransport(SSLTransport): > service = "HTTP@" + host.split(':')[0] > > try: >- (rc, vc) = kerberos.authGSSClientInit(service, self.flags) >+ (rc, vc) = kerberos.authGSSClientInit(service, gssflags=self.flags) > except kerberos.GSSError, e: > self._handle_exception(e) > > >now client install on the server almost works, but only almost because.. > >> Also, I'm reusing the RedHatService() stuff for services that have >> native systemd jobs, but in the later phases of install (and during >> uninstall) ipactl is trying to (re)start 'dirsv at .service' and not >> 'dirsrv at REALM.service' like in the dirsrv phase.. any hints here would >> be welcome as well. Otherwise I'll just use DebianSysvService() for >> dirsrv too.. > >..this is still something I haven't figured out. Dirsrv restart after >LDAP updates fail, so client install on the server will fail because it >can't get SASL up. Something for tomorrow then.. still got until Sunday >to get this fixed and uploaded and then accepted to unstable by ftpmasters, >or it won't migrate to Jessie in time for the freeze. But that's an >eternity! :) Since dirsrv at .service is instance-based, when instance is missing we rewrite dirsrv at .service to be dirsrv.target. This means 'start whatever is requiring this synchronization point'. Enabling instances of dirsrv means they are symlinked as dependencies on dirsrv.target: # ls -l /etc/systemd/system/dirsrv.target.wants/ total 0 lrwxrwxrwx. 1 root root 39 Oct 20 17:56 dirsrv at IPACLOUD-TEST.service -> /usr/lib/systemd/system/dirsrv at .service >Oh and the web UI is blank when I try it. Does the client install fail have >something to do with it? check /var/log/ipaclient-install.log -- / Alexander Bokovoy From npmccallum at redhat.com Thu Oct 23 22:07:06 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Oct 2014 18:07:06 -0400 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable Message-ID: <1414102026.4610.6.camel@redhat.com> This patch gives the administrator variables to control the size of the authentication and synchronization windows for OTP tokens. https://fedorahosted.org/freeipa/ticket/4511 NOTE: There is one known issue with this patch which I don't know how to solve. This patch changes the schema in install/share/60ipaconfig.ldif. On an upgrade, all of the new attributeTypes appear correctly. However, the modifications to the pre-existing objectClass do not show up on the server. What am I doing wrong? After modifying ipaGuiConfig manually, everything in this patch works just fine. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0074-Make-token-window-sizes-configurable.patch Type: text/x-patch Size: 36521 bytes Desc: not available URL: From tjaalton at ubuntu.com Thu Oct 23 22:18:07 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Fri, 24 Oct 2014 01:18:07 +0300 Subject: [Freeipa-devel] issues with Debian port In-Reply-To: <20141023214700.GL5446@redhat.com> References: <54467D94.4060309@ubuntu.com> <5449753B.4020605@ubuntu.com> <20141023214700.GL5446@redhat.com> Message-ID: <54497E9F.4080600@ubuntu.com> On 24.10.2014 00:47, Alexander Bokovoy wrote: > On Fri, 24 Oct 2014, Timo Aaltonen wrote: > Since dirsrv at .service is instance-based, when instance is missing we > rewrite dirsrv at .service to be dirsrv.target. This means 'start whatever > is requiring this synchronization point'. Enabling instances of dirsrv > means they are symlinked as dependencies on dirsrv.target: > > # ls -l /etc/systemd/system/dirsrv.target.wants/ > total 0 > lrwxrwxrwx. 1 root root 39 Oct 20 17:56 dirsrv at IPACLOUD-TEST.service -> > /usr/lib/systemd/system/dirsrv at .service right, I hadn't changed LIB_SYSTEMD_SYSTEMD_DIR in paths.py.. doing that fixed this issue, thanks! >> Oh and the web UI is blank when I try it. Does the client install fail >> have >> something to do with it? > check /var/log/ipaclient-install.log Well it fails because it can't connect to the server: 2014-10-23T22:10:57Z DEBUG approved_usage = SSL Server intended_usage = SSL Server 2014-10-23T22:10:57Z DEBUG cert valid True for "CN=sid.tyrell,O=SID" 2014-10-23T22:10:57Z DEBUG handshake complete, peer = 192.168.1.31:443 2014-10-23T22:10:57Z ERROR Cannot connect to the server due to generic error: Authentication method not supported: sasl mechanism not supported I thought it was because of the dirsrv restart failing before this step, but after fixing it the failure is still the same.. -- t From dkupka at redhat.com Fri Oct 24 07:51:03 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 24 Oct 2014 09:51:03 +0200 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. Message-ID: <544A04E7.7010101@redhat.com> https://fedorahosted.org/freeipa/ticket/4585 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0025-Respect-UID-and-GID-soft-static-allocation.patch Type: text/x-patch Size: 8007 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 24 08:19:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 24 Oct 2014 10:19:21 +0200 Subject: [Freeipa-devel] issues with Debian port In-Reply-To: <5449753B.4020605@ubuntu.com> References: <54467D94.4060309@ubuntu.com> <5449753B.4020605@ubuntu.com> Message-ID: <544A0B89.7050109@redhat.com> On 23.10.2014 23:38, Timo Aaltonen wrote: > > > Oh and the web UI is blank when I try it. Does the client install fail have > something to do with it? > Client install fail should not affect displaying of Web UI. What do you mean by blank? Are Web UI files downloaded? Is there a JavaScript error? Can be checked in browser developer tools, in console and network tab. Web UI debugging help: https://pvoborni.fedorapeople.org/doc/#!/guide/Debugging -- Petr Vobornik From mbasti at redhat.com Fri Oct 24 08:43:00 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 24 Oct 2014 10:43:00 +0200 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <544A04E7.7010101@redhat.com> References: <544A04E7.7010101@redhat.com> Message-ID: <544A1114.6090301@redhat.com> On 24/10/14 09:51, David Kupka wrote: > https://fedorahosted.org/freeipa/ticket/4585 NACK 1) Why is there line with 'DS System User?' The comment should depend on service. + args = [ + paths.USERADD, + '-g', group, + '-c', 'DS System User', + '-d', homedir, + '-s', shell, + '-M', '-r', name, + ] 2) code create_system_user is duplicated between base and redhat tasks with platform dependent changes. IMO it would be better to have one method to create user, with keyword arguments. And then platform dependent method which will call method to create user with appropriate arguments (or with default arguments) -- Martin Basti From dkupka at redhat.com Fri Oct 24 11:06:27 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 24 Oct 2014 13:06:27 +0200 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <544A1114.6090301@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> Message-ID: <544A32B3.2020707@redhat.com> On 10/24/2014 10:43 AM, Martin Basti wrote: > On 24/10/14 09:51, David Kupka wrote: >> https://fedorahosted.org/freeipa/ticket/4585 > NACK > > 1) > Why is there line with 'DS System User?' The comment should depend on > service. > > + args = [ > + paths.USERADD, > + '-g', group, > + '-c', 'DS System User', > + '-d', homedir, > + '-s', shell, > + '-M', '-r', name, > + ] This was part of the original code and I didn't notice it. Nice catch, thanks. > > 2) > code create_system_user is duplicated between base and redhat tasks with > platform dependent changes. > IMO it would be better to have one method to create user, with keyword > arguments. And then platform dependent method which will call method to > create user with appropriate arguments (or with default arguments) > You're right it was ugly. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0025-2-Respect-UID-and-GID-soft-static-allocation.patch Type: text/x-patch Size: 7097 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 24 11:27:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 24 Oct 2014 13:27:48 +0200 Subject: [Freeipa-devel] [PATCH 0153] fix regression: DNS zonemgr validation raises assertion error Message-ID: <544A37B4.9040308@redhat.com> https://fedorahosted.org/freeipa/ticket/4663 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0153-Fix-dns-zonemgr-validation-regression.patch Type: text/x-patch Size: 801 bytes Desc: not available URL: From abokovoy at redhat.com Fri Oct 24 12:05:39 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Oct 2014 15:05:39 +0300 Subject: [Freeipa-devel] [PATCH] 0168 add permission for reading ipaSshPubkey for ID overrides Message-ID: <20141024120539.GO5446@redhat.com> Hi! A small patch to fix https://fedorahosted.org/freeipa/ticket/4664 -- / Alexander Bokovoy -------------- next part -------------- From 6f793a9e4450d6a41576c98ca61f6273277ccd60 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 24 Oct 2014 15:01:27 +0300 Subject: [PATCH] Add ipaSshPubkey to the ACI to read ID user overrides https://fedorahosted.org/freeipa/ticket/4664 --- ACI.txt | 2 +- ipalib/plugins/idviews.py | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/ACI.txt b/ACI.txt index 27a5d2f..f987807 100644 --- a/ACI.txt +++ b/ACI.txt @@ -131,7 +131,7 @@ aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:S dn: cn=views,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || entryusn || gidnumber || ipaanchoruuid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System: Read Group ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "createtimestamp || description || entryusn || gecos || homedirectory || ipaanchoruuid || ipaoriginaluid || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "createtimestamp || description || entryusn || gecos || homedirectory || ipaanchoruuid || ipaoriginaluid || ipasshpubkey || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ranges,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipabaseid || ipabaserid || ipaidrangesize || ipanttrusteddomainsid || iparangetype || ipasecondarybaserid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaidrange)")(version 3.0;acl "permission:System: Read ID Ranges";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index bfa8675..cd297a4 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -659,6 +659,7 @@ class idoverrideuser(baseidoverride): 'ipapermdefaultattr': { 'objectClass', 'ipaAnchorUUID', 'uidNumber', 'description', 'homeDirectory', 'uid', 'ipaOriginalUid', 'loginShell', 'gecos', + 'ipaSshPubkey', }, }, } -- 2.1.0 From dkupka at redhat.com Fri Oct 24 12:12:41 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 24 Oct 2014 14:12:41 +0200 Subject: [Freeipa-devel] [PATCH 0153] fix regression: DNS zonemgr validation raises assertion error In-Reply-To: <544A37B4.9040308@redhat.com> References: <544A37B4.9040308@redhat.com> Message-ID: <544A4239.9000600@redhat.com> Works for me, ACK. On 10/24/2014 01:27 PM, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4663 > > Patch attached. > -- David Kupka From abokovoy at redhat.com Fri Oct 24 12:14:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Oct 2014 15:14:48 +0300 Subject: [Freeipa-devel] [PATCH] 0168 add permission for reading ipaSshPubkey for ID overrides In-Reply-To: <20141024120539.GO5446@redhat.com> References: <20141024120539.GO5446@redhat.com> Message-ID: <20141024121448.GP5446@redhat.com> On Fri, 24 Oct 2014, Alexander Bokovoy wrote: > Hi! > > A small patch to fix https://fedorahosted.org/freeipa/ticket/4664 > Sumit noted that we also miss gidNumber from the user's override permissions. Added to the new version of the patch. -- / Alexander Bokovoy -------------- next part -------------- From f980405957aeb912b28f8559416faba9c6bbd1bb Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 24 Oct 2014 15:01:27 +0300 Subject: [PATCH] Add ipaSshPubkey to the ACI to read ID user overrides https://fedorahosted.org/freeipa/ticket/4664 --- ACI.txt | 2 +- ipalib/plugins/idviews.py | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/ACI.txt b/ACI.txt index 27a5d2f..6680f65 100644 --- a/ACI.txt +++ b/ACI.txt @@ -131,7 +131,7 @@ aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:S dn: cn=views,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || entryusn || gidnumber || ipaanchoruuid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System: Read Group ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "createtimestamp || description || entryusn || gecos || homedirectory || ipaanchoruuid || ipaoriginaluid || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "createtimestamp || description || entryusn || gecos || gidnumber || homedirectory || ipaanchoruuid || ipaoriginaluid || ipasshpubkey || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ranges,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipabaseid || ipabaserid || ipaidrangesize || ipanttrusteddomainsid || iparangetype || ipasecondarybaserid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaidrange)")(version 3.0;acl "permission:System: Read ID Ranges";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index bfa8675..9c87210 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -659,6 +659,7 @@ class idoverrideuser(baseidoverride): 'ipapermdefaultattr': { 'objectClass', 'ipaAnchorUUID', 'uidNumber', 'description', 'homeDirectory', 'uid', 'ipaOriginalUid', 'loginShell', 'gecos', + 'gidNumber', 'ipaSshPubkey', }, }, } -- 2.1.0 From dkupka at redhat.com Fri Oct 24 13:05:40 2014 From: dkupka at redhat.com (David Kupka) Date: Fri, 24 Oct 2014 15:05:40 +0200 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <544A32B3.2020707@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> Message-ID: <544A4EA4.40908@redhat.com> On 10/24/2014 01:06 PM, David Kupka wrote: > On 10/24/2014 10:43 AM, Martin Basti wrote: >> On 24/10/14 09:51, David Kupka wrote: >>> https://fedorahosted.org/freeipa/ticket/4585 >> NACK >> >> 1) >> Why is there line with 'DS System User?' The comment should depend on >> service. >> >> + args = [ >> + paths.USERADD, >> + '-g', group, >> + '-c', 'DS System User', >> + '-d', homedir, >> + '-s', shell, >> + '-M', '-r', name, >> + ] > > This was part of the original code and I didn't notice it. Nice catch, > thanks. > >> >> 2) >> code create_system_user is duplicated between base and redhat tasks with >> platform dependent changes. >> IMO it would be better to have one method to create user, with keyword >> arguments. And then platform dependent method which will call method to >> create user with appropriate arguments (or with default arguments) >> > > You're right it was ugly. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > I shouldn't break SOLID principles. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0025-3-Respect-UID-and-GID-soft-static-allocation.patch Type: text/x-patch Size: 7100 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 24 13:21:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 Oct 2014 15:21:15 +0200 Subject: [Freeipa-devel] [PATCH] 0168 add permission for reading ipaSshPubkey for ID overrides In-Reply-To: <20141024121448.GP5446@redhat.com> References: <20141024120539.GO5446@redhat.com> <20141024121448.GP5446@redhat.com> Message-ID: <544A524B.1050009@redhat.com> On 10/24/2014 02:14 PM, Alexander Bokovoy wrote: > On Fri, 24 Oct 2014, Alexander Bokovoy wrote: >> Hi! >> >> A small patch to fix https://fedorahosted.org/freeipa/ticket/4664 >> > Sumit noted that we also miss gidNumber from the user's override > permissions. Added to the new version of the patch. The patch itself works fine, I tested an upgrade + ldapsearch with host/ principal. However, patch description needs update to also reflect gidNumber being added. From npmccallum at redhat.com Fri Oct 24 13:21:29 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 24 Oct 2014 09:21:29 -0400 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1414102026.4610.6.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> Message-ID: <1414156889.13428.0.camel@redhat.com> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > This patch gives the administrator variables to control the size of > the authentication and synchronization windows for OTP tokens. > > https://fedorahosted.org/freeipa/ticket/4511 > > NOTE: There is one known issue with this patch which I don't know how to > solve. This patch changes the schema in install/share/60ipaconfig.ldif. > On an upgrade, all of the new attributeTypes appear correctly. However, > the modifications to the pre-existing objectClass do not show up on the > server. What am I doing wrong? > > After modifying ipaGuiConfig manually, everything in this patch works > just fine. Also, I need an allocation of OIDs for the new attributes. From abokovoy at redhat.com Fri Oct 24 13:32:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Oct 2014 16:32:36 +0300 Subject: [Freeipa-devel] [PATCH] 0168 add permission for reading ipaSshPubkey for ID overrides In-Reply-To: <544A524B.1050009@redhat.com> References: <20141024120539.GO5446@redhat.com> <20141024121448.GP5446@redhat.com> <544A524B.1050009@redhat.com> Message-ID: <20141024133236.GS5446@redhat.com> On Fri, 24 Oct 2014, Martin Kosek wrote: >On 10/24/2014 02:14 PM, Alexander Bokovoy wrote: >>On Fri, 24 Oct 2014, Alexander Bokovoy wrote: >>>Hi! >>> >>>A small patch to fix https://fedorahosted.org/freeipa/ticket/4664 >>> >>Sumit noted that we also miss gidNumber from the user's override >>permissions. Added to the new version of the patch. > >The patch itself works fine, I tested an upgrade + ldapsearch with >host/ principal. However, patch description needs update to also >reflect gidNumber being added. Updated. -- / Alexander Bokovoy -------------- next part -------------- From 208e9d750948bf2144aeae1ae6133f035b5716cd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 24 Oct 2014 15:01:27 +0300 Subject: [PATCH] Add ipaSshPubkey and gidNumber to the ACI to read ID user overrides https://fedorahosted.org/freeipa/ticket/4664 --- ACI.txt | 2 +- ipalib/plugins/idviews.py | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/ACI.txt b/ACI.txt index 27a5d2f..6680f65 100644 --- a/ACI.txt +++ b/ACI.txt @@ -131,7 +131,7 @@ aci: (targetfilter = "(objectclass=ipahostgroup)")(version 3.0;acl "permission:S dn: cn=views,cn=accounts,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || description || entryusn || gidnumber || ipaanchoruuid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaGroupOverride)")(version 3.0;acl "permission:System: Read Group ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example -aci: (targetattr = "createtimestamp || description || entryusn || gecos || homedirectory || ipaanchoruuid || ipaoriginaluid || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) +aci: (targetattr = "createtimestamp || description || entryusn || gecos || gidnumber || homedirectory || ipaanchoruuid || ipaoriginaluid || ipasshpubkey || loginshell || modifytimestamp || objectclass || uid || uidnumber")(targetfilter = "(objectclass=ipaUserOverride)")(version 3.0;acl "permission:System: Read User ID Overrides";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=ranges,cn=etc,dc=ipa,dc=example aci: (targetattr = "cn || createtimestamp || entryusn || ipabaseid || ipabaserid || ipaidrangesize || ipanttrusteddomainsid || iparangetype || ipasecondarybaserid || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaidrange)")(version 3.0;acl "permission:System: Read ID Ranges";allow (compare,read,search) userdn = "ldap:///all";) dn: cn=views,cn=accounts,dc=ipa,dc=example diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index bfa8675..9c87210 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -659,6 +659,7 @@ class idoverrideuser(baseidoverride): 'ipapermdefaultattr': { 'objectClass', 'ipaAnchorUUID', 'uidNumber', 'description', 'homeDirectory', 'uid', 'ipaOriginalUid', 'loginShell', 'gecos', + 'gidNumber', 'ipaSshPubkey', }, }, } -- 2.1.0 From pvoborni at redhat.com Fri Oct 24 13:46:36 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 24 Oct 2014 15:46:36 +0200 Subject: [Freeipa-devel] [PATCH] 773-777 ranges: prohibit setting --rid-base with ipa-trust-ad-posix type In-Reply-To: <5448BEBB.6030609@redhat.com> References: <543E6685.8000704@redhat.com> <5447EBE0.4080203@redhat.com> <5448BEBB.6030609@redhat.com> Message-ID: <544A583C.3060601@redhat.com> On 23.10.2014 10:39, Martin Kosek wrote: > On 10/22/2014 07:39 PM, Tomas Babej wrote: >> Hi, >> >> thank you for the patches, comments inline. >> >> >> On 10/15/2014 02:20 PM, Petr Vobornik wrote: >>> ticket: https://fedorahosted.org/freeipa/ticket/4221 >>> >>> == [PATCH] 773 ranges: prohibit setting --rid-base with >>> ipa-trust-ad-posix type == >>> >>> We should not allow setting --rid-base for ranges of >>> ipa-trust-ad-posix since we do not perform any RID -> UID/GID mappings >>> for these ranges (objects have UID/GID set in AD). Thus, setting RID >>> base makes no sense. >>> >>> Since ipaBaseRID is a MUST in ipaTrustedADDomainRange object class, >>> value '0' is allowed and used internally for 'ipa-trust-ad-posix' >>> range type. >> >> We probably don't want to display the first RID if it is 0 and the type >> is ad-posix. This occurs in idrange-find: >> >> [tbabej at vm-043 labtool]$ ipa idrange-find >> >> ---------------- >> 2 ranges matched >> ---------------- >> Range name: DOM043.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range >> First Posix ID of the range: 514800000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 1000 >> First RID of the secondary RID range: 100000000 >> Range type: local domain range >> >> Range name: TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range >> First Posix ID of the range: 10000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 0 >> Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 >> Range type: Active Directory trust range with POSIX attributes >> >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> And also idrange-show: >> >> [tbabej at vm-043 labtool]$ ipa idrange-show TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range >> Range name: TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM_id_range >> First Posix ID of the range: 10000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 0 >> Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726 >> Range type: Active Directory trust range with POSIX attributes >> >> >>> >>> No schema change is done. Fixed snip >>> >>> == [PATCH] 775 ldapupdater: set baserid to 0 for ipa-ad-trust-posix >>> ranges == >> >> Can you use the paged_search=True in find_entries instead of having a >> infinite loop? It would make this code quite cleaner. > > I also saw you did not update Makefile.am. Because I did not add a new file. updated patches attached (only 773-775 are changed) -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0777-1-webui-prohibit-setting-rid-base-with-ipa-trust-ad-po.patch Type: text/x-patch Size: 5415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0776-1-idrange-include-raw-range-type-in-output.patch Type: text/x-patch Size: 4540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0775-1-ldapupdater-set-baserid-to-0-for-ipa-ad-trust-posix-.patch Type: text/x-patch Size: 3810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0774-1-unittests-baserid-for-ipa-ad-trust-posix-idranges.patch Type: text/x-patch Size: 12972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0773-1-ranges-prohibit-setting-rid-base-with-ipa-trust-ad-p.patch Type: text/x-patch Size: 6651 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 24 13:56:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 24 Oct 2014 15:56:07 +0200 Subject: [Freeipa-devel] [PATCH] 0168 add permission for reading ipaSshPubkey for ID overrides In-Reply-To: <20141024133236.GS5446@redhat.com> References: <20141024120539.GO5446@redhat.com> <20141024121448.GP5446@redhat.com> <544A524B.1050009@redhat.com> <20141024133236.GS5446@redhat.com> Message-ID: <544A5A77.4020309@redhat.com> On 10/24/2014 03:32 PM, Alexander Bokovoy wrote: > On Fri, 24 Oct 2014, Martin Kosek wrote: >> On 10/24/2014 02:14 PM, Alexander Bokovoy wrote: >>> On Fri, 24 Oct 2014, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> A small patch to fix https://fedorahosted.org/freeipa/ticket/4664 >>>> >>> Sumit noted that we also miss gidNumber from the user's override >>> permissions. Added to the new version of the patch. >> >> The patch itself works fine, I tested an upgrade + ldapsearch with host/ >> principal. However, patch description needs update to also reflect gidNumber >> being added. > Updated. > ACK. Pushed to: master: d6b28f29ecffae604801a5380efdff135734785d ipa-4-1: 47ab6351f1dc75cee0f2b868401f38174b67f87a Martin From tjaalton at ubuntu.com Fri Oct 24 20:15:49 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Fri, 24 Oct 2014 23:15:49 +0300 Subject: [Freeipa-devel] issues with Debian port In-Reply-To: <544A0B89.7050109@redhat.com> References: <54467D94.4060309@ubuntu.com> <5449753B.4020605@ubuntu.com> <544A0B89.7050109@redhat.com> Message-ID: <544AB375.8010407@ubuntu.com> On 24.10.2014 11:19, Petr Vobornik wrote: > On 23.10.2014 23:38, Timo Aaltonen wrote: >> >> >> Oh and the web UI is blank when I try it. Does the client install fail >> have >> something to do with it? >> > > Client install fail should not affect displaying of Web UI. > > What do you mean by blank? > Are Web UI files downloaded? > Is there a JavaScript error? > > Can be checked in browser developer tools, in console and network tab. > > Web UI debugging help: > https://pvoborni.fedorapeople.org/doc/#!/guide/Debugging The debugging hint was key, I've now gone back to using embedded dojo/jsquery instead of linking to system versions which didn't work because the apache config didn't allow accessing them. and the UI is looking rather nice ;) -- t From npmccallum at redhat.com Fri Oct 24 20:21:26 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 24 Oct 2014 16:21:26 -0400 Subject: [Freeipa-devel] [PATCH 0075] Ensure users exist when assigning tokens to them Message-ID: <1414182086.13428.7.camel@redhat.com> https://fedorahosted.org/freeipa/ticket/4642 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0075-Ensure-users-exist-when-assigning-tokens-to-them.patch Type: text/x-patch Size: 1150 bytes Desc: not available URL: From pviktori at redhat.com Mon Oct 27 14:56:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 27 Oct 2014 15:56:16 +0100 Subject: [Freeipa-devel] [PATCH 0153] fix regression: DNS zonemgr validation raises assertion error In-Reply-To: <544A4239.9000600@redhat.com> References: <544A37B4.9040308@redhat.com> <544A4239.9000600@redhat.com> Message-ID: <544E5D10.5040100@redhat.com> On 10/24/2014 02:12 PM, David Kupka wrote: > Works for me, ACK. > > On 10/24/2014 01:27 PM, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4663 >> >> Patch attached. >> > Pushed to: master: e971fad5c1235bb755e58d131f8183f1646770e6 ipa-4-1: 75cdc50ba91a94682eac11f99995746be283f668 -- Petr? From pviktori at redhat.com Mon Oct 27 15:38:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 27 Oct 2014 16:38:16 +0100 Subject: [Freeipa-devel] [PATCHES] 0661-0672 Switch the test suite to pytest In-Reply-To: <543E6F82.7090309@redhat.com> References: <543E6F82.7090309@redhat.com> Message-ID: <544E66E8.6010903@redhat.com> On 10/15/2014 02:58 PM, Petr Viktorin wrote: > This almost completes the switch to pytest. There are two missing things: > - the details of test results (--with-xunit) are not read correctly by > Jenkins. I have a theory I'm investigating here. > - the beakerlib integration is still not ready > > > I'll not be available for the rest of the week so I'm sending this > early, in case someone wants to take a look. I've updated (and rearranged) the patches after some more testing. Both points above are fixed. Individual plugins are broken out; some would be nice to even release independently of IPA. (There is some demand for the BeakerLib plugin; for that I'd only need to break the dependency on ipa_log_manager.) These depend on my patches 0656-0660. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0661.2-dogtag-plugin-Don-t-use-doctest-syntax-for-non-docte.patch Type: text/x-patch Size: 2523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0662.2-test_webui-Don-t-use-__init__-for-test-classes.patch Type: text/x-patch Size: 6696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0663.2-test_ipapython-Use-functions-instead-of-classes-in-t.patch Type: text/x-patch Size: 3192 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0664.2-Configure-pytest-to-run-doctests.patch Type: text/x-patch Size: 3135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0665.2-Declarative-tests-Move-cleanup-to-setup_class-teardo.patch Type: text/x-patch Size: 2761 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0666.2-Declarative-tests-Switch-to-pytest.patch Type: text/x-patch Size: 5130 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0667.2-Integration-tests-Port-the-ordering-plugin-to-pytest.patch Type: text/x-patch Size: 12864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0668.2-Switch-make-test-to-pytest.patch Type: text/x-patch Size: 2033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0669.2-Add-local-pytest-plugin-for-with-xunit-and-logging-l.patch Type: text/x-patch Size: 4507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0670.2-Switch-ipa-run-tests-to-pytest.patch Type: text/x-patch Size: 3002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0671.2-Switch-integration-testing-config-to-a-fixture.patch Type: text/x-patch Size: 8108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0672.2-Integration-tests-Port-the-BeakerLib-plugin-and-log-.patch Type: text/x-patch Size: 30089 bytes Desc: not available URL: From npmccallum at redhat.com Tue Oct 28 20:59:16 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 28 Oct 2014 16:59:16 -0400 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1414102026.4610.6.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> Message-ID: <1414529956.16650.3.camel@redhat.com> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > This patch gives the administrator variables to control the size of > the authentication and synchronization windows for OTP tokens. > > https://fedorahosted.org/freeipa/ticket/4511 > > NOTE: There is one known issue with this patch which I don't know how to > solve. This patch changes the schema in install/share/60ipaconfig.ldif. > On an upgrade, all of the new attributeTypes appear correctly. However, > the modifications to the pre-existing objectClass do not show up on the > server. What am I doing wrong? > > After modifying ipaGuiConfig manually, everything in this patch works > just fine. This new version takes into account the new (proper) OIDs and attribute names. The above known issue still remains. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0074.1-Make-token-window-sizes-configurable.patch Type: text/x-patch Size: 37776 bytes Desc: not available URL: From abokovoy at redhat.com Tue Oct 28 21:11:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 28 Oct 2014 23:11:36 +0200 Subject: [Freeipa-devel] [PATCH, slapi-nis] ID view-related patches to slapi-nis Message-ID: <20141028211136.GL26496@redhat.com> Hi, two patches to slapi-nis are attached: - make sure only DNs from the schema-compat trees are targeted for ID view replacement. This solves issue of https://bugzilla.redhat.com/show_bug.cgi?id=1157989 found by Sumit. - support ID overrides in the BIND callback. So far the only thing we need is overriding uid. They need to be applied in this order, on top of 0.54 release version of slapi-nis. -- / Alexander Bokovoy -------------- next part -------------- From 4645af44d48c81d8332020eb390db877ab179b3b Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 28 Oct 2014 10:09:47 +0200 Subject: [PATCH 1/2] ID views: ignore searches for views outside the subtrees of schema-compat sets schema-compat plugin may provide multiple disjoint subtrees which can be used to request overridden entries by prefixing the subtree suffix with a cn=,cn=views, As subtrees may be disjoint, we cannot rely on the common suffix. Thus, any attempt to replace target DN and update filter terms must only be done once we are sure the search will be done in the subtree. This optimization prevents mistakenly changing the search filter when FreeIPA and SSSD search for the ID overrides themselves, as the same structure of the target DN is used for cn=views,cn=accounts,$SUFFIX subtree in FreeIPA. This subtree is never handled by slapi-nis and should be ignored. https://bugzilla.redhat.com/show_bug.cgi?id=1157989 --- src/back-sch-idview.c | 11 +++++-- src/back-sch.c | 83 +++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 83 insertions(+), 11 deletions(-) diff --git a/src/back-sch-idview.c b/src/back-sch-idview.c index 5a2b450..a56a9e9 100644 --- a/src/back-sch-idview.c +++ b/src/back-sch-idview.c @@ -334,6 +334,10 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b slapi_ber_bvdone(bval); slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); config->override_found = TRUE; + slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, + "Overriding the filter %s with %s=%*s from the override %s\n.", + filter_type, filter_type, bval->bv_len, bval->bv_val, + slapi_entry_get_dn_const(cbdata->overrides[i])); break; } } @@ -346,6 +350,11 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b slapi_ber_bvdone(bval); slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); config->override_found = TRUE; + slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, + "Overriding the filter %s with %s=%*s from the override %s\n.", + filter_type, IPA_IDVIEWS_ATTR_ANCHORUUID, + bval->bv_len, bval->bv_val, + slapi_entry_get_dn_const(cbdata->overrides[i])); break; } @@ -366,8 +375,6 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b * * Note that in reality we don't use original value of the uid/cn attribue. Instead, we use ipaAnchorUUID * to refer to the original entry. */ -extern char * -slapi_filter_to_string( const struct slapi_filter *f, char *buf, size_t bufsize ); void idview_replace_filter(struct backend_search_cbdata *cbdata) { diff --git a/src/back-sch.c b/src/back-sch.c index 27d5101..902adb2 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -1166,6 +1166,44 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, return TRUE; } +/* Routines to search if a target DN is within any of the sets we handle */ +static bool_t +backend_search_find_set_dn_in_group_cb(const char *group, const char *set, bool_t flag, + void *backend_data, void *cb_data) +{ + struct backend_search_cbdata *cbdata; + struct backend_set_data *set_data; + + cbdata = cb_data; + set_data = backend_data; + + if (slapi_sdn_scope_test(cbdata->target_dn, + set_data->container_sdn, + cbdata->scope) == 1) { + cbdata->answer = TRUE; + } + + if (slapi_sdn_compare(set_data->container_sdn, + cbdata->target_dn) == 0) { + cbdata->answer = TRUE; + } + + return TRUE; + +} + +static bool_t +backend_search_find_set_dn_cb(const char *group, void *cb_data) +{ + struct backend_search_cbdata *cbdata; + + cbdata = cb_data; + map_data_foreach_map(cbdata->state, group, + backend_search_find_set_dn_in_group_cb, cb_data); + return TRUE; +} + +/* Routines to find out the set that has the same group as requested */ static bool_t backend_search_find_set_data_in_group_cb(const char *group, const char *set, bool_t flag, void *backend_data, void *cb_data) @@ -1340,9 +1378,6 @@ backend_search_cb(Slapi_PBlock *pb) "searching from \"%s\" for \"%s\" with scope %d%s\n", cbdata.target, cbdata.strfilter, cbdata.scope, backend_sch_scope_as_string(cbdata.scope)); -#ifdef USE_IPA_IDVIEWS - idview_replace_target_dn(&cbdata.target, &cbdata.idview); -#endif cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); /* Check if there's a backend handling this search. */ if (!slapi_be_exist(cbdata.target_dn)) { @@ -1351,19 +1386,49 @@ backend_search_cb(Slapi_PBlock *pb) "slapi_be_exists(\"%s\") = 0, " "ignoring search\n", cbdata.target); slapi_sdn_free(&cbdata.target_dn); + return 0; + } + +#ifdef USE_IPA_IDVIEWS + /* We may have multiple disjoint trees in the sets, search if the target matches any of them + * as in general there don't have to be a single subtree (cn=compat,$SUFFIX) for all trees to easily + * detect the ID view use. Unless the ID view is within the set we control, don't consider the override */ + map_data_foreach_domain(cbdata.state, backend_search_find_set_dn_cb, &cbdata); + if (cbdata.answer == FALSE) { + idview_replace_target_dn(&cbdata.target, &cbdata.idview); if (cbdata.idview != NULL) { - slapi_ch_free_string(&cbdata.target); + slapi_sdn_free(&cbdata.target_dn); + /* Perform another check, now for rewritten DN */ + cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); + map_data_foreach_domain(cbdata.state, backend_search_find_set_dn_cb, &cbdata); + /* Rewritten DN might still be outside of our trees */ + if (cbdata.answer == TRUE) { + slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, + "Use of ID view '%s' is detected, searching from \"%s\" " + "for \"%s\" with scope %d%s. Filter may get overridden later.\n", + cbdata.idview, cbdata.target, cbdata.strfilter, cbdata.scope, + backend_sch_scope_as_string(cbdata.scope)); + cbdata.answer = FALSE; + } else { + slapi_sdn_free(&cbdata.target_dn); + slapi_ch_free_string(&cbdata.target); + slapi_ch_free_string(&cbdata.idview); + slapi_log_error(SLAPI_LOG_PLUGIN, + cbdata.state->plugin_desc->spd_id, + "The search base didn't match any of the containers, " + "ignoring search\n"); + return 0; + } } - slapi_ch_free_string(&cbdata.idview); -#ifdef USE_IPA_IDVIEWS - idview_free_overrides(&cbdata); -#endif - return 0; + } else { + cbdata.answer = FALSE; } +#endif /* Walk the list of groups. */ wrap_inc_call_level(); #ifdef USE_IPA_IDVIEWS + /* Filter replacement requires increased call level as we may fetch overrides and thus come back here */ idview_replace_filter(&cbdata); #endif if (map_rdlock() == 0) { -- 2.1.0 -------------- next part -------------- From ec01afd2bd2543dbd2a79a3f78b4c6b6aa085c6c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 28 Oct 2014 11:16:50 +0200 Subject: [PATCH 2/2] schema-compat: support ID overrides in bind callback If RDN of the bind DN is overridden within the ID view, rewrite the target to use original value of the uid attribute. If original uid attribute is not available, fail the search and thus the whole bind request by claiming that bind DN does not exist. --- src/back-sch-idview.c | 86 ++++++++++++++++++++++++++++++++++----------------- src/back-sch.c | 52 ++++++++++++++++++++++++++----- src/back-sch.h | 4 +++ 3 files changed, 107 insertions(+), 35 deletions(-) diff --git a/src/back-sch-idview.c b/src/back-sch-idview.c index a56a9e9..f1150cd 100644 --- a/src/back-sch-idview.c +++ b/src/back-sch-idview.c @@ -290,21 +290,15 @@ idview_replace_target_dn(char **target, char **idview) } } -static int -idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct berval *bval, struct backend_search_filter_config *config) +int +idview_replace_bval_by_override(const char *bval_usage, const char *attr_name, + struct berval *bval, struct backend_search_cbdata *cbdata) { int res, i; - Slapi_Value *filter_val, *value, *anchor_val; + Slapi_Value *attr_val, *value, *anchor_val; Slapi_Attr *anchor, *attr = NULL; - struct backend_search_cbdata *cbdata = (struct backend_search_cbdata *) config->callback_data; - - if (cbdata == NULL || cbdata->idview == NULL) { - return SLAPI_FILTER_SCAN_CONTINUE; - } - - if (filter_type == NULL || config->name == NULL) { - return SLAPI_FILTER_SCAN_CONTINUE; - } + bool_t uid_override_found = FALSE; + bool_t anchor_override_found = FALSE; if (cbdata->overrides == NULL) { /* Only retrieve overrides for the view first time when neccessary */ @@ -312,31 +306,34 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b } if (cbdata->overrides == NULL) { - return SLAPI_FILTER_SCAN_CONTINUE; + return 0; } - filter_val = slapi_value_new_berval(bval); + attr_val = slapi_value_new_berval(bval); + slapi_log_error(SLAPI_LOG_FATAL, cbdata->state->plugin_desc->spd_id, + "Searching for an override of the %s %s with %s=%*s from the overrides\n.", + bval_usage, attr_name, attr_name, (int) bval->bv_len, bval->bv_val); /* If filter contains an attribute name which is overridden in the view and filter value * corresponds to the override, replace the filter by (ipaAnchorUUID=...) from the override * to point to the original because otherwise an entry will not be found in the slapi-nis map */ for(i=0; cbdata->overrides[i] != NULL; i++) { - res = slapi_entry_attr_find(cbdata->overrides[i], filter_type, &attr); + res = slapi_entry_attr_find(cbdata->overrides[i], attr_name, &attr); if ((res == 0) && (attr != NULL)) { res = slapi_attr_first_value(attr, &value); - res = slapi_value_compare(attr, value, filter_val); + res = slapi_value_compare(attr, value, attr_val); if (res == 0) { /* For uid overrides we should have ipaOriginalUID in the override */ - if (strcasecmp(filter_type, "uid") == 0) { + if (strcasecmp(attr_name, "uid") == 0) { res = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ORIGINALUID, &anchor); if (res == 0) { res = slapi_attr_first_value(anchor, &anchor_val); slapi_ber_bvdone(bval); slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); - config->override_found = TRUE; - slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, - "Overriding the filter %s with %s=%*s from the override %s\n.", - filter_type, filter_type, bval->bv_len, bval->bv_val, + uid_override_found = TRUE; + slapi_log_error(SLAPI_LOG_FATAL, cbdata->state->plugin_desc->spd_id, + "Overriding the %s %s with %s=%*s from the override %s\n.", + bval_usage, attr_name, attr_name, (int) bval->bv_len, bval->bv_val, slapi_entry_get_dn_const(cbdata->overrides[i])); break; } @@ -346,14 +343,13 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b res = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ANCHORUUID, &anchor); if (res == 0) { res = slapi_attr_first_value(anchor, &anchor_val); - slapi_filter_changetype(filter, IPA_IDVIEWS_ATTR_ANCHORUUID); slapi_ber_bvdone(bval); slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); - config->override_found = TRUE; - slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, - "Overriding the filter %s with %s=%*s from the override %s\n.", - filter_type, IPA_IDVIEWS_ATTR_ANCHORUUID, - bval->bv_len, bval->bv_val, + anchor_override_found = TRUE; + slapi_log_error(SLAPI_LOG_FATAL, cbdata->state->plugin_desc->spd_id, + "Overriding the %s %s with %s=%*s from the override %s\n.", + bval_usage, attr_name, IPA_IDVIEWS_ATTR_ANCHORUUID, + (int) bval->bv_len, bval->bv_val, slapi_entry_get_dn_const(cbdata->overrides[i])); break; } @@ -362,7 +358,41 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b } } - slapi_value_free(&filter_val); + slapi_value_free(&attr_val); + + if (uid_override_found) { + return 1; + } + + if (anchor_override_found) { + return 2; + } + + return 0; +} + +static int +idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, + struct berval *bval, struct backend_search_filter_config *config) +{ + int res; + struct backend_search_cbdata *cbdata = (struct backend_search_cbdata *) config->callback_data; + + if (cbdata == NULL || cbdata->idview == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + if (filter_type == NULL || config->name == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + res = idview_replace_bval_by_override("filter", filter_type, bval, cbdata); + + if (res == 2) { + slapi_filter_changetype(filter, IPA_IDVIEWS_ATTR_ANCHORUUID); + } + + config->override_found = (res != 0); return SLAPI_FILTER_SCAN_CONTINUE; diff --git a/src/back-sch.c b/src/back-sch.c index 902adb2..8bcf655 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -1634,6 +1634,7 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** { struct backend_locate_cbdata cbdata; char *idview = NULL; + char *target = NULL; slapi_pblock_get(pb, SLAPI_PLUGIN_PRIVATE, &cbdata.state); if (cbdata.state->plugin_base == NULL) { @@ -1642,22 +1643,59 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** return; } slapi_pblock_get(pb, SLAPI_TARGET_DN, &cbdata.target); -#ifdef USE_IPA_IDVIEWS - idview_replace_target_dn(&cbdata.target, &idview); -#endif + cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); cbdata.entry_data = NULL; cbdata.entry_group = NULL; cbdata.entry_set = NULL; map_data_foreach_map(cbdata.state, NULL, backend_locate_cb, &cbdata); +#ifdef USE_IPA_IDVIEWS + /* In case nothing was found but we are operating on the ID override, + * rebuild the target's RDN to use original attribute's value */ + if (cbdata.entry_data == NULL) { + target = slapi_ch_strdup(cbdata.target); + idview_replace_target_dn(&target, &idview); + if (idview != NULL) { + char *rdnstr; + char *val; + struct berval bval; + int res; + struct backend_search_cbdata scbdata; + Slapi_RDN *rdn = slapi_rdn_new_all_dn(target); + if (rdn != NULL) { + res = slapi_rdn_get_first(rdn, &rdnstr, &val); + if (res == 1) { + bval.bv_len = strlen(val) + 1; + bval.bv_val = slapi_ch_strdup(val); + memset(&scbdata, 0, sizeof(scbdata)); + scbdata.idview = idview; + scbdata.target = target; + scbdata.pb = pb; + scbdata.state = cbdata.state; + scbdata.target_dn = slapi_sdn_new_dn_byval(target); + res = idview_replace_bval_by_override("rdn", rdnstr, &bval, &scbdata); + /* only accept uid overrides */ + if (res == 1) { + slapi_rdn_remove_index(rdn, 1); + slapi_rdn_add(rdn, "uid", bval.bv_val); + slapi_sdn_free(&cbdata.target_dn); + cbdata.target_dn = slapi_sdn_set_rdn(scbdata.target_dn, rdn); + map_data_foreach_map(cbdata.state, NULL, backend_locate_cb, &cbdata); + } + slapi_ber_bvdone(&bval); + slapi_rdn_free(&rdn); + idview_free_overrides(&scbdata); + } + } + } + slapi_ch_free_string(&target); + slapi_ch_free_string(&idview); + } +#endif *data = cbdata.entry_data; *group = cbdata.entry_group; *set = cbdata.entry_set; slapi_sdn_free(&cbdata.target_dn); - if (idview != NULL) { - slapi_ch_free_string(&cbdata.target); - } - slapi_ch_free_string(&idview); } /* Check if the target DN is part of this group's tree. If it is, return an diff --git a/src/back-sch.h b/src/back-sch.h index 9f0b201..26e12d1 100644 --- a/src/back-sch.h +++ b/src/back-sch.h @@ -131,6 +131,10 @@ void idview_process_overrides(struct backend_search_cbdata *cbdata, Slapi_Entry *entry); void idview_replace_target_dn(char **target, char **idview); void idview_replace_filter(struct backend_search_cbdata *cbdata); +/* Takes struct berval value of an attribute attr_name and replaces it with an override + * Returns 0 if no override was found, 1 for 'uid' replacement, 2 for ipaAnchorUUID replacement */ +int idview_replace_bval_by_override(const char *bval_usage, const char *attr_name, + struct berval *bval, struct backend_search_cbdata *cbdata); #endif #endif -- 2.1.0 From edewata at redhat.com Tue Oct 28 21:51:01 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Oct 2014 16:51:01 -0500 Subject: [Freeipa-devel] [PATCH] 352 Fixed KRA backend. In-Reply-To: <5448C356.9040105@redhat.com> References: <543F4294.1080001@redhat.com> <5447C07C.4000800@redhat.com> <5448C356.9040105@redhat.com> Message-ID: <54500FC5.7070207@redhat.com> Thanks for the review. New patch attached. On 10/23/2014 3:59 AM, Petr Viktorin wrote: > In IPA we usually include the full ticket URL, not just the number. Fixed. > The build fails with a lint message: > ************* Module ipaserver.plugins.dogtag > ipaserver/plugins/dogtag.py:1903: [E1123(unexpected-keyword-arg), > kra.get_client] Unexpected keyword argument 'password_file' in > constructor call) > ipaserver/plugins/dogtag.py:1903: [E1120(no-value-for-parameter), > kra.get_client] No value for argument 'certdb_password' in constructor > call) > > I have pki-base-10.2.0-3.fc21.noarch, where NSSCryptoProvider indeed > takes password and not password_file. If a newer version is required you > should put it in the spec. Fixed. Dependency is bumped to 10.2.1-0.1 which is available from my COPR repo: dnf copr enable edewata/pki > ipaserver.install.certs.CertDB.install_pem_from_p12: > If p12_passwd is missing and pwd_fname is None, this will crash. > Please document how the method should be called. And assert that exactly > one of p12_passwd and pwd_fname is given. I reverted this change because the KRA backend actually no longer uses install_pem_from_p12(). The KRA backend is now using the CLI from the new Dogtag which generates the proper PEM format for client authentication, so I'll leave install_pem_from_p12() unmodified because it's still used by KrbInstance. > ipaserver.plugins.dogtag.kra.get_client: > Should every caller check if this returns None? > If not, raise an exception instead. > If yes, at least mention it in a docstring. Fixed. It's now raising a generic exception. Is there an existing exception that is more appropriate for backend issues like this? > Typo in commit message: "modified to use Dogtag's CLI *go* create" Fixed. -- Endi S. Dewata -------------- next part -------------- >From 6f1f289f32dd68c85c09a41422e5b2e0c204ee4c Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Wed, 1 Oct 2014 14:59:46 -0400 Subject: [PATCH] Fixed KRA backend. The KRA backend has been simplified since most of the tasks have been moved somewhere else. The transport certificate will be installed on the client, and it is not needed by KRA backend. The KRA agent's PEM certificate is now generated during installation due to permission issue. The kra_host() for now is removed since the current ldap_enable() cannot register the KRA service, so it is using the kra_host environment variable. The KRA installer has been modified to use Dogtag's CLI to create KRA agent and setup the client authentication. The proxy settings have been updated to include KRA's URLs. Some constants have been renamed for clarity. The DOGTAG_AGENT_P12 has been renamed to DOGTAG_ADMIN_P12 since file actually contains the Dogtag admin's certificate and private key and it can be used to access both CA and KRA. The DOGTAG_AGENT_PEM has been renamed to KRA_AGENT_PEM since it can only be used for KRA. The Dogtag dependency has been updated to 10.2.1-0.1. https://fedorahosted.org/freeipa/ticket/4503 --- freeipa.spec.in | 4 +- install/conf/ipa-pki-proxy.conf | 2 +- ipaplatform/base/paths.py | 4 +- ipaserver/install/cainstance.py | 4 +- ipaserver/install/ipa_backup.py | 3 +- ipaserver/install/krainstance.py | 83 +++++++++++++++++++++++--- ipaserver/plugins/dogtag.py | 122 ++++++--------------------------------- 7 files changed, 101 insertions(+), 121 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 8fcb535e229db4f7a8eaaee3c99b18446eef7f1e..dc04be48b2bb52ff05f9fab371c4b333a15d24ca 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -130,8 +130,8 @@ Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base Requires: slapi-nis >= 0.54-1 -Requires: pki-ca >= 10.2.0-3 -Requires: pki-kra >= 10.2.0 +Requires: pki-ca >= 10.2.1-0.1 +Requires: pki-kra >= 10.2.1-0.1 %if 0%{?rhel} Requires: subscription-manager %endif diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 2370b4d7a7467a7e47c0d223915e018c9a009e83..5d21156848f3b5ddf14c42d92a26a30a9f94af36 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -19,7 +19,7 @@ ProxyRequests Off # matches for agent port and eeca port - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://localhost:$DOGTAG_PORT diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index bbe6eed76ccb3c5f325fd368694ac6a2afbb72f0..01505594a7af926c860f867b817bd397c54efff5 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -138,8 +138,8 @@ class BasePathNamespace(object): HOME_DIR = "/home" ROOT_IPA_CACHE = "/root/.ipa_cache" ROOT_PKI = "/root/.pki" - DOGTAG_AGENT_P12 = "/root/ca-agent.p12" - DOGTAG_AGENT_PEM = "/etc/httpd/alias/agent.pem" + DOGTAG_ADMIN_P12 = "/root/ca-agent.p12" + KRA_AGENT_PEM = "/etc/httpd/alias/kra-agent.pem" CACERT_P12 = "/root/cacert.p12" ROOT_IPA_CSR = "/root/ipa.csr" ROOT_TMP_CA_P12 = "/root/tmp-ca.p12" diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 1ae39639ac9702651851e6c3964faa69788db31e..fe95201517a577b9f6dba7642afe09b4eef2328d 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -514,7 +514,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_admin_nickname", "ipa-ca-agent") config.set("CA", "pki_admin_subject_dn", str(DN(('cn', 'ipa-ca-agent'), self.subject_base))) - config.set("CA", "pki_client_admin_cert_p12", paths.DOGTAG_AGENT_P12) + config.set("CA", "pki_client_admin_cert_p12", paths.DOGTAG_ADMIN_P12) # Directory server config.set("CA", "pki_ds_ldap_port", str(self.ds_port)) @@ -979,7 +979,7 @@ class CAInstance(DogtagInstance): try: ipautil.run([paths.PK12UTIL, "-n", "ipa-ca-agent", - "-o", paths.DOGTAG_AGENT_P12, + "-o", paths.DOGTAG_ADMIN_P12, "-d", self.agent_db, "-k", pwd_name, "-w", pwd_name]) diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py index 014b49bb63579227c12a8380cfb630a0bd6c677a..ed9139576f511c4c0989675d3e5b0d356584d893 100644 --- a/ipaserver/install/ipa_backup.py +++ b/ipaserver/install/ipa_backup.py @@ -158,7 +158,8 @@ class Backup(admintool.AdminTool): paths.NTP_CONF, paths.SMB_CONF, paths.SAMBA_KEYTAB, - paths.DOGTAG_AGENT_P12, + paths.DOGTAG_ADMIN_P12, + paths.KRA_AGENT_PEM, paths.CACERT_P12, paths.KRB5KDC_KDC_CONF, paths.SYSTEMD_IPA_SERVICE, diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index 1af1c0f721cd9b0df7c6134798494d507e2ba07c..7c1bded4173420a7e8f0ebfe40fe7e12ba0476c4 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -169,7 +169,7 @@ class KRAInstance(DogtagInstance): str(DN(('cn', 'ipa-ca-agent'), self.subject_base))) config.set("KRA", "pki_import_admin_cert", "True") config.set("KRA", "pki_admin_cert_file", paths.ADMIN_CERT_PATH) - config.set("KRA", "pki_client_admin_cert_p12", paths.DOGTAG_AGENT_P12) + config.set("KRA", "pki_client_admin_cert_p12", paths.DOGTAG_ADMIN_P12) # Directory server config.set("KRA", "pki_ds_ldap_port", str(self.ds_port)) @@ -259,16 +259,81 @@ class KRAInstance(DogtagInstance): """ Add RA agent created for CA to KRA agent group. """ - conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) - conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) - entry_dn = DN(('uid', "ipara"), ('ou', 'People'), ('o', 'ipaca')) - dn = DN(('cn', 'Data Recovery Manager Agents'), ('ou', 'groups'), - self.basedn) - modlist = [(0, 'uniqueMember', '%s' % entry_dn)] - conn.modify_s(dn, modlist) + # import CA certificate into temporary security database + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-import", + "--pkcs12", paths.KRACERT_P12, + "--pkcs12-password", self.admin_password] + ipautil.run(args) - conn.unbind() + # trust CA certificate + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-mod", "Certificate Authority - %s" % api.env.realm, + "--trust", "CT,c,"] + ipautil.run(args) + + # import Dogtag admin certificate into temporary security database + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-import", + "--pkcs12", paths.DOGTAG_ADMIN_P12, + "--pkcs12-password", self.admin_password] + ipautil.run(args) + + # as Dogtag admin, create ipakra user in KRA + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-add", "ipakra", + "--fullName", "IPA KRA User"] + ipautil.run(args) + + # as Dogtag admin, add ipakra into KRA agents group + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-membership-add", "ipakra", "Data Recovery Manager Agents"] + ipautil.run(args) + + # assign ipaCert to ipakra + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + # export ipaCert without private key + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--cert", filename] + ipautil.run(args) + + # as Dogtag admin, upload and assign ipaCert to ipakra + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-cert-add", "ipakra", + "--input", filename] + ipautil.run(args) + + finally: + os.remove(filename) + + # export ipaCert with private key for client authentication + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--client-cert", paths.KRA_AGENT_PEM] + ipautil.run(args) @staticmethod def update_cert_config(nickname, cert, dogtag_constants=None): diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 0e141a45c290b84d65b15b8c2c638577a3a39363..f0e7233211a61cfd8355aba8fb189acc82ba5df8 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1890,122 +1890,36 @@ class kra(Backend): """ def __init__(self, kra_port=443): - if api.env.in_tree: - self.sec_dir = os.path.join(api.env.dot_ipa, 'alias') - pwd_file = os.path.join(self.sec_dir, '.pwd') - self.pem_file = os.path.join(self.sec_dir, ".pemfile") - else: - self.sec_dir = paths.HTTPD_ALIAS_DIR - pwd_file = paths.ALIAS_PWDFILE_TXT - self.pem_file = paths.DOGTAG_AGENT_PEM self.kra_port = kra_port - self.transport_nick = "IPA KRA Transport Cert" - self.password = "" - with open(pwd_file, "r") as f: - self.password = f.readline().strip() - self.keyclient = None super(kra, self).__init__() - def _create_pem_file(self): - """ Create PEM file used by KRA plugin for authentication. - - This function reads the IPA HTTPD database and extracts the - Dogtag agent certificate and keys into a PKCS#12 temporary file. - The PKCS#12 file is then converted into PEM format so that it - can be used by python-requests to authenticate to the KRA. - - :return: None - """ - (p12_pwd_fd, p12_pwd_fname) = tempfile.mkstemp() - (p12_fd, p12_fname) = tempfile.mkstemp() - - try: - os.write(p12_pwd_fd, self.password) - os.close(p12_pwd_fd) - os.close(p12_fd) - - certdb = CertDB(api.env.realm) - certdb.export_pkcs12(p12_fname, p12_pwd_fname, "ipaCert") - - certdb.install_pem_from_p12(p12_fname, self.password, self.pem_file) - except: - self.debug("Error when creating PEM file for KRA operations") - raise - finally: - os.remove(p12_fname) - os.remove(p12_pwd_fname) - - def _transport_cert_present(self): - """ Check if the client certDB contains the KRA transport certificate - :return: True/False + def get_client(self): """ - # certutil -L -d db_dir -n cert_nick - certdb = CertDB(api.env.realm) - return certdb.has_nickname(self.transport_nick) - - def _setup(self): - """ Do initial setup and crypto initialization of the KRA client + Returns an authenticated KRA client to access KRA services. - Creates a PEM file containing the KRA agent cert/keys to be used for - authentication to the KRA (if it does not already exist), Sets up a - connection to the KRA and initializes an NSS certificate database to - store the transport certificate, Retrieves the transport certificate - if it is not already present. + Raises a generic exception if KRA is not enabled. """ - #set up pem file if not present - if not os.path.exists(self.pem_file): - self._create_pem_file() - # set up connection - connection = PKIConnection('https', - self.kra_host, - str(self.kra_port), - 'kra') - connection.set_authentication_cert(self.pem_file) + if not api.env.enable_kra: + # TODO: replace this with a more specific exception + raise Exception(_('KRA service is not enabled')) - crypto = cryptoutil.NSSCryptoProvider(self.sec_dir, self.password) + crypto = cryptoutil.NSSCryptoProvider( + paths.HTTPD_ALIAS_DIR, + password_file=paths.ALIAS_PWDFILE_TXT) - #create kraclient - kraclient = KRAClient(connection, crypto) + # TODO: obtain KRA host & port from IPA service list or point to KRA load balancer + # https://fedorahosted.org/freeipa/ticket/4557 + connection = PKIConnection( + 'https', + api.env.kra_host, + str(self.kra_port), + 'kra') - # get transport cert if needed - if not self._transport_cert_present(): - transport_cert = kraclient.system_certs.get_transport_cert() - crypto.import_cert(self.transport_nick, transport_cert, "u,u,u") + connection.set_authentication_cert(paths.KRA_AGENT_PEM) - crypto.initialize() - - self.keyclient = kraclient.keys - self.keyclient.set_transport_cert(self.transport_nick) - - @cachedproperty - def kra_host(self): - """ - :return: host - as str - - Select our KRA host. - """ - ldap2 = self.api.Backend.ldap2 - if host_has_service(api.env.kra_host, ldap2, "kra"): - return api.env.kra_host - if api.env.host != api.env.kra_host: - if host_has_service(api.env.host, ldap2, "kra"): - return api.env.host - host = select_any_master(ldap2, "kra") - if host: - return host - else: - return api.env.kra_host - - def get_keyclient(self): - """Return a keyclient to perform key archival and retrieval. - :return: pki.key.keyclient - """ - if self.keyclient is None: - self._setup() - return self.keyclient + return KRAClient(connection, crypto) api.register(kra) -- 1.9.0 From edewata at redhat.com Tue Oct 28 22:17:54 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Oct 2014 17:17:54 -0500 Subject: [Freeipa-devel] [PATCH] 354 Modififed NSSConnection not to shutdown existing database. In-Reply-To: <5447BC13.6010500@redhat.com> References: <5447BC13.6010500@redhat.com> Message-ID: <54501612.8060701@redhat.com> On 10/22/2014 9:15 AM, Endi Sukma Dewata wrote: > The NSSConnection class has been modified not to shutdown the > existing NSS database if the database is already opened to > establish an SSL connection, or is already opened by another > code that uses an NSS database without establishing an SSL > connection such as vault CLIs. > > Ticket #4638 New patch attached. It's identical except for the ticket URL in the commit log. -- Endi S. Dewata -------------- next part -------------- >From 34bd77959687673db9fbf71c443b6ffe5ed4ca71 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 16 Sep 2014 20:11:35 -0400 Subject: [PATCH] Modififed NSSConnection not to shutdown existing database. The NSSConnection class has been modified not to shutdown the existing NSS database if the database is already opened to establish an SSL connection, or is already opened by another code that uses an NSS database without establishing an SSL connection such as vault CLIs. https://fedorahosted.org/freeipa/ticket/4638 --- ipalib/rpc.py | 34 +++++++++++++++++++--------------- ipapython/nsslib.py | 35 +++++++++++++++++++++++------------ 2 files changed, 42 insertions(+), 27 deletions(-) diff --git a/ipalib/rpc.py b/ipalib/rpc.py index 5934f0c26e4b7c0a44adbab978c1f9b319d72e9f..001b7f1ca06edadfc7aad635d9d564e517008a63 100644 --- a/ipalib/rpc.py +++ b/ipalib/rpc.py @@ -63,6 +63,7 @@ from ipaplatform.paths import paths from ipapython.cookie import Cookie from ipapython.dnsutil import DNSName from ipalib.text import _ +import ipapython.nsslib from ipapython.nsslib import NSSHTTPS, NSSConnection from ipalib.krb_utils import KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, KRB5KRB_AP_ERR_TKT_EXPIRED, \ KRB5_FCC_PERM, KRB5_FCC_NOFILE, KRB5_CC_FORMAT, KRB5_REALM_CANT_RESOLVE @@ -450,14 +451,10 @@ class LanguageAwareTransport(MultiProtocolTransport): class SSLTransport(LanguageAwareTransport): """Handles an HTTPS transaction to an XML-RPC server.""" - def __nss_initialized(self, dbdir): + def get_connection_dbdir(self): """ - If there is another connections open it may have already - initialized NSS. This is likely to lead to an NSS shutdown - failure. One way to mitigate this is to tell NSS to not - initialize if it has already been done in another open connection. - - Returns True if another connection is using the same db. + If there is a connections open it may have already initialized + NSS database. Return the database location used by the connection. """ for value in context.__dict__.values(): if not isinstance(value, Connection): @@ -466,25 +463,32 @@ class SSLTransport(LanguageAwareTransport): getattr(value.conn, '_ServerProxy__transport', None), SSLTransport): continue - if hasattr(value.conn._ServerProxy__transport, 'dbdir') and \ - value.conn._ServerProxy__transport.dbdir == dbdir: - return True - return False + if hasattr(value.conn._ServerProxy__transport, 'dbdir'): + return value.conn._ServerProxy__transport.dbdir + return None def make_connection(self, host): host, self._extra_headers, x509 = self.get_host_info(host) # Python 2.7 changed the internal class used in xmlrpclib from # HTTP to HTTPConnection. We need to use the proper subclass - # If we an existing connection exists using the same NSS database - # there is no need to re-initialize. Pass thsi into the NSS - # connection creator. if sys.version_info >= (2, 7): if self._connection and host == self._connection[0]: return self._connection[1] dbdir = getattr(context, 'nss_dir', paths.IPA_NSSDB_DIR) - no_init = self.__nss_initialized(dbdir) + connection_dbdir = self.get_connection_dbdir() + + if connection_dbdir: + # If an existing connection is already using the same NSS + # database there is no need to re-initialize. + no_init = dbdir == connection_dbdir + + else: + # If the NSS database is already being used there is no + # need to re-initialize. + no_init = dbdir == ipapython.nsslib.current_dbdir + if sys.version_info < (2, 7): conn = NSSHTTPS(host, 443, dbdir=dbdir, no_init=no_init) else: diff --git a/ipapython/nsslib.py b/ipapython/nsslib.py index 93b0c56fcff4fc69841a6823aae8f694c1f76ff0..1452a2a5844a5fb017d4408aadf56f7fcfc7fa25 100644 --- a/ipapython/nsslib.py +++ b/ipapython/nsslib.py @@ -31,6 +31,9 @@ import nss.ssl as ssl import nss.error as error from ipaplatform.paths import paths +# NSS database currently open +current_dbdir = None + def auth_certificate_callback(sock, check_sig, is_server, certdb): cert_is_valid = False @@ -184,19 +187,27 @@ class NSSConnection(httplib.HTTPConnection, NSSAddressFamilyFallback): httplib.HTTPConnection.__init__(self, host, port, strict) NSSAddressFamilyFallback.__init__(self, family) - if not dbdir: - raise RuntimeError("dbdir is required") - root_logger.debug('%s init %s', self.__class__.__name__, host) - if not no_init and nss.nss_is_initialized(): - # close any open NSS database and use the new one - ssl.clear_session_cache() - try: - nss.nss_shutdown() - except NSPRError, e: - if e.errno != error.SEC_ERROR_NOT_INITIALIZED: - raise e - nss.nss_init(dbdir) + + # If initialization is requested, initialize the new database. + if not no_init: + + if nss.nss_is_initialized(): + ssl.clear_session_cache() + try: + nss.nss_shutdown() + except NSPRError, e: + if e.errno != error.SEC_ERROR_NOT_INITIALIZED: + raise e + + if not dbdir: + raise RuntimeError("dbdir is required") + + nss.nss_init(dbdir) + + global current_dbdir + current_dbdir = dbdir + ssl.set_domestic_policy() nss.set_password_callback(self.password_callback) -- 1.9.0 From edewata at redhat.com Tue Oct 28 22:34:55 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Oct 2014 17:34:55 -0500 Subject: [Freeipa-devel] [PATCH] 353 Added initial vault implementation. In-Reply-To: <54480DD5.10504@redhat.com> References: <543F429C.2040006@redhat.com> <544034B2.5010609@redhat.com> <54480DD5.10504@redhat.com> Message-ID: <54501A0F.30805@redhat.com> On 10/22/2014 3:04 PM, Endi Sukma Dewata wrote: > On 10/16/2014 4:12 PM, Endi Sukma Dewata wrote: >> On 10/15/2014 10:59 PM, Endi Sukma Dewata wrote: >>> The NSSConnection class has to be modified not to shutdown existing >>> database because some of the vault clients (e.g. vault-archive and >>> vault-retrieve) also use a database to encrypt/decrypt the secret. >> >> The problem is described in more detail in this ticket: >> https://fedorahosted.org/freeipa/ticket/4638 >> >> The changes to the NSSConnection in the first patch caused the >> installation to fail. Attached is a new patch that uses the solution >> proposed by jdennis. > > New patch attached. It's now using the correct OID's for the schema. It > also has been rebased on top of #352-1 and #354. New patch attached to fix the ticket URL. It depends on #352-2 and #354-1. -- Endi S. Dewata -------------- next part -------------- >From cd3daa901f7139801ea61ae1e2716810da131bcc Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Tue, 21 Oct 2014 10:57:08 -0400 Subject: [PATCH] Added initial vault implementation. This patch provides the initial vault implementation which allows the admin to create a vault, archive a secret, and retrieve the secret using a standard vault. It also included the initial LDAP schema. It currently has limitations including: - The vault only supports the standard vault type. - The vault can only be used by the admin user. - The transport certificate has to be installed manually. These limitations, other vault features, schema and ACL changes will be addressed in subsequent patches. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 160 ++++++++ VERSION | 4 +- install/share/60basev4.ldif | 3 + install/share/Makefile.am | 1 + install/share/copy-schema-to-ca.py | 1 + install/updates/40-vault.update | 27 ++ install/updates/Makefile.am | 1 + ipa-client/man/default.conf.5 | 1 + ipalib/constants.py | 1 + ipalib/plugins/user.py | 9 + ipalib/plugins/vault.py | 724 +++++++++++++++++++++++++++++++++++++ ipaserver/install/dsinstance.py | 1 + 12 files changed, 931 insertions(+), 2 deletions(-) create mode 100644 install/share/60basev4.ldif create mode 100644 install/updates/40-vault.update create mode 100644 ipalib/plugins/vault.py diff --git a/API.txt b/API.txt index 0000491d7a76fd1d2d50208d314d1600839ce295..cfa6558fcf678e5915a90407da517f9a591a41bf 100644 --- a/API.txt +++ b/API.txt @@ -4475,6 +4475,166 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add +args: 1,8,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('in?', cli_name='in') +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret', attribute=True, cli_name='secret', multivalue=False, required=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_archive +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Bytes('encrypted_data?', cli_name='encrypted_data') +option: Str('in?', cli_name='in') +option: Bytes('nonce?', cli_name='nonce') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret?', cli_name='secret') +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vault_find +args: 1,10,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Bytes('secret', attribute=True, autofill=False, cli_name='secret', multivalue=False, query=True, required=False) +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vault_mod +args: 1,10,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Bytes('secret', attribute=True, autofill=False, cli_name='secret', multivalue=False, required=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_retrieve +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('out?', cli_name='out') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +option: Bytes('wrapped_session_key?', cli_name='wrapped_session_key') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vault_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_add +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_del +args: 1,3,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: ListOfPrimaryKeys('value', None, None) +command: vaultcontainer_find +args: 1,9,4 +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: vaultcontainer_mod +args: 1,9,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) +command: vaultcontainer_show +args: 1,5,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: PrimaryKey('value', None, None) capability: messages 2.52 capability: optional_uid_params 2.54 capability: permissions2 2.69 diff --git a/VERSION b/VERSION index b0d41e5e1ec59ddefbdcccf588b97bac2ff798ee..fe23eae5f349f4a2d40c3d3e55f6168a82b961b2 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=108 -# Last change: pvoborni - manage authorization of keytab operations +IPA_API_VERSION_MINOR=109 +# Last change: edewata - initial vault implementation diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif new file mode 100644 index 0000000000000000000000000000000000000000..97553d53938093c1b0ecba0826fc469d0d758c62 --- /dev/null +++ b/install/share/60basev4.ldif @@ -0,0 +1,3 @@ +dn: cn=schema +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) diff --git a/install/share/Makefile.am b/install/share/Makefile.am index 878d8868bbbb4f774d378b1d2e886841e2b4b7e4..ec417b634aeb80be3a39f2b8e3410e68a1131ee0 100644 --- a/install/share/Makefile.am +++ b/install/share/Makefile.am @@ -14,6 +14,7 @@ app_DATA = \ 60ipaconfig.ldif \ 60basev2.ldif \ 60basev3.ldif \ + 60basev4.ldif \ 60ipadns.ldif \ 60ipapk11.ldif \ 61kerberos-ipav3.ldif \ diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py index fc53fe4cb52486cc618bec77aabe8283ad5eadbc..fb938d212f0f4ddd9a8250a362b89c29d3078efd 100755 --- a/install/share/copy-schema-to-ca.py +++ b/install/share/copy-schema-to-ca.py @@ -29,6 +29,7 @@ SCHEMA_FILENAMES = ( "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", "65ipacertstore.ldif", diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update new file mode 100644 index 0000000000000000000000000000000000000000..59e5b629ce4e6c5acac06df78f02106afa6c859e --- /dev/null +++ b/install/updates/40-vault.update @@ -0,0 +1,27 @@ +dn: cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: vaults +default: description: Root vault container + +dn: cn=services,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: services +default: description: Services vault container + +dn: cn=shared,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: shared +default: description: Shared vault container + +dn: cn=users,cn=vaults,$SUFFIX +default: objectClass: top +default: objectClass: nsContainer +default: objectClass: ipaVaultContainer +default: cn: users +default: description: Users vault container diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 2bd877a0d89525a69ea2d09647499ab2311bb358..a127f91cbe03aa13ec90bd628eaa29b7a898c3b9 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -32,6 +32,7 @@ app_DATA = \ 40-dns.update \ 40-automember.update \ 40-otp.update \ + 40-vault.update \ 45-roles.update \ 50-7_bit_check.update \ 50-dogtag10-migration.update \ diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5 index dbc8a5b4647439de4de7c01152d098eb0561e236..0973f1a07179ad64daa326a02803cdc9ba1870aa 100644 --- a/ipa-client/man/default.conf.5 +++ b/ipa-client/man/default.conf.5 @@ -221,6 +221,7 @@ The following define the containers for the IPA server. Containers define where container_sudocmdgroup: cn=sudocmdgroups,cn=sudo container_sudorule: cn=sudorules,cn=sudo container_user: cn=users,cn=accounts + container_vault: cn=vaults container_virtual: cn=virtual operations,cn=etc .SH "FILES" diff --git a/ipalib/constants.py b/ipalib/constants.py index 325414b64fdacd4d8df261588cfc9b7481923be1..f64e02b5cf2a949a3c0ea7c1702132a3a09c1c19 100644 --- a/ipalib/constants.py +++ b/ipalib/constants.py @@ -97,6 +97,7 @@ DEFAULT_CONFIG = ( ('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))), ('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))), ('container_dns', DN(('cn', 'dns'))), + ('container_vault', DN(('cn', 'vaults'))), ('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))), ('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))), ('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))), diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py index e206289248dfe9ae79bd87271ff2c7672fb98b4f..928a996e35cf31d21e6e85e4ea31380ec9b2c2ce 100644 --- a/ipalib/plugins/user.py +++ b/ipalib/plugins/user.py @@ -22,6 +22,7 @@ from time import gmtime, strftime import string import posixpath import os +import traceback from ipalib import api, errors from ipalib import Flag, Int, Password, Str, Bool, StrEnum, DateTime @@ -889,6 +890,14 @@ class user_del(LDAPDelete): else: self.api.Command.otptoken_del(token) + # Delete user's private vault container. + try: + vaultcontainer_id = self.api.Object.vaultcontainer.get_private_id(owner) + (vaultcontainer_parent_id, vaultcontainer_name) = self.api.Object.vaultcontainer.split_id(vaultcontainer_id) + self.api.Command.vaultcontainer_del(vaultcontainer_name, parent=vaultcontainer_parent_id) + except errors.NotFound: + pass + return dn diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py new file mode 100644 index 0000000000000000000000000000000000000000..c0e66621d1cf326b0bfb88565951d66cda3b9500 --- /dev/null +++ b/ipalib/plugins/vault.py @@ -0,0 +1,724 @@ +# Authors: +# Endi S. Dewata +# +# Copyright (C) 2014 Red Hat +# see file 'COPYING' for use and warranty information +# +# 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 PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +import json +import os +import random +import shutil +import string +import tempfile + +import pki +import pki.account +import pki.crypto +import pki.key + +from ipalib import api, errors +from ipalib import Str, Bytes +from ipalib.plugable import Registry +from ipalib.plugins.baseldap import * +from ipalib.plugins import baseldap +from ipalib.request import context +from ipalib.plugins.user import split_principal +from ipalib import _, ngettext +from ipaplatform.paths import paths +import ipapython.nsslib + +__doc__ = _(""" +Vaults + +Manage vaults and vault containers. + +EXAMPLES: + + List private vaults: + ipa vault-find + + List shared vaults: + ipa vault-find --parent /shared + + Add a vault: + ipa vault-add MyVault + + Show a vault: + ipa vault-show MyVault + + Archive a secret: + ipa vault-archive MyVault --in secret.in + + Retrieve a secret: + ipa vault-retrieve MyVault --out secret.out + + Delete a vault: + ipa vault-del MyVault + + List private vault containers: + ipa vaultcontainer-find + + List top-level vault containers: + ipa vaultcontainer-find --parent / + + Add a vault container: + ipa vaultcontainer-add MyContainer + + Show a vault container: + ipa vaultcontainer-show MyContainer + + Delete a vault container: + ipa vaultcontainer-del MyContainer +""") + +register = Registry() +transport_cert_nickname = "KRA Transport Certificate" + + at register() +class vaultcontainer(LDAPObject): + """ + Vault container object. + """ + container_dn = api.env.container_vault + object_name = _('vault container') + object_name_plural = _('vault containers') + + object_class = ['ipaVaultContainer'] + default_attributes = [ + 'cn', 'description', + ] + search_display_attributes = [ + 'cn', 'description', + ] + + label = _('Vault Containers') + label_singular = _('Vault Container') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='container_name', + label=_('Container name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Container description'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + ) + + def get_private_id(self, username=None): + """ + Returns user's private container ID (i.e. /users//). + """ + + if not username: + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + + return u'/users/' + username + u'/' + + def normalize_id(self, id): + """ + Normalizes container ID. + """ + + # if ID is empty, return user's private container ID + if not id: + return self.get_private_id() + + # make sure ID ends with slash + if not id.endswith(u'/'): + id += u'/' + + # if it's an absolute ID, do nothing + if id.startswith(u'/'): + return id + + # otherwise, prepend with user's private container ID + return self.get_private_id() + id + + def split_id(self, id): + """ + Split a normalized container ID into (parent ID, container name) tuple. + """ + + # handle root ID + if id == u'/': + return (None, None) + + # split ID into parent ID, container name, and empty string + parts = id.rsplit(u'/', 2) + + # return parent ID and container name + return (parts[-3] + u'/', parts[-2]) + + def get_dn(self, *keys, **kwargs): + """ + Generate vault container DN. + """ + + id = keys[0] + dn = DN(self.container_dn, api.env.basedn) + + # if ID is not specified, return base DN + if not id: + return dn + + # for each name in the ID, prepend the base DN + for name in id.split(u'/'): + if name: + dn = DN(('cn', name), dn) + + return dn + + + at register() +class vaultcontainer_add(LDAPCreate): + __doc__ = _('Create a new vault container.') + + msg_summary = _('Added vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + + name = entry_attrs.get('cn') + parent_id = self.obj.normalize_id(options.get('parent')) + + # add parent container if it doesn't exist + try: + (grandparent_id, parent_name) = self.obj.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + id = parent_id + name + dn = self.obj.get_dn(id) + + return dn + + + at register() +class vaultcontainer_del(LDAPDelete): + __doc__ = _('Delete a vault container.') + + msg_summary = _('Deleted vault container "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_find(LDAPSearch): + __doc__ = _('Search for vault containers.') + + msg_summary = ngettext( + '%(count)d vault container matched', '%(count)d vault containers matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + + parent_id = self.obj.normalize_id(options.get('parent')) + base_dn = self.obj.get_dn(parent_id) + return (filter, base_dn, scope) + + + at register() +class vaultcontainer_mod(LDAPUpdate): + __doc__ = _('Modify a vault container.') + + msg_summary = _('Modified vault container "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[1] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_show(LDAPRetrieve): + __doc__ = _('Display information about a vault container.') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vault(LDAPObject): + """ + Vault object. + """ + container_dn = api.env.container_vault + object_name = _('vault') + object_name_plural = _('vaults') + + object_class = ['ipaVault'] + default_attributes = [ + 'cn', 'description', + ] + search_display_attributes = [ + 'cn', 'description', + ] + + label = _('Vaults') + label_singular = _('Vault') + + takes_params = ( + Str('cn', + pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', + pattern_errmsg='may only include letters, numbers, _, -, . and $', + maxlength=255, + cli_name='vault_name', + label=_('Vault name'), + primary_key=True, + ), + Str('description?', + cli_name='desc', + label=_('Description'), + doc=_('Vault description'), + ), + Bytes('secret?', + cli_name='secret', + label=_('Secret'), + doc=_('Secret'), + ), + Str('parent?', + cli_name='parent', + label=_('Parent'), + doc=_('Parent container'), + flags=('virtual_attribute'), + ), + ) + + def get_dn(self, *keys, **kwargs): + """ + Generate vault DN. + """ + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(kwargs.get('parent')) + parent_dn = api.Object.vaultcontainer.get_dn(parent_id) + dn = DN(('cn', name), parent_dn) + + return dn + + + at register() +class vault_add(LDAPCreate): + __doc__ = _('Create a new vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('in?', + cli_name='in', + doc=_('Input file containing the secret'), + ), + ) + + msg_summary = _('Added vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + + name = entry_attrs.get('cn') + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + + # add parent container if it doesn't exist + try: + (grandparent_id, parent_name) = api.Object.vaultcontainer.split_id(parent_id) + if parent_name: + api.Command.vaultcontainer_add(parent_name, parent=grandparent_id) + except errors.DuplicateEntry: + pass + + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + secret = options.get('secret') + file = options.get('in') + + # don't send these parameters to server + if 'secret' in options: + del options['secret'] + if 'in' in options: + del options['in'] + + if secret: + pass + + elif file: + with open(file) as f: + secret = f.read() + + # create the vault + response = super(vault_add, self).forward(*args, **options) + + # archive an empty secret + api.Command.vault_archive(vault_id, secret=secret) + + return response + + + at register() +class vault_del(LDAPDelete): + __doc__ = _('Delete a vault.') + + msg_summary = _('Deleted vault "%(value)s"') + + takes_options = LDAPDelete.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, *keys, **options): + + vault_id = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(vault_id, parent=parent_id) + + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa-' + vault_id + + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + return dn + + + at register() +class vault_find(LDAPSearch): + __doc__ = _('Search for vaults.') + + msg_summary = ngettext( + '%(count)d vault matched', '%(count)d vaults matched', 0 + ) + + def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *keys, **options): + + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + base_dn = api.Object.vaultcontainer.get_dn(parent_id) + return (filter, base_dn, scope) + + + at register() +class vault_mod(LDAPUpdate): + __doc__ = _('Modify a vault.') + + msg_summary = _('Modified vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[1] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_show(LDAPRetrieve): + __doc__ = _('Display information about a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_archive(LDAPRetrieve): + __doc__ = _('Archive a secret into a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Bytes('secret?', + cli_name='secret', + doc=_('Secret to archive'), + ), + Str('in?', + cli_name='in', + doc=_('Input file containing the secret'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + Bytes('encrypted_data?', + cli_name='encrypted_data', + doc=_('Data encrypted with session key and encoded in base-64'), + ), + Bytes('nonce?', + cli_name='nonce', + doc=_('Nonce encrypted encoded in base-64'), + ), + ) + + msg_summary = _('Archived secret into vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + + vault_id = entry_attrs.get('cn')[0] + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + client_key_id = 'ipa-' + vault_id + + try: + key_info = kra_client.keys.get_active_key_info(client_key_id) + + kra_client.keys.modify_key_status( + key_info.get_key_id(), + pki.key.KeyClient.KEY_STATUS_INACTIVE) + + except pki.ResourceNotFoundException, e: + pass + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + encrypted_data = base64.b64decode(options['encrypted_data']) + nonce = base64.b64decode(options['nonce']) + + kra_client.keys.archive_encrypted_data( + client_key_id, + pki.key.KeyClient.PASS_PHRASE_TYPE, + encrypted_data, + wrapped_session_key, + "{1 2 840 113549 3 7}", + base64.encodestring(nonce), + ) + + kra_account.logout() + + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + secret = options.get('secret') + file = options.get('in') + + # don't send these parameters to server + if 'secret' in options: + del options['secret'] + if 'in' in options: + del options['in'] + + if secret: + pass + + elif file: + with open(file) as f: + secret = f.read() + + else: + secret = '' + + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + nonce = crypto.generate_nonce_iv() + session_key = crypto.generate_session_key() + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + encrypted_data = crypto.symmetric_wrap( + secret, + session_key, + nonce_iv=nonce + ) + + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + options['encrypted_data'] = base64.b64encode(encrypted_data) + options['nonce'] = base64.b64encode(nonce) + + return super(vault_archive, self).forward(*args, **options) + + + at register() +class vault_retrieve(LDAPRetrieve): + __doc__ = _('Retrieve a secret from a vault.') + + takes_options = LDAPRetrieve.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + Str('out?', + cli_name='out', + doc=_('Output file to store the secret'), + ), + Bytes('wrapped_session_key?', + cli_name='wrapped_session_key', + doc=_('Session key wrapped with transport certificate and encoded in base-64'), + ), + ) + + msg_summary = _('Retrieved secret from vault "%(value)s"') + + def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + + vault_id = entry_attrs.get('cn')[0] + + wrapped_session_key = base64.b64decode(options['wrapped_session_key']) + + client_key_id = 'ipa-' + vault_id + + kra_client = api.Backend.kra.get_client() + + kra_account = pki.account.AccountClient(kra_client.connection) + kra_account.login() + + key_client = kra_client.keys + key_info = key_client.get_active_key_info(client_key_id) + + key = key_client.retrieve_key( + key_info.get_key_id(), + wrapped_session_key) + + entry_attrs['encrypted_data'] = base64.b64encode(key.encrypted_data) + entry_attrs['nonce'] = base64.b64encode(key.nonce_data) + + kra_account.logout() + + return dn + + def forward(self, *args, **options): + + vault_id = args[0] + + file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + crypto = pki.crypto.NSSCryptoProvider(paths.IPA_NSSDB_DIR) + crypto.initialize() + ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR + + session_key = crypto.generate_session_key() + nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + wrapped_session_key = crypto.asymmetric_wrap( + session_key, + nss_transport_cert + ) + + options['wrapped_session_key'] = base64.b64encode(wrapped_session_key) + + response = super(vault_retrieve, self).forward(*args, **options) + + encrypted_data = base64.b64decode(response['result']['encrypted_data']) + nonce = base64.b64decode(response['result']['nonce']) + + secret = crypto.symmetric_unwrap( + encrypted_data, + session_key, + nonce_iv=nonce) + + if file: + with open(file, 'w') as f: + f.write(secret) + + else: + response['result']['secret'] = unicode(secret) + + return response diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index d1569697cba7d7fb9f44a3b85afb643a42624f20..9fa736dcf635b286035b4438a6c342e64f09d1d6 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -56,6 +56,7 @@ IPA_SCHEMA_FILES = ("60kerberos.ldif", "60ipaconfig.ldif", "60basev2.ldif", "60basev3.ldif", + "60basev4.ldif", "60ipapk11.ldif", "60ipadns.ldif", "61kerberos-ipav3.ldif", -- 1.9.0 From edewata at redhat.com Tue Oct 28 22:35:30 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Oct 2014 17:35:30 -0500 Subject: [Freeipa-devel] [PATCH] 355 Added vault access control. In-Reply-To: <54480DE1.3070103@redhat.com> References: <54480DE1.3070103@redhat.com> Message-ID: <54501A32.3080905@redhat.com> On 10/22/2014 3:04 PM, Endi Sukma Dewata wrote: > New LDAP ACIs have been added to allow users to create their own > private vault container, to allow owners to manage vaults and > containers, and to allow members to use the vaults. New CLIs have > been added to manage the owner and member list. For archive and > retrieve operations the access control has to be enforced by the > plugins because the operations only affects KRA. The LDAP schema > has been updated as well. > > Ticket #3872 > > This patch depends on #353-2. New patch attached to fix the ticket URL. It depends on #353-3. -- Endi S. Dewata -------------- next part -------------- >From 6f464581e4e30e6105522ff25047764ec97e5a53 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Fri, 17 Oct 2014 12:05:34 -0400 Subject: [PATCH] Added vault access control. New LDAP ACIs have been added to allow users to create their own private vault container, to allow owners to manage vaults and containers, and to allow members to use the vaults. New CLIs have been added to manage the owner and member list. For archive and retrieve operations the access control has to be enforced by the plugins because the operations only affects KRA. The LDAP schema has been updated as well. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 134 +++++++++++++++++++++-- VERSION | 4 +- install/share/60basev4.ldif | 4 +- install/updates/40-vault.update | 7 ++ ipalib/plugins/vault.py | 233 +++++++++++++++++++++++++++++++++++++++- 5 files changed, 366 insertions(+), 16 deletions(-) diff --git a/API.txt b/API.txt index cfa6558fcf678e5915a90407da517f9a591a41bf..a46592ec9e82e618154bf09393c83d4b854315c5 100644 --- a/API.txt +++ b/API.txt @@ -4476,11 +4476,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_add -args: 1,8,3 +args: 1,9,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) option: Str('in?', cli_name='in') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4489,12 +4490,39 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_add_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault_add_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_archive -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Bytes('encrypted_data?', cli_name='encrypted_data') option: Str('in?', cli_name='in') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Bytes('nonce?', cli_name='nonce') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4515,11 +4543,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vault_find -args: 1,10,4 +args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4532,12 +4561,13 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vault_mod -args: 1,10,3 +args: 1,11,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4547,10 +4577,37 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_remove_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vault_remove_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vault_retrieve -args: 1,7,3 +args: 1,8,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('out?', cli_name='out') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4561,9 +4618,10 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vault_show -args: 1,5,3 +args: 1,6,3 arg: Str('cn', attribute=True, cli_name='vault_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4572,11 +4630,12 @@ output: Entry('result', , Gettext('A dictionary representing an LDA output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) command: vaultcontainer_add -args: 1,7,3 +args: 1,8,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('setattr*', cli_name='setattr', exclude='webui') @@ -4584,6 +4643,32 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vaultcontainer_add_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vaultcontainer_add_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vaultcontainer_del args: 1,3,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=True, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) @@ -4594,11 +4679,12 @@ output: Output('result', , None) output: Output('summary', (, ), None) output: ListOfPrimaryKeys('value', None, None) command: vaultcontainer_find -args: 1,9,4 +args: 1,10,4 arg: Str('criteria?', noextrawhitespace=False) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('cn', attribute=True, autofill=False, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False) option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, query=True, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, query=True, required=False) option: Flag('pkey_only?', autofill=True, default=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') @@ -4610,12 +4696,13 @@ output: ListOfEntries('result', (, ), Gettext('A list output: Output('summary', (, ), None) output: Output('truncated', , None) command: vaultcontainer_mod -args: 1,9,3 +args: 1,10,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') option: Str('description', attribute=True, autofill=False, cli_name='desc', multivalue=False, required=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent', attribute=False, autofill=False, cli_name='parent', multivalue=False, required=False) option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Flag('rights', autofill=True, default=False) @@ -4624,11 +4711,38 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vaultcontainer_remove_member +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +command: vaultcontainer_remove_owner +args: 1,7,3 +arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('group*', alwaysask=True, cli_name='groups', csv=True) +option: Flag('no_members', autofill=True, default=False, exclude='webui') +option: Str('parent?', cli_name='parent') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('user*', alwaysask=True, cli_name='users', csv=True) +option: Str('version?', exclude='webui') +output: Output('completed', , None) +output: Output('failed', , None) +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) command: vaultcontainer_show -args: 1,5,3 +args: 1,6,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=True) option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Flag('no_members', autofill=True, default=False, exclude='webui') option: Str('parent?', cli_name='parent') option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') option: Str('version?', exclude='webui') diff --git a/VERSION b/VERSION index fe23eae5f349f4a2d40c3d3e55f6168a82b961b2..c471ed80af6a2c26be7fc89281ae60fac6c68577 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=109 -# Last change: edewata - initial vault implementation +IPA_API_VERSION_MINOR=110 +# Last change: edewata - added vault access control diff --git a/install/share/60basev4.ldif b/install/share/60basev4.ldif index 97553d53938093c1b0ecba0826fc469d0d758c62..61590562ffa174134e10567be93c18ab437d8008 100644 --- a/install/share/60basev4.ldif +++ b/install/share/60basev4.ldif @@ -1,3 +1,3 @@ dn: cn=schema -objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) -objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.1 NAME 'ipaVault' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.1' ) +objectClasses: (2.16.840.1.113730.3.8.18.1.2 NAME 'ipaVaultContainer' SUP nsContainer STRUCTURAL MAY ( description $ owner $ member ) X-ORIGIN 'IPA v4.1' ) diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update index 59e5b629ce4e6c5acac06df78f02106afa6c859e..455d4719f612198890f8a914d3a13794a3b9ad75 100644 --- a/install/updates/40-vault.update +++ b/install/updates/40-vault.update @@ -4,6 +4,13 @@ default: objectClass: nsContainer default: objectClass: ipaVaultContainer default: cn: vaults default: description: Root vault container +default: aci: (target="ldap:///cn=*,cn=users,cn=vaults,$SUFFIX")(targetattr="*")(version 3.0; acl "Allow add macro dn"; allow (add) userdn = "ldap:///uid=($$attr.cn),cn=users,cn=accounts,$SUFFIX";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container members can access the container"; allow(read, search, compare) userattr="member#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container owners can modify the container"; allow(read, search, compare, write) userattr="owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVaultContainer)")(targetattr="*")(version 3.0; acl "Container owners can manage sub-containers"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Container owners can manage vaults in the container"; allow(read, search, compare, add, delete) userattr="parent[1].owner#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault members can access the vault"; allow(read, search, compare) userattr="member#USERDN";) +default: aci: (targetfilter="(objectClass=ipaVault)")(targetattr="*")(version 3.0; acl "Vault owners can modify the vault"; allow(read, search, compare, write) userattr="owner#USERDN";) dn: cn=services,cn=vaults,$SUFFIX default: objectClass: top diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index c0e66621d1cf326b0bfb88565951d66cda3b9500..95f96859235af1c477c8f5738a27571d64aabe3a 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -68,6 +68,18 @@ EXAMPLES: Delete a vault: ipa vault-del MyVault + Add a vault owner: + ipa vault-add-owner MyVault --users testuser + + Delete a vault owner: + ipa vault-remove-owner MyVault --users testuser + + Add a vault member: + ipa vault-add-member MyVault --users testuser + + Delete a vault member: + ipa vault-remove-member MyVault --users testuser + List private vault containers: ipa vaultcontainer-find @@ -82,6 +94,18 @@ EXAMPLES: Delete a vault container: ipa vaultcontainer-del MyContainer + + Add a vault container owner: + ipa vaultcontainer-add-owner MyContainer --users testuser + + Delete a vault container owner: + ipa vaultcontainer-remove-owner MyContainer --users testuser + + Add a vault container member: + ipa vaultcontainer-add-member MyContainer --users testuser + + Delete a vault container member: + ipa vaultcontainer-remove-member MyContainer --users testuser """) register = Registry() @@ -98,11 +122,15 @@ class vaultcontainer(LDAPObject): object_class = ['ipaVaultContainer'] default_attributes = [ - 'cn', 'description', + 'cn', 'description', 'owner', 'member', ] search_display_attributes = [ 'cn', 'description', ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } label = _('Vault Containers') label_singular = _('Vault Container') @@ -206,6 +234,11 @@ class vaultcontainer_add(LDAPCreate): name = entry_attrs.get('cn') parent_id = self.obj.normalize_id(options.get('parent')) + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + owner_dn = self.api.Object['user'].get_dn(username) + entry_attrs['owner'] = owner_dn + # add parent container if it doesn't exist try: (grandparent_id, parent_name) = self.obj.split_id(parent_id) @@ -293,6 +326,93 @@ class vaultcontainer_show(LDAPRetrieve): @register() +class vaultcontainer_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault container.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner added.', '%i owners added.') + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault container.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner removed.', '%i owners removed.') + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault container.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() +class vaultcontainer_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault container.') + + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = self.obj.normalize_id(options.get('parent')) + id = parent_id + name + dn = self.obj.get_dn(id) + return dn + + + at register() class vault(LDAPObject): """ Vault object. @@ -303,11 +423,15 @@ class vault(LDAPObject): object_class = ['ipaVault'] default_attributes = [ - 'cn', 'description', + 'cn', 'description', 'owner', 'member', ] search_display_attributes = [ 'cn', 'description', ] + attribute_members = { + 'owner': ['user', 'group'], + 'member': ['user', 'group'], + } label = _('Vaults') label_singular = _('Vault') @@ -371,6 +495,11 @@ class vault_add(LDAPCreate): parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) dn = self.obj.get_dn(name, parent=parent_id) + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + owner_dn = self.api.Object['user'].get_dn(username) + entry_attrs['owner'] = owner_dn + # add parent container if it doesn't exist try: (grandparent_id, parent_name) = api.Object.vaultcontainer.split_id(parent_id) @@ -541,6 +670,15 @@ class vault_archive(LDAPRetrieve): def post_callback(self, ldap, dn, entry_attrs, *keys, **options): vault_id = entry_attrs.get('cn')[0] + owners = entry_attrs.get('owner', []) + members = entry_attrs.get('member', []) + + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + user_dn = self.api.Object['user'].get_dn(username) + + if user_dn not in owners and user_dn not in members: + raise errors.ACIError(info=_("Insufficient access to vault '%s'.") % vault_id) kra_client = api.Backend.kra.get_client() @@ -656,6 +794,15 @@ class vault_retrieve(LDAPRetrieve): def post_callback(self, ldap, dn, entry_attrs, *keys, **options): vault_id = entry_attrs.get('cn')[0] + owners = entry_attrs.get('owner', []) + members = entry_attrs.get('member', []) + + principal = getattr(context, 'principal') + (username, realm) = split_principal(principal) + user_dn = self.api.Object['user'].get_dn(username) + + if user_dn not in owners and user_dn not in members: + raise errors.ACIError(info=_("Insufficient access to vault '%s'.") % vault_id) wrapped_session_key = base64.b64decode(options['wrapped_session_key']) @@ -722,3 +869,85 @@ class vault_retrieve(LDAPRetrieve): response['result']['secret'] = unicode(secret) return response + + + at register() +class vault_add_owner(LDAPAddMember): + __doc__ = _('Add owners to a vault.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner added.', '%i owners added.') + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_remove_owner(LDAPRemoveMember): + __doc__ = _('Remove owners from a vault.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + member_attributes = ['owner'] + member_count_out = ('%i owner removed.', '%i owners removed.') + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_add_member(LDAPAddMember): + __doc__ = _('Add members to a vault.') + + takes_options = LDAPAddMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn + + + at register() +class vault_remove_member(LDAPRemoveMember): + __doc__ = _('Remove members from a vault.') + + takes_options = LDAPRemoveMember.takes_options + ( + Str('parent?', + cli_name='parent', + doc=_('Parent container'), + ), + ) + + def pre_callback(self, ldap, dn, found, not_found, *keys, **options): + + name = keys[0] + parent_id = api.Object.vaultcontainer.normalize_id(options.get('parent')) + dn = self.obj.get_dn(name, parent=parent_id) + return dn -- 1.9.0 From edewata at redhat.com Tue Oct 28 23:26:36 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 28 Oct 2014 18:26:36 -0500 Subject: [Freeipa-devel] [PATCH] 356 Added command to retrieve vault transport certificate. In-Reply-To: <5448E41D.5030401@redhat.com> References: <54480E30.8040905@redhat.com> <5448E41D.5030401@redhat.com> Message-ID: <5450262C.9050906@redhat.com> On 10/23/2014 6:18 AM, Jan Cholasta wrote: > Hi, > > Dne 22.10.2014 v 22:06 Endi Sukma Dewata napsal(a): >> A new command has been added to retrieve the vault transport >> certificate and optionally save it into a file. The vault archive >> and retrieve command has been modified to retrieve the transport >> certificate and store it locally for subsequent usage. This way >> it's no longer necessary to manually import the transport >> certificate into the client's NSS database. > > As part of the CA certificate renewal feature in 4.1, I have added a > LDAP certificate store to IPA, see > . Currently it > supports only CA certificates, but can be extended to support end entity > certificates rather easily. If you use it for the vault transport > certificate, it can be added to the client NSS database automatically on > install. > > Honza > I'm attaching a new patch that's identical to the previous one with ticket URL updated. I'm thinking we should check this patch in first because it's already done, and then investigate the use of CA cert management utility as a separate enhancement since the it seems to need to be generalized before it can be used to manage KRA transport cert. I'll also need to investigate the KRA transport cert replacement process to make sure it can be accommodated via IPA's cert management utility. -- Endi S. Dewata -------------- next part -------------- >From 1bffa29d35fee0ac06cb1bc943f9de8beee58d05 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Wed, 22 Oct 2014 10:02:25 -0400 Subject: [PATCH] Added command to retrieve vault transport certificate. A new command has been added to retrieve the vault transport certificate and optionally save it into a file. The vault archive and retrieve command has been modified to retrieve the transport certificate and store it locally for subsequent usage. This way it's no longer necessary to manually import the transport certificate into the client's NSS database. https://fedorahosted.org/freeipa/ticket/3872 --- API.txt | 5 +++ VERSION | 4 +-- ipalib/plugins/vault.py | 85 +++++++++++++++++++++++++++++++++++++++++++++++-- 3 files changed, 89 insertions(+), 5 deletions(-) diff --git a/API.txt b/API.txt index a46592ec9e82e618154bf09393c83d4b854315c5..95b86ce84f5bc9f1d879e561e07b0348d719c90e 100644 --- a/API.txt +++ b/API.txt @@ -4629,6 +4629,11 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: PrimaryKey('value', None, None) +command: vault_transport_cert +args: 0,2,1 +option: Str('out?', cli_name='out') +option: Str('version?', exclude='webui') +output: Output('result', None, None) command: vaultcontainer_add args: 1,8,3 arg: Str('cn', attribute=True, cli_name='container_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) diff --git a/VERSION b/VERSION index c471ed80af6a2c26be7fc89281ae60fac6c68577..d0ada131b700e93faa8c4946b811db36d76341a9 100644 --- a/VERSION +++ b/VERSION @@ -90,5 +90,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=110 -# Last change: edewata - added vault access control +IPA_API_VERSION_MINOR=111 +# Last change: edewata - added vault transport certificate diff --git a/ipalib/plugins/vault.py b/ipalib/plugins/vault.py index 95f96859235af1c477c8f5738a27571d64aabe3a..871c3e3a25c688a64ba0ecfde5ccbd50b47fbe01 100644 --- a/ipalib/plugins/vault.py +++ b/ipalib/plugins/vault.py @@ -24,6 +24,8 @@ import shutil import string import tempfile +import nss.nss as nss + import pki import pki.account import pki.crypto @@ -109,7 +111,7 @@ EXAMPLES: """) register = Registry() -transport_cert_nickname = "KRA Transport Certificate" +transport_cert_filename = "vault-transport.pem" @register() class vaultcontainer(LDAPObject): @@ -628,6 +630,63 @@ class vault_show(LDAPRetrieve): @register() +class vault_transport_cert(Command): + __doc__ = _('Retrieve vault transport certificate.') + + + # list of attributes we want exported to JSON + json_friendly_attributes = ( + 'takes_args', + ) + + takes_options = ( + Str('out?', + cli_name='out', + doc=_('Output file to store the transport certificate'), + ), + ) + + has_output_params = ( + Str('certificate', + label=_('Certificate'), + ), + ) + + def __json__(self): + json_dict = dict( + (a, getattr(self, a)) for a in self.json_friendly_attributes + ) + json_dict['takes_options'] = list(self.get_json_options()) + return json_dict + + def execute(self, *args, **options): + + kra_client = api.Backend.kra.get_client() + transport_cert = kra_client.system_certs.get_transport_cert() + return { + 'result': { + 'certificate': transport_cert.encoded + } + } + + def forward(self, *args, **options): + + file = options.get('out') + + # don't send these parameters to server + if 'out' in options: + del options['out'] + + response = super(vault_transport_cert, self).forward(*args, **options) + + if file: + with open(file, 'w') as f: + f.write(response['result']['certificate']) + + return response + + + at register() class vault_archive(LDAPRetrieve): __doc__ = _('Archive a secret into a vault.') @@ -743,7 +802,17 @@ class vault_archive(LDAPRetrieve): nonce = crypto.generate_nonce_iv() session_key = crypto.generate_session_key() - nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + ipa_dir = os.path.join(os.path.expanduser('~'), '.ipa') + if not os.path.exists(ipa_dir): + os.makedirs(ipa_dir) + + transport_cert_path = os.path.join(ipa_dir, transport_cert_filename) + if not os.path.exists(transport_cert_path): + api.Command.vault_transport_cert(out=unicode(transport_cert_path)) + + transport_cert_der = nss.read_der_from_file(transport_cert_path, True) + nss_transport_cert = nss.Certificate(transport_cert_der) wrapped_session_key = crypto.asymmetric_wrap( session_key, @@ -842,7 +911,17 @@ class vault_retrieve(LDAPRetrieve): ipapython.nsslib.current_dbdir = paths.IPA_NSSDB_DIR session_key = crypto.generate_session_key() - nss_transport_cert = crypto.get_cert(transport_cert_nickname) + + ipa_dir = os.path.join(os.path.expanduser('~'), '.ipa') + if not os.path.exists(ipa_dir): + os.makedirs(ipa_dir) + + transport_cert_path = os.path.join(ipa_dir, transport_cert_filename) + if not os.path.exists(transport_cert_path): + api.Command.vault_transport_cert(out=unicode(transport_cert_path)) + + transport_cert_der = nss.read_der_from_file(transport_cert_path, True) + nss_transport_cert = nss.Certificate(transport_cert_der) wrapped_session_key = crypto.asymmetric_wrap( session_key, -- 1.9.0 From mkosek at redhat.com Wed Oct 29 09:37:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 29 Oct 2014 10:37:37 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <1414529956.16650.3.camel@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> Message-ID: <5450B561.6080505@redhat.com> On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >> This patch gives the administrator variables to control the size of >> the authentication and synchronization windows for OTP tokens. >> >> https://fedorahosted.org/freeipa/ticket/4511 >> >> NOTE: There is one known issue with this patch which I don't know how to >> solve. This patch changes the schema in install/share/60ipaconfig.ldif. >> On an upgrade, all of the new attributeTypes appear correctly. However, >> the modifications to the pre-existing objectClass do not show up on the >> server. What am I doing wrong? >> >> After modifying ipaGuiConfig manually, everything in this patch works >> just fine. > > This new version takes into account the new (proper) OIDs and attribute > names. Thanks Nathaniel! > The above known issue still remains. Petr3, any idea what could have gone wrong? ObjectClass MAY list extension should work just fine, AFAIK. Martin From pviktori at redhat.com Wed Oct 29 11:21:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 29 Oct 2014 12:21:27 +0100 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <5450B561.6080505@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> Message-ID: <5450CDB7.4070207@redhat.com> On 10/29/2014 10:37 AM, Martin Kosek wrote: > On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: >> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: >>> This patch gives the administrator variables to control the size of >>> the authentication and synchronization windows for OTP tokens. >>> >>> https://fedorahosted.org/freeipa/ticket/4511 >>> >>> NOTE: There is one known issue with this patch which I don't know how to >>> solve. This patch changes the schema in install/share/60ipaconfig.ldif. >>> On an upgrade, all of the new attributeTypes appear correctly. However, >>> the modifications to the pre-existing objectClass do not show up on the >>> server. What am I doing wrong? >>> >>> After modifying ipaGuiConfig manually, everything in this patch works >>> just fine. >> >> This new version takes into account the new (proper) OIDs and attribute >> names. > > Thanks Nathaniel! > >> The above known issue still remains. > > Petr3, any idea what could have gone wrong? ObjectClass MAY list extension > should work just fine, AFAIK. You added a blank line to the LDIF file. This is an entry separator, so the objectClasses after the blank line don't belong to cn=schema, so they aren't considered in the update. Without the blank line it works fine. -- Petr? From dkupka at redhat.com Wed Oct 29 11:37:29 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 29 Oct 2014 12:37:29 +0100 Subject: [Freeipa-devel] [PATCH] 333 Handle profile changes in dogtag-ipa-ca-renew-agent In-Reply-To: <543CE460.7070006@redhat.com> References: <543CE460.7070006@redhat.com> Message-ID: <5450D179.1050206@redhat.com> On 10/14/2014 10:52 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > (The original patch was posted at > .) > > > How to test: > > 1. install server > > 2. run "ipa-certupdate" > > 3. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert > cert-pki-ca'", the request should be in CA_WORKING state > > 4. run "ipa-cacert-manage renew" > > 5. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert > cert-pki-ca'", the request should be in MONITORING state, there should > be no ca-error > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. -- David Kupka From tbordaz at redhat.com Wed Oct 29 12:14:25 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 29 Oct 2014 13:14:25 +0100 Subject: [Freeipa-devel] [PATCH, slapi-nis] ID view-related patches to slapi-nis In-Reply-To: <20141028211136.GL26496@redhat.com> References: <20141028211136.GL26496@redhat.com> Message-ID: <5450DA21.6000009@redhat.com> On 10/28/2014 10:11 PM, Alexander Bokovoy wrote: > Hi, > > two patches to slapi-nis are attached: > > - make sure only DNs from the schema-compat trees are targeted for ID > view replacement. This solves issue of > https://bugzilla.redhat.com/show_bug.cgi?id=1157989 > found by Sumit. > > - support ID overrides in the BIND callback. So far the only thing we > need is overriding uid. > > They need to be applied in this order, on top of 0.54 release version of > slapi-nis. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hi Alexander, The patches fixed the test case in https://bugzilla.redhat.com/show_bug.cgi?id=1157989. Few comments regarding the patch: * in backend_search_cb, it checks if the search is in one of the container. We need that cbdata.answer=FALSE at the end of the checking. Why not setting it systematically at the end. * in backend_locate, 'target' is a duplicate of cbdata.target. But then when calling idview_replace_target_dn it may be changed. Will not it lead to a leak ? Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Wed Oct 29 12:22:59 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 29 Oct 2014 13:22:59 +0100 Subject: [Freeipa-devel] [PATCHES] 0661-0672 Switch the test suite to pytest In-Reply-To: <544E66E8.6010903@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> Message-ID: <5450DC23.4090907@redhat.com> On 10/27/2014 04:38 PM, Petr Viktorin wrote: > On 10/15/2014 02:58 PM, Petr Viktorin wrote: >> This almost completes the switch to pytest. There are two missing >> things: >> - the details of test results (--with-xunit) are not read correctly by >> Jenkins. I have a theory I'm investigating here. >> - the beakerlib integration is still not ready >> >> >> I'll not be available for the rest of the week so I'm sending this >> early, in case someone wants to take a look. > > I've updated (and rearranged) the patches after some more testing. > Both points above are fixed. Individual plugins are broken out; some > would be nice to even release independently of IPA. (There is some > demand for the BeakerLib plugin; for that I'd only need to break the > dependency on ipa_log_manager.) > > > These depend on my patches 0656-0660. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Thanks for this effort! #### Patch 0656: tests: Use PEP8-compliant setup/teardown method names There are some references to the old names in the test_ipapython and test_install: [tbabej at thinkpad7 ipatests]$ git grep setUpClass [tbabej at thinkpad7 ipatests]$ git grep tearDownClass [tbabej at thinkpad7 ipatests]$ git grep setUp test_install/test_updates.py: def setUp(self): test_ipapython/test_cookie.py: def setUp(self): test_ipapython/test_cookie.py: def setUp(self): test_ipapython/test_cookie.py: def setUp(self): test_ipapython/test_dn.py: def setUp(self): test_ipapython/test_dn.py: def setUp(self): test_ipapython/test_dn.py: def setUp(self): test_ipapython/test_dn.py: def setUp(self): test_ipapython/test_dn.py: def setUp(self): [tbabej at thinkpad7 ipatests]$ git grep tearDown test_install/test_updates.py: def tearDown(self): #### Patch 0657: tests: Add configuration for pytest Shouldn't we rather change the class names? #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in get_subcls ACK. #### Patch 0659: test_automount_plugin: Fix test ordering ACK. #### PATCH 0660: Use setup_class/teardown_class in Declarative tests --- a/ipatests/test_ipaserver/test_changepw.py +++ b/ipatests/test_ipaserver/test_changepw.py @@ -33,8 +33,7 @@ class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): app_uri = '/ipa/session/change_password' - def setup(self): - super(test_changepw, self).setup() + def setup(cls): try: api.Command['user_add'](uid=testuser, givenname=u'Test', sn=u'User') api.Command['passwd'](testuser, password=u'old_password') @@ -43,12 +42,11 @@ def setup(self): 'Cannot set up test user: %s' % e ) - def teardown(self): + def teardown(cls): try: api.Command['user_del']([testuser]) except errors.NotFound: pass - super(test_changepw, self).teardown() The setup/teardown methods are not classmethods, so the name of the first argument should remain "self". #### PATCH 0661: dogtag plugin: Don't use doctest syntax for non-doctest examples ACK. #### PATCH 0662: test_webui: Don't use __init__ for test classes I don't think the following change will work: - def __init__(self, driver=None, config=None): + def setup(self, driver=None, config=None): self.request_timeout = 30 self.driver = driver self.config = config if not config: self.load_config() + self.get_driver().maximize_window() + + def teardown(self): + self.driver.quit() def load_config(self): """ @@ -161,20 +165,6 @@ def load_config(self): if 'type' not in c: c['type'] = DEFAULT_TYPE - def setup(self): - """ - Test setup - """ - if not self.driver: - self.driver = self.get_driver() - self.driver.maximize_window() - - def teardown(self): - """ - Test clean up - """ - self.driver.quit() The setup(self) method used to set the self.driver attribute on the class instance, now nothing sets it. The setup method should do: def setup(self, driver=None, config=None): self.request_timeout = 30 self.driver = driver self.config = config if not config: self.load_config() if not self.driver: self.driver = self.get_driver() self.driver.maximize_window() However, I would prefer having self.driver as a cached property. #### PATCH 0663: test_ipapython: Use functions instead of classes in test generators ACK. #### PATCH 0664: Configure pytest to run doctests ACK. #### PATCH 0665: Declarative tests: Move cleanup to setup_class/teardown_class You should also remove the now redundant cleanup_generate method. Also: Do we really want to print out error.NotFound or errors.EmptyModList exceptions produced by cleanup commands? #### PATCH 0666: Declarative tests: Switch to pytest Nitpitck: declarative.py has wrong year in the copyright header. Otherwise ACK. #### PATCH 0667: Integration tests: Port the ordering plugin to pytest Specfile change belongs to the previous patch, but I doubt these would be separated, so not worth spending the time IMHO. Why does TestIPACommands have ordered decorator applied? It is applied on IntegrationTest directly, from which CALessBase inherits from. I don't think it's necessary (unless I'm missing something), so we should rather remove the occurence of the decorator in the test_caless.py than fixing the import. #### PATCH 0668: Switch make-test to pytest Nice simplification. However, make-test does not work for me: I'm getting tons of errors (during the collection) along the lines of: ________________ ERROR collecting ipatests/test_xmlrpc/testcert.py _________________ /usr/lib/python2.7/site-packages/py/_path/local.py:661: in pyimport raise self.ImportMismatchError(modname, modfile, self) E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) _______________ ERROR collecting ipatests/test_xmlrpc/xmlrpc_test.py _______________ /usr/lib/python2.7/site-packages/py/_path/local.py:661: in pyimport raise self.ImportMismatchError(modname, modfile, self) E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) _______________ ERROR collecting ipatests/test_xmlrpc/xmlrpc_test.py _______________ import file mismatch: imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this __file__ attribute: /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py which is not the same as the test file we want to collect: /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules ================ 163 passed, 7 skipped, 679 error in 48.14 seconds ============== I am running this as ./make-test from the directory containing the freeipa sources. The ipa-run-tests command seems to work fine though. #### PATCH 0669: Add local pytest plugin for --with-xunit and --logging-level ACK. #### PATCH 0670: Switch ipa-run-tests to pytest ACK. #### PATCH 0671: Switch integration testing config to a fixture ACK. #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log collection to pytest I didn't see any glitches, but I haven't tested this one out yet functionally. ### General notes I did two IPA master installs today, one with your patches applied. There were significant differences in the number of successfully passing tests: nose: FAILED (SKIP=60, errors=46, failures=14) pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in 860.47 seconds ========= Did you not encounter this in your testing? I will look more deeply into the failures themselves. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed Oct 29 12:58:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 29 Oct 2014 13:58:26 +0100 Subject: [Freeipa-devel] [PATCH] 352 Fixed KRA backend. In-Reply-To: <54500FC5.7070207@redhat.com> References: <543F4294.1080001@redhat.com> <5447C07C.4000800@redhat.com> <5448C356.9040105@redhat.com> <54500FC5.7070207@redhat.com> Message-ID: <5450E472.90903@redhat.com> On 10/28/2014 10:51 PM, Endi Sukma Dewata wrote: > Thanks for the review. New patch attached. > > On 10/23/2014 3:59 AM, Petr Viktorin wrote: >> In IPA we usually include the full ticket URL, not just the number. > > Fixed. > >> The build fails with a lint message: >> ************* Module ipaserver.plugins.dogtag >> ipaserver/plugins/dogtag.py:1903: [E1123(unexpected-keyword-arg), >> kra.get_client] Unexpected keyword argument 'password_file' in >> constructor call) >> ipaserver/plugins/dogtag.py:1903: [E1120(no-value-for-parameter), >> kra.get_client] No value for argument 'certdb_password' in constructor >> call) >> >> I have pki-base-10.2.0-3.fc21.noarch, where NSSCryptoProvider indeed >> takes password and not password_file. If a newer version is required you >> should put it in the spec. > > Fixed. Dependency is bumped to 10.2.1-0.1 which is available from my > COPR repo: > > dnf copr enable edewata/pki OK. We should get that to an IPA COPR before merging this. >> ipaserver.install.certs.CertDB.install_pem_from_p12: >> If p12_passwd is missing and pwd_fname is None, this will crash. >> Please document how the method should be called. And assert that exactly >> one of p12_passwd and pwd_fname is given. > > I reverted this change because the KRA backend actually no longer uses > install_pem_from_p12(). The KRA backend is now using the CLI from the > new Dogtag which generates the proper PEM format for client > authentication, so I'll leave install_pem_from_p12() unmodified because > it's still used by KrbInstance. > >> ipaserver.plugins.dogtag.kra.get_client: >> Should every caller check if this returns None? >> If not, raise an exception instead. >> If yes, at least mention it in a docstring. > > Fixed. It's now raising a generic exception. > > Is there an existing exception that is more appropriate for backend > issues like this? I'd go for RuntimeError. Don't use translatable strings (the _ function) if you're not using ipalib.PublicError subclasses. > >> Typo in commit message: "modified to use Dogtag's CLI *go* create" > > Fixed. > How can I do some basic smoke check on this? Is there something I still need to to besides ipa-kra-istall? Any other patches? I tried: from ipalib import api from pki.key import KeyClient api.bootstrap(context='server') api.finalize() keyclient = api.Backend.kra.get_client() keyclient.keys.archive_key('test3', KeyClient.PASS_PHRASE_TYPE, 'tkey') which gives me: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/pki/__init__.py", line 295, in handler return fn_call(inst, *args, **kwargs) File "/usr/lib/python2.7/site-packages/pki/key.py", line 687, in archive_key nonce_iv = self.crypto.generate_nonce_iv() File "/usr/lib/python2.7/site-packages/pki/crypto.py", line 176, in generate_nonce_iv iv_data = nss.generate_random(iv_length) nss.error.NSPRError: (SEC_ERROR_NO_TOKEN) The security card or token does not exist, needs to be initialized, or has been removed. -- Petr? From mbasti at redhat.com Wed Oct 29 13:01:27 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 29 Oct 2014 14:01:27 +0100 Subject: [Freeipa-devel] [PATCH 0020] Fix zone name to directory name conversion in BINDMgr In-Reply-To: <54490627.1070208@redhat.com> References: <5448F17D.9080702@redhat.com> <54490627.1070208@redhat.com> Message-ID: <5450E527.9030501@redhat.com> On 23/10/14 15:44, Martin Basti wrote: > On 23/10/14 14:15, Petr Spacek wrote: >> Hello, >> >> Fix zone name to directory name conversion in BINDMgr. >> >> https://fedorahosted.org/freeipa/ticket/4657 >> > ACK, signing the root zone works fine now > The patch is ready to be pushed. -- Martin Basti From abokovoy at redhat.com Wed Oct 29 13:23:35 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 29 Oct 2014 15:23:35 +0200 Subject: [Freeipa-devel] [PATCH, slapi-nis] ID view-related patches to slapi-nis In-Reply-To: <5450DA21.6000009@redhat.com> References: <20141028211136.GL26496@redhat.com> <5450DA21.6000009@redhat.com> Message-ID: <20141029132335.GA5100@redhat.com> On Wed, 29 Oct 2014, thierry bordaz wrote: >The patches fixed the test case in >https://bugzilla.redhat.com/show_bug.cgi?id=1157989. >Few comments regarding the patch: > > * in backend_search_cb, it checks if the search is in one of the > container. We need that cbdata.answer=FALSE at the end of the checking. > Why not setting it systematically at the end. I've moved it to the end of the block. > * in backend_locate, 'target' is a duplicate of cbdata.target. But > then when calling idview_replace_target_dn it may be changed. > Will not it lead to a leak ? Good catch, thanks! Fixed version attached. -- / Alexander Bokovoy -------------- next part -------------- From 79391fda05fba164af577bd0e08a2807643b7b48 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 28 Oct 2014 10:09:47 +0200 Subject: [PATCH 1/2] ID views: ignore searches for views outside the subtrees of schema-compat sets schema-compat plugin may provide multiple disjoint subtrees which can be used to request overridden entries by prefixing the subtree suffix with a cn=,cn=views, As subtrees may be disjoint, we cannot rely on the common suffix. Thus, any attempt to replace target DN and update filter terms must only be done once we are sure the search will be done in the subtree. This optimization prevents mistakenly changing the search filter when FreeIPA and SSSD search for the ID overrides themselves, as the same structure of the target DN is used for cn=views,cn=accounts,$SUFFIX subtree in FreeIPA. This subtree is never handled by slapi-nis and should be ignored. https://bugzilla.redhat.com/show_bug.cgi?id=1157989 --- src/back-sch-idview.c | 11 +++++-- src/back-sch.c | 81 +++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 81 insertions(+), 11 deletions(-) diff --git a/src/back-sch-idview.c b/src/back-sch-idview.c index 5a2b450..a56a9e9 100644 --- a/src/back-sch-idview.c +++ b/src/back-sch-idview.c @@ -334,6 +334,10 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b slapi_ber_bvdone(bval); slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); config->override_found = TRUE; + slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, + "Overriding the filter %s with %s=%*s from the override %s\n.", + filter_type, filter_type, bval->bv_len, bval->bv_val, + slapi_entry_get_dn_const(cbdata->overrides[i])); break; } } @@ -346,6 +350,11 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b slapi_ber_bvdone(bval); slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); config->override_found = TRUE; + slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, + "Overriding the filter %s with %s=%*s from the override %s\n.", + filter_type, IPA_IDVIEWS_ATTR_ANCHORUUID, + bval->bv_len, bval->bv_val, + slapi_entry_get_dn_const(cbdata->overrides[i])); break; } @@ -366,8 +375,6 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b * * Note that in reality we don't use original value of the uid/cn attribue. Instead, we use ipaAnchorUUID * to refer to the original entry. */ -extern char * -slapi_filter_to_string( const struct slapi_filter *f, char *buf, size_t bufsize ); void idview_replace_filter(struct backend_search_cbdata *cbdata) { diff --git a/src/back-sch.c b/src/back-sch.c index 27d5101..27ac24f 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -1166,6 +1166,44 @@ backend_search_set_cb(const char *group, const char *set, bool_t flag, return TRUE; } +/* Routines to search if a target DN is within any of the sets we handle */ +static bool_t +backend_search_find_set_dn_in_group_cb(const char *group, const char *set, bool_t flag, + void *backend_data, void *cb_data) +{ + struct backend_search_cbdata *cbdata; + struct backend_set_data *set_data; + + cbdata = cb_data; + set_data = backend_data; + + if (slapi_sdn_scope_test(cbdata->target_dn, + set_data->container_sdn, + cbdata->scope) == 1) { + cbdata->answer = TRUE; + } + + if (slapi_sdn_compare(set_data->container_sdn, + cbdata->target_dn) == 0) { + cbdata->answer = TRUE; + } + + return TRUE; + +} + +static bool_t +backend_search_find_set_dn_cb(const char *group, void *cb_data) +{ + struct backend_search_cbdata *cbdata; + + cbdata = cb_data; + map_data_foreach_map(cbdata->state, group, + backend_search_find_set_dn_in_group_cb, cb_data); + return TRUE; +} + +/* Routines to find out the set that has the same group as requested */ static bool_t backend_search_find_set_data_in_group_cb(const char *group, const char *set, bool_t flag, void *backend_data, void *cb_data) @@ -1340,9 +1378,6 @@ backend_search_cb(Slapi_PBlock *pb) "searching from \"%s\" for \"%s\" with scope %d%s\n", cbdata.target, cbdata.strfilter, cbdata.scope, backend_sch_scope_as_string(cbdata.scope)); -#ifdef USE_IPA_IDVIEWS - idview_replace_target_dn(&cbdata.target, &cbdata.idview); -#endif cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); /* Check if there's a backend handling this search. */ if (!slapi_be_exist(cbdata.target_dn)) { @@ -1351,19 +1386,47 @@ backend_search_cb(Slapi_PBlock *pb) "slapi_be_exists(\"%s\") = 0, " "ignoring search\n", cbdata.target); slapi_sdn_free(&cbdata.target_dn); + return 0; + } + +#ifdef USE_IPA_IDVIEWS + /* We may have multiple disjoint trees in the sets, search if the target matches any of them + * as in general there don't have to be a single subtree (cn=compat,$SUFFIX) for all trees to easily + * detect the ID view use. Unless the ID view is within the set we control, don't consider the override */ + map_data_foreach_domain(cbdata.state, backend_search_find_set_dn_cb, &cbdata); + if (cbdata.answer == FALSE) { + idview_replace_target_dn(&cbdata.target, &cbdata.idview); if (cbdata.idview != NULL) { - slapi_ch_free_string(&cbdata.target); + slapi_sdn_free(&cbdata.target_dn); + /* Perform another check, now for rewritten DN */ + cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); + map_data_foreach_domain(cbdata.state, backend_search_find_set_dn_cb, &cbdata); + /* Rewritten DN might still be outside of our trees */ + if (cbdata.answer == TRUE) { + slapi_log_error(SLAPI_LOG_PLUGIN, cbdata.state->plugin_desc->spd_id, + "Use of ID view '%s' is detected, searching from \"%s\" " + "for \"%s\" with scope %d%s. Filter may get overridden later.\n", + cbdata.idview, cbdata.target, cbdata.strfilter, cbdata.scope, + backend_sch_scope_as_string(cbdata.scope)); + } else { + slapi_sdn_free(&cbdata.target_dn); + slapi_ch_free_string(&cbdata.target); + slapi_ch_free_string(&cbdata.idview); + slapi_log_error(SLAPI_LOG_PLUGIN, + cbdata.state->plugin_desc->spd_id, + "The search base didn't match any of the containers, " + "ignoring search\n"); + return 0; + } } - slapi_ch_free_string(&cbdata.idview); -#ifdef USE_IPA_IDVIEWS - idview_free_overrides(&cbdata); -#endif - return 0; } + cbdata.answer = FALSE; +#endif /* Walk the list of groups. */ wrap_inc_call_level(); #ifdef USE_IPA_IDVIEWS + /* Filter replacement requires increased call level as we may fetch overrides and thus come back here */ idview_replace_filter(&cbdata); #endif if (map_rdlock() == 0) { -- 2.1.0 -------------- next part -------------- From 5f5f302e97560b05b154473f562410733e0b775b Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 28 Oct 2014 11:16:50 +0200 Subject: [PATCH 2/2] schema-compat: support ID overrides in bind callback If RDN of the bind DN is overridden within the ID view, rewrite the target to use original value of the uid attribute. If original uid attribute is not available, fail the search and thus the whole bind request by claiming that bind DN does not exist. --- src/back-sch-idview.c | 86 ++++++++++++++++++++++++++++++++++----------------- src/back-sch.c | 57 +++++++++++++++++++++++++++++----- src/back-sch.h | 4 +++ 3 files changed, 111 insertions(+), 36 deletions(-) diff --git a/src/back-sch-idview.c b/src/back-sch-idview.c index a56a9e9..f1150cd 100644 --- a/src/back-sch-idview.c +++ b/src/back-sch-idview.c @@ -290,21 +290,15 @@ idview_replace_target_dn(char **target, char **idview) } } -static int -idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct berval *bval, struct backend_search_filter_config *config) +int +idview_replace_bval_by_override(const char *bval_usage, const char *attr_name, + struct berval *bval, struct backend_search_cbdata *cbdata) { int res, i; - Slapi_Value *filter_val, *value, *anchor_val; + Slapi_Value *attr_val, *value, *anchor_val; Slapi_Attr *anchor, *attr = NULL; - struct backend_search_cbdata *cbdata = (struct backend_search_cbdata *) config->callback_data; - - if (cbdata == NULL || cbdata->idview == NULL) { - return SLAPI_FILTER_SCAN_CONTINUE; - } - - if (filter_type == NULL || config->name == NULL) { - return SLAPI_FILTER_SCAN_CONTINUE; - } + bool_t uid_override_found = FALSE; + bool_t anchor_override_found = FALSE; if (cbdata->overrides == NULL) { /* Only retrieve overrides for the view first time when neccessary */ @@ -312,31 +306,34 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b } if (cbdata->overrides == NULL) { - return SLAPI_FILTER_SCAN_CONTINUE; + return 0; } - filter_val = slapi_value_new_berval(bval); + attr_val = slapi_value_new_berval(bval); + slapi_log_error(SLAPI_LOG_FATAL, cbdata->state->plugin_desc->spd_id, + "Searching for an override of the %s %s with %s=%*s from the overrides\n.", + bval_usage, attr_name, attr_name, (int) bval->bv_len, bval->bv_val); /* If filter contains an attribute name which is overridden in the view and filter value * corresponds to the override, replace the filter by (ipaAnchorUUID=...) from the override * to point to the original because otherwise an entry will not be found in the slapi-nis map */ for(i=0; cbdata->overrides[i] != NULL; i++) { - res = slapi_entry_attr_find(cbdata->overrides[i], filter_type, &attr); + res = slapi_entry_attr_find(cbdata->overrides[i], attr_name, &attr); if ((res == 0) && (attr != NULL)) { res = slapi_attr_first_value(attr, &value); - res = slapi_value_compare(attr, value, filter_val); + res = slapi_value_compare(attr, value, attr_val); if (res == 0) { /* For uid overrides we should have ipaOriginalUID in the override */ - if (strcasecmp(filter_type, "uid") == 0) { + if (strcasecmp(attr_name, "uid") == 0) { res = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ORIGINALUID, &anchor); if (res == 0) { res = slapi_attr_first_value(anchor, &anchor_val); slapi_ber_bvdone(bval); slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); - config->override_found = TRUE; - slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, - "Overriding the filter %s with %s=%*s from the override %s\n.", - filter_type, filter_type, bval->bv_len, bval->bv_val, + uid_override_found = TRUE; + slapi_log_error(SLAPI_LOG_FATAL, cbdata->state->plugin_desc->spd_id, + "Overriding the %s %s with %s=%*s from the override %s\n.", + bval_usage, attr_name, attr_name, (int) bval->bv_len, bval->bv_val, slapi_entry_get_dn_const(cbdata->overrides[i])); break; } @@ -346,14 +343,13 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b res = slapi_entry_attr_find(cbdata->overrides[i], IPA_IDVIEWS_ATTR_ANCHORUUID, &anchor); if (res == 0) { res = slapi_attr_first_value(anchor, &anchor_val); - slapi_filter_changetype(filter, IPA_IDVIEWS_ATTR_ANCHORUUID); slapi_ber_bvdone(bval); slapi_ber_bvcpy(bval, slapi_value_get_berval(anchor_val)); - config->override_found = TRUE; - slapi_log_error(SLAPI_LOG_PLUGIN, cbdata->state->plugin_desc->spd_id, - "Overriding the filter %s with %s=%*s from the override %s\n.", - filter_type, IPA_IDVIEWS_ATTR_ANCHORUUID, - bval->bv_len, bval->bv_val, + anchor_override_found = TRUE; + slapi_log_error(SLAPI_LOG_FATAL, cbdata->state->plugin_desc->spd_id, + "Overriding the %s %s with %s=%*s from the override %s\n.", + bval_usage, attr_name, IPA_IDVIEWS_ATTR_ANCHORUUID, + (int) bval->bv_len, bval->bv_val, slapi_entry_get_dn_const(cbdata->overrides[i])); break; } @@ -362,7 +358,41 @@ idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, struct b } } - slapi_value_free(&filter_val); + slapi_value_free(&attr_val); + + if (uid_override_found) { + return 1; + } + + if (anchor_override_found) { + return 2; + } + + return 0; +} + +static int +idview_process_filter_cb(Slapi_Filter *filter, const char *filter_type, + struct berval *bval, struct backend_search_filter_config *config) +{ + int res; + struct backend_search_cbdata *cbdata = (struct backend_search_cbdata *) config->callback_data; + + if (cbdata == NULL || cbdata->idview == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + if (filter_type == NULL || config->name == NULL) { + return SLAPI_FILTER_SCAN_CONTINUE; + } + + res = idview_replace_bval_by_override("filter", filter_type, bval, cbdata); + + if (res == 2) { + slapi_filter_changetype(filter, IPA_IDVIEWS_ATTR_ANCHORUUID); + } + + config->override_found = (res != 0); return SLAPI_FILTER_SCAN_CONTINUE; diff --git a/src/back-sch.c b/src/back-sch.c index 27ac24f..2388d2f 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -1631,7 +1631,6 @@ static void backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char **group, const char**set) { struct backend_locate_cbdata cbdata; - char *idview = NULL; slapi_pblock_get(pb, SLAPI_PLUGIN_PRIVATE, &cbdata.state); if (cbdata.state->plugin_base == NULL) { @@ -1640,22 +1639,64 @@ backend_locate(Slapi_PBlock *pb, struct backend_entry_data **data, const char ** return; } slapi_pblock_get(pb, SLAPI_TARGET_DN, &cbdata.target); -#ifdef USE_IPA_IDVIEWS - idview_replace_target_dn(&cbdata.target, &idview); -#endif + cbdata.target_dn = slapi_sdn_new_dn_byval(cbdata.target); cbdata.entry_data = NULL; cbdata.entry_group = NULL; cbdata.entry_set = NULL; map_data_foreach_map(cbdata.state, NULL, backend_locate_cb, &cbdata); +#ifdef USE_IPA_IDVIEWS + /* In case nothing was found but we are operating on the ID override, + * rebuild the target's RDN to use original attribute's value */ + if (cbdata.entry_data == NULL) { + char *idview = NULL; + char *target, *original_target; + target = original_target = slapi_ch_strdup(cbdata.target); + idview_replace_target_dn(&target, &idview); + if (target != original_target) { + slapi_ch_free_string(&original_target); + } + if (idview != NULL) { + char *rdnstr; + char *val; + struct berval bval; + int res; + struct backend_search_cbdata scbdata; + Slapi_RDN *rdn = slapi_rdn_new_all_dn(target); + if (rdn != NULL) { + res = slapi_rdn_get_first(rdn, &rdnstr, &val); + if (res == 1) { + bval.bv_len = strlen(val) + 1; + bval.bv_val = slapi_ch_strdup(val); + memset(&scbdata, 0, sizeof(scbdata)); + scbdata.idview = idview; + scbdata.target = target; + scbdata.pb = pb; + scbdata.state = cbdata.state; + scbdata.target_dn = slapi_sdn_new_dn_byval(target); + res = idview_replace_bval_by_override("rdn", rdnstr, &bval, &scbdata); + /* only accept uid overrides */ + if (res == 1) { + slapi_rdn_remove_index(rdn, 1); + slapi_rdn_add(rdn, "uid", bval.bv_val); + slapi_sdn_free(&cbdata.target_dn); + cbdata.target_dn = slapi_sdn_set_rdn(scbdata.target_dn, rdn); + map_data_foreach_map(cbdata.state, NULL, backend_locate_cb, &cbdata); + } + slapi_ber_bvdone(&bval); + slapi_rdn_free(&rdn); + idview_free_overrides(&scbdata); + } + } + } + slapi_ch_free_string(&target); + slapi_ch_free_string(&idview); + } +#endif *data = cbdata.entry_data; *group = cbdata.entry_group; *set = cbdata.entry_set; slapi_sdn_free(&cbdata.target_dn); - if (idview != NULL) { - slapi_ch_free_string(&cbdata.target); - } - slapi_ch_free_string(&idview); } /* Check if the target DN is part of this group's tree. If it is, return an diff --git a/src/back-sch.h b/src/back-sch.h index 9f0b201..26e12d1 100644 --- a/src/back-sch.h +++ b/src/back-sch.h @@ -131,6 +131,10 @@ void idview_process_overrides(struct backend_search_cbdata *cbdata, Slapi_Entry *entry); void idview_replace_target_dn(char **target, char **idview); void idview_replace_filter(struct backend_search_cbdata *cbdata); +/* Takes struct berval value of an attribute attr_name and replaces it with an override + * Returns 0 if no override was found, 1 for 'uid' replacement, 2 for ipaAnchorUUID replacement */ +int idview_replace_bval_by_override(const char *bval_usage, const char *attr_name, + struct berval *bval, struct backend_search_cbdata *cbdata); #endif #endif -- 2.1.0 From dkupka at redhat.com Wed Oct 29 13:34:37 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 29 Oct 2014 14:34:37 +0100 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <544A4EA4.40908@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> <544A4EA4.40908@redhat.com> Message-ID: <5450ECED.2060208@redhat.com> On 10/24/2014 03:05 PM, David Kupka wrote: > On 10/24/2014 01:06 PM, David Kupka wrote: >> On 10/24/2014 10:43 AM, Martin Basti wrote: >>> On 24/10/14 09:51, David Kupka wrote: >>>> https://fedorahosted.org/freeipa/ticket/4585 >>> NACK >>> >>> 1) >>> Why is there line with 'DS System User?' The comment should depend on >>> service. >>> >>> + args = [ >>> + paths.USERADD, >>> + '-g', group, >>> + '-c', 'DS System User', >>> + '-d', homedir, >>> + '-s', shell, >>> + '-M', '-r', name, >>> + ] >> >> This was part of the original code and I didn't notice it. Nice catch, >> thanks. >> >>> >>> 2) >>> code create_system_user is duplicated between base and redhat tasks with >>> platform dependent changes. >>> IMO it would be better to have one method to create user, with keyword >>> arguments. And then platform dependent method which will call method to >>> create user with appropriate arguments (or with default arguments) >>> >> >> You're right it was ugly. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > I shouldn't break SOLID principles. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Using super is probably better that explicit naming of parent class. Let user (developer) override UID/GID and hope that he knows why ... -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0025-4-Respect-UID-and-GID-soft-static-allocation.patch Type: text/x-patch Size: 7101 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 29 13:34:57 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 29 Oct 2014 09:34:57 -0400 Subject: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable In-Reply-To: <5450CDB7.4070207@redhat.com> References: <1414102026.4610.6.camel@redhat.com> <1414529956.16650.3.camel@redhat.com> <5450B561.6080505@redhat.com> <5450CDB7.4070207@redhat.com> Message-ID: <1414589697.16650.4.camel@redhat.com> On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote: > On 10/29/2014 10:37 AM, Martin Kosek wrote: > > On 10/28/2014 09:59 PM, Nathaniel McCallum wrote: > >> On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote: > >>> This patch gives the administrator variables to control the size of > >>> the authentication and synchronization windows for OTP tokens. > >>> > >>> https://fedorahosted.org/freeipa/ticket/4511 > >>> > >>> NOTE: There is one known issue with this patch which I don't know how to > >>> solve. This patch changes the schema in install/share/60ipaconfig.ldif. > >>> On an upgrade, all of the new attributeTypes appear correctly. However, > >>> the modifications to the pre-existing objectClass do not show up on the > >>> server. What am I doing wrong? > >>> > >>> After modifying ipaGuiConfig manually, everything in this patch works > >>> just fine. > >> > >> This new version takes into account the new (proper) OIDs and attribute > >> names. > > > > Thanks Nathaniel! > > > >> The above known issue still remains. > > > > Petr3, any idea what could have gone wrong? ObjectClass MAY list extension > > should work just fine, AFAIK. > > You added a blank line to the LDIF file. This is an entry separator, so > the objectClasses after the blank line don't belong to cn=schema, so > they aren't considered in the update. > Without the blank line it works fine. Thanks for the catch! Here is a version without the blank line. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0074.2-Make-token-window-sizes-configurable.patch Type: text/x-patch Size: 37774 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 29 14:02:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 29 Oct 2014 15:02:54 +0100 Subject: [Freeipa-devel] [PATCH 0020] Fix zone name to directory name conversion in BINDMgr In-Reply-To: <5450E527.9030501@redhat.com> References: <5448F17D.9080702@redhat.com> <54490627.1070208@redhat.com> <5450E527.9030501@redhat.com> Message-ID: <5450F38E.9020105@redhat.com> On 10/29/2014 02:01 PM, Martin Basti wrote: > On 23/10/14 15:44, Martin Basti wrote: >> On 23/10/14 14:15, Petr Spacek wrote: >>> Hello, >>> >>> Fix zone name to directory name conversion in BINDMgr. >>> >>> https://fedorahosted.org/freeipa/ticket/4657 >>> >> ACK, signing the root zone works fine now >> > The patch is ready to be pushed. > Pushed to: master: ac500003fda7142c4c0bb27cd5d1e5aea105f777 ipa-4-1: 4e42d171300114bffc62ac12bbe1c00f7c8f4518 -- Petr? From pviktori at redhat.com Wed Oct 29 14:06:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 29 Oct 2014 15:06:28 +0100 Subject: [Freeipa-devel] [PATCH] 333 Handle profile changes in dogtag-ipa-ca-renew-agent In-Reply-To: <5450D179.1050206@redhat.com> References: <543CE460.7070006@redhat.com> <5450D179.1050206@redhat.com> Message-ID: <5450F464.50305@redhat.com> On 10/29/2014 12:37 PM, David Kupka wrote: > On 10/14/2014 10:52 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> (The original patch was posted at >> .) >> >> >> >> How to test: >> >> 1. install server >> >> 2. run "ipa-certupdate" >> >> 3. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert >> cert-pki-ca'", the request should be in CA_WORKING state >> >> 4. run "ipa-cacert-manage renew" >> >> 5. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert >> cert-pki-ca'", the request should be in MONITORING state, there should >> be no ca-error >> >> Honza >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Works for me, ACK. Pushed to: master: a649a84a1bd7eb3c727fdcfc341b326a19b0ee5a ipa-4-1: 2ee248bd7efc3559d4420751f8ee34b270b36b49 -- Petr? From tbordaz at redhat.com Wed Oct 29 14:20:20 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 29 Oct 2014 15:20:20 +0100 Subject: [Freeipa-devel] [PATCH, slapi-nis] ID view-related patches to slapi-nis In-Reply-To: <20141029132335.GA5100@redhat.com> References: <20141028211136.GL26496@redhat.com> <5450DA21.6000009@redhat.com> <20141029132335.GA5100@redhat.com> Message-ID: <5450F7A4.7030202@redhat.com> On 10/29/2014 02:23 PM, Alexander Bokovoy wrote: > On Wed, 29 Oct 2014, thierry bordaz wrote: >> The patches fixed the test case in >> https://bugzilla.redhat.com/show_bug.cgi?id=1157989. >> Few comments regarding the patch: >> >> * in backend_search_cb, it checks if the search is in one of the >> container. We need that cbdata.answer=FALSE at the end of the >> checking. >> Why not setting it systematically at the end. > I've moved it to the end of the block. > >> * in backend_locate, 'target' is a duplicate of cbdata.target. But >> then when calling idview_replace_target_dn it may be changed. >> Will not it lead to a leak ? > Good catch, thanks! > > Fixed version attached. > Hi Alexander, The patches are good to me. Ack thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 29 14:29:13 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 29 Oct 2014 15:29:13 +0100 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <5450ECED.2060208@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> <544A4EA4.40908@redhat.com> <5450ECED.2060208@redhat.com> Message-ID: <5450F9B9.2000402@redhat.com> On 29/10/14 14:34, David Kupka wrote: > On 10/24/2014 03:05 PM, David Kupka wrote: >> On 10/24/2014 01:06 PM, David Kupka wrote: >>> On 10/24/2014 10:43 AM, Martin Basti wrote: >>>> On 24/10/14 09:51, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4585 >>>> NACK >>>> >>>> 1) >>>> Why is there line with 'DS System User?' The comment should depend on >>>> service. >>>> >>>> + args = [ >>>> + paths.USERADD, >>>> + '-g', group, >>>> + '-c', 'DS System User', >>>> + '-d', homedir, >>>> + '-s', shell, >>>> + '-M', '-r', name, >>>> + ] >>> >>> This was part of the original code and I didn't notice it. Nice catch, >>> thanks. >>> >>>> >>>> 2) >>>> code create_system_user is duplicated between base and redhat tasks >>>> with >>>> platform dependent changes. >>>> IMO it would be better to have one method to create user, with keyword >>>> arguments. And then platform dependent method which will call >>>> method to >>>> create user with appropriate arguments (or with default arguments) >>>> >>> >>> You're right it was ugly. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> I shouldn't break SOLID principles. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Using super is probably better that explicit naming of parent class. > Let user (developer) override UID/GID and hope that he knows why ... NACK 2014-10-29T02:28:02Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 642, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 1143, in main dsinstance.create_ds_user() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 159, in create_ds_user shell=paths.NOLOGIN, File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/tasks.py", line 415, in create_system_user homedir, shell, uid, gid, comment) 2014-10-29T02:28:02Z DEBUG The ipa-server-install command failed, exception: TypeError: create_system_user() takes at most 8 arguments (9 given) -- Martin Basti From dkupka at redhat.com Wed Oct 29 14:29:46 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 29 Oct 2014 15:29:46 +0100 Subject: [Freeipa-devel] [PATCH] 334 Do not wait for new CA certificate to appear in LDAP in ipa-certupdate In-Reply-To: <543E86D7.50208@redhat.com> References: <543E86D7.50208@redhat.com> Message-ID: <5450F9DA.6020103@redhat.com> On 10/15/2014 04:38 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > It depends on my patch 333, which is also attached. > > (The original patch was posted at > .) > > > How to test: > > 1. install server > > 2. run "ipa-certupdate" > > 3. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert > cert-pki-ca'", the request should be in MONITORING state, there should > be no ca-error > > Honza > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > Works for me, ACK. Note: Push only freeipa-jcholast-334 patch, patch freeipa-jcholast-333 was already ACKed and pushed. -- David Kupka From pviktori at redhat.com Wed Oct 29 14:33:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 29 Oct 2014 15:33:17 +0100 Subject: [Freeipa-devel] [PATCHES] 0661-0672 Switch the test suite to pytest In-Reply-To: <5450DC23.4090907@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> Message-ID: <5450FAAD.9080802@redhat.com> On 10/29/2014 01:22 PM, Tomas Babej wrote: > > On 10/27/2014 04:38 PM, Petr Viktorin wrote: >> On 10/15/2014 02:58 PM, Petr Viktorin wrote: >>> This almost completes the switch to pytest. There are two missing >>> things: >>> - the details of test results (--with-xunit) are not read correctly by >>> Jenkins. I have a theory I'm investigating here. >>> - the beakerlib integration is still not ready >>> >>> >>> I'll not be available for the rest of the week so I'm sending this >>> early, in case someone wants to take a look. >> >> I've updated (and rearranged) the patches after some more testing. >> Both points above are fixed. Individual plugins are broken out; some >> would be nice to even release independently of IPA. (There is some >> demand for the BeakerLib plugin; for that I'd only need to break the >> dependency on ipa_log_manager.) >> >> >> These depend on my patches 0656-0660. >> > Thanks for this effort! > > #### Patch 0656: tests: Use PEP8-compliant setup/teardown method names > > There are some references to the old names in the test_ipapython and > test_install: > > [tbabej at thinkpad7 ipatests]$ git grep setUpClass > [tbabej at thinkpad7 ipatests]$ git grep tearDownClass > [tbabej at thinkpad7 ipatests]$ git grep setUp > test_install/test_updates.py: def setUp(self): > test_ipapython/test_cookie.py: def setUp(self): > test_ipapython/test_cookie.py: def setUp(self): > test_ipapython/test_cookie.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > [tbabej at thinkpad7 ipatests]$ git grep tearDown > test_install/test_updates.py: def tearDown(self): These are in unittest.testCase. It would be nice to convert those as well, but that's for a larger cleanup. > #### Patch 0657: tests: Add configuration for pytest > > Shouldn't we rather change the class names? Ideally yes, but I don't think renaming most of our test classes would be worth the benefit. > #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in > get_subcls > > ACK. > > #### Patch 0659: test_automount_plugin: Fix test ordering > > ACK. > > #### PATCH 0660: Use setup_class/teardown_class in Declarative tests > > --- a/ipatests/test_ipaserver/test_changepw.py > +++ b/ipatests/test_ipaserver/test_changepw.py > @@ -33,8 +33,7 @@ > class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): > app_uri = '/ipa/session/change_password' > > - def setup(self): > - super(test_changepw, self).setup() > + def setup(cls): > try: > api.Command['user_add'](uid=testuser, > givenname=u'Test', sn=u'User') > api.Command['passwd'](testuser, password=u'old_password') > @@ -43,12 +42,11 @@ def setup(self): > 'Cannot set up test user: %s' % e > ) > > - def teardown(self): > + def teardown(cls): > try: > api.Command['user_del']([testuser]) > except errors.NotFound: > pass > - super(test_changepw, self).teardown() > > The setup/teardown methods are not classmethods, so the name of the > first argument should remain "self". Oops, thanks for the catch! > #### PATCH 0661: dogtag plugin: Don't use doctest syntax for non-doctest > examples > > ACK. > > #### PATCH 0662: test_webui: Don't use __init__ for test classes > > I don't think the following change will work: > > - def __init__(self, driver=None, config=None): > + def setup(self, driver=None, config=None): > self.request_timeout = 30 > self.driver = driver > self.config = config > if not config: > self.load_config() > + self.get_driver().maximize_window() > + > + def teardown(self): > + self.driver.quit() > > def load_config(self): > """ > @@ -161,20 +165,6 @@ def load_config(self): > if 'type' not in c: > c['type'] = DEFAULT_TYPE > > - def setup(self): > - """ > - Test setup > - """ > - if not self.driver: > - self.driver = self.get_driver() > - self.driver.maximize_window() > - > - def teardown(self): > - """ > - Test clean up > - """ > - self.driver.quit() > > > The setup(self) method used to set the self.driver attribute on the > class instance, now nothing sets it. The setup method should do: > > def setup(self, driver=None, config=None): > self.request_timeout = 30 > self.driver = driver > self.config = config > if not config: > self.load_config() > if not self.driver: > self.driver = self.get_driver() > self.driver.maximize_window() > > However, I would prefer having self.driver as a cached property. Well, ideally these would be fixtures. Thanks for the catch. > #### PATCH 0663: test_ipapython: Use functions instead of classes in > test generators > > ACK. > > #### PATCH 0664: Configure pytest to run doctests > > ACK. > > #### PATCH 0665: Declarative tests: Move cleanup to > setup_class/teardown_class > > You should also remove the now redundant cleanup_generate method. Right, removed. > Also: Do we really want to print out error.NotFound or > errors.EmptyModList exceptions produced by cleanup commands? It's just one line, might help debugging. It should only show up on failures. > #### PATCH 0666: Declarative tests: Switch to pytest > > Nitpitck: declarative.py has wrong year in the copyright header. > Otherwise ACK. Fixed. > #### PATCH 0667: Integration tests: Port the ordering plugin to pytest > > Specfile change belongs to the previous patch, but I doubt these would > be separated, so not worth spending the time IMHO. > > Why does TestIPACommands have ordered decorator applied? It is applied > on IntegrationTest directly, from which CALessBase inherits from. I > don't think it's necessary (unless I'm missing something), so we should > rather remove the occurence of the decorator in the test_caless.py than > fixing the import. > > #### PATCH 0668: Switch make-test to pytest > > Nice simplification. However, make-test does not work for me: > > I'm getting tons of errors (during the collection) along the lines of: > > ________________ ERROR collecting ipatests/test_xmlrpc/testcert.py > _________________ > /usr/lib/python2.7/site-packages/py/_path/local.py:661: in pyimport > raise self.ImportMismatchError(modname, modfile, self) > E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', > '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', > local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) > _______________ ERROR collecting > ipatests/test_xmlrpc/xmlrpc_test.py _______________ > /usr/lib/python2.7/site-packages/py/_path/local.py:661: in pyimport > raise self.ImportMismatchError(modname, modfile, self) > E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', > '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', > local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) > _______________ ERROR collecting > ipatests/test_xmlrpc/xmlrpc_test.py _______________ > import file mismatch: > imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this > __file__ attribute: > /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py > which is not the same as the test file we want to collect: > /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py > HINT: remove __pycache__ / .pyc files and/or use a unique basename > for your test file modules > ================ 163 passed, 7 skipped, 679 error in 48.14 seconds > ============== > > > I am running this as ./make-test from the directory containing the > freeipa sources. The ipa-run-tests command seems to work fine though. > > #### PATCH 0669: Add local pytest plugin for --with-xunit and > --logging-level > > ACK. > > #### PATCH 0670: Switch ipa-run-tests to pytest > > ACK. > > #### PATCH 0671: Switch integration testing config to a fixture > > ACK. > > #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log > collection to pytest > > I didn't see any glitches, but I haven't tested this one out yet > functionally. > > ### General notes > > I did two IPA master installs today, one with your patches applied. > There were significant differences in the number of successfully passing > tests: > > nose: FAILED (SKIP=60, errors=46, failures=14) > pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in > 860.47 seconds ========= > > Did you not encounter this in your testing? I will look more deeply into > the failures themselves. > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > -- Petr? From pviktori at redhat.com Wed Oct 29 14:34:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 29 Oct 2014 15:34:01 +0100 Subject: [Freeipa-devel] [PATCHES] 0661-0672 Switch the test suite to pytest In-Reply-To: <5450FAAD.9080802@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> <5450FAAD.9080802@redhat.com> Message-ID: <5450FAD9.4040104@redhat.com> Please ignore the previous mail, I hit Send my mistake. -- Petr? From pviktori at redhat.com Wed Oct 29 15:52:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 29 Oct 2014 16:52:09 +0100 Subject: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest In-Reply-To: <5450DC23.4090907@redhat.com> References: <543E6F82.7090309@redhat.com> <544E66E8.6010903@redhat.com> <5450DC23.4090907@redhat.com> Message-ID: <54510D29.1020804@redhat.com> On 10/29/2014 01:22 PM, Tomas Babej wrote: > > On 10/27/2014 04:38 PM, Petr Viktorin wrote: >> On 10/15/2014 02:58 PM, Petr Viktorin wrote: >>> This almost completes the switch to pytest. There are two missing >>> things: >>> - the details of test results (--with-xunit) are not read correctly by >>> Jenkins. I have a theory I'm investigating here. >>> - the beakerlib integration is still not ready >>> >>> >>> I'll not be available for the rest of the week so I'm sending this >>> early, in case someone wants to take a look. >> >> I've updated (and rearranged) the patches after some more testing. >> Both points above are fixed. Individual plugins are broken out; some >> would be nice to even release independently of IPA. (There is some >> demand for the BeakerLib plugin; for that I'd only need to break the >> dependency on ipa_log_manager.) >> >> >> These depend on my patches 0656-0660. >> > Thanks for this effort! > > #### Patch 0656: tests: Use PEP8-compliant setup/teardown method names > > There are some references to the old names in the test_ipapython and > test_install: > > [tbabej at thinkpad7 ipatests]$ git grep setUpClass > [tbabej at thinkpad7 ipatests]$ git grep tearDownClass > [tbabej at thinkpad7 ipatests]$ git grep setUp > test_install/test_updates.py: def setUp(self): > test_ipapython/test_cookie.py: def setUp(self): > test_ipapython/test_cookie.py: def setUp(self): > test_ipapython/test_cookie.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > test_ipapython/test_dn.py: def setUp(self): > [tbabej at thinkpad7 ipatests]$ git grep tearDown > test_install/test_updates.py: def tearDown(self): These are in unittest.testCase. It would be nice to convert those as well, but that's for a larger cleanup. > #### Patch 0657: tests: Add configuration for pytest > > Shouldn't we rather change the class names? Ideally yes, but I don't think renaming most of our test classes would be worth the benefit. > #### Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in > get_subcls > > ACK. > > #### Patch 0659: test_automount_plugin: Fix test ordering > > ACK. > > #### PATCH 0660: Use setup_class/teardown_class in Declarative tests > > --- a/ipatests/test_ipaserver/test_changepw.py > +++ b/ipatests/test_ipaserver/test_changepw.py > @@ -33,8 +33,7 @@ > class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): > app_uri = '/ipa/session/change_password' > > - def setup(self): > - super(test_changepw, self).setup() > + def setup(cls): > try: > api.Command['user_add'](uid=testuser, > givenname=u'Test', sn=u'User') > api.Command['passwd'](testuser, password=u'old_password') > @@ -43,12 +42,11 @@ def setup(self): > 'Cannot set up test user: %s' % e > ) > > - def teardown(self): > + def teardown(cls): > try: > api.Command['user_del']([testuser]) > except errors.NotFound: > pass > - super(test_changepw, self).teardown() > > The setup/teardown methods are not classmethods, so the name of the > first argument should remain "self". Oops, thanks for the catch! > #### PATCH 0661: dogtag plugin: Don't use doctest syntax for non-doctest > examples > > ACK. > > #### PATCH 0662: test_webui: Don't use __init__ for test classes > > I don't think the following change will work: > > - def __init__(self, driver=None, config=None): > + def setup(self, driver=None, config=None): > self.request_timeout = 30 > self.driver = driver > self.config = config > if not config: > self.load_config() > + self.get_driver().maximize_window() > + > + def teardown(self): > + self.driver.quit() > > def load_config(self): > """ > @@ -161,20 +165,6 @@ def load_config(self): > if 'type' not in c: > c['type'] = DEFAULT_TYPE > > - def setup(self): > - """ > - Test setup > - """ > - if not self.driver: > - self.driver = self.get_driver() > - self.driver.maximize_window() > - > - def teardown(self): > - """ > - Test clean up > - """ > - self.driver.quit() > > > The setup(self) method used to set the self.driver attribute on the > class instance, now nothing sets it. The setup method should do: > > def setup(self, driver=None, config=None): > self.request_timeout = 30 > self.driver = driver > self.config = config > if not config: > self.load_config() > if not self.driver: > self.driver = self.get_driver() > self.driver.maximize_window() > > However, I would prefer having self.driver as a cached property. Well, ideally these would be fixtures. Thanks for the catch. > #### PATCH 0663: test_ipapython: Use functions instead of classes in > test generators > > ACK. > > #### PATCH 0664: Configure pytest to run doctests > > ACK. > > #### PATCH 0665: Declarative tests: Move cleanup to > setup_class/teardown_class > > You should also remove the now redundant cleanup_generate method. Right, removed. > Also: Do we really want to print out error.NotFound or > errors.EmptyModList exceptions produced by cleanup commands? It's just one line, might help debugging. It should only show up on failures. > #### PATCH 0666: Declarative tests: Switch to pytest > > Nitpitck: declarative.py has wrong year in the copyright header. > Otherwise ACK. Fixed. > #### PATCH 0667: Integration tests: Port the ordering plugin to pytest > > Specfile change belongs to the previous patch, but I doubt these would > be separated, so not worth spending the time IMHO. Also, the previous patch doesn't actually import pytest. But a lot of these patches break tests by themselves, so they shouldn't be separated. > Why does TestIPACommands have ordered decorator applied? It is applied > on IntegrationTest directly, from which CALessBase inherits from. I > don't think it's necessary (unless I'm missing something), so we should > rather remove the occurence of the decorator in the test_caless.py than > fixing the import. Actually, I think only only the classes that actually need it should have the decorator. Again, cleanup for a future time. > #### PATCH 0668: Switch make-test to pytest > > Nice simplification. However, make-test does not work for me: > > I'm getting tons of errors (during the collection) along the lines of: > > ________________ ERROR collecting ipatests/test_xmlrpc/testcert.py > _________________ > /usr/lib/python2.7/site-packages/py/_path/local.py:661: in pyimport > raise self.ImportMismatchError(modname, modfile, self) > E ImportMismatchError: ('ipatests.test_xmlrpc.testcert', > '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/testcert.py', > local('/ipadev/freeipa/ipatests/test_xmlrpc/testcert.py')) > _______________ ERROR collecting > ipatests/test_xmlrpc/xmlrpc_test.py _______________ > /usr/lib/python2.7/site-packages/py/_path/local.py:661: in pyimport > raise self.ImportMismatchError(modname, modfile, self) > E ImportMismatchError: ('ipatests.test_xmlrpc.xmlrpc_test', > '/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py', > local('/ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py')) > _______________ ERROR collecting > ipatests/test_xmlrpc/xmlrpc_test.py _______________ > import file mismatch: > imported module 'ipatests.test_xmlrpc.xmlrpc_test' has this > __file__ attribute: > /usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py > which is not the same as the test file we want to collect: > /ipadev/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py > HINT: remove __pycache__ / .pyc files and/or use a unique basename > for your test file modules > ================ 163 passed, 7 skipped, 679 error in 48.14 seconds > ============== > > > I am running this as ./make-test from the directory containing the > freeipa sources. The ipa-run-tests command seems to work fine though. Hm. Doesn't happen for me. Did you follow the hint (git clean -fxd)? I've added . to PYTHONPATH, that may help (and it should also help with plugin loading in some cases). > #### PATCH 0669: Add local pytest plugin for --with-xunit and > --logging-level > > ACK. > > #### PATCH 0670: Switch ipa-run-tests to pytest > > ACK. > > #### PATCH 0671: Switch integration testing config to a fixture > > ACK. > > #### PATCH 0672: Integration tests: Port the BeakerLib plugin and log > collection to pytest > > I didn't see any glitches, but I haven't tested this one out yet > functionally. > > ### General notes > > I did two IPA master installs today, one with your patches applied. > There were significant differences in the number of successfully passing > tests: > > nose: FAILED (SKIP=60, errors=46, failures=14) > pytest: ========= 42 failed, 1830 passed, 422 skipped, 340 error in > 860.47 seconds ========= > > Did you not encounter this in your testing? I will look more deeply into > the failures themselves. I did, but it was always some stupid mistake :) Do you have ~/.ipa set up, and $MASTER undefined? The integration test did fail for me now when they were not configured. I added an additional patch to fix that. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0656.3-tests-Use-PEP8-compliant-setup-teardown-method-names.patch Type: text/x-patch Size: 20247 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0657.3-tests-Add-configuration-for-pytest.patch Type: text/x-patch Size: 781 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0658.3-ipatests.util.ClassChecker-Raise-AttributeError-in-g.patch Type: text/x-patch Size: 878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0659.3-test_automount_plugin-Fix-test-ordering.patch Type: text/x-patch Size: 1605 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0660.3-Use-setup_class-teardown_class-in-Declarative-tests.patch Type: text/x-patch Size: 4907 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0661.3-dogtag-plugin-Don-t-use-doctest-syntax-for-non-docte.patch Type: text/x-patch Size: 2523 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0662.3-test_webui-Don-t-use-__init__-for-test-classes.patch Type: text/x-patch Size: 6780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0663.3-test_ipapython-Use-functions-instead-of-classes-in-t.patch Type: text/x-patch Size: 3192 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0664.3-Configure-pytest-to-run-doctests.patch Type: text/x-patch Size: 3135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0665.3-Declarative-tests-Move-cleanup-to-setup_class-teardo.patch Type: text/x-patch Size: 2829 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0666.3-Declarative-tests-Switch-to-pytest.patch Type: text/x-patch Size: 5130 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0667.3-Integration-tests-Port-the-ordering-plugin-to-pytest.patch Type: text/x-patch Size: 12864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0668.3-Switch-make-test-to-pytest.patch Type: text/x-patch Size: 2058 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0669.3-Add-local-pytest-plugin-for-with-xunit-and-logging-l.patch Type: text/x-patch Size: 4507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0670.3-Switch-ipa-run-tests-to-pytest.patch Type: text/x-patch Size: 3002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0671.3-Switch-integration-testing-config-to-a-fixture.patch Type: text/x-patch Size: 8108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0672.3-Integration-tests-Port-the-BeakerLib-plugin-and-log-.patch Type: text/x-patch Size: 30089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0673.3-test_integration-Adjust-tests-for-pytest.patch Type: text/x-patch Size: 5933 bytes Desc: not available URL: From dkupka at redhat.com Wed Oct 29 16:23:14 2014 From: dkupka at redhat.com (David Kupka) Date: Wed, 29 Oct 2014 17:23:14 +0100 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <5450ECED.2060208@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> <544A4EA4.40908@redhat.com> <5450ECED.2060208@redhat.com> Message-ID: <54511472.5010004@redhat.com> On 10/29/2014 02:34 PM, David Kupka wrote: > On 10/24/2014 03:05 PM, David Kupka wrote: >> On 10/24/2014 01:06 PM, David Kupka wrote: >>> On 10/24/2014 10:43 AM, Martin Basti wrote: >>>> On 24/10/14 09:51, David Kupka wrote: >>>>> https://fedorahosted.org/freeipa/ticket/4585 >>>> NACK >>>> >>>> 1) >>>> Why is there line with 'DS System User?' The comment should depend on >>>> service. >>>> >>>> + args = [ >>>> + paths.USERADD, >>>> + '-g', group, >>>> + '-c', 'DS System User', >>>> + '-d', homedir, >>>> + '-s', shell, >>>> + '-M', '-r', name, >>>> + ] >>> >>> This was part of the original code and I didn't notice it. Nice catch, >>> thanks. >>> >>>> >>>> 2) >>>> code create_system_user is duplicated between base and redhat tasks >>>> with >>>> platform dependent changes. >>>> IMO it would be better to have one method to create user, with keyword >>>> arguments. And then platform dependent method which will call >>>> method to >>>> create user with appropriate arguments (or with default arguments) >>>> >>> >>> You're right it was ugly. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> I shouldn't break SOLID principles. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Using super is probably better that explicit naming of parent class. > Let user (developer) override UID/GID and hope that he knows why ... > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-dkupka-0025-5-Respect-UID-and-GID-soft-static-allocation.patch Type: text/x-patch Size: 7171 bytes Desc: not available URL: From edewata at redhat.com Wed Oct 29 19:10:11 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 29 Oct 2014 14:10:11 -0500 Subject: [Freeipa-devel] [PATCH] 352 Fixed KRA backend. In-Reply-To: <5450E472.90903@redhat.com> References: <543F4294.1080001@redhat.com> <5447C07C.4000800@redhat.com> <5448C356.9040105@redhat.com> <54500FC5.7070207@redhat.com> <5450E472.90903@redhat.com> Message-ID: <54513B93.2020409@redhat.com> New patch attached. On 10/29/2014 7:58 AM, Petr Viktorin wrote: >> Dependency is bumped to 10.2.1-0.1 which is available from my >> COPR repo: >> >> dnf copr enable edewata/pki > > OK. We should get that to an IPA COPR before merging this. How do we do that? Here is the SRPM: https://edewata.fedorapeople.org/pki/copr/pki-core-10.2.1-0.1.fc20.src.rpm >>> ipaserver.plugins.dogtag.kra.get_client: >>> Should every caller check if this returns None? >>> If not, raise an exception instead. >>> If yes, at least mention it in a docstring. >> >> Fixed. It's now raising a generic exception. >> >> Is there an existing exception that is more appropriate for backend >> issues like this? > > I'd go for RuntimeError. Fixed. > Don't use translatable strings (the _ function) if you're not using > ipalib.PublicError subclasses. Fixed. > How can I do some basic smoke check on this? Is there something I still > need to to besides ipa-kra-istall? Any other patches? > I tried: > > from ipalib import api > from pki.key import KeyClient > api.bootstrap(context='server') > api.finalize() > keyclient = api.Backend.kra.get_client() > keyclient.keys.archive_key('test3', KeyClient.PASS_PHRASE_TYPE, 'tkey') > > which gives me: > > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.7/site-packages/pki/__init__.py", line 295, in > handler > return fn_call(inst, *args, **kwargs) > File "/usr/lib/python2.7/site-packages/pki/key.py", line 687, in > archive_key > nonce_iv = self.crypto.generate_nonce_iv() > File "/usr/lib/python2.7/site-packages/pki/crypto.py", line 176, in > generate_nonce_iv > iv_data = nss.generate_random(iv_length) > nss.error.NSPRError: (SEC_ERROR_NO_TOKEN) The security card or token > does not exist, needs to be initialized, or has been removed. The simplest test is probably this: from ipalib import api api.bootstrap(context='server') api.finalize() kra_client = api.Backend.kra.get_client() transport_cert = kra_client.system_certs.get_transport_cert() print "Serial number: %s" % transport_cert.serial_number print "Issuer DN: %s" % transport_cert.issuer_dn print "Subject DN: %s" % transport_cert.subject_dn print transport_cert.encoded If you want to test the key archival it would require installing a transport certificate and add some authentication operations. A better way to do that is to install patch #354-1, #353-3, #355-1, and #356-1 and test the vault-archive command. It will install the transport cert automatically and perform the required authentication. -- Endi S. Dewata -------------- next part -------------- >From 7b68ff1c93554975abd75e6d672ee18a7a0bcf04 Mon Sep 17 00:00:00 2001 From: "Endi S. Dewata" Date: Wed, 1 Oct 2014 14:59:46 -0400 Subject: [PATCH] Fixed KRA backend. The KRA backend has been simplified since most of the tasks have been moved somewhere else. The transport certificate will be installed on the client, and it is not needed by KRA backend. The KRA agent's PEM certificate is now generated during installation due to permission issue. The kra_host() for now is removed since the current ldap_enable() cannot register the KRA service, so it is using the kra_host environment variable. The KRA installer has been modified to use Dogtag's CLI to create KRA agent and setup the client authentication. The proxy settings have been updated to include KRA's URLs. Some constants have been renamed for clarity. The DOGTAG_AGENT_P12 has been renamed to DOGTAG_ADMIN_P12 since file actually contains the Dogtag admin's certificate and private key and it can be used to access both CA and KRA. The DOGTAG_AGENT_PEM has been renamed to KRA_AGENT_PEM since it can only be used for KRA. The Dogtag dependency has been updated to 10.2.1-0.1. https://fedorahosted.org/freeipa/ticket/4503 --- freeipa.spec.in | 4 +- install/conf/ipa-pki-proxy.conf | 2 +- ipaplatform/base/paths.py | 4 +- ipaserver/install/cainstance.py | 4 +- ipaserver/install/ipa_backup.py | 3 +- ipaserver/install/krainstance.py | 83 +++++++++++++++++++++++--- ipaserver/plugins/dogtag.py | 122 ++++++--------------------------------- 7 files changed, 101 insertions(+), 121 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 8fcb535e229db4f7a8eaaee3c99b18446eef7f1e..dc04be48b2bb52ff05f9fab371c4b333a15d24ca 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -130,8 +130,8 @@ Requires(post): systemd-units Requires: selinux-policy >= %{selinux_policy_version} Requires(post): selinux-policy-base Requires: slapi-nis >= 0.54-1 -Requires: pki-ca >= 10.2.0-3 -Requires: pki-kra >= 10.2.0 +Requires: pki-ca >= 10.2.1-0.1 +Requires: pki-kra >= 10.2.1-0.1 %if 0%{?rhel} Requires: subscription-manager %endif diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 2370b4d7a7467a7e47c0d223915e018c9a009e83..5d21156848f3b5ddf14c42d92a26a30a9f94af36 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -19,7 +19,7 @@ ProxyRequests Off # matches for agent port and eeca port - + NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://localhost:$DOGTAG_PORT diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index bbe6eed76ccb3c5f325fd368694ac6a2afbb72f0..01505594a7af926c860f867b817bd397c54efff5 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -138,8 +138,8 @@ class BasePathNamespace(object): HOME_DIR = "/home" ROOT_IPA_CACHE = "/root/.ipa_cache" ROOT_PKI = "/root/.pki" - DOGTAG_AGENT_P12 = "/root/ca-agent.p12" - DOGTAG_AGENT_PEM = "/etc/httpd/alias/agent.pem" + DOGTAG_ADMIN_P12 = "/root/ca-agent.p12" + KRA_AGENT_PEM = "/etc/httpd/alias/kra-agent.pem" CACERT_P12 = "/root/cacert.p12" ROOT_IPA_CSR = "/root/ipa.csr" ROOT_TMP_CA_P12 = "/root/tmp-ca.p12" diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 1ae39639ac9702651851e6c3964faa69788db31e..fe95201517a577b9f6dba7642afe09b4eef2328d 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -514,7 +514,7 @@ class CAInstance(DogtagInstance): config.set("CA", "pki_admin_nickname", "ipa-ca-agent") config.set("CA", "pki_admin_subject_dn", str(DN(('cn', 'ipa-ca-agent'), self.subject_base))) - config.set("CA", "pki_client_admin_cert_p12", paths.DOGTAG_AGENT_P12) + config.set("CA", "pki_client_admin_cert_p12", paths.DOGTAG_ADMIN_P12) # Directory server config.set("CA", "pki_ds_ldap_port", str(self.ds_port)) @@ -979,7 +979,7 @@ class CAInstance(DogtagInstance): try: ipautil.run([paths.PK12UTIL, "-n", "ipa-ca-agent", - "-o", paths.DOGTAG_AGENT_P12, + "-o", paths.DOGTAG_ADMIN_P12, "-d", self.agent_db, "-k", pwd_name, "-w", pwd_name]) diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py index 014b49bb63579227c12a8380cfb630a0bd6c677a..ed9139576f511c4c0989675d3e5b0d356584d893 100644 --- a/ipaserver/install/ipa_backup.py +++ b/ipaserver/install/ipa_backup.py @@ -158,7 +158,8 @@ class Backup(admintool.AdminTool): paths.NTP_CONF, paths.SMB_CONF, paths.SAMBA_KEYTAB, - paths.DOGTAG_AGENT_P12, + paths.DOGTAG_ADMIN_P12, + paths.KRA_AGENT_PEM, paths.CACERT_P12, paths.KRB5KDC_KDC_CONF, paths.SYSTEMD_IPA_SERVICE, diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index 1af1c0f721cd9b0df7c6134798494d507e2ba07c..7c1bded4173420a7e8f0ebfe40fe7e12ba0476c4 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -169,7 +169,7 @@ class KRAInstance(DogtagInstance): str(DN(('cn', 'ipa-ca-agent'), self.subject_base))) config.set("KRA", "pki_import_admin_cert", "True") config.set("KRA", "pki_admin_cert_file", paths.ADMIN_CERT_PATH) - config.set("KRA", "pki_client_admin_cert_p12", paths.DOGTAG_AGENT_P12) + config.set("KRA", "pki_client_admin_cert_p12", paths.DOGTAG_ADMIN_P12) # Directory server config.set("KRA", "pki_ds_ldap_port", str(self.ds_port)) @@ -259,16 +259,81 @@ class KRAInstance(DogtagInstance): """ Add RA agent created for CA to KRA agent group. """ - conn = ipaldap.IPAdmin(self.fqdn, self.ds_port) - conn.do_simple_bind(DN(('cn', 'Directory Manager')), self.dm_password) - entry_dn = DN(('uid', "ipara"), ('ou', 'People'), ('o', 'ipaca')) - dn = DN(('cn', 'Data Recovery Manager Agents'), ('ou', 'groups'), - self.basedn) - modlist = [(0, 'uniqueMember', '%s' % entry_dn)] - conn.modify_s(dn, modlist) + # import CA certificate into temporary security database + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-import", + "--pkcs12", paths.KRACERT_P12, + "--pkcs12-password", self.admin_password] + ipautil.run(args) - conn.unbind() + # trust CA certificate + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-mod", "Certificate Authority - %s" % api.env.realm, + "--trust", "CT,c,"] + ipautil.run(args) + + # import Dogtag admin certificate into temporary security database + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "client-cert-import", + "--pkcs12", paths.DOGTAG_ADMIN_P12, + "--pkcs12-password", self.admin_password] + ipautil.run(args) + + # as Dogtag admin, create ipakra user in KRA + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-add", "ipakra", + "--fullName", "IPA KRA User"] + ipautil.run(args) + + # as Dogtag admin, add ipakra into KRA agents group + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-membership-add", "ipakra", "Data Recovery Manager Agents"] + ipautil.run(args) + + # assign ipaCert to ipakra + (file, filename) = tempfile.mkstemp() + os.close(file) + try: + # export ipaCert without private key + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--cert", filename] + ipautil.run(args) + + # as Dogtag admin, upload and assign ipaCert to ipakra + args = ["/usr/bin/pki", + "-d", self.agent_db, + "-c", self.admin_password, + "-n", "ipa-ca-agent", + "kra-user-cert-add", "ipakra", + "--input", filename] + ipautil.run(args) + + finally: + os.remove(filename) + + # export ipaCert with private key for client authentication + args = ["/usr/bin/pki", + "-d", paths.HTTPD_ALIAS_DIR, + "-C", paths.ALIAS_PWDFILE_TXT, + "client-cert-show", "ipaCert", + "--client-cert", paths.KRA_AGENT_PEM] + ipautil.run(args) @staticmethod def update_cert_config(nickname, cert, dogtag_constants=None): diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 0e141a45c290b84d65b15b8c2c638577a3a39363..cd1c05cd53429e85df39cd793e209d69e77ce643 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1890,122 +1890,36 @@ class kra(Backend): """ def __init__(self, kra_port=443): - if api.env.in_tree: - self.sec_dir = os.path.join(api.env.dot_ipa, 'alias') - pwd_file = os.path.join(self.sec_dir, '.pwd') - self.pem_file = os.path.join(self.sec_dir, ".pemfile") - else: - self.sec_dir = paths.HTTPD_ALIAS_DIR - pwd_file = paths.ALIAS_PWDFILE_TXT - self.pem_file = paths.DOGTAG_AGENT_PEM self.kra_port = kra_port - self.transport_nick = "IPA KRA Transport Cert" - self.password = "" - with open(pwd_file, "r") as f: - self.password = f.readline().strip() - self.keyclient = None super(kra, self).__init__() - def _create_pem_file(self): - """ Create PEM file used by KRA plugin for authentication. - - This function reads the IPA HTTPD database and extracts the - Dogtag agent certificate and keys into a PKCS#12 temporary file. - The PKCS#12 file is then converted into PEM format so that it - can be used by python-requests to authenticate to the KRA. - - :return: None - """ - (p12_pwd_fd, p12_pwd_fname) = tempfile.mkstemp() - (p12_fd, p12_fname) = tempfile.mkstemp() - - try: - os.write(p12_pwd_fd, self.password) - os.close(p12_pwd_fd) - os.close(p12_fd) - - certdb = CertDB(api.env.realm) - certdb.export_pkcs12(p12_fname, p12_pwd_fname, "ipaCert") - - certdb.install_pem_from_p12(p12_fname, self.password, self.pem_file) - except: - self.debug("Error when creating PEM file for KRA operations") - raise - finally: - os.remove(p12_fname) - os.remove(p12_pwd_fname) - - def _transport_cert_present(self): - """ Check if the client certDB contains the KRA transport certificate - :return: True/False + def get_client(self): """ - # certutil -L -d db_dir -n cert_nick - certdb = CertDB(api.env.realm) - return certdb.has_nickname(self.transport_nick) - - def _setup(self): - """ Do initial setup and crypto initialization of the KRA client + Returns an authenticated KRA client to access KRA services. - Creates a PEM file containing the KRA agent cert/keys to be used for - authentication to the KRA (if it does not already exist), Sets up a - connection to the KRA and initializes an NSS certificate database to - store the transport certificate, Retrieves the transport certificate - if it is not already present. + Raises a generic exception if KRA is not enabled. """ - #set up pem file if not present - if not os.path.exists(self.pem_file): - self._create_pem_file() - # set up connection - connection = PKIConnection('https', - self.kra_host, - str(self.kra_port), - 'kra') - connection.set_authentication_cert(self.pem_file) + if not api.env.enable_kra: + # TODO: replace this with a more specific exception + raise RuntimeError('KRA service is not enabled') - crypto = cryptoutil.NSSCryptoProvider(self.sec_dir, self.password) + crypto = cryptoutil.NSSCryptoProvider( + paths.HTTPD_ALIAS_DIR, + password_file=paths.ALIAS_PWDFILE_TXT) - #create kraclient - kraclient = KRAClient(connection, crypto) + # TODO: obtain KRA host & port from IPA service list or point to KRA load balancer + # https://fedorahosted.org/freeipa/ticket/4557 + connection = PKIConnection( + 'https', + api.env.kra_host, + str(self.kra_port), + 'kra') - # get transport cert if needed - if not self._transport_cert_present(): - transport_cert = kraclient.system_certs.get_transport_cert() - crypto.import_cert(self.transport_nick, transport_cert, "u,u,u") + connection.set_authentication_cert(paths.KRA_AGENT_PEM) - crypto.initialize() - - self.keyclient = kraclient.keys - self.keyclient.set_transport_cert(self.transport_nick) - - @cachedproperty - def kra_host(self): - """ - :return: host - as str - - Select our KRA host. - """ - ldap2 = self.api.Backend.ldap2 - if host_has_service(api.env.kra_host, ldap2, "kra"): - return api.env.kra_host - if api.env.host != api.env.kra_host: - if host_has_service(api.env.host, ldap2, "kra"): - return api.env.host - host = select_any_master(ldap2, "kra") - if host: - return host - else: - return api.env.kra_host - - def get_keyclient(self): - """Return a keyclient to perform key archival and retrieval. - :return: pki.key.keyclient - """ - if self.keyclient is None: - self._setup() - return self.keyclient + return KRAClient(connection, crypto) api.register(kra) -- 1.9.0 From mbasti at redhat.com Thu Oct 30 09:42:18 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 30 Oct 2014 10:42:18 +0100 Subject: [Freeipa-devel] [PATCH] 0025 Respect UID and GID soft static allocation. In-Reply-To: <54511472.5010004@redhat.com> References: <544A04E7.7010101@redhat.com> <544A1114.6090301@redhat.com> <544A32B3.2020707@redhat.com> <544A4EA4.40908@redhat.com> <5450ECED.2060208@redhat.com> <54511472.5010004@redhat.com> Message-ID: <545207FA.1040407@redhat.com> On 29/10/14 17:23, David Kupka wrote: > On 10/29/2014 02:34 PM, David Kupka wrote: >> On 10/24/2014 03:05 PM, David Kupka wrote: >>> On 10/24/2014 01:06 PM, David Kupka wrote: >>>> On 10/24/2014 10:43 AM, Martin Basti wrote: >>>>> On 24/10/14 09:51, David Kupka wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/4585 >>>>> NACK >>>>> >>>>> 1) >>>>> Why is there line with 'DS System User?' The comment should depend on >>>>> service. >>>>> >>>>> + args = [ >>>>> + paths.USERADD, >>>>> + '-g', group, >>>>> + '-c', 'DS System User', >>>>> + '-d', homedir, >>>>> + '-s', shell, >>>>> + '-M', '-r', name, >>>>> + ] >>>> >>>> This was part of the original code and I didn't notice it. Nice catch, >>>> thanks. >>>> >>>>> >>>>> 2) >>>>> code create_system_user is duplicated between base and redhat tasks >>>>> with >>>>> platform dependent changes. >>>>> IMO it would be better to have one method to create user, with >>>>> keyword >>>>> arguments. And then platform dependent method which will call >>>>> method to >>>>> create user with appropriate arguments (or with default arguments) >>>>> >>>> >>>> You're right it was ugly. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>> I shouldn't break SOLID principles. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Using super is probably better that explicit naming of parent class. >> Let user (developer) override UID/GID and hope that he knows why ... >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > In your former patch you had pki homedir path VAR_LIB_PKI_DIR : + if name == 'pkiuser': + uid = 17 + gid = 17 + homedir = paths.VAR_LIB_PKI_DIR + shell = paths.NOLOGIN + comment = 'CA System User' in last patch you change it back to: homedir=paths.VAR_LIB, so what is the correct path? -- Martin Basti From pviktori at redhat.com Thu Oct 30 09:49:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 30 Oct 2014 10:49:42 +0100 Subject: [Freeipa-devel] [PATCH] 352 Fixed KRA backend. In-Reply-To: <54513B93.2020409@redhat.com> References: <543F4294.1080001@redhat.com> <5447C07C.4000800@redhat.com> <5448C356.9040105@redhat.com> <54500FC5.7070207@redhat.com> <5450E472.90903@redhat.com> <54513B93.2020409@redhat.com> Message-ID: <545209B6.5000504@redhat.com> On 10/29/2014 08:10 PM, Endi Sukma Dewata wrote: > New patch attached. > > On 10/29/2014 7:58 AM, Petr Viktorin wrote: >>> Dependency is bumped to 10.2.1-0.1 which is available from my >>> COPR repo: >>> >>> dnf copr enable edewata/pki >> >> OK. We should get that to an IPA COPR before merging this. > > How do we do that? Here is the SRPM: > https://edewata.fedorapeople.org/pki/copr/pki-core-10.2.1-0.1.fc20.src.rpm Martin and I will handle this today. >> How can I do some basic smoke check on this? Is there something I still >> need to to besides ipa-kra-istall? Any other patches? [...] > > The simplest test is probably this: > > from ipalib import api > > api.bootstrap(context='server') > api.finalize() > > kra_client = api.Backend.kra.get_client() > transport_cert = kra_client.system_certs.get_transport_cert() > > print "Serial number: %s" % transport_cert.serial_number > print "Issuer DN: %s" % transport_cert.issuer_dn > print "Subject DN: %s" % transport_cert.subject_dn > > print transport_cert.encoded Thanks! Works here; the rest is for other patches. ACK, to be pushed when the COPR is ready. -- Petr? From pviktori at redhat.com Thu Oct 30 09:52:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 30 Oct 2014 10:52:09 +0100 Subject: [Freeipa-devel] [PATCH] 334 Do not wait for new CA certificate to appear in LDAP in ipa-certupdate In-Reply-To: <5450F9DA.6020103@redhat.com> References: <543E86D7.50208@redhat.com> <5450F9DA.6020103@redhat.com> Message-ID: <54520A49.1040300@redhat.com> On 10/29/2014 03:29 PM, David Kupka wrote: > On 10/15/2014 04:38 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> It depends on my patch 333, which is also attached. >> >> (The original patch was posted at >> .) >> >> >> >> How to test: >> >> 1. install server >> >> 2. run "ipa-certupdate" >> >> 3. run "getcert list -d /etc/pki/pki-tomcat/alias -n 'caSigningCert >> cert-pki-ca'", the request should be in MONITORING state, there should >> be no ca-error >> >> Honza > Works for me, ACK. > Note: Push only freeipa-jcholast-334 patch, patch freeipa-jcholast-333 > was already ACKed and pushed. Pushed to: master: 35947c6e103a18c3f81af4b6d3795218a93b3b57 ipa-4-1: 1b940d39f3908c3ce18a16c45c6ac06c9b704d8e -- Petr? From tbordaz at redhat.com Thu Oct 30 13:47:20 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 30 Oct 2014 14:47:20 +0100 Subject: [Freeipa-devel] [PATCH] 005 Deadlock in schema compat plugin (between automember_update_membership task and dse update) Message-ID: <54524168.8040108@redhat.com> https://fedorahosted.org/freeipa/ticket/4635 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0005-Deadlock-in-schema-compat-plugin.patch Type: text/x-patch Size: 5624 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 30 14:33:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 30 Oct 2014 15:33:54 +0100 Subject: [Freeipa-devel] [PATCH 0154] Add bind-dyndb-ldap workdir to IPA specfile Message-ID: <54524C52.20404@redhat.com> https://fedorahosted.org/freeipa/ticket/4657#comment:6 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0154-Add-bind-dyndb-ldap-working-dir-to-IPA-specfile.patch Type: text/x-patch Size: 1475 bytes Desc: not available URL: From pspacek at redhat.com Fri Oct 31 08:05:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 31 Oct 2014 09:05:45 +0100 Subject: [Freeipa-devel] [PATCH 0154] Add bind-dyndb-ldap workdir to IPA specfile In-Reply-To: <54524C52.20404@redhat.com> References: <54524C52.20404@redhat.com> Message-ID: <545342D9.8030800@redhat.com> On 30.10.2014 15:33, Martin Basti wrote: > https://fedorahosted.org/freeipa/ticket/4657#comment:6 > > Patch attached. ACK -- Petr^2 Spacek From pviktori at redhat.com Fri Oct 31 12:17:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 31 Oct 2014 13:17:24 +0100 Subject: [Freeipa-devel] freeipa-master COPR for Fedora 21 Message-ID: <54537DD4.7020105@redhat.com> Hello, The COPR repo with dependencies for FreeIPA master is here: https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/ It will contain all build and run dependencies that aren't in updates and updates-testing yet. So before adding new deps to master, be sure they are here. Notice that there is no repo for Fedora 20 any more. The list of additional packages needed there was growing too large, so we dropped it. Use the 4.1 branch on Fedora 20. -- Petr? From pvoborni at redhat.com Fri Oct 31 14:05:37 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 31 Oct 2014 15:05:37 +0100 Subject: [Freeipa-devel] [PATCH 0154] Add bind-dyndb-ldap workdir to IPA specfile In-Reply-To: <545342D9.8030800@redhat.com> References: <54524C52.20404@redhat.com> <545342D9.8030800@redhat.com> Message-ID: <54539731.5070701@redhat.com> On 31.10.2014 09:05, Petr Spacek wrote: > On 30.10.2014 15:33, Martin Basti wrote: >> https://fedorahosted.org/freeipa/ticket/4657#comment:6 >> >> Patch attached. > > ACK > Pushed to: master: 42724a4b22f9c7025254c875e9f8fcba17f8b9bf ipa-4-1: a21443168e6e23e6f0485a2d71861e6e8fead67c -- Petr Vobornik From mbasti at redhat.com Fri Oct 31 15:54:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 31 Oct 2014 16:54:35 +0100 Subject: [Freeipa-devel] Question how memberof plugin works Message-ID: <5453B0BB.9060409@redhat.com> Hello list, I ran upgrade (related steps listed in order): ipa-ldap-updater --upgrade - applying update files (including 55-pbacmemberof.update) - updating ACI (new permissions created, added to existing privilege) ipa-upgradeconfig - setting up new service (which uses privilege with new permission) At the end I was expecting, the privilege will missing the new permission (memberOf attribute), but I tested it in lab, and membership was OK. How the memberof plugin works? We had similar issue with new DNS installation, where meberOf attributes was missing, if DNS was installed later. But I cant reproduce this behavior during upgrade. (Fix was use 55-pbacmemberof.update as last step of bind service installation) PS: we had a case where user had broken DNS privileges and 55-pbacmemberof.update helps. But he had multiple errors and it could be cascade effect. -- Martin Basti From pvoborni at redhat.com Fri Oct 31 16:31:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 31 Oct 2014 17:31:03 +0100 Subject: [Freeipa-devel] Question how memberof plugin works In-Reply-To: <5453B0BB.9060409@redhat.com> References: <5453B0BB.9060409@redhat.com> Message-ID: <5453B947.7060901@redhat.com> On 31.10.2014 16:54, Martin Basti wrote: > Hello list, > > I ran upgrade (related steps listed in order): > > ipa-ldap-updater --upgrade > - applying update files (including 55-pbacmemberof.update) > - updating ACI (new permissions created, added to existing privilege) > ipa-upgradeconfig > - setting up new service (which uses privilege with new permission) > > At the end I was expecting, the privilege will missing the new > permission (memberOf attribute), but I tested it in lab, and membership > was OK. > > How the memberof plugin works? I know of http://directory.fedoraproject.org/docs/389ds/design/memberof-plugin.html If there is other source, I would like to see it as well. > > We had similar issue with new DNS installation, where meberOf attributes > was missing, if DNS was installed later. But I cant reproduce this > behavior during upgrade. (Fix was use 55-pbacmemberof.update as last > step of bind service installation) Was fixed by a fixup task call in: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=895f350ebf5f002a8ba5aff3d521640b12aa3cde > > PS: we had a case where user had broken DNS privileges and > 55-pbacmemberof.update helps. But he had multiple errors and it could be > cascade effect. > -- Petr Vobornik From lkrispen at redhat.com Fri Oct 31 17:05:33 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 31 Oct 2014 18:05:33 +0100 Subject: [Freeipa-devel] Question how memberof plugin works In-Reply-To: <5453B947.7060901@redhat.com> References: <5453B0BB.9060409@redhat.com> <5453B947.7060901@redhat.com> Message-ID: <5453C15D.5080208@redhat.com> On 10/31/2014 05:31 PM, Petr Vobornik wrote: > On 31.10.2014 16:54, Martin Basti wrote: >> Hello list, >> >> I ran upgrade (related steps listed in order): >> >> ipa-ldap-updater --upgrade >> - applying update files (including 55-pbacmemberof.update) >> - updating ACI (new permissions created, added to existing privilege) >> ipa-upgradeconfig >> - setting up new service (which uses privilege with new permission) >> >> At the end I was expecting, the privilege will missing the new >> permission (memberOf attribute), but I tested it in lab, and membership >> was OK. >> >> How the memberof plugin works? > > I know of > http://directory.fedoraproject.org/docs/389ds/design/memberof-plugin.html > If there is other source, I would like to see it as well. I don't know of another doc, but the mechanism of memberof is quit simple: In the plugin config you define one or more groupattr and a memberofattr, eg |memberofgroupattr: member memberofgroupattr: uniqueMember memberofattr: memberOf then for any occurrence of the groupattr a value for the memberofattr in the referenced entry will be created, eg: ||dn: cn=group,dc=example member: cn=user,dc=example will trigger the addition of the memberofattr to the referenced entry cn=users dn: cn=user,dc=example objectclass: inetUser memberOf: cn=group,dc=example| This happens for any add/delete of a |memberofgroupattr or when the memberof fixup task is run. You have to make sure that the entry which you expect the memberof has an objectclass allowing the memberof attribute, | > >> >> We had similar issue with new DNS installation, where meberOf attributes >> was missing, if DNS was installed later. But I cant reproduce this >> behavior during upgrade. (Fix was use 55-pbacmemberof.update as last >> step of bind service installation) > > Was fixed by a fixup task call in: > > https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=895f350ebf5f002a8ba5aff3d521640b12aa3cde > > >> >> PS: we had a case where user had broken DNS privileges and >> 55-pbacmemberof.update helps. But he had multiple errors and it could be >> cascade effect. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: