From pvoborni at redhat.com Tue Apr 1 06:47:25 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 01 Apr 2014 08:47:25 +0200 Subject: [Freeipa-devel] [PATCH] 584 migration: fix import of wsgiref.util Message-ID: <533A60FD.6080707@redhat.com> https://fedorahosted.org/freeipa/ticket/4293 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0584-migration-fix-import-of-wsgiref.util.patch Type: text/x-patch Size: 1197 bytes Desc: not available URL: From jpazdziora at redhat.com Tue Apr 1 06:49:04 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 1 Apr 2014 08:49:04 +0200 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <5334163C.7060007@redhat.com> References: <5334163C.7060007@redhat.com> Message-ID: <20140401064904.GB3872@redhat.com> On Thu, Mar 27, 2014 at 01:14:52PM +0100, Tomas Babej wrote: > Hi, > > When cleaning the range_info struct, simple free of the struct > is not enough, we have to free contents of char pointers in the > struct as well. > > https://fedorahosted.org/freeipa/ticket/4276 [...] > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c > index 0ef33e5869bbcb4f721394ce35e2338095bf5d36..c877a7dc445b31b3de085aa66028d7652df6b9cc 100644 > --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c > +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c > @@ -96,6 +96,15 @@ struct domain_info { > struct domain_info *next; > }; > > +static void free_range_info(struct range_info *range) { > + if (range != NULL) { > + slapi_ch_free_string(&(range->name)); > + slapi_ch_free_string(&(range->domain_id)); > + slapi_ch_free_string(&(range->forest_root_id)); > + slapi_ch_free_string(&(range->id_range_type)); > + free(range); > + } > +} In master, the range_info is struct range_info { char *name; char *domain_id; uint32_t base_id; uint32_t id_range_size; uint32_t base_rid; uint32_t secondary_base_rid; }; -- no forest_root_id and no id_range_type. So NACK for applying to master. Perhaps there is some dependency patch? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Tue Apr 1 07:05:21 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 1 Apr 2014 09:05:21 +0200 Subject: [Freeipa-devel] FreeIPA repository and it's committers In-Reply-To: <533567A7.2060405@redhat.com> References: <533567A7.2060405@redhat.com> Message-ID: <20140401070521.GC3872@redhat.com> On Fri, Mar 28, 2014 at 01:14:31PM +0100, Martin Kosek wrote: > This week there was a request to be added to the list of FreeIPA committers, > which I denied as the person was not a member of the short list of selected > trusted active core upstream developers doing the pushes. While that makes sense, I don't see why freeipa-docs needs to share the same list of committers. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Tue Apr 1 07:11:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 1 Apr 2014 10:11:55 +0300 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <20140401064904.GB3872@redhat.com> References: <5334163C.7060007@redhat.com> <20140401064904.GB3872@redhat.com> Message-ID: <20140401071155.GA17186@redhat.com> On Tue, 01 Apr 2014, Jan Pazdziora wrote: >On Thu, Mar 27, 2014 at 01:14:52PM +0100, Tomas Babej wrote: >> Hi, >> >> When cleaning the range_info struct, simple free of the struct >> is not enough, we have to free contents of char pointers in the >> struct as well. >> >> https://fedorahosted.org/freeipa/ticket/4276 > >[...] > > >> 1 file changed, 13 insertions(+), 4 deletions(-) >> >> diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> index 0ef33e5869bbcb4f721394ce35e2338095bf5d36..c877a7dc445b31b3de085aa66028d7652df6b9cc 100644 >> --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> @@ -96,6 +96,15 @@ struct domain_info { >> struct domain_info *next; >> }; >> >> +static void free_range_info(struct range_info *range) { >> + if (range != NULL) { >> + slapi_ch_free_string(&(range->name)); >> + slapi_ch_free_string(&(range->domain_id)); >> + slapi_ch_free_string(&(range->forest_root_id)); >> + slapi_ch_free_string(&(range->id_range_type)); >> + free(range); >> + } >> +} > >In master, the range_info is > > struct range_info { > char *name; > char *domain_id; > uint32_t base_id; > uint32_t id_range_size; > uint32_t base_rid; > uint32_t secondary_base_rid; > }; > >-- no forest_root_id and no id_range_type. > >So NACK for applying to master. Perhaps there is some dependency >patch? I think Tomas took his own range check patch into account. I would also prefer splitting their dependencies. First make this one to work on master, then add forest_root_id and id_range_type freeing as part of the range check patches. -- / Alexander Bokovoy From tbabej at redhat.com Tue Apr 1 07:17:36 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 01 Apr 2014 09:17:36 +0200 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <20140401071155.GA17186@redhat.com> References: <5334163C.7060007@redhat.com> <20140401064904.GB3872@redhat.com> <20140401071155.GA17186@redhat.com> Message-ID: <533A6810.7020008@redhat.com> On 04/01/2014 09:11 AM, Alexander Bokovoy wrote: > On Tue, 01 Apr 2014, Jan Pazdziora wrote: >> On Thu, Mar 27, 2014 at 01:14:52PM +0100, Tomas Babej wrote: >>> Hi, >>> >>> When cleaning the range_info struct, simple free of the struct >>> is not enough, we have to free contents of char pointers in the >>> struct as well. >>> >>> https://fedorahosted.org/freeipa/ticket/4276 >> >> [...] >> >> >>> 1 file changed, 13 insertions(+), 4 deletions(-) >>> >>> diff --git >>> a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >>> b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >>> index >>> 0ef33e5869bbcb4f721394ce35e2338095bf5d36..c877a7dc445b31b3de085aa66028d7652df6b9cc >>> 100644 >>> --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >>> +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >>> @@ -96,6 +96,15 @@ struct domain_info { >>> struct domain_info *next; >>> }; >>> >>> +static void free_range_info(struct range_info *range) { >>> + if (range != NULL) { >>> + slapi_ch_free_string(&(range->name)); >>> + slapi_ch_free_string(&(range->domain_id)); >>> + slapi_ch_free_string(&(range->forest_root_id)); >>> + slapi_ch_free_string(&(range->id_range_type)); >>> + free(range); >>> + } >>> +} >> >> In master, the range_info is >> >> struct range_info { >> char *name; >> char *domain_id; >> uint32_t base_id; >> uint32_t id_range_size; >> uint32_t base_rid; >> uint32_t secondary_base_rid; >> }; >> >> -- no forest_root_id and no id_range_type. >> >> So NACK for applying to master. Perhaps there is some dependency >> patch? > I think Tomas took his own range check patch into account. > > I would also prefer splitting their dependencies. First make this one to > work on master, then add forest_root_id and id_range_type freeing as > part of the range check patches. > Yes, that was the intention. Mistake on my part, I'll send updated patches. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From jpazdziora at redhat.com Tue Apr 1 07:25:15 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 1 Apr 2014 09:25:15 +0200 Subject: [Freeipa-devel] [PATCH] 584 migration: fix import of wsgiref.util In-Reply-To: <533A60FD.6080707@redhat.com> References: <533A60FD.6080707@redhat.com> Message-ID: <20140401072515.GE3872@redhat.com> On Tue, Apr 01, 2014 at 08:47:25AM +0200, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/4293 > -- > Petr Vobornik > From dc4eaf9d622b4eac9fb3d942b23083bfb903be9a Mon Sep 17 00:00:00 2001 > From: Petr Vobornik > Date: Tue, 1 Apr 2014 08:45:08 +0200 > Subject: [PATCH] migration: fix import of wsgiref.util > > https://fedorahosted.org/freeipa/ticket/4293 > --- > install/migration/migration.py | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/install/migration/migration.py b/install/migration/migration.py > index 27e23a59f660c791c12948b4c40406d03b0f0966..acc1ee48dd8744f6abd2d7a59f0d5feb54fc93f9 100644 > --- a/install/migration/migration.py > +++ b/install/migration/migration.py > @@ -23,7 +23,7 @@ Password migration script > import cgi > import errno > import glob > -import wsgiref > +from wsgiref.util import request_uri > > from ipapython.ipa_log_manager import root_logger > from ipapython.ipautil import get_ipa_basedn > @@ -37,7 +37,7 @@ def wsgi_redirect(start_response, loc): > return [] > > def get_ui_url(environ): > - full_url = wsgiref.util.request_uri(environ) > + full_url = request_uri(environ) Sadly, this antipattern seems needed even if the proper solution would be to fix wsgi to properly export util. Is there bug filed for that. Ack based on reading the code and wsgiref documentation where the same import style is used. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Tue Apr 1 07:40:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Apr 2014 09:40:37 +0200 Subject: [Freeipa-devel] FreeIPA repository and it's committers In-Reply-To: <20140401070521.GC3872@redhat.com> References: <533567A7.2060405@redhat.com> <20140401070521.GC3872@redhat.com> Message-ID: <533A6D75.7000109@redhat.com> On 04/01/2014 09:05 AM, Jan Pazdziora wrote: > On Fri, Mar 28, 2014 at 01:14:31PM +0100, Martin Kosek wrote: >> This week there was a request to be added to the list of FreeIPA committers, >> which I denied as the person was not a member of the short list of selected >> trusted active core upstream developers doing the pushes. > > While that makes sense, I don't see why freeipa-docs needs to share > the same list of committers. It does not need to share the same list of committers. I requested a separate group: https://fedorahosted.org/fedora-infrastructure/ticket/4287 Martin From tbabej at redhat.com Tue Apr 1 08:05:39 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 01 Apr 2014 10:05:39 +0200 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <533A6810.7020008@redhat.com> References: <5334163C.7060007@redhat.com> <20140401064904.GB3872@redhat.com> <20140401071155.GA17186@redhat.com> <533A6810.7020008@redhat.com> Message-ID: <533A7353.7040909@redhat.com> On 04/01/2014 09:17 AM, Tomas Babej wrote: > On 04/01/2014 09:11 AM, Alexander Bokovoy wrote: >> On Tue, 01 Apr 2014, Jan Pazdziora wrote: >>> On Thu, Mar 27, 2014 at 01:14:52PM +0100, Tomas Babej wrote: >>>> Hi, >>>> >>>> When cleaning the range_info struct, simple free of the struct >>>> is not enough, we have to free contents of char pointers in the >>>> struct as well. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4276 >>> [...] >>> >>> >>>> 1 file changed, 13 insertions(+), 4 deletions(-) >>>> >>>> diff --git >>>> a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >>>> b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >>>> index >>>> 0ef33e5869bbcb4f721394ce35e2338095bf5d36..c877a7dc445b31b3de085aa66028d7652df6b9cc >>>> 100644 >>>> --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >>>> +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >>>> @@ -96,6 +96,15 @@ struct domain_info { >>>> struct domain_info *next; >>>> }; >>>> >>>> +static void free_range_info(struct range_info *range) { >>>> + if (range != NULL) { >>>> + slapi_ch_free_string(&(range->name)); >>>> + slapi_ch_free_string(&(range->domain_id)); >>>> + slapi_ch_free_string(&(range->forest_root_id)); >>>> + slapi_ch_free_string(&(range->id_range_type)); >>>> + free(range); >>>> + } >>>> +} >>> In master, the range_info is >>> >>> struct range_info { >>> char *name; >>> char *domain_id; >>> uint32_t base_id; >>> uint32_t id_range_size; >>> uint32_t base_rid; >>> uint32_t secondary_base_rid; >>> }; >>> >>> -- no forest_root_id and no id_range_type. >>> >>> So NACK for applying to master. Perhaps there is some dependency >>> patch? >> I think Tomas took his own range check patch into account. >> >> I would also prefer splitting their dependencies. First make this one to >> work on master, then add forest_root_id and id_range_type freeing as >> part of the range check patches. >> > Yes, that was the intention. Mistake on my part, I'll send updated patches. > Updated patch attached. -- 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-0161-2-ipa-range-check-Fix-memory-leaks-when-freeing-range-.patch Type: text/x-patch Size: 2191 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 1 08:08:00 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 01 Apr 2014 10:08:00 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <53341563.9050204@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> <53341563.9050204@redhat.com> Message-ID: <533A73E0.9030707@redhat.com> A slightly new version, properly adds new attributes of the range_info struct to the free_range_info method. Should be applied on top of my 161 patch. On 03/27/2014 01:11 PM, Tomas Babej wrote: > The updated version handles the ret variable properly. It also makes > sure the memory is properly freed. > > On 03/18/2014 04:45 PM, Alexander Bokovoy wrote: >> On Tue, 18 Mar 2014, Tomas Babej wrote: >>> On 03/18/2014 09:19 AM, Alexander Bokovoy wrote: >>>> On Mon, 17 Mar 2014, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> The ipa-range-check plugin used to determine the range type depending >>>>> on the value of the attributes such as RID or secondary RID base. This >>>>> approached caused variety of issues since the portfolio of ID range >>>>> types expanded. >>>>> >>>>> The patch makes sure the following rules are implemented: >>>>> * No ID range pair can overlap on base ranges, with exception >>>>> of two ipa-ad-trust-posix ranges belonging to the same forest >>>>> * For any ID range pair of ranges belonging to the same domain: >>>>> * Both ID ranges must be of the same type >>>>> * For ranges of ipa-ad-trust type or ipa-local type: >>>>> * Primary RID ranges can not overlap >>>>> * For ranges of ipa-local type: >>>>> * Primary and secondary RID ranges can not overlap >>>>> * Secondary RID ranges cannot overlap >>>>> >>>>> For the implementation part, the plugin was extended with a domain ID >>>>> to forest root domain ID mapping derivation capabilities. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4137 >>>>> >>>>> Test coverage coming soon! >>>> I don't really like that you are using a list here. The list is built >>>> and then destroyed in preop callback every time we process the range >>>> object, so it is one-off operation. Now, when you fetch trust domain >>>> objects to build the list, why can't you use an array directly? >>>> >>>> Given that all you need the list for is to map domain to a trust (if >>>> any) and trust name is the name of the root level domain, you can >>>> simply >>>> make an array of a struct (name, root) where root is a and index to the >>>> same array or -1 if this is the root domain itself. >>> I don't see much benefit of using array over linked list in this case. >>> In both cases, we would need to build the data container, and it would >>> be one-off operation (once for the ADD/MOD operation). >>> >>> Additionaly, using linked list, I can only pass around the pointer to >>> the head of the list, instead of passing around the array and it's >>> size. >> If you make a {NULL, NULL} entry as the last one, no need to pass array >> size. But anyway... >> >> >>> I reworked the part of the patch that fetches the data from the LDAP as >>> we discussed. Instead of performing multiple LDAP searches, we do a >>> single extra search per operation. >> See comments below. >> >>> +static struct domain_info* build_domain_to_forest_root_map(struct >>> domain_info *head, >>> + struct >>> ipa_range_check_ctx *ctx){ >>> + >>> + Slapi_PBlock *trusted_domain_search_pb = NULL; >>> + Slapi_Entry **trusted_domain_entries = NULL; >>> + Slapi_DN *base_dn = NULL; >>> + Slapi_RDN *rdn = NULL; >>> + >>> + int search_result; >>> + int ret; >>> + >>> + /* Set the base DN for the search to cn=ad, cn=trusts, $SUFFIX */ >>> + base_dn = slapi_sdn_new_dn_byref(ctx->base_dn); >>> + if (base_dn == NULL) { >>> + LOG_FATAL("Failed to convert base DN.\n"); >>> + ret = LDAP_OPERATIONS_ERROR; >>> + goto done; >>> + } >>> + >>> + rdn = slapi_rdn_new(); >>> + if (rdn == NULL) { >>> + LOG_FATAL("Failed to obtain RDN struct.\n"); >>> + ret = LDAP_OPERATIONS_ERROR; >>> + goto done; >>> + } >>> + >>> + slapi_rdn_add(rdn, "cn", "trusts"); >>> + slapi_sdn_add_rdn(base_dn, rdn); >>> + slapi_rdn_done(rdn); >>> + >>> + slapi_rdn_add(rdn, "cn", "ad"); >>> + slapi_sdn_add_rdn(base_dn, rdn); >>> + slapi_rdn_done(rdn); >> given that slapi_search_internal_set_pb() wants 'const char *base', why >> not use asprintf() instead? >> >> Here is what we do in ipa-kdb: >> ret = asprintf(&base, "cn=ad,cn=trusts,%s", ipactx->base); >> if (ret == -1) { >> ret = ENOMEM; >> goto done; >> } >> >> That's enough, IMHO. 389-ds internally will anyway create new sdn >> explicitly from a string you've passed. >> >>> + >>> + /* Allocate a new parameter block */ >>> + trusted_domain_search_pb = slapi_pblock_new(); >>> + if (trusted_domain_search_pb == NULL) { >>> + LOG_FATAL("Failed to create new pblock.\n"); >>> + ret = LDAP_OPERATIONS_ERROR; >> in done: label you don't deal with 'ret' at all. Do you need it? >> >>> + //goto done; >> is it goto or not? >> >>> + } >>> + >>> + /* Search for all the root domains, note the LDAP_SCOPE_ONELEVEL */ >>> + slapi_search_internal_set_pb(trusted_domain_search_pb, >>> + slapi_sdn_get_dn(base_dn), >> here just use 'base_dn'. >> >>> + LDAP_SCOPE_SUBTREE, DOMAIN_ID_FILTER, >>> + NULL, 0, NULL, NULL, >>> ctx->plugin_id, 0); >>> + >>> + ret = slapi_search_internal_pb(trusted_domain_search_pb); >>> + if (ret != 0) { >>> + LOG_FATAL("Starting internal search failed.\n"); >>> + goto done; >> make sure you are consistent with 'ret' -- either handling it or not, >> and if overriding with LDAP_OPERATIONS_ERROR, make sure it is overridden >> everywhere. >> >>> + } >>> + >>> + ret = slapi_pblock_get(trusted_domain_search_pb, >>> SLAPI_PLUGIN_INTOP_RESULT, &search_result); >>> + if (ret != 0 || search_result != LDAP_SUCCESS) { >>> + LOG_FATAL("Internal search failed.\n"); >>> + ret = LDAP_OPERATIONS_ERROR; >>> + goto done; >>> + } >> same here >> >>> + >>> + ret = slapi_pblock_get(trusted_domain_search_pb, >>> SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, >>> + &trusted_domain_entries); >>> + >>> + if (ret != 0) { >>> + LOG_FATAL("Failed to read searched root domain entries.\n"); >> same here >> >>> + goto done; >>> + } >>> + >>> + if (trusted_domain_entries == NULL || trusted_domain_entries[0] >>> == NULL) { >>> + LOG("No existing root domain entries.\n"); >>> + ret = 0; >>> + goto done; >>> + } >> Here as well >> >>> + >>> + /* now we iterate the domains and determine which of them are >>> root domains */ >>> + for (int i = 0; trusted_domain_entries[i] != NULL; i++) { >>> + >>> + ret = slapi_sdn_isparent(base_dn, >>> + >>> slapi_entry_get_sdn(trusted_domain_entries[i])); >>> + >>> + /* trusted domain is root domain */ >>> + if (ret == 1) { >>> + map_domain_to_root(head, >>> + trusted_domain_entries[i], >>> + trusted_domain_entries[i]); >>> + } >>> + else { >>> + /* we need to search for the root domain */ >>> + for (int j = 0; trusted_domain_entries[j] != NULL; j++) { >>> + ret = slapi_sdn_isparent( >>> + >>> slapi_entry_get_sdn(trusted_domain_entries[j]), >>> + >>> slapi_entry_get_sdn(trusted_domain_entries[i])); >>> + >>> + /* match, set the jth domain as the root domain for >>> the ith */ >>> + if (ret == 1) { >>> + map_domain_to_root(head, >>> + trusted_domain_entries[i], >>> + trusted_domain_entries[j]); >>> + break; >>> + } >>> + } >>> + } >>> + } >>> + >>> +done: >>> + slapi_free_search_results_internal(trusted_domain_search_pb); >>> + slapi_pblock_destroy(trusted_domain_search_pb); >>> + slapi_rdn_free(&rdn); >>> + >>> + return head; >>> + >>> +} >>> + >>> +static int slapi_entry_to_range_info(struct domain_info >>> *domain_info_head, >>> + struct slapi_entry *entry, >>> struct range_info **_range) >>> { >>> int ret; >>> @@ -97,6 +273,9 @@ static int slapi_entry_to_range_info(struct >>> slapi_entry *entry, >>> } >>> >>> range->domain_id = slapi_entry_attr_get_charptr(entry, >>> IPA_DOMAIN_ID); >>> + range->id_range_type = slapi_entry_attr_get_charptr(entry, >>> IPA_RANGE_TYPE); >>> + range->forest_root_id = get_forest_root_id(domain_info_head, >>> + range->domain_id); >>> >>> ul_val = slapi_entry_attr_get_ulong(entry, IPA_BASE_ID); >>> if (ul_val == 0 || ul_val >= UINT32_MAX) { >>> @@ -161,58 +340,67 @@ static bool intervals_overlap(uint32_t x, >>> uint32_t base, uint32_t x_size, uint32 >>> * | | / \ | >>> * new range: base rid sec_rid >>> **/ >>> -static int ranges_overlap(struct range_info *r1, struct range_info *r2) >>> +static int check_ranges(struct range_info *r1, struct range_info *r2) >>> { >>> + /* Do not check overlaps of range with the range itself */ >>> if (r1->name != NULL && r2->name != NULL && >>> strcasecmp(r1->name, r2->name) == 0) { >>> return 0; >>> } >>> >>> - /* check if base range overlaps with existing base range */ >>> - if (intervals_overlap(r1->base_id, r2->base_id, >>> - r1->id_range_size, r2->id_range_size)){ >>> - return 1; >>> + /* Check if base range overlaps with existing base range. >>> + * Exception: ipa-ad-trust-posix ranges from the same forest */ >>> + if (!(strcasecmp(r1->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >>> + strcasecmp(r2->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >>> + r1->forest_root_id != NULL && r2->forest_root_id !=NULL && >>> + strcasecmp(r1->forest_root_id, r2->forest_root_id) == 0)) { >>> + >>> + if (intervals_overlap(r1->base_id, r2->base_id, >>> + r1->id_range_size, r2->id_range_size)){ >>> + return 1; >>> + } >>> + >>> } >>> >>> - /* if both base_rid and secondary_base_rid = 0, the rid range is >>> not set */ >>> - bool rid_ranges_set = (r1->base_rid != 0 || >>> r1->secondary_base_rid != 0) && >>> - (r2->base_rid != 0 || >>> r2->secondary_base_rid != 0); >>> - >>> - /** >>> - * ipaNTTrustedDomainSID is not set for local ranges, use it to >>> - * determine the type of the range **/ >>> - bool local_ranges = r1->domain_id == NULL && r2->domain_id == NULL; >>> - >>> + /* Following checks apply for the ranges from the same domain */ >>> bool ranges_from_same_domain = >>> (r1->domain_id == NULL && r2->domain_id == NULL) || >>> (r1->domain_id != NULL && r2->domain_id != NULL && >>> strcasecmp(r1->domain_id, r2->domain_id) == 0); >>> >>> - /** >>> - * in case rid range is not set or ranges belong to different >>> domains >>> - * we can skip rid range tests as they are irrelevant **/ >>> - if (rid_ranges_set && ranges_from_same_domain){ >>> - >>> - /* check if rid range overlaps with existing rid range */ >>> - if (intervals_overlap(r1->base_rid, r2->base_rid, >>> - r1->id_range_size, r2->id_range_size)) >>> - return 2; >>> - >>> - /** >>> - * The following 3 checks are relevant only if both ranges >>> are local. >>> - * Check if secondary rid range overlaps with existing >>> secondary rid >>> - * range. **/ >>> - if (local_ranges){ >>> + if (ranges_from_same_domain) { >>> + >>> + /* Ranges from the same domain must have the same type */ >>> + if (strcasecmp(r1->id_range_type, r2->id_range_type) != 0) { >>> + return 6; >>> + } >>> + >>> + /* For ipa-local or ipa-ad-trust range types primary RID >>> ranges should >>> + * not overlap */ >>> + if (strcasecmp(r1->id_range_type, AD_TRUST_RANGE_TYPE) == 0 || >>> + strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0) { >>> + >>> + /* Check if rid range overlaps with existing rid range */ >>> + if (intervals_overlap(r1->base_rid, r2->base_rid, >>> + r1->id_range_size, r2->id_range_size)) >>> + return 2; >>> + } >>> + >>> + /* The following 3 checks are relevant only if both ranges >>> are local. */ >>> + if (strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0){ >>> + >>> + /* Check if secondary RID range overlaps with existing >>> secondary or >>> + * primary RID range. */ >>> if (intervals_overlap(r1->secondary_base_rid, >>> r2->secondary_base_rid, r1->id_range_size, >>> r2->id_range_size)) >>> return 3; >>> >>> - /* check if rid range overlaps with existing secondary >>> rid range */ >>> + /* Check if RID range overlaps with existing secondary >>> RID range */ >>> if (intervals_overlap(r1->base_rid, r2->secondary_base_rid, >>> r1->id_range_size, r2->id_range_size)) >>> return 4; >>> >>> - /* check if secondary rid range overlaps with existing >>> rid range */ >>> + /* Check if secondary RID range overlaps with existing >>> RID range */ >>> if (intervals_overlap(r1->secondary_base_rid, r2->base_rid, >>> r1->id_range_size, r2->id_range_size)) >>> return 5; >>> @@ -248,9 +436,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock >>> *pb, int modtype) >>> int search_result; >>> Slapi_Entry **search_entries = NULL; >>> size_t c; >>> - int no_overlap = 0; >>> + int ranges_valid = 0; >>> const char *check_attr; >>> char *errmsg = NULL; >>> + struct domain_info *domain_info_head = NULL; >>> >>> ret = slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, >>> &is_repl_op); >>> if (ret != 0) { >>> @@ -337,7 +526,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock >>> *pb, int modtype) >>> goto done; >>> } >>> >>> - ret = slapi_entry_to_range_info(entry, &new_range); >>> + /* build a linked list of domain_info structs */ >>> + domain_info_head = >>> build_domain_to_forest_root_map(domain_info_head, ctx); >>> + >>> + ret = slapi_entry_to_range_info(domain_info_head, entry, >>> &new_range); >>> if (ret != 0) { >>> LOG_FATAL("Failed to convert LDAP entry to range struct.\n"); >>> goto done; >>> @@ -381,19 +573,20 @@ static int ipa_range_check_pre_op(Slapi_PBlock >>> *pb, int modtype) >>> } >>> >>> for (c = 0; search_entries[c] != NULL; c++) { >>> - ret = slapi_entry_to_range_info(search_entries[c], &old_range); >>> + ret = slapi_entry_to_range_info(domain_info_head, >>> search_entries[c], >>> + &old_range); >>> if (ret != 0) { >>> LOG_FATAL("Failed to convert LDAP entry to range >>> struct.\n"); >>> goto done; >>> } >>> >>> - no_overlap = ranges_overlap(new_range, old_range); >>> + ranges_valid = check_ranges(new_range, old_range); >>> free(old_range); >>> old_range = NULL; >>> - if (no_overlap != 0) { >>> + if (ranges_valid != 0) { >>> ret = LDAP_CONSTRAINT_VIOLATION; >>> >>> - switch (no_overlap){ >>> + switch (ranges_valid){ >>> case 1: >>> errmsg = "New base range overlaps with existing base >>> range."; >>> break; >>> @@ -409,6 +602,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock >>> *pb, int modtype) >>> case 5: >>> errmsg = "New secondary rid range overlaps with >>> existing primary rid range."; >>> break; >>> + case 6: >>> + errmsg = "New ID range has invalid type. All ranges >>> in the same domain must be of the same type."; >>> default: >>> errmsg = "New range overlaps with existing one."; >>> break; >>> @@ -432,6 +627,14 @@ done: >>> slapi_entry_free(entry); >>> } >>> >>> + /* Remove the domain info linked list from memory */ >>> + struct domain_info *next; >>> + while(domain_info_head) { >>> + next = domain_info_head->next; >>> + free(domain_info_head); >>> + domain_info_head = next; >>> + } >> Who would clean up all the strings in each record? >> I think we also have the issue in the original code with freeing >> range objects. A mere free(new_range) is not enough. >> >>> + >>> if (ret != 0) { >>> if (errmsg == NULL) { >>> errmsg = "Range Check error"; >>> -- >>> 1.8.5.3 >>> >> > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0158-4-Extend-ipa-range-check-DS-plugin-to-handle-range-typ.patch Type: text/x-patch Size: 17113 bytes Desc: not available URL: From abokovoy at redhat.com Tue Apr 1 08:40:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 1 Apr 2014 11:40:16 +0300 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <533A73E0.9030707@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> <53341563.9050204@redhat.com> <533A73E0.9030707@redhat.com> Message-ID: <20140401084016.GI3094@redhat.com> On Tue, 01 Apr 2014, Tomas Babej wrote: >From 736b3f747188696fd4a46ca63d91a6cca942fd56 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 5 Mar 2014 12:28:18 +0100 >Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types > >The ipa-range-check plugin used to determine the range type depending >on the value of the attributes such as RID or secondary RID base. This >approached caused variety of issues since the portfolio of ID range >types expanded. > >The patch makes sure the following rules are implemented: > * No ID range pair can overlap on base ranges, with exception > of two ipa-ad-trust-posix ranges belonging to the same forest > * For any ID range pair of ranges belonging to the same domain: > * Both ID ranges must be of the same type > * For ranges of ipa-ad-trust type or ipa-local type: > * Primary RID ranges can not overlap > * For ranges of ipa-local type: > * Primary and secondary RID ranges can not overlap > * Secondary RID ranges cannot overlap > >For the implementation part, the plugin was extended with a domain ID >to forest root domain ID mapping derivation capabilities. > >https://fedorahosted.org/freeipa/ticket/4137 > >-static int slapi_entry_to_range_info(struct slapi_entry *entry, >+struct domain_info { >+ char *domain_id; >+ char *forest_root_id; >+ struct domain_info *next; >+}; >+ >+static void free_domain_info(struct domain_info *info) { >+ if (info != NULL) { >+ slapi_ch_free_string(&(info->domain_id)); >+ slapi_ch_free_string(&(info->forest_root_id)); >+ free_domain_info(info->next); >+ free(info); >+ } >+} Please, don't use recursion in the freeing part, there is really no pressing need to do so. Just use while() like you do in get_forest_root_id(): >+/* Searches for the domain_info struct with the specified domain_id >+ * in the linked list. Returns the forest root domain's ID, or NULL for >+ * local ranges. */ >+ >+static char* get_forest_root_id(struct domain_info *head, char* domain_id) { >+ >+ /* For local ranges there is no forest root domain, >+ * so consider only ranges with domain_id set */ >+ if (domain_id != NULL) { >+ while(head) { >+ if (strcasecmp(head->domain_id, domain_id) == 0) { >+ return head->forest_root_id; >+ } >+ head = head->next; >+ } >+ } >+ >+ return NULL; >+} >+ -- / Alexander Bokovoy From jcholast at redhat.com Tue Apr 1 08:45:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 01 Apr 2014 10:45:42 +0200 Subject: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks Message-ID: <533A7CB6.9010400@redhat.com> Hi, while working with Martin Ba?ti on issues in his dns plugin patches we ran into several limitations in the framework. The attached patches remove these limitations. Also, Tom?? Babej pointed out that when using --raw, all the attribute names should use letter casing as returned by python-ldap. Patch 259 implements that. See commit messages for details. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-255-Allow-primary-keys-to-use-different-type-than-unicod.patch Type: text/x-patch Size: 173273 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-256-Support-API-version-specific-RPC-marshalling.patch Type: text/x-patch Size: 11077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-257-Replace-get_syntax-method-of-IPASimpleObject-with-ne.patch Type: text/x-patch Size: 2980 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-258-Use-raw-attribute-values-in-command-result-when-raw-.patch Type: text/x-patch Size: 3568 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-259-Keep-original-name-when-setting-attribute-in-LDAPEnt.patch Type: text/x-patch Size: 3955 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 1 08:52:25 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 01 Apr 2014 10:52:25 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <20140401084016.GI3094@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> <53341563.9050204@redhat.com> <533A73E0.9030707@redhat.com> <20140401084016.GI3094@redhat.com> Message-ID: <533A7E49.604@redhat.com> On 04/01/2014 10:40 AM, Alexander Bokovoy wrote: > On Tue, 01 Apr 2014, Tomas Babej wrote: >> From 736b3f747188696fd4a46ca63d91a6cca942fd56 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Wed, 5 Mar 2014 12:28:18 +0100 >> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >> >> The ipa-range-check plugin used to determine the range type depending >> on the value of the attributes such as RID or secondary RID base. This >> approached caused variety of issues since the portfolio of ID range >> types expanded. >> >> The patch makes sure the following rules are implemented: >> * No ID range pair can overlap on base ranges, with exception >> of two ipa-ad-trust-posix ranges belonging to the same forest >> * For any ID range pair of ranges belonging to the same domain: >> * Both ID ranges must be of the same type >> * For ranges of ipa-ad-trust type or ipa-local type: >> * Primary RID ranges can not overlap >> * For ranges of ipa-local type: >> * Primary and secondary RID ranges can not overlap >> * Secondary RID ranges cannot overlap >> >> For the implementation part, the plugin was extended with a domain ID >> to forest root domain ID mapping derivation capabilities. >> >> https://fedorahosted.org/freeipa/ticket/4137 >> >> -static int slapi_entry_to_range_info(struct slapi_entry *entry, >> +struct domain_info { >> + char *domain_id; >> + char *forest_root_id; >> + struct domain_info *next; >> +}; >> + >> +static void free_domain_info(struct domain_info *info) { >> + if (info != NULL) { >> + slapi_ch_free_string(&(info->domain_id)); >> + slapi_ch_free_string(&(info->forest_root_id)); >> + free_domain_info(info->next); >> + free(info); >> + } >> +} > Please, don't use recursion in the freeing part, there is really no > pressing need to do so. Just use while() like you do in > get_forest_root_id(): > >> +/* Searches for the domain_info struct with the specified domain_id >> + * in the linked list. Returns the forest root domain's ID, or NULL for >> + * local ranges. */ >> + >> +static char* get_forest_root_id(struct domain_info *head, char* >> domain_id) { >> + >> + /* For local ranges there is no forest root domain, >> + * so consider only ranges with domain_id set */ >> + if (domain_id != NULL) { >> + while(head) { >> + if (strcasecmp(head->domain_id, domain_id) == 0) { >> + return head->forest_root_id; >> + } >> + head = head->next; >> + } >> + } >> + >> + return NULL; >> +} >> + > > Fixed, updated patch attached. -- 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-0158-5-Extend-ipa-range-check-DS-plugin-to-handle-range-typ.patch Type: text/x-patch Size: 17222 bytes Desc: not available URL: From jpazdziora at redhat.com Tue Apr 1 10:03:12 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 1 Apr 2014 12:03:12 +0200 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <533A7353.7040909@redhat.com> References: <5334163C.7060007@redhat.com> <20140401064904.GB3872@redhat.com> <20140401071155.GA17186@redhat.com> <533A6810.7020008@redhat.com> <533A7353.7040909@redhat.com> Message-ID: <20140401100312.GG3872@redhat.com> On Tue, Apr 01, 2014 at 10:05:39AM +0200, Tomas Babej wrote: > > > Yes, that was the intention. Mistake on my part, I'll send updated patches. > > > > Updated patch attached. Ack based on reading the code and documentation for slapi_ch_free_string. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From tbabej at redhat.com Tue Apr 1 11:00:47 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 01 Apr 2014 13:00:47 +0200 Subject: [Freeipa-devel] [PATCH 0162] ipa-pwd-extop: Fix memory leak in ipapwd_pre_bind Message-ID: <533A9C5F.9090300@redhat.com> Hi, We need to free the entry before returning from the function. https://fedorahosted.org/freeipa/ticket/4295 -- 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-0162-ipa-pwd-extop-Fix-memory-leak-in-ipapwd_pre_bind.patch Type: text/x-patch Size: 1131 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 1 11:32:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Apr 2014 13:32:29 +0200 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <1396281660.1844.100.camel@willson.li.ssimo.org> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <1396270435.1844.98.camel@willson.li.ssimo.org> <5339701B.9070901@redhat.com> <1396281660.1844.100.camel@willson.li.ssimo.org> Message-ID: <533AA3CD.2010203@redhat.com> On 03/31/2014 06:01 PM, Simo Sorce wrote: > On Mon, 2014-03-31 at 15:39 +0200, Martin Kosek wrote: >> On 03/31/2014 02:53 PM, Simo Sorce wrote: >>> On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote: >> ... >>>>> 3) Add a special attribute to mark "public" containers, and add an ACI >>>>> with a filter on that. Something like objectClass=ipaPublicContainer >>>>> would do. >>>> there is one more option >>>> 4) add an allow aci for cn=accounts,$S and a deny aci for >>>> cn=*,cn=accounts,$S or uid=*,cn=accounts,$S >>> >>> We want to get rid of deny ACIs if at all possible. >>> >>>> In general I think we should implement 1), there will be other scenarios >>>> where it could be useful. If something is needed imemdiately I would >>>> also prefer 3) >>> >>> I wonder, can we have an objectclass that defines no attributes ? >>> Or do we always need to have a MAY at least ? >> >> This particular objectclass could have just one MUST attribute - cn. Similarly >> to what nsContainer has. >> >>> Anyway I agree that the simplest solution would be to have an >>> objectclass to filter on. >>> >>> But I see 2 options. >>> 1. objectClass=ipaPublicContainer >>> 2. objectClass=ipaPrivateContainer >>> >>> The problem with the second is adding a >>> (!(objectclass=ipaPrivateContainer)) everywhere ... >>> >> >> I already elaborated on that topic later in this thread, please check it. It >> also includes an attached list of container we already have. IMO most of >> containers we have will be public, rather than private as LDAP nsContainer's cn >> attribute is semantically not meant to contain secrets we want to hide. >> >> So instead of adding 61 ipaPublicContainer everywhere I would just allow >> reading nsContainers (cn+objectclass) anonymously + have ipaPrivateContainer >> available in case we need it (I am not aware of any such case though). > > Yeah sorry, I replied in order. > > I agree with your proposal of allowing (objectclass=nsContainer) and a > targetfilter that simply excludes the cn=etc subtree. > > Simo. Ok. I just wonder if we really need the ipaPrivateContainer ACI exception. We may want to wait with such objectclass unless it is really needed. For now, it did not seem to me that there is any entry where it is needed. Martin From abokovoy at redhat.com Tue Apr 1 11:59:42 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 1 Apr 2014 14:59:42 +0300 Subject: [Freeipa-devel] [PATCH 0162] ipa-pwd-extop: Fix memory leak in ipapwd_pre_bind In-Reply-To: <533A9C5F.9090300@redhat.com> References: <533A9C5F.9090300@redhat.com> Message-ID: <20140401115942.GK3094@redhat.com> On Tue, 01 Apr 2014, Tomas Babej wrote: >Hi, > >We need to free the entry before returning from the function. > >https://fedorahosted.org/freeipa/ticket/4295 ACK. -- / Alexander Bokovoy From simo at redhat.com Tue Apr 1 12:31:23 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 01 Apr 2014 08:31:23 -0400 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <533AA3CD.2010203@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <1396270435.1844.98.camel@willson.li.ssimo.org> <5339701B.9070901@redhat.com> <1396281660.1844.100.camel@willson.li.ssimo.org> <533AA3CD.2010203@redhat.com> Message-ID: <1396355483.1844.141.camel@willson.li.ssimo.org> On Tue, 2014-04-01 at 13:32 +0200, Martin Kosek wrote: > On 03/31/2014 06:01 PM, Simo Sorce wrote: > > On Mon, 2014-03-31 at 15:39 +0200, Martin Kosek wrote: > >> On 03/31/2014 02:53 PM, Simo Sorce wrote: > >>> On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote: > >> ... > >>>>> 3) Add a special attribute to mark "public" containers, and add an ACI > >>>>> with a filter on that. Something like objectClass=ipaPublicContainer > >>>>> would do. > >>>> there is one more option > >>>> 4) add an allow aci for cn=accounts,$S and a deny aci for > >>>> cn=*,cn=accounts,$S or uid=*,cn=accounts,$S > >>> > >>> We want to get rid of deny ACIs if at all possible. > >>> > >>>> In general I think we should implement 1), there will be other scenarios > >>>> where it could be useful. If something is needed imemdiately I would > >>>> also prefer 3) > >>> > >>> I wonder, can we have an objectclass that defines no attributes ? > >>> Or do we always need to have a MAY at least ? > >> > >> This particular objectclass could have just one MUST attribute - cn. Similarly > >> to what nsContainer has. > >> > >>> Anyway I agree that the simplest solution would be to have an > >>> objectclass to filter on. > >>> > >>> But I see 2 options. > >>> 1. objectClass=ipaPublicContainer > >>> 2. objectClass=ipaPrivateContainer > >>> > >>> The problem with the second is adding a > >>> (!(objectclass=ipaPrivateContainer)) everywhere ... > >>> > >> > >> I already elaborated on that topic later in this thread, please check it. It > >> also includes an attached list of container we already have. IMO most of > >> containers we have will be public, rather than private as LDAP nsContainer's cn > >> attribute is semantically not meant to contain secrets we want to hide. > >> > >> So instead of adding 61 ipaPublicContainer everywhere I would just allow > >> reading nsContainers (cn+objectclass) anonymously + have ipaPrivateContainer > >> available in case we need it (I am not aware of any such case though). > > > > Yeah sorry, I replied in order. > > > > I agree with your proposal of allowing (objectclass=nsContainer) and a > > targetfilter that simply excludes the cn=etc subtree. > > > > Simo. > > Ok. I just wonder if we really need the ipaPrivateContainer ACI exception. We > may want to wait with such objectclass unless it is really needed. For now, it > did not seem to me that there is any entry where it is needed. I would hold on as well. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Apr 1 14:26:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Apr 2014 16:26:29 +0200 Subject: [Freeipa-devel] [PATCH] 468 Make ipa-client-automount backwards compatible Message-ID: <533ACC95.9050709@redhat.com> ipa-client-automount calls automountlocation-show command during the process. Unfortunately, FreeIPA commands are forward compatible only and thus fail the installer. Similarly to ipa-client-install, call XML-RPC interface directly with version fixed to 2.0 (command was already available at that version) to fix the failure. https://fedorahosted.org/freeipa/ticket/4290 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-468-make-ipa-client-automount-backwards-compatible.patch Type: text/x-patch Size: 1636 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 1 15:12:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 01 Apr 2014 17:12:06 +0200 Subject: [Freeipa-devel] OTP work, what's left? In-Reply-To: <53353E1F.2080809@redhat.com> References: <20140323212657.GC3482@redhat.com> <53353E1F.2080809@redhat.com> Message-ID: <533AD746.6000906@redhat.com> On 03/28/2014 10:17 AM, Martin Kosek wrote: > On 03/23/2014 10:26 PM, Alexander Bokovoy wrote: >> Hi! >> >> I've updated my COPR repo with current git master versions of FreeIPA >> and SSSD with few added patches on top that close OTP gaps (Nathaniel's >> patch 0038 and Jakub Hrozek's patch for password changes). >> >> With these patches we currently lack following parts of the OTP work: >> >> - OTP sync client. Still in development, patches and approach need >> additional review/discussion on the list >> >> - Password change in WebUI fails when OTP token exist for the user. More >> detailed examination is needed, I'm getting ACIError. >> >> >> http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ > > Alexander or Nathaniel, I see you progressed with the OTP development a lot, > good job. > > Please provide a clean list of patches + information who acked what so that it > can be pushed to master. Hint: "OTP Patches" thread is too chaotic for me to > follow. > > Martin Hi Nathaniel, I did a quick search in the thread and it seems to me that at least following 2 patches are not merged (though appears to be ACKed): [PATCH 17/17] schema-compat: set precedence to 49 to allow OTP binds over compat tree [PATCH] freeipa.spec.in: update dependencies to 389-ds and selinux-policy Is that all that is left to be pushed from this long thread? Thanks, Martin From rcritten at redhat.com Tue Apr 1 17:33:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2014 13:33:21 -0400 Subject: [Freeipa-devel] [PATCH] 468 Make ipa-client-automount backwards compatible In-Reply-To: <533ACC95.9050709@redhat.com> References: <533ACC95.9050709@redhat.com> Message-ID: <533AF861.4070106@redhat.com> Martin Kosek wrote: > ipa-client-automount calls automountlocation-show command during the > process. Unfortunately, FreeIPA commands are forward compatible only > and thus fail the installer. > > Similarly to ipa-client-install, call XML-RPC interface directly > with version fixed to 2.0 (command was already available at that > version) to fix the failure. > > https://fedorahosted.org/freeipa/ticket/4290 ACK. Tested F-20 client against RHEL 6.5 server. rob From pspacek at redhat.com Tue Apr 1 18:29:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 01 Apr 2014 20:29:10 +0200 Subject: [Freeipa-devel] [PATCH 0231] Fix record parsing to prevent child zone corruption Message-ID: <533B0576.2090409@redhat.com> Hello, Fix record parsing to prevent child zone corruption. Child zone hosted on the same server as parent zone was corrupted by bug in update_record(). Child zone's apex was modified by update_records() instead of delegation records in the parent zone. https://fedorahosted.org/bind-dyndb-ldap/ticket/134 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0231-Fix-record-parsing-to-prevent-child-zone-corruption.patch Type: text/x-patch Size: 1674 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 2 06:48:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Apr 2014 08:48:49 +0200 Subject: [Freeipa-devel] [PATCH] 468 Make ipa-client-automount backwards compatible In-Reply-To: <533AF861.4070106@redhat.com> References: <533ACC95.9050709@redhat.com> <533AF861.4070106@redhat.com> Message-ID: <533BB2D1.9090502@redhat.com> On 04/01/2014 07:33 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> ipa-client-automount calls automountlocation-show command during the >> process. Unfortunately, FreeIPA commands are forward compatible only >> and thus fail the installer. >> >> Similarly to ipa-client-install, call XML-RPC interface directly >> with version fixed to 2.0 (command was already available at that >> version) to fix the failure. >> >> https://fedorahosted.org/freeipa/ticket/4290 > > ACK. Tested F-20 client against RHEL 6.5 server. > > rob > Thanks. Pushed to: master: 66fb4d5e849a049e95d3ef4fcf2b86217488634d ipa-3-3: ee2fac9bee6728facfa4525b8f97585f7030a14c Martin From jcholast at redhat.com Wed Apr 2 09:13:14 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 02 Apr 2014 11:13:14 +0200 Subject: [Freeipa-devel] [PATCH] 260 Fix update_ca_renewal_master plugin on CA-less installs Message-ID: <533BD4AA.6040705@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-260-Fix-update_ca_renewal_master-plugin-on-CA-less-insta.patch Type: text/x-patch Size: 4849 bytes Desc: not available URL: From tbabej at redhat.com Wed Apr 2 11:34:04 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 02 Apr 2014 13:34:04 +0200 Subject: [Freeipa-devel] [PATCH 0001] Add basic trust and legacy client integration tests Message-ID: <533BF5AC.6050605@redhat.com> Hi, this adds basic trust and legacy client integration tests to our Jenkins jobs repo. -- 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-ci-tbabej-0001-Add-basic-trust-and-legacy-client-integration-tests.patch Type: text/x-patch Size: 3141 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 2 11:56:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Apr 2014 13:56:24 +0200 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <20140401100312.GG3872@redhat.com> References: <5334163C.7060007@redhat.com> <20140401064904.GB3872@redhat.com> <20140401071155.GA17186@redhat.com> <533A6810.7020008@redhat.com> <533A7353.7040909@redhat.com> <20140401100312.GG3872@redhat.com> Message-ID: <533BFAE8.2030906@redhat.com> On 04/01/2014 12:03 PM, Jan Pazdziora wrote: > On Tue, Apr 01, 2014 at 10:05:39AM +0200, Tomas Babej wrote: >> >>> Yes, that was the intention. Mistake on my part, I'll send updated patches. >>> >> >> Updated patch attached. > > Ack based on reading the code and documentation for > slapi_ch_free_string. > Ok, thanks. Though I would like this patch to be also functionally tested that it does not break anything, ideally together with your other ipa-range patches. Martin From mbasti at redhat.com Wed Apr 2 12:07:10 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 02 Apr 2014 14:07:10 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin Message-ID: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> Helo list, this patchset allows to use internationalized domian in DNS plugin. - dns names are stored in ACE form(punycoded) in LDAP - raw option shows dns data in ACE form, otherwise dns names are converted to unicode - plugin allow all characters in domain name, which are valid by IDN RFCs (almost everything including non-printable), should be validation more restrictive? (there is bug in dnspython with special characters, will be fixed soon) - TODO update WebUI to support DNSName objects Required patches: freeipa-jcholast-255-Allow-primary-keys-to-use-different-type-than-unicod.patch freeipa-jcholast-256-Support-API-version-specific-RPC-marshalling.patch freeipa-jcholast-257-Replace-get_syntax-method-of-IPASimpleObject-with-ne.patch freeipa-jcholast-258-Use-raw-attribute-values-in-command-result-when-raw-.patch freeipa-jcholast-259-Keep-original-name-when-setting-attribute-in-LDAPEnt.patch Patches attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0029-Allows-to-sort-non-text-entries.patch Type: text/x-patch Size: 1818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0030-DNSName-type.patch Type: text/x-patch Size: 3680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0031-DNSNameParam-parameter.patch Type: text/x-patch Size: 4810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0032-New-capability-added.patch Type: text/x-patch Size: 1469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0033-Convert-DNSName-in-Str-class.patch Type: text/x-patch Size: 994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0034-DNSName-data-transport-in-RPC.patch Type: text/x-patch Size: 3247 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0035-CLI-conversion-of-DNSName-type.patch Type: text/x-patch Size: 1072 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0036-DNSName-conversion-in-ipaldap.patch Type: text/x-patch Size: 1722 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0037-Modified-has_output-attributes.patch Type: text/x-patch Size: 4411 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0038-Modified-dns-related-global-functions.patch Type: text/x-patch Size: 17215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0039-Modified-records-and-zone-parameters-to-use-DNSNameP.patch Type: text/x-patch Size: 7236 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0040-Modified-record-and-zone-class-to-support-IDN.patch Type: text/x-patch Size: 23044 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0041-_domain_name_validatord-moved-from-DNS-to-realmdomai.patch Type: text/x-patch Size: 2309 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0042-move-hostname-validation-from-DNS-to-hosts.patch Type: text/x-patch Size: 2507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0043-use-DNSName-in-functions-imported-from-DNS-plugin.patch Type: text/x-patch Size: 2249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0044-API-change.patch Type: text/x-patch Size: 39963 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0045-DNS-modified-tests.patch Type: text/x-patch Size: 56744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0046-DNS-new-tests.patch Type: text/x-patch Size: 34928 bytes Desc: not available URL: From abokovoy at redhat.com Wed Apr 2 12:10:30 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 2 Apr 2014 15:10:30 +0300 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <533BFAE8.2030906@redhat.com> References: <5334163C.7060007@redhat.com> <20140401064904.GB3872@redhat.com> <20140401071155.GA17186@redhat.com> <533A6810.7020008@redhat.com> <533A7353.7040909@redhat.com> <20140401100312.GG3872@redhat.com> <533BFAE8.2030906@redhat.com> Message-ID: <20140402121030.GM3094@redhat.com> On Wed, 02 Apr 2014, Martin Kosek wrote: >On 04/01/2014 12:03 PM, Jan Pazdziora wrote: >> On Tue, Apr 01, 2014 at 10:05:39AM +0200, Tomas Babej wrote: >>> >>>> Yes, that was the intention. Mistake on my part, I'll send updated patches. >>>> >>> >>> Updated patch attached. >> >> Ack based on reading the code and documentation for >> slapi_ch_free_string. >> > >Ok, thanks. Though I would like this patch to be also functionally tested that >it does not break anything, ideally together with your other ipa-range patches. It is on my test list, don't worry. -- / Alexander Bokovoy From pspacek at redhat.com Wed Apr 2 12:36:37 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Apr 2014 14:36:37 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add wait_for_dns option to default.conf Message-ID: <533C0455.9010101@redhat.com> Hello, Add wait_for_dns option to default.conf. This option makes record changes in DNS tree synchronous. IPA calls will wait until new data are visible over DNS protocol or until timeout. It is intended only for testing. It should prevent tests from failing if there is bigger delay between changes in LDAP and DNS. My personal recommendation is to use value "5" (for testing!). -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0017-Add-wait_for_dns-option-to-default.conf.patch Type: text/x-patch Size: 15865 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 2 12:38:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Apr 2014 14:38:27 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add wait_for_dns option to default.conf In-Reply-To: <533C0455.9010101@redhat.com> References: <533C0455.9010101@redhat.com> Message-ID: <533C04C3.5040602@redhat.com> On 2.4.2014 14:36, Petr Spacek wrote: > Hello, > > Add wait_for_dns option to default.conf. > > This option makes record changes in DNS tree synchronous. > IPA calls will wait until new data are visible over DNS protocol > or until timeout. > > It is intended only for testing. It should prevent tests from > failing if there is bigger delay between changes in LDAP and DNS. > > My personal recommendation is to use value "5" (for testing!). Ah, my hands were faster than head :-) This patch was supersedes patch my patch 0015 and should apply to vanilla master (at the moment). -- Petr^2 Spacek From pspacek at redhat.com Wed Apr 2 12:39:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Apr 2014 14:39:26 +0200 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <53353642.4000909@redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> <5304D782.4060704@redhat.com> <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> <530604DC.5090801@redhat.com> <1392908170.2329.4.camel@unused-4-145.brq.redhat.com> <53341648.6070602@redhat.com> <5334556B.80607@redhat.com> <533534BA.1020702@redhat.com> <53353642.4000909@redhat.com> Message-ID: <533C04FE.2090807@redhat.com> On 28.3.2014 09:43, Martin Kosek wrote: > On 03/28/2014 09:37 AM, Petr Viktorin wrote: >> On 03/27/2014 05:44 PM, Petr Spacek wrote: >>> On 27.3.2014 13:15, Martin Kosek wrote: >>>> On 02/20/2014 03:56 PM, Martin Basti wrote: >>>>> On Thu, 2014-02-20 at 14:36 +0100, Petr Spacek wrote: >>>>>> On 19.2.2014 17:55, Martin Basti wrote: >>>>>>> On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote: >>>>>>>> On 19.2.2014 15:11, Petr Spacek wrote: >>>>>>>>> On 18.2.2014 17:34, Nathaniel McCallum wrote: >>>>>>>>>> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: >>>>>>>>>>> On 02/18/2014 04:45 PM, Petr Spacek wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Add wait_for_dns option to default.conf. >>>>>>>>>>>> >>>>>>>>>>>> This option makes record changes in DNS tree synchronous. >>>>>>>>>>>> IPA calls will wait until new data are visible over DNS protocol. >>>>>>>>>>>> >>>>>>>>>>>> It is intended only for testing - it should prevent tests from >>>>>>>>>>>> failing if there is bigger delay between change in LDAP and DNS. >>>>>>>>>>>> >>>>>>>>>>>> I would recommend value like 10 seconds. >>>>>>>>>>> >>>>>>>>>>> Here are a few Python nitpicks you requested. >>>>>>>>> >>>>>>>>> Thank you very much. This new version solves problems you found + >>>>>>>>> adds proper >>>>>>>>> handling for real DNS timeouts. >>>>>>>>> >>>>>>>>>> It seems to me like a more general TimeoutError would be useful >>>>>>>>>> in a >>>>>>>>>> broader context. DNSTimeout seems overly narrow to me, unless I'm >>>>>>>>>> missing something. >>>>>>>>> >>>>>>>>> I would like to keep them separate. DNSTimeout shouldn't be >>>>>>>>> handled at all >>>>>>>>> because it means that your DNS server or database is dead or >>>>>>>>> broken in some >>>>>>>>> interesting way. >>>>>>>>> >>>>>>>>> I assume that generic TimeoutError could be interpreted as 'try it >>>>>>>>> again'/'failover' or something like that. >>>>>>>>> >>>>>>>>> Maybe the DNSTimeout is not the best name, I'm open to suggestions. >>>>>>>> >>>>>>>> I have sent the old version with new name, gggrrr. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> >>>>>>> Tests failed: >>>>>>> test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone >>>>>>> u'zone3.test' ... ok >>>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>>>>> runTest >>>>>>> self.test(*self.arg) >>>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>>> 291, in >>>>>>> >>>>>>> func = lambda: self.check(nice, **test) >>>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>>> 309, in >>>>>>> check >>>>>>> self.check_output(nice, cmd, args, options, expected, >>>>>>> extra_check) >>>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>>> 348, in >>>>>>> check_output >>>>>>> got = api.Command[cmd](*args, **options) >>>>>>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>>>>>> ret = self.run(*args, **options) >>>>>>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>>>>>> return self.forward(*args, **options) >>>>>>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>>>>>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>>>>>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>>>>>> return self._call_command(command, params) >>>>>>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>>>>>> return command(*params) >>>>>>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>>>>>> return self.__request(name, args) >>>>>>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>>>>>> raise error_class(message=error['message']) >>>>>>> DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. >>>>>>> 86400 IN >>>>>>> TXT "IDM.LAB.ENG.BRQ.REDHAT.COM"} got {SERVFAIL} >>>>>>> >>>>>>> ====================================================================== >>>>>>> ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to >>>>>>> u'zone2.test' >>>>>>> zone record using dnsrecord_add >>>>>>> ---------------------------------------------------------------------- >>>>>>> Traceback (most recent call last): >>>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>>>>> runTest >>>>>>> self.test(*self.arg) >>>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>>> 291, in >>>>>>> >>>>>>> func = lambda: self.check(nice, **test) >>>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>>> 309, in >>>>>>> check >>>>>>> self.check_output(nice, cmd, args, options, expected, >>>>>>> extra_check) >>>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>>> 348, in >>>>>>> check_output >>>>>>> got = api.Command[cmd](*args, **options) >>>>>>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>>>>>> ret = self.run(*args, **options) >>>>>>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>>>>>> return self.forward(*args, **options) >>>>>>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>>>>>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>>>>>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>>>>>> return self._call_command(command, params) >>>>>>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>>>>>> return command(*params) >>>>>>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>>>>>> return self.__request(name, args) >>>>>>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>>>>>> raise error_class(message=error['message']) >>>>>>> DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS >>>>>>> ns1.dnszone.test. >>>>>>> zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL} >>>>>>> >>>>>>> configuration was: wait_for_dns=10 >>>>>>> >>>>>>> All tests passed without wait_for_dns option. >>>>>>> >>>>>>> Sometimes at first run, I get only error and testing is interrupted. >>>>>> >>>>>> I hope I covered all corner cases in this version. >>>>>> >>>>>> I renamed DNSTimeout exception to DNSDataMismatch in hope that it >>>>>> will be less >>>>>> confusing. >>>>>> >>>>> >>>>> A change in patch was required to pass doctest. >>>>> With this change ACK. >>>>> Updated patch attached. >>>> >>>> This patch seems to be in limbo for more than one month now. Do I get >>>> it right >>>> that it is now clear to be pushed? >>>> >>>> Is wait_for_dns enabled in our DNS test suite so that it is stable? Do >>>> we want >>>> it to be enabled? >>> >>> Ah, good point. In meantime I have released bind-dyndb-ldap 4.x and >>> nobody complained >> >> Let me do that then! >> >>> about race conditions and mysterious errors in test >>> suite. >> >> Sometimes (very rarely) there are some mysterious failures in the DNS tests. >> They just don't get noticed too much because the ones from automember rebuild >> are far more frequent. > > Yes, I suspect they may be caused by the issue you tried to fix. I would really > like having our tests stable and not dependent on the right timing. Therefore, > if your patch makes that happen and is OK, I would prefer to merge it + enable > it for our test suite. This patch was superseded by my patch 0017. I'm sorry for the confusion. -- Petr^2 Spacek From pviktori at redhat.com Wed Apr 2 15:50:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Apr 2014 17:50:59 +0200 Subject: [Freeipa-devel] [PATCH 0001] Add basic trust and legacy client integration tests In-Reply-To: <533BF5AC.6050605@redhat.com> References: <533BF5AC.6050605@redhat.com> Message-ID: <533C31E3.9070803@redhat.com> On 04/02/2014 01:34 PM, Tomas Babej wrote: > Hi, > > this adds basic trust and legacy client integration tests to our Jenkins > jobs repo. Thanks! Pushed to master at https://github.com/encukou/freeipa-ci -- Petr? From amisnyov at redhat.com Wed Apr 2 15:57:07 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 2 Apr 2014 17:57:07 +0200 Subject: [Freeipa-devel] [PATCH] 565-568 webui: field and widget binding refactoring In-Reply-To: <53343ECB.8070601@redhat.com> References: <53343ECB.8070601@redhat.com> Message-ID: <20140402175707.74951796@unused-4-246.brq.redhat.com> On Thu, 27 Mar 2014 16:07:55 +0100 Petr Vobornik wrote: > The last refactoring I did while implementing RCUE login or more > precisely support for standalone facets which have forms but are not > details facets. > > [PATCH] webui: field and widget binding refactoring > > This is a Web UI wide change. Fields and Widgets binding was > refactored to enable proper two-way binding between them. This should > allow to have one source of truth (field) for multiple consumers - > widgets or something else. One of the goal is to have fields and > widget implementations independent on each other. So that one could > use a widget without field or use one field for multiple widgets, > etc.. > > Basically a fields logic was split into separate components: > - adapters > - parsers & formatters > - binder > > Adapters > - extract data from data source (FreeIPA RPC command result) > - prepares them for commands. > > Parsers > - parse extracted data to format expected by field > - parse widget value to format expected by field > > Formatters > - format field value to format suitable for widgets > - format field value to format suitable for adapter > > Binder > - is a communication bridge between field and widget > - listens to field's and widget's events and call appropriate methods > > Some side benefits: > - better validation reporting in multivalued widget > > [PATCH] webui: replace widget's hidden property with visible > > Hidden was used only in ACI. There is no reason to have two properties > which are negations of each other. > > [PATCH] webui: change widget updated event into value change event > > This change allow us to use proper two way binding between a field and > a widget. In previous implementation field was not changed if > something changed the value of a widget in 'update'. Now listeners > are notified when the widget value is changed by: calling 'update', > 'set_value' or by user change. > > [PATCH] webui-tests: binding test suite > > Add basic tests for two-way binding between a field and two widgets > Integration tests and unit tests ran as expected, looking through the code, and manually testing it confirmed that, so ACK Greets Adam From rcritten at redhat.com Wed Apr 2 23:05:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Apr 2014 19:05:24 -0400 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <53319650.4000303@redhat.com> References: <53319650.4000303@redhat.com> Message-ID: <533C97B4.4030100@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patches implement automatic CA certificate renewal as well > as the initial version of the CA certificate management tool. > > Requires my patches 172-196. > > In order to test, you must install current git version of certmonger > (see ) and set SELinux to > permissive (see ). > Make sure you install certmonger before running > ipa-server-install/ipa-replica-install. On F20 you can use RPMs located > at . > > To test automatic renewal, move system time forward (see > for more info > about certificate renewal testing, nickname of the CA certificate is > "caSigningCert cert-pki-ca"). In CA-full installs the renewal should be > fully automatic, in CA-less installs you should be alerted via syslog to > renew the certificate using ipa-cacert-manage. > > To test manual renewal, run "ipa-cacert-manage renew". You can run it on > any CA master. To make the renewed certificate available on other CA > masters, you must run "getcert resubmit -d /etc/pki/pki-tomcat/alias -n > 'caSigningCert cert-pki-ca'" on each of them. Note that currently you > can't change the chaining of the CA certificate. 241 Not to be too anal, but would it be too outlandish to compare the Authority Key Identifier (if there is one) with the Subject Key ID to see if the cert is self-signed? Same subject then yeah, it is probably self-signed. The keys match? Definitely. 242 I wonder if it would be clearer to use variables instead of a raw list in the return value for these handlers: (result, message) = handler(...) rather than examining result[0], etc. That may be beyond the scope of this patch though. x509.normalize_certificate() can raise an exception, there should be a try/except around it. For an invalid cookie, please include the values seen in the environment in the error message. 243 You are going to end up with a lot of acis with the same comment value. Perhaps add the host in there as well. These are not removed when a master is deleted. 244 There are now several different places where the caCertificate value is updated. I wonder if it's time for a function. I found it it in dsinstance.py, upload_cacert and now renew_ca_cert. 246 caRenewalMaster should be checked when a replica is deleted and moved to another master. This is a good idea. I wonder if a ticket should be opened to do something similar for CRL generation. 247 We've been burned by hardcoded timeouts in the past. Should this be configurable? This module doesn't currently do any logging but it might be worth spitting out a "waiting" message, at least for debugging. 249 nss_init() is always scary to me since we can only have one. I didn't see anything blow up, just wondering if this should be wrapped with an is_initialized()->shutdown() at the top. The find_cert_from_nickname() should be in a try/except in case the cert is not found for some reason. 251 The tool should provide some feedback while it's running. For the impatient (me) it takes a really long time and it's hard to know what is going on, something in between nothing and full debug output. The man page needs some more work too. I think some more explanation is needed and an example would probably be really helpful as well. I think particularly an example for external certs and a description of what you mean by Self-signed CA (I assume you mean IPA-provided). I don't think it really matters how many steps there are unless you are going to provide progress output. Got a backtrace when running as non-root: $ ipa-cacert-manage -v renew ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 168, in execute self.validate_options() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", line 62, in validate_options super(CACertManage, self).validate_options(needs_root=True) File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 189, in validate_options raise ScriptError('Must be root to run %s' % self.command_name, 1) ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The ipa-cacert-manage command failed, exception: ScriptError: Must be root to run ipa-cacert-manage ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be root to run ipa-cacert-manage 252 In what context would this be executing? My guess is that certmonger is trying to do the renewal but a new cert hasn't been issued yet, so this gets sysloged? Still doing functional testing. rob From pviktori at redhat.com Thu Apr 3 10:09:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Apr 2014 12:09:36 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects Message-ID: <533D3360.7080106@redhat.com> Hello, This adds read permissions to read Sudo commands, command groups, rules. Read access is given to all authenticated users. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0504-Add-managed-read-permissions-to-Sudo-objects.patch Type: text/x-patch Size: 4592 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 3 10:09:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Apr 2014 12:09:38 +0200 Subject: [Freeipa-devel] [PATCH] 0505 Default read ACIs for HBAC objects Message-ID: <533D3362.3060208@redhat.com> Hello, This adds read permissions to read HBAC rules, services, and service groups. Read access is given to all authenticated users. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0505-Add-managed-read-permissions-to-HBAC-objects.patch Type: text/x-patch Size: 4216 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 3 10:09:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Apr 2014 12:09:40 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts Message-ID: <533D3364.1010606@redhat.com> Hello, This adds read permissions to read hosts. Read access is given to all authenticated users. For reading host membership info, there is a separate permission that also defaults to all authenticated users. The userPassword attribute is not included for obvious reasons. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0506-Add-managed-read-permissions-to-host.patch Type: text/x-patch Size: 1776 bytes Desc: not available URL: From pvoborni at redhat.com Thu Apr 3 10:42:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Apr 2014 12:42:08 +0200 Subject: [Freeipa-devel] [PATCH] 565-568 webui: field and widget binding refactoring In-Reply-To: <20140402175707.74951796@unused-4-246.brq.redhat.com> References: <53343ECB.8070601@redhat.com> <20140402175707.74951796@unused-4-246.brq.redhat.com> Message-ID: <533D3B00.2040504@redhat.com> On 2.4.2014 17:57, Misnyovszki Adam wrote: > On Thu, 27 Mar 2014 16:07:55 +0100 > Petr Vobornik wrote: > >> The last refactoring I did while implementing RCUE login or more >> precisely support for standalone facets which have forms but are not >> details facets. >> >> [PATCH] webui: field and widget binding refactoring >> >> This is a Web UI wide change. Fields and Widgets binding was >> refactored to enable proper two-way binding between them. This should >> allow to have one source of truth (field) for multiple consumers - >> widgets or something else. One of the goal is to have fields and >> widget implementations independent on each other. So that one could >> use a widget without field or use one field for multiple widgets, >> etc.. >> >> Basically a fields logic was split into separate components: >> - adapters >> - parsers & formatters >> - binder >> >> Adapters >> - extract data from data source (FreeIPA RPC command result) >> - prepares them for commands. >> >> Parsers >> - parse extracted data to format expected by field >> - parse widget value to format expected by field >> >> Formatters >> - format field value to format suitable for widgets >> - format field value to format suitable for adapter >> >> Binder >> - is a communication bridge between field and widget >> - listens to field's and widget's events and call appropriate methods >> >> Some side benefits: >> - better validation reporting in multivalued widget >> >> [PATCH] webui: replace widget's hidden property with visible >> >> Hidden was used only in ACI. There is no reason to have two properties >> which are negations of each other. >> >> [PATCH] webui: change widget updated event into value change event >> >> This change allow us to use proper two way binding between a field and >> a widget. In previous implementation field was not changed if >> something changed the value of a widget in 'update'. Now listeners >> are notified when the widget value is changed by: calling 'update', >> 'set_value' or by user change. >> >> [PATCH] webui-tests: binding test suite >> >> Add basic tests for two-way binding between a field and two widgets >> > > Integration tests and unit tests ran as expected, looking through the > code, and manually testing it confirmed that, so > ACK > > Greets > Adam > Pushed to master: * 0d05a50e19b71cade636d9ca4882e453f614a78c webui: field and widget binding refactoring * aadde0f849bc7f129ef5bfdd96391ebeee273829 webui: replace widget's hidden property with visible * df18a3bc040299dae2dc573667ec7ee2db45a8e5 webui: change widget updated event into value change event * 480eba26a14cc616c4c336a6db69fb8ba66a0a60 webui-tests: binding test suite -- Petr Vobornik From tbabej at redhat.com Thu Apr 3 10:42:37 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 03 Apr 2014 12:42:37 +0200 Subject: [Freeipa-devel] [PATCHES 163-166] Various ipatests fixes Message-ID: <533D3B1D.1060606@redhat.com> Hi. these fix the following: * not properly removed PKI instance on IPA uninstall * improper usage of external hostname of AD subdomain in the legacy client tests * relax regex checks in legacy client tests * put 2 seconds of sleep after restart of SSSD when clearing the cache -- 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-0163-ipatests-Make-sure-that-remnants-of-PKI-are-removed.patch Type: text/x-patch Size: 1218 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0164-ipatests-legacy_clients-Use-hostname-instead-of-exte.patch Type: text/x-patch Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0165-ipatests-legacy_clients-Relax-regex-checks.patch Type: text/x-patch Size: 1458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0166-ipatests-tasks-Wait-2-seconds-after-restart-of-SSSD-.patch Type: text/x-patch Size: 850 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 3 10:55:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Apr 2014 12:55:20 +0200 Subject: [Freeipa-devel] [PATCHES 163-166] Various ipatests fixes In-Reply-To: <533D3B1D.1060606@redhat.com> References: <533D3B1D.1060606@redhat.com> Message-ID: <533D3E18.9050704@redhat.com> On 04/03/2014 12:42 PM, Tomas Babej wrote: > Hi. > > these fix the following: > > * not properly removed PKI instance on IPA uninstall > * improper usage of external hostname of AD subdomain in the legacy > client tests > * relax regex checks in legacy client tests > * put 2 seconds of sleep after restart of SSSD when clearing the cache I will take the review. -- Petr? From pviktori at redhat.com Thu Apr 3 11:34:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Apr 2014 13:34:03 +0200 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers Message-ID: <533D472B.1010807@redhat.com> Hello, This adds anonymous read access to containers, as discussed in this thread: https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html Additionally access is granted for $SUFFIX itself with targetfilter "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, associatedDomain. These are raw ACIs, not permission-based ones. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0507-Allow-anonymous-read-access-to-containers.patch Type: text/x-patch Size: 1696 bytes Desc: not available URL: From simo at redhat.com Thu Apr 3 12:53:31 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Apr 2014 08:53:31 -0400 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers In-Reply-To: <533D472B.1010807@redhat.com> References: <533D472B.1010807@redhat.com> Message-ID: <1396529611.18479.13.camel@willson.li.ssimo.org> On Thu, 2014-04-03 at 13:34 +0200, Petr Viktorin wrote: > Hello, > This adds anonymous read access to containers, as discussed in this > thread: > https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html > > Additionally access is granted for $SUFFIX itself with targetfilter > "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, > associatedDomain. > > These are raw ACIs, not permission-based ones. > Why is this not set in default-aci.ldif as well ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Apr 3 13:19:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Apr 2014 15:19:45 +0200 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers In-Reply-To: <1396529611.18479.13.camel@willson.li.ssimo.org> References: <533D472B.1010807@redhat.com> <1396529611.18479.13.camel@willson.li.ssimo.org> Message-ID: <533D5FF1.3000409@redhat.com> On 04/03/2014 02:53 PM, Simo Sorce wrote: > On Thu, 2014-04-03 at 13:34 +0200, Petr Viktorin wrote: >> Hello, >> This adds anonymous read access to containers, as discussed in this >> thread: >> https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html >> >> Additionally access is granted for $SUFFIX itself with targetfilter >> "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, >> associatedDomain. >> >> These are raw ACIs, not permission-based ones. >> > > Why is this not set in default-aci.ldif as well ? > > Simo. Because we don't want to duplicate information. -- Petr? From simo at redhat.com Thu Apr 3 13:28:15 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 03 Apr 2014 09:28:15 -0400 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers In-Reply-To: <533D5FF1.3000409@redhat.com> References: <533D472B.1010807@redhat.com> <1396529611.18479.13.camel@willson.li.ssimo.org> <533D5FF1.3000409@redhat.com> Message-ID: <1396531695.18479.16.camel@willson.li.ssimo.org> On Thu, 2014-04-03 at 15:19 +0200, Petr Viktorin wrote: > On 04/03/2014 02:53 PM, Simo Sorce wrote: > > On Thu, 2014-04-03 at 13:34 +0200, Petr Viktorin wrote: > >> Hello, > >> This adds anonymous read access to containers, as discussed in this > >> thread: > >> https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html > >> > >> Additionally access is granted for $SUFFIX itself with targetfilter > >> "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, > >> associatedDomain. > >> > >> These are raw ACIs, not permission-based ones. > >> > > > > Why is this not set in default-aci.ldif as well ? > > > > Simo. > > Because we don't want to duplicate information. So are we removing default-aci.ldif completely ? I think we already mentioned this, but I can hardly recall the discussion, sorry. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Thu Apr 3 13:35:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 03 Apr 2014 15:35:23 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> Message-ID: <533D639B.50901@redhat.com> On 2.4.2014 14:07, Martin Basti wrote: > Helo list, > > this patchset allows to use internationalized domian in DNS plugin. > - dns names are stored in ACE form(punycoded) in LDAP > - raw option shows dns data in ACE form, otherwise dns names are > converted to unicode > - plugin allow all characters in domain name, which are valid by IDN > RFCs (almost everything including non-printable), should be validation > more restrictive? (there is bug in dnspython with special characters, > will be fixed soon) > - TODO update WebUI to support DNSName objects > > Required patches: > freeipa-jcholast-255-Allow-primary-keys-to-use-different-type-than-unicod.patch > freeipa-jcholast-256-Support-API-version-specific-RPC-marshalling.patch > freeipa-jcholast-257-Replace-get_syntax-method-of-IPASimpleObject-with-ne.patch > freeipa-jcholast-258-Use-raw-attribute-values-in-command-result-when-raw-.patch > freeipa-jcholast-259-Keep-original-name-when-setting-attribute-in-LDAPEnt.patch > > > Patches attached. > First batch of comments, so far I have only read the code/patches, without doing actual testing. Patch 30: 1) It might make sense to put all of this into a new module (e.g. dnsutil.py) rather than ipautil. 2) + if isinstance(labels, str): + if not labels: + raise ValueError('empty string') ... + elif isinstance(labels, unicode): + if not labels: + raise ValueError('empty string') It might be nicer to: + if isinstance(labels, basestring) and not labels: + raise ValueError('empty string') + + if isinstance(labels, str): ... + elif isinstance(labels, unicode): 3) + def __nonzero__(self): + return True It would be nice to include a comment about why DNSName always evaluates to True (mention "@"). 4) + @staticmethod + def get_root(): + return DNSName(dns.name.root) + + @staticmethod + def get_origin_sign(): + return DNSName(u'@') + + @staticmethod + def get_rev_zone(): + return DNSName(u'in-addr.arpa.') + + @staticmethod + def get_ip6_rev_zone(): + return DNSName(u'ip6.arpa.') I think you should either drop the "get_" prefix from the name, or (even better) make these global constants. I would shorten "origin_sign" to just "sign". Can you please use tuples of str objects (i.e. what dns.name.Name uses internally) instead of unicode objects for the initialization? I think it should be the preferred style of initializing DNSName objects (DN objects do the same). 5) + def __str__(self): + return super(DNSName, self).to_text() You don't need to use super here. 6) + def ToASCII(self, omit_final_dot=False): + return super(DNSName, self).to_text(omit_final_dot=omit_final_dot).decode('ascii') + + def ToUnicode(self, omit_final_dot=False): + return super(DNSName, self).to_unicode(omit_final_dot=omit_final_dot).decode('utf-8') What was the reason for the unusual naming again? I would prefer PEP-8 compatible names (e.g. "to_ascii" and "to_unicode"), but if the current names absolutely have to stay, please add a comment with explanation. I don't like the "omit_final_dot" flag. IMHO it should be dropped and whether the result includes a final dot or not should depend solely on whether the name is absolute or relative. You can still use e.g. "name.derelativize(root).ToUnicode()" to drop the final dot, which is more explanatory. In ToUnicode, the call to dns.name.Name.to_unicode already returns a unicode object, no need to call decode on it. 7) + def concatenate(self, other): + return DNSName(super(DNSName, self).concatenate(other).labels) + + def relativize(self, origin): + return DNSName(super(DNSName, self).relativize(origin).labels) + + def derelativize(self, origin): + return DNSName(super(DNSName, self).derelativize(origin).labels) + + def choose_relativity(self, origin=None, relativize=True): + return DNSName(super(DNSName, self).choose_relativity(origin=origin, relativize=relativize).labels) Why use ".labels" here? The DNSName constructor knows how to deal with dns.name.Name objects, right? 8) + def is_ip_reverse(self): + if self.is_subdomain(self.get_rev_zone()): + return True + return False + + def is_ip6_reverse(self): + if self.is_subdomain(self.get_ip6_rev_zone()): + return True + return False + + def is_reverse(self): + if self.is_ip_reverse() or self.is_ip6_reverse(): + return True + return False The ifs are all redundant. Return the result of the check directly ("return self.is_subdomain ..." etc.) Patch 31: 1) + kwargs = Param.kwargs + ( + ('require_absolute', bool, False), + ('require_relative', bool, False), + ) What about renaming these to 'only_absolute' and 'only_relative'? IMO it better captures the meaning (yes I know we already discussed the naming in length :-) 2) + except (dns.name.LabelTooLong, UnicodeError): + #dnspython bug?, punycoded label longer than 63 ASCII-chars returns Unicode Error + #instead of LabelTooLong If that's true, it should be handled in DNSName constructor, not here. 3) All of the dns.name exceptions inherit from dns.exception.SyntaxError, I think you should add an except for it as well. 4) + #compare if IDN normalized and original domain match + normalized_domain_name = encodings.idna.nameprep(value) + if(value != normalized_domain_name): + raise ValueError( _("domain name '%(domain)s' and normalized domain name " + "'%(normalized)s' do not match. Please use only " + "normalized domains") % {'domain':value, + 'normalized':normalized_domain_name}) Can we instead try to normalize the name in the beginning of _convert_scalar rather than raise an error later? 5) + except Exception as e: + raise ValidationError(name=self.name, + value=value, + index=index, + error=unicode(e)) Since this is _convert_scalar, I think this should be ConversionError (even if the errors are technically validation errors). Also, use self.get_param_name() instead of self.name. 6) I'm not a fan of the layout of _convert_scalar, can you please use something like this instead (includes changes requested in the previous comments): def _convert_scalar(self, value, index): if isinstance(value, unicode): value = encodings.idna.nameprep(value) error = None try: value = DNSName(value) except dns.name.BadEscape: error = _("invalid escape code") ... except dns.exception.SyntaxError: error = _("invalid syntax") if error: raise ConversionError( name=self.get_param_name(), index=index, error=error) return super(DNSNameParam, self)._convert_scalar(value, index) Patch 33: Why is this patch necessary? It does not seem right to me. Patch 34: This patch should be squashed with patch 32. They don't make sense without each other. Patch 37: 1) -def _rname_validator(ugettext, zonemgr): What's up with this renaming of everything? Don't do it please, unless absolutely necessary. 2) You don't need to redefine has_output for dnszone_add, dnszone_mod, dnszone_show, dnsrecord_add, dnsrecord_mod and dnsrecord_show. They already use standard_entry. 3) + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + assert isinstance(dn, DN) + _ns_zone_post_convert(entry_attrs, **options) + return dn + Please don't use stuff that is not defined in this or previous patches. IPA should be at least buildable after each patch is applied. 4) has_output = output.standard_value + msg_summary = _('Disabled DNS zone "%(value)s"') No new whitespace please (seen 2 times in the patch). Patch 38: 1) +_dns_zone_record = DNSName(u'@') You know you already defined a constant for this in patch 30, right? 2) No new whitespace please (seen 2 times in the patch). 3) + #TODO This is used by realmdomains.py (but it shouldnt allow classless), not used in DNS + #TODO This is used by Host.py I don't think you should add these comments, since they are resolved in patches 41 and 42. 4) +def _hostname_validator_idn(ugettext, value): + assert isinstance(value, DNSName) + + req_len = 2 + if value.is_absolute(): + req_len = 3 + if len(value.labels) < req_len: + return _('invalid domain-name: not fully qualified') + + return None Why the "_idn" postfix? It does not seem to be related to IDN. However, it does seem like it does the same thing as _hostname_validator, so I think they should be merged. 5) zonename = zone['idnsname'][0] - if revdns.endswith(zonename) and len(zonename) > len(revzone): - revzone = zonename + if revdns.is_subdomain(zonename.make_absolute()): + if revzone is None: + revzone = zonename + elif zonename.is_subdomain(revzone): + revzone = zonename The idnsname returned from dnszone_find should already be absolute, so why "zonename.make_absolute()"? You can shorten the condition to: if revdns.is_subdomain(zonename) and (revzone is None or zonename.is_subdomain(revzone)) 6) - revzone = u'.'.join(items[pos:]) + revzone = DNSName(u'.'.join(items[pos:])) You join the items here into string which is split again in DNSName. Use this instead: revzone = DNSName(items[pos:]) 7) - return revzone, revname + return DNSName(revzone), DNSName(revname) Aren't both revzone and revname DNSName objects already? 8) - reason=_('DNS zone %(zone)s not found') % dict(zone=domain) + reason=_('DNS zone %(zone)s not found') % dict(zone=domain.ToUnicode()) Is the ".ToUnicode()" necessary? (seen 4 times in the patch) 9) IMO normalize_zonemgr_idn and validate_zonemgr_idn should be merged into normalize_zonemgr and validate_zonemgr, respectively. 10) def zone_is_reverse(zone_name): - zone_name = normalize_zone(zone_name) - if any(zone_name.endswith(name) for name in REVERSE_DNS_ZONES): - return True + if(isinstance(zone_name, DNSName)): + if any(zone_name.is_subdomain(DNSName(name)) for name in REVERSE_DNS_ZONES): + return True + else: + zone_name = normalize_zone(zone_name) + if any(zone_name.endswith(name) for name in REVERSE_DNS_ZONES): + return True return False Something like this would definitely be better: def zone_is_reverse(zone_name): if not isinstance(zone_name, DNSName): zone_name = DNSName(zone_name) return zone_name.is_reverse() Patch 39: 1) - Str('hostname', - _hostname_validator, - normalizer=_normalize_hostname, + DNSNameParam('hostname', + #RFC 2317 section 5.2 -- don't have to be FQDN It seems you are changing behavior here. Such things belong in separate patches. Patch 40: 1) + addr = DNSName(u'') This will always raise ValueError with the current implementation of DNSName. 2) No new whitespace please (seen 5 times in the patch). Patch 43: I think this patch should be squashed into patch 38. Patch 44: This patch should be squashed into patch 39. 1) +<<<<<<< HEAD output: PrimaryKey('value', None, None) +======= +output: Output('value', , None) +>>>>>>> 5df7ed2... API change It seems you overlooked this. This is all for now. Expect more later ;-) Honza -- Jan Cholasta From abokovoy at redhat.com Thu Apr 3 14:31:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 3 Apr 2014 17:31:40 +0300 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <533BFAE8.2030906@redhat.com> References: <5334163C.7060007@redhat.com> <20140401064904.GB3872@redhat.com> <20140401071155.GA17186@redhat.com> <533A6810.7020008@redhat.com> <533A7353.7040909@redhat.com> <20140401100312.GG3872@redhat.com> <533BFAE8.2030906@redhat.com> Message-ID: <20140403143140.GU3094@redhat.com> On Wed, 02 Apr 2014, Martin Kosek wrote: >On 04/01/2014 12:03 PM, Jan Pazdziora wrote: >> On Tue, Apr 01, 2014 at 10:05:39AM +0200, Tomas Babej wrote: >>> >>>> Yes, that was the intention. Mistake on my part, I'll send updated patches. >>>> >>> >>> Updated patch attached. >> >> Ack based on reading the code and documentation for >> slapi_ch_free_string. >> > >Ok, thanks. Though I would like this patch to be also functionally tested that >it does not break anything, ideally together with your other ipa-range patches. ACK to 0162, 0161, 0158 (should be applied in this order). # ipa idrange-find ---------------- 2 ranges matched ---------------- Range name: AD.TEST_id_range First Posix ID of the range: 1115000000 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-2275361654-3393353068-3720134936 Range type: Active Directory domain range Range name: T.VDA.LI_id_range First Posix ID of the range: 917400000 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 ---------------------------- Number of entries returned 2 ---------------------------- # ipa idrange-add AD.TEST_1_id_range First Posix ID of the range: 1119000000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 First RID of the secondary RID range: 1000000 ipa: ERROR: Constraint violation: New primary rid range overlaps with existing primary rid range. the message comes from the ipa-range-check plugin. -- / Alexander Bokovoy From pvoborni at redhat.com Thu Apr 3 14:36:59 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Apr 2014 16:36:59 +0200 Subject: [Freeipa-devel] Changing RCUE to PatternFly Message-ID: <533D720B.7090305@redhat.com> Hi all, this is a notice about what I'm going to do so you can raise objections before I spend any time on it. == Intro == First some facts: 1. RCUE was based on Bootstrap 2 (BS2), it used BS2 css file and provided it's own less files with overrides 2. the RCUE adoption started with this version at the end of last year 3. during the winter RCUE was renamed to PatternFly and rebased on Bootstrap 3. It doesn't use BS 3 CSS file anymore but it uses its LESS files to make just one output CSS. 4. PatternFly+Bootstrap 3 LESS files can be compiled only by NodeJS less compiler atm. Support in python-lesscpy is being implemented by OpenStack guys. I planned to upgrade from RCUE to PatternFly when python-lesscpy was ready but now it seems that it will happen no sooner than in F21. As the adoption goes forward I need more stuff from PatternFly (styles for tables, alerts, tabs,...). Using RCUE and cherry picking from BS3 and PatternFly is messy and creates more work. So I decided to upgrade now. The issue with css file provided by PatternFly project is that, that it contains font definitions which force us to bundle font files. == What I'm going to do == - I'll prepare simple less file which will use(combine) all Bootstrap 3, PatternFly and FontAwesome LESS files without the ones which force us to bundle fonts (we already have replacements for those). - it will be compiled by developer using nodejs-lessc - minified output CSS will be added to our git - it should change rarely - I'll document how I did it/write script so others can reproduce it later when needed No third-party LESS files will be in our git except variables.less from each project so we will be able to use the constants in our style definitions (simplifies upgrades). Our own LESS files don't use any new Less markup features so we are still able to compile it with current version of python-lesscpy. -- Petr Vobornik From npmccallum at redhat.com Thu Apr 3 15:07:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 03 Apr 2014 11:07:09 -0400 Subject: [Freeipa-devel] OTP work, what's left? In-Reply-To: <533AD746.6000906@redhat.com> References: <20140323212657.GC3482@redhat.com> <53353E1F.2080809@redhat.com> <533AD746.6000906@redhat.com> Message-ID: <1396537629.8470.12.camel@localhost.localdomain> On Tue, 2014-04-01 at 17:12 +0200, Martin Kosek wrote: > On 03/28/2014 10:17 AM, Martin Kosek wrote: > > On 03/23/2014 10:26 PM, Alexander Bokovoy wrote: > >> Hi! > >> > >> I've updated my COPR repo with current git master versions of FreeIPA > >> and SSSD with few added patches on top that close OTP gaps (Nathaniel's > >> patch 0038 and Jakub Hrozek's patch for password changes). > >> > >> With these patches we currently lack following parts of the OTP work: > >> > >> - OTP sync client. Still in development, patches and approach need > >> additional review/discussion on the list > >> > >> - Password change in WebUI fails when OTP token exist for the user. More > >> detailed examination is needed, I'm getting ACIError. > >> > >> > >> http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ > > > > Alexander or Nathaniel, I see you progressed with the OTP development a lot, > > good job. > > > > Please provide a clean list of patches + information who acked what so that it > > can be pushed to master. Hint: "OTP Patches" thread is too chaotic for me to > > follow. > > > > Martin > > Hi Nathaniel, > > I did a quick search in the thread and it seems to me that at least following 2 > patches are not merged (though appears to be ACKed): > > [PATCH 17/17] schema-compat: set precedence to 49 to allow OTP binds > over compat tree > [PATCH] freeipa.spec.in: update dependencies to 389-ds and > selinux-policy > > Is that all that is left to be pushed from this long thread? Yup. Nathaniel From justin.brown at fandingo.org Thu Apr 3 16:33:51 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Thu, 3 Apr 2014 11:33:51 -0500 Subject: [Freeipa-devel] Ipa-server-install Firewall Support Message-ID: This discussion morphs out of some questions that I asked over on the user's mailing list: https://www.redhat.com/archives/freeipa-users/2014-April/msg00033.html. It's also related to Trac #2110. (The subject says ipa-server-install, but this will also apply to replica installs, too.) What is the expected compatibility with RHEL 5 and 6? Neither of those comes with FirewallD. Integrating with iptables is bound to be messy, and I feel like there's too many ways to get into trouble with destroying a user's iptables configuration. (Due to the unsafety of `iptables-restore`, there's no way to guarantee that the user's configuration will persist through a reboot.) Seeing as FirewallD has been the default in Fedora since 18 and will be in RHEL 7, it seems like a reasonable thing to do. Would there be opposition to making FirewallD the only firewall that ipa-server-install will configure, and just print out iptables (or iptables-save fragments) for non-FirewallD systems? The implementation should be pretty simple and straightforward, but I wanted to run over it briefly to see if there were any initial feedback. First, there's a question of dependence. FirewallD exposes a DBus interface on the system bus. While it is possible to interact with shell commands, I would greatly prefer to make use of DBus directly. That will require pulling in python-dbus as a package dependency. Second, FirewallD operates on "zones" to which interfaces are attached. To apply any sort of configuration, we'll need to attach a freeipa-server FirewallD service to the proper zone. During the current installation program, we already know the server's IP address from a call to installutils.get_server_ip_address(). I'll need to resolve on which interface this IP resides, and then FirewallD can tell me which zone should be modified. It is possible to scrape the output of `ip address` to determine, but that's a messy solution. The better method is to use the NetworkManager DBus interfaces to query for this information. This gets back to my compatibility question above. Fedora doesn't really work without NetworkManager anymore, and I assume that will hold for RHEL 7. Third, do we want to allow the user to limit the network access? I think that it makes sense to allow users to specify a network (e.g. 192.168.0.0/16) to limit accessibility to their FreeIPA server. Yet, there's always some trade-off to adding more options to ipa-server-install. Fourth, FirewallD configuration is simple and quick, so I think it makes sense to get it out of the way early in the install process. I'm thinking right after ipaservices.backup_and_replace_hostname() (line 1,038) runs. Implementation Walkthrough ---------------------------------------- ~$ ipa-server-install --firewall --firewall-allow 192.168.0.0/24 --firewall-allow 192.168.1.0/24 [...] [skip to line 1038] 1. Detect if FirewallD is running via DBus. (If not generate sample iptables rules, print/log them, and continue normal install.) 2. Use NM DBus to resolve IP->interface. (If NM not available, potentially fallback to scrapping `ip a`.) 3. Use FirewallD DBus to resolve interface to zone. 4. FreeIPA will include a service XML template (like dsinstance.INF_TEMPLATE) that specifies the necessary ports/protocols. Write this service file to /etc/firewalld/services/. 5. If the user provided --firewall-allow args, generate rich rules based on the template, and add them to the proper zone. If not, the service is still added as a rich rule (for consistency and ease of uninstall). Thanks, Justin From mkosek at redhat.com Fri Apr 4 06:26:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Apr 2014 08:26:34 +0200 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: References: Message-ID: <533E509A.4000004@redhat.com> On 04/03/2014 06:33 PM, Justin Brown wrote: > This discussion morphs out of some questions that I asked over on the > user's mailing list: > https://www.redhat.com/archives/freeipa-users/2014-April/msg00033.html. > It's also related to Trac #2110. (The subject says ipa-server-install, > but this will also apply to replica installs, too.) > > What is the expected compatibility with RHEL 5 and 6? Neither of those > comes with FirewallD. Integrating with iptables is bound to be messy, > and I feel like there's too many ways to get into trouble with > destroying a user's iptables configuration. (Due to the unsafety of > `iptables-restore`, there's no way to guarantee that the user's > configuration will persist through a reboot.) Seeing as FirewallD has > been the default in Fedora since 18 and will be in RHEL 7, it seems > like a reasonable thing to do. Would there be opposition to making > FirewallD the only firewall that ipa-server-install will configure, > and just print out iptables (or iptables-save fragments) for > non-FirewallD systems? Right. I do not think there will be opposition for firewalld. As you said, it is present in recent Fedoras and RHEL-7.0 and we do not plan to release FreeIPA 4.0 in older systems than that. > The implementation should be pretty simple and straightforward, but I > wanted to run over it briefly to see if there were any initial > feedback. +1. > First, there's a question of dependence. FirewallD exposes a DBus > interface on the system bus. While it is possible to interact with > shell commands, I would greatly prefer to make use of DBus directly. > That will require pulling in python-dbus as a package dependency. I personally have nothing against using python-dbus interface (dbus-python package in Fedora), it is programmatically easier to control that parsing output from commands. > > Second, FirewallD operates on "zones" to which interfaces are > attached. To apply any sort of configuration, we'll need to attach a > freeipa-server FirewallD service to the proper zone. During the > current installation program, we already know the server's IP address > from a call to installutils.get_server_ip_address(). I'll need to > resolve on which interface this IP resides, and then FirewallD can > tell me which zone should be modified. It is possible to scrape the > output of `ip address` to determine, but that's a messy solution. The > better method is to use the NetworkManager DBus interfaces to query > for this information. This gets back to my compatibility question > above. Fedora doesn't really work without NetworkManager anymore, and > I assume that will hold for RHEL 7. Right, I personally do not see a problem here in your thoughts. > Third, do we want to allow the user to limit the network access? I > think that it makes sense to allow users to specify a network (e.g. > 192.168.0.0/16) to limit accessibility to their FreeIPA server. Yet, > there's always some trade-off to adding more options to > ipa-server-install. Hm, I would personally prefer to avoid complicating the feature and start with something easy to configure and straightforward. We can always extend it if wee see an interest. In general, ipa-server-install does the basic, functional and recommended configuration - fine tuning is left for the administrator to continue after that. But I will leave that up to you and other developers. > Fourth, FirewallD configuration is simple and quick, so I think it > makes sense to get it out of the way early in the install process. I'm > thinking right after ipaservices.backup_and_replace_hostname() (line > 1,038) runs. I would actually do it the opposite way and open the ports after the FreeIPA server is fully configured. After all, I do not think we want to open the ports when the server is just half-configured and for example some ACIs are missing. > > > Implementation Walkthrough > ---------------------------------------- > > ~$ ipa-server-install --firewall --firewall-allow 192.168.0.0/24 > --firewall-allow 192.168.1.0/24 [...] > [skip to line 1038] > 1. Detect if FirewallD is running via DBus. (If not generate sample > iptables rules, print/log them, and continue normal install.) We print list of ports that FreeIPA uses at the end of ipa-server-install process. I would report firewalld/iptables related information there. (We for example also create here example BIND zone content and pass it to user, it may make sense to have this around this location). On the beginning of the installation (in the interactive part of ipa-server-install) I would just check if firewalld is available and if not, I would print a warning to user so that he can for example exit the wizard and fix firewalld before continuing. > 2. Use NM DBus to resolve IP->interface. (If NM not available, > potentially fallback to scrapping `ip a`.) > 3. Use FirewallD DBus to resolve interface to zone. > 4. FreeIPA will include a service XML template (like > dsinstance.INF_TEMPLATE) that specifies the necessary ports/protocols. > Write this service file to /etc/firewalld/services/. Ok. We also should not crash if the directory is not available. There are some recommendations about the XML contents in a Bugzilla comment: https://bugzilla.redhat.com/show_bug.cgi?id=885483#c2 I think it would be better to have them all in a single XML file though (like freeipa.xml), less chance of name collisions and we would have all ports in one place. Not sure about the names, but it may be good idea to prefix the port names with "freeipa", i.e. "freeipa-ldap", "freeipa-ldaps", "freeipa-kerberos" to avoid collisions. > 5. If the user provided --firewall-allow args, generate rich rules > based on the template, and add them to the proper zone. If not, the > service is still added as a rich rule (for consistency and ease of > uninstall). Ok. > > > Thanks, > Justin I think you are on a good path Justin, good luck! Martin From mkosek at redhat.com Fri Apr 4 06:52:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Apr 2014 08:52:32 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1395668013.26874.0.camel@localhost.localdomain> References: <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> <20140220112706.GJ16644@redhat.com> <20140220123338.GK16644@redhat.com> <1392905964.1957.0.camel@localhost.localdomain> <1392922612.23210.3.camel@localhost.localdomain> <20140220220859.GR16644@redhat.com> <1392993378.23210.15.camel@localhost.localdomain> <20140319153749.GL16644@redhat.com> <1395668013.26874.0.camel@localhost.localdomain> Message-ID: <533E56B0.10200@redhat.com> On 03/24/2014 02:33 PM, Nathaniel McCallum wrote: > On Wed, 2014-03-19 at 17:37 +0200, Alexander Bokovoy wrote: >> On Fri, 21 Feb 2014, Nathaniel McCallum wrote: >>> On Fri, 2014-02-21 at 00:08 +0200, Alexander Bokovoy wrote: >>>> On Thu, 20 Feb 2014, Nathaniel McCallum wrote: >>>>>>>>> There is an error in libotp's find() function which assumes that >>>>>>>>> get_basedn() always returns non-NULL value. This is not true for at >>>>>>>>> least cn=Directory Manager. >>>>>>>>> >>>>>>>>> Patch attached. >>>>>>>> More fixes required, now that Thierry produced the fix for 389-ds ticket >>>>>>>> 47699 which allows to re-arrange schema-compat and ipa-pwd-extop >>>>>>>> plugins. I'm getting crash in find() in libotp.c for internal search in >>>>>>>> some other conditions but at least user dn now is the correct one. >>>>>>>> >>>>>>>> Stay tuned. >>>>>>> OK, finally I've got it working -- my last patch had error which could >>>>>>> be attributed to the late night time. >>>>>>> >>>>>>> New patch is attached to fix libotp to work properly with empty base dn >>>>>>> (such as cn=Directory Manager). >>>>>>> >>>>>>> Also I'm attaching the patch that sets precedence of schema-compat >>>>>>> plugin to 49 (less than default 50). With this patch and 389-ds with >>>>>>> patch from ticket 47699 compat tree binds work with OTP. >>>>>>> >>>>>>> When updated 389-ds-base will be released, we'll need to add Requires: >>>>>>> to our RPM spec to depend on it. Without the updated 389-ds-base compat >>>>>>> tree binds will not work with OTP but the rest will be working fine. >>>>>>> >>>>>>> Finally, ACK to all OTP patches. >>>>>> >>>>>> ACK to both of these patches. >>>>> >>>>> I've merged the first patch here -- >>>>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00341.html >>>>> >>>>> I just realized the second patch shouldn't be ACK'd until we have a new >>>>> 389DS release with the fix. When that happens, reissue this patch with >>>>> an update versioned require. >>>> No, it can be safely merged as 389DS will use default precedence (50) unless >>>> the fix is there. So the worst we get is the same as now -- OTP binds >>>> will not work over compat tree. And when 389DS will be upgraded, they >>>> will start working after 389DS restart. >>> >>> But this patch doesn't actually do anything until we get the new version >>> of 389DS. If we are ever going to add a versioned dependency on the new >>> 389DS for this feature, it should go in this patch. Otherwise, it is an >>> ACK from me. >> New 389-DS is in Fedora 20 updates stable and Rawhide already. >> 389-ds-base-1.3.2.16-1.fc20. Also, selinux-policy 3.12.1-135 is now in >> Fedora 20 updates testing, providing multiple policy enhancements that >> make possible Apache process to work with kernel-based credentials >> caches. >> >> Attached patch makes use of the new packages. > > ACK Pushed both patches below: [PATCH 17/17] schema-compat: set precedence to 49 to allow OTP binds over compat tree [PATCH] freeipa.spec.in: update dependencies to 389-ds and selinux-policy to master. Martin From mkosek at redhat.com Fri Apr 4 06:52:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Apr 2014 08:52:47 +0200 Subject: [Freeipa-devel] OTP work, what's left? In-Reply-To: <1396537629.8470.12.camel@localhost.localdomain> References: <20140323212657.GC3482@redhat.com> <53353E1F.2080809@redhat.com> <533AD746.6000906@redhat.com> <1396537629.8470.12.camel@localhost.localdomain> Message-ID: <533E56BF.50008@redhat.com> On 04/03/2014 05:07 PM, Nathaniel McCallum wrote: > On Tue, 2014-04-01 at 17:12 +0200, Martin Kosek wrote: >> On 03/28/2014 10:17 AM, Martin Kosek wrote: >>> On 03/23/2014 10:26 PM, Alexander Bokovoy wrote: >>>> Hi! >>>> >>>> I've updated my COPR repo with current git master versions of FreeIPA >>>> and SSSD with few added patches on top that close OTP gaps (Nathaniel's >>>> patch 0038 and Jakub Hrozek's patch for password changes). >>>> >>>> With these patches we currently lack following parts of the OTP work: >>>> >>>> - OTP sync client. Still in development, patches and approach need >>>> additional review/discussion on the list >>>> >>>> - Password change in WebUI fails when OTP token exist for the user. More >>>> detailed examination is needed, I'm getting ACIError. >>>> >>>> >>>> http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ >>> >>> Alexander or Nathaniel, I see you progressed with the OTP development a lot, >>> good job. >>> >>> Please provide a clean list of patches + information who acked what so that it >>> can be pushed to master. Hint: "OTP Patches" thread is too chaotic for me to >>> follow. >>> >>> Martin >> >> Hi Nathaniel, >> >> I did a quick search in the thread and it seems to me that at least following 2 >> patches are not merged (though appears to be ACKed): >> >> [PATCH 17/17] schema-compat: set precedence to 49 to allow OTP binds >> over compat tree >> [PATCH] freeipa.spec.in: update dependencies to 389-ds and >> selinux-policy >> >> Is that all that is left to be pushed from this long thread? > > Yup. > > Nathaniel Thanks, I pushed both to master. Martin From justin.brown at fandingo.org Fri Apr 4 07:04:19 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Fri, 4 Apr 2014 02:04:19 -0500 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <533E509A.4000004@redhat.com> References: <533E509A.4000004@redhat.com> Message-ID: Thanks for the feedback Martin. > I would actually do it the opposite way and open the ports after the FreeIPA server is fully configured. After all, I do not think we want to open the ports when the server is just half-configured and for example some ACIs are missing. My thinking was that nothing would be listening on these ports if the install doesn't succeed, but there's really necessity to modify the firewall configuration early. (All of the internal install communication will be over a local interface (to netfilter) and unblock anyways. I don't have any problem in delaying firewall configuration to the end of install. > We print list of ports that FreeIPA uses at the end of ipa-server-install process. I would report firewalld/iptables related information there. (We for example also create here example BIND zone content and pass it to user, it may make sense to have this around this location). Agreed and noted. > Hm, I would personally prefer to avoid complicating the feature and start with something easy to configure and straightforward. We can always extend it if we see an interest. In general, ipa-server-install does the basic, functional and recommended configuration - fine tuning is left for the administrator to continue after that. But I will leave that up to you and other developers. > I think it would be better to have them all in a single XML file though (like freeipa.xml), less chance of name collisions and we would have all ports in one place. > Not sure about the names, but it may be good idea to prefix the port names with "freeipa", i.e. "freeipa-ldap", "freeipa-ldaps", "freeipa-kerberos" to avoid collisions. My thinking here was that it is quite cumbersome to restrict a FirewallD service to specific networks (i.e. taking a service assigned to a zone and replacing it with rich rules that do allow source restrictions). I'm not sure how people actually use FreeIPA outside my use-case, but if users are unable to restrict server-ipa-install firewall configuration to specific networks, they'll most likely need to depend on an external firewall (e.g. Amazon's EC2 firewall). On the other hand, I totally agree with your apprehension to add more options to ipa-server-install. I'll prepare two patch sets that just add the service (without source restrictions) and another that allows network restrictions. That will make it easier for the project to choose the correct solution and have an implementation for either solution. As to the specific service name, FirewallD already has most service definitions that FreeIPA needs (http(s), kerberos, kpasswd, ntp, etc.). I would imagine that these services will always be available, but I'm going to inquire with the FirewallD project to make sure. If we are sure those services will always be there, I would greatly prefer to use those built-in services as much as possible. For example, FirewallD includes a ldap service, and I don't think there's a good reason to include a freeipa-ldap that covers the same ports. > Ok. We also should not crash if the directory is not available. There are some recommendations about the XML contents in a Bugzilla comment: Yep. I'm always vigilant to catch exceptions. Thanks, Justin On Fri, Apr 4, 2014 at 1:26 AM, Martin Kosek wrote: > On 04/03/2014 06:33 PM, Justin Brown wrote: >> This discussion morphs out of some questions that I asked over on the >> user's mailing list: >> https://www.redhat.com/archives/freeipa-users/2014-April/msg00033.html. >> It's also related to Trac #2110. (The subject says ipa-server-install, >> but this will also apply to replica installs, too.) >> >> What is the expected compatibility with RHEL 5 and 6? Neither of those >> comes with FirewallD. Integrating with iptables is bound to be messy, >> and I feel like there's too many ways to get into trouble with >> destroying a user's iptables configuration. (Due to the unsafety of >> `iptables-restore`, there's no way to guarantee that the user's >> configuration will persist through a reboot.) Seeing as FirewallD has >> been the default in Fedora since 18 and will be in RHEL 7, it seems >> like a reasonable thing to do. Would there be opposition to making >> FirewallD the only firewall that ipa-server-install will configure, >> and just print out iptables (or iptables-save fragments) for >> non-FirewallD systems? > > Right. I do not think there will be opposition for firewalld. As you said, it > is present in recent Fedoras and RHEL-7.0 and we do not plan to release FreeIPA > 4.0 in older systems than that. > > >> The implementation should be pretty simple and straightforward, but I >> wanted to run over it briefly to see if there were any initial >> feedback. > > +1. > >> First, there's a question of dependence. FirewallD exposes a DBus >> interface on the system bus. While it is possible to interact with >> shell commands, I would greatly prefer to make use of DBus directly. >> That will require pulling in python-dbus as a package dependency. > > I personally have nothing against using python-dbus interface (dbus-python > package in Fedora), it is programmatically easier to control that parsing > output from commands. > >> >> Second, FirewallD operates on "zones" to which interfaces are >> attached. To apply any sort of configuration, we'll need to attach a >> freeipa-server FirewallD service to the proper zone. During the >> current installation program, we already know the server's IP address >> from a call to installutils.get_server_ip_address(). I'll need to >> resolve on which interface this IP resides, and then FirewallD can >> tell me which zone should be modified. It is possible to scrape the >> output of `ip address` to determine, but that's a messy solution. The >> better method is to use the NetworkManager DBus interfaces to query >> for this information. This gets back to my compatibility question >> above. Fedora doesn't really work without NetworkManager anymore, and >> I assume that will hold for RHEL 7. > > Right, I personally do not see a problem here in your thoughts. > >> Third, do we want to allow the user to limit the network access? I >> think that it makes sense to allow users to specify a network (e.g. >> 192.168.0.0/16) to limit accessibility to their FreeIPA server. Yet, >> there's always some trade-off to adding more options to >> ipa-server-install. > > Hm, I would personally prefer to avoid complicating the feature and start with > something easy to configure and straightforward. We can always extend it if wee > see an interest. In general, ipa-server-install does the basic, functional and > recommended configuration - fine tuning is left for the administrator to > continue after that. But I will leave that up to you and other developers. > >> Fourth, FirewallD configuration is simple and quick, so I think it >> makes sense to get it out of the way early in the install process. I'm >> thinking right after ipaservices.backup_and_replace_hostname() (line >> 1,038) runs. > > I would actually do it the opposite way and open the ports after the FreeIPA > server is fully configured. After all, I do not think we want to open the ports > when the server is just half-configured and for example some ACIs are missing. > >> >> >> Implementation Walkthrough >> ---------------------------------------- >> >> ~$ ipa-server-install --firewall --firewall-allow 192.168.0.0/24 >> --firewall-allow 192.168.1.0/24 [...] >> [skip to line 1038] >> 1. Detect if FirewallD is running via DBus. (If not generate sample >> iptables rules, print/log them, and continue normal install.) > > We print list of ports that FreeIPA uses at the end of ipa-server-install > process. I would report firewalld/iptables related information there. (We for > example also create here example BIND zone content and pass it to user, it may > make sense to have this around this location). > > On the beginning of the installation (in the interactive part of > ipa-server-install) I would just check if firewalld is available and if not, I > would print a warning to user so that he can for example exit the wizard and > fix firewalld before continuing. > >> 2. Use NM DBus to resolve IP->interface. (If NM not available, >> potentially fallback to scrapping `ip a`.) >> 3. Use FirewallD DBus to resolve interface to zone. >> 4. FreeIPA will include a service XML template (like >> dsinstance.INF_TEMPLATE) that specifies the necessary ports/protocols. >> Write this service file to /etc/firewalld/services/. > > Ok. We also should not crash if the directory is not available. There are some > recommendations about the XML contents in a Bugzilla comment: > > https://bugzilla.redhat.com/show_bug.cgi?id=885483#c2 > > I think it would be better to have them all in a single XML file though (like > freeipa.xml), less chance of name collisions and we would have all ports in one > place. > > Not sure about the names, but it may be good idea to prefix the port names with > "freeipa", i.e. "freeipa-ldap", "freeipa-ldaps", "freeipa-kerberos" to avoid > collisions. > > >> 5. If the user provided --firewall-allow args, generate rich rules >> based on the template, and add them to the proper zone. If not, the >> service is still added as a rich rule (for consistency and ease of >> uninstall). > > Ok. > >> >> >> Thanks, >> Justin > > I think you are on a good path Justin, good luck! > > Martin From mkosek at redhat.com Fri Apr 4 07:17:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Apr 2014 09:17:30 +0200 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: References: <533E509A.4000004@redhat.com> Message-ID: <533E5C8A.20306@redhat.com> On 04/04/2014 09:04 AM, Justin Brown wrote: > Thanks for the feedback Martin. > >> I would actually do it the opposite way and open the ports after the FreeIPA server is fully configured. After all, I do not think we want to open the ports when the server is just half-configured and for example some ACIs are missing. > > My thinking was that nothing would be listening on these ports if the > install doesn't succeed, but there's really necessity to modify the > firewall configuration early. (All of the internal install > communication will be over a local interface (to netfilter) and > unblock anyways. I don't have any problem in delaying firewall > configuration to the end of install. If ipa-server-install does succeed without configuring the firewalld, then we will indeed have no other option than to do it early. I am thinking that we may want to put all the firewalld configuration in ipaserver/install/firewalldinstance.py, and then make the firewalld configuration the actual step of the installation. Something like: ... Configuring Firewall (firewalld) [1/2]: looking up the right zone [2/2]: allowing ports Done configuring Firewall (firewalld). ... The Service class derived object can be really simple, we would just reuse the functionality it already has + let us properly hook into it in ipa-{server,replica}-install and the uninstallation. It would also make it easier to split this functionality to freeipa-server-firewalld if we chose to in a future. >> We print list of ports that FreeIPA uses at the end of ipa-server-install process. I would report firewalld/iptables related information there. (We for example also create here example BIND zone content and pass it to user, it may make sense to have this around this location). > > Agreed and noted. > >> Hm, I would personally prefer to avoid complicating the feature and start with something easy to configure and straightforward. We can always extend it if we see an interest. In general, ipa-server-install does the basic, functional and recommended configuration - fine tuning is left for the administrator to continue after that. But I will leave that up to you and other developers. > >> I think it would be better to have them all in a single XML file though (like freeipa.xml), less chance of name collisions and we would have all ports in one place. > >> Not sure about the names, but it may be good idea to prefix the port names with "freeipa", i.e. "freeipa-ldap", "freeipa-ldaps", "freeipa-kerberos" to avoid collisions. > > My thinking here was that it is quite cumbersome to restrict a > FirewallD service to specific networks (i.e. taking a service assigned > to a zone and replacing it with rich rules that do allow source > restrictions). I'm not sure how people actually use FreeIPA outside my > use-case, but if users are unable to restrict server-ipa-install > firewall configuration to specific networks, they'll most likely need > to depend on an external firewall (e.g. Amazon's EC2 firewall). On the > other hand, I totally agree with your apprehension to add more options > to ipa-server-install. I'll prepare two patch sets that just add the > service (without source restrictions) and another that allows network > restrictions. That will make it easier for the project to choose the > correct solution and have an implementation for either solution. Ok, though I would not make this 2 paralel patch sets, it may be easier for you (and reviewers) to have patches adding basic Firewalld support and then a patch on top of that adding the zone restriction options. > As to the specific service name, FirewallD already has most service > definitions that FreeIPA needs (http(s), kerberos, kpasswd, ntp, > etc.). I would imagine that these services will always be available, > but I'm going to inquire with the FirewallD project to make sure. Ok, a feedback from FirewallD upstream may be valuable > If > we are sure those services will always be there, I would greatly > prefer to use those built-in services as much as possible. For > example, FirewallD includes a ldap service, and I don't think there's > a good reason to include a freeipa-ldap that covers the same ports. Makes sense. > >> Ok. We also should not crash if the directory is not available. There are some recommendations about the XML contents in a Bugzilla comment: > > Yep. I'm always vigilant to catch exceptions. > > Thanks, > Justin Thanks, Martin From abokovoy at redhat.com Fri Apr 4 07:49:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Apr 2014 10:49:51 +0300 Subject: [Freeipa-devel] Changing RCUE to PatternFly In-Reply-To: <533D720B.7090305@redhat.com> References: <533D720B.7090305@redhat.com> Message-ID: <20140404074951.GB14617@redhat.com> On Thu, 03 Apr 2014, Petr Vobornik wrote: >Hi all, > >this is a notice about what I'm going to do so you can raise >objections before I spend any time on it. > >== Intro == >First some facts: >1. RCUE was based on Bootstrap 2 (BS2), it used BS2 css file and >provided it's own less files with overrides >2. the RCUE adoption started with this version at the end of last year >3. during the winter RCUE was renamed to PatternFly and rebased on >Bootstrap 3. It doesn't use BS 3 CSS file anymore but it uses its >LESS files to make just one output CSS. >4. PatternFly+Bootstrap 3 LESS files can be compiled only by NodeJS >less compiler atm. Support in python-lesscpy is being implemented by >OpenStack guys. > >I planned to upgrade from RCUE to PatternFly when python-lesscpy was >ready but now it seems that it will happen no sooner than in F21. > >As the adoption goes forward I need more stuff from PatternFly >(styles for tables, alerts, tabs,...). Using RCUE and cherry picking >from BS3 and PatternFly is messy and creates more work. So I decided >to upgrade now. > >The issue with css file provided by PatternFly project is that, that >it contains font definitions which force us to bundle font files. > >== What I'm going to do == > >- I'll prepare simple less file which will use(combine) all Bootstrap >3, PatternFly and FontAwesome LESS files without the ones which force >us to bundle fonts (we already have replacements for those). >- it will be compiled by developer using nodejs-lessc >- minified output CSS will be added to our git - it should change rarely >- I'll document how I did it/write script so others can reproduce it >later when needed > >No third-party LESS files will be in our git except variables.less >from each project so we will be able to use the constants in our >style definitions (simplifies upgrades). > >Our own LESS files don't use any new Less markup features so we are >still able to compile it with current version of python-lesscpy. ACK. All proposed seems reasonable. -- / Alexander Bokovoy From pspacek at redhat.com Fri Apr 4 07:59:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Apr 2014 09:59:33 +0200 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <533E5C8A.20306@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> Message-ID: <533E6665.6000402@redhat.com> On 4.4.2014 09:17, Martin Kosek wrote: > On 04/04/2014 09:04 AM, Justin Brown wrote: >>> I would actually do it the opposite way and open the ports after the FreeIPA server is fully configured. After all, I do not think we want to open the ports when the server is just half-configured and for example some ACIs are missing. >> >> My thinking was that nothing would be listening on these ports if the >> install doesn't succeed, but there's really necessity to modify the >> firewall configuration early. (All of the internal install >> communication will be over a local interface (to netfilter) and >> unblock anyways. I don't have any problem in delaying firewall >> configuration to the end of install. > > If ipa-server-install does succeed without configuring the firewalld, then we > will indeed have no other option than to do it early. > > I am thinking that we may want to put all the firewalld configuration in > ipaserver/install/firewalldinstance.py, > and then make the firewalld configuration the actual step of the installation. > Something like: > > ... > Configuring Firewall (firewalld) > [1/2]: looking up the right zone > [2/2]: allowing ports > Done configuring Firewall (firewalld). > ... > > The Service class derived object can be really simple, we would just reuse the > functionality it already has + let us properly hook into it in > ipa-{server,replica}-install and the uninstallation. > > It would also make it easier to split this functionality to > freeipa-server-firewalld if we chose to in a future. In general I agree with the idea, thank you Justin for working on that! I would like to emphasis the necessity to work without NetworkManager and FirewallD. New dependencies make Debian folks unhappy ... On the other hand, it is perfectly fine to skip firewall configuration if NM/FirewallD/DBus is not available. Have a nice day! -- Petr^2 Spacek From lkrispen at redhat.com Fri Apr 4 08:20:14 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 04 Apr 2014 10:20:14 +0200 Subject: [Freeipa-devel] questions regarding ldap schema for pkcs11 Message-ID: <533E6B3E.60808@redhat.com> In the review discussion for the ldap schema for pkcs11 there was one topic, which we wanted to get the opinion from a broader audience before making a final decision. In pkcs11 there are many boolean attributes, like CKA_EXTRACTABLE, CKA_DERIVE, CKA_VERIFY and there are two suggestions how to represent them in ldap. 1] one ldap attribute for each pkcs11 attribute. This was my initial proposal to define a ldap attribute with boolean syntax. Most attributes have default values and need not to be present example: pkcs11extractable: true pkcs11derive: false pkcs11verify: true 2] one ldap attribute with pkcs11 attributes as values During the review Simo suggested to have a single attribute (or a few of them, key,cert,...) and for each pkcs11 attribute with value true add it as a value example: pkcs11keyFlags: CKA_EXTRACTABLE pkcs11keyFlags: CKA_VERIFY Pros & Cons pro 1] : * direct mapping of pkcs11attributes * required or allowed attributes are defined in an objectclass con 1]: * huge number of schema attributes, which will probably not be needed pro 2]: * smaller schema definition * possible to add new attributes/flags without extending the schema con 2]: * no input validation, application could set undefined flags * since presence of a flag means TRUE, and absence FALSE all default true values need to be present An other question was what should be the prefix for the ldap attribute names, the initial proposal was ipapkcs11, which was considered too ipa specific, so the next was pkcs11, where there are now concerns that this might be too ambitious pretending this is somehow official pkcs11. So there are proposals of p11,pk11,c11 which also are used already by others (nss,p11-glue) so any good ideas are welcome -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Apr 4 08:54:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Apr 2014 10:54:15 +0200 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers In-Reply-To: <1396531695.18479.16.camel@willson.li.ssimo.org> References: <533D472B.1010807@redhat.com> <1396529611.18479.13.camel@willson.li.ssimo.org> <533D5FF1.3000409@redhat.com> <1396531695.18479.16.camel@willson.li.ssimo.org> Message-ID: <533E7337.6060307@redhat.com> On 04/03/2014 03:28 PM, Simo Sorce wrote: > On Thu, 2014-04-03 at 15:19 +0200, Petr Viktorin wrote: >> On 04/03/2014 02:53 PM, Simo Sorce wrote: >>> On Thu, 2014-04-03 at 13:34 +0200, Petr Viktorin wrote: >>>> Hello, >>>> This adds anonymous read access to containers, as discussed in this >>>> thread: >>>> https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html >>>> >>>> Additionally access is granted for $SUFFIX itself with targetfilter >>>> "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, >>>> associatedDomain. >>>> >>>> These are raw ACIs, not permission-based ones. >>>> >>> >>> Why is this not set in default-aci.ldif as well ? >>> >>> Simo. >> >> Because we don't want to duplicate information. > > So are we removing default-aci.ldif completely ? > I think we already mentioned this, but I can hardly recall the > discussion, sorry. > > Simo. > Sorry for the brief answer, I was just leaving for the day. Storing the data in both the LDIFs and update files is unnecessary, and the two files will get out of sync so one would need to look at both of them to get the full picture anyway. So now the plan is to put new data only in update files (except for schema which has a special LDIF-based updater). default-aci.ldif might end up being removed completely but it doesn't really bring us anything except being "cleaner", so it's not a priority. I found the discussion: http://www.redhat.com/archives/freeipa-devel/2013-September/msg00106.html; the relevant part is: Rob: > The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened. Petr: > Good to know. Is it still the plan? Do I only need to change the update files? Rob: > It would be my preference. It goes beyond only changing one set of files. The existing ldif that duplicate things need to be deprecated. We can't get to a zero-ldif install, but it can be reduced significantly. -- Petr? From amisnyov at redhat.com Fri Apr 4 08:59:11 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 4 Apr 2014 10:59:11 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 9 CA-less tests generate failure Message-ID: <20140404105911.7742aac0@unused-4-246.brq.redhat.com> Hi, CA-less test suite always generate failures when installing revoked certificates. This is a known issue, described in https://fedorahosted.org/freeipa/ticket/4270 , this fix skips these tests, outputting a notification message for the ticket. Now it outputs this: [amisnyov at host freeipa]$ ./make-test ipatests/test_integration/test_caless.py:TestServerInstall.test_revoked_http /usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins ipatests/test_integration/test_caless.py:TestServerInstall.test_revoked_http IPA server install with revoked HTTP certificate ... SKIP: Known CA-less installation defect, see https://fedorahosted.org/freeipa/ticket/4270 ---------------------------------------------------------------------- Ran 1 test in 1020.253s OK (SKIP=1) ====================================================================== passed under '/usr/bin/python2.7' ** pass ** https://fedorahosted.org/freeipa/ticket/4271 There could be another possible solution, I could write a nose plugin to enable raising warnings instead of skipping a test. This could be achieved by adding a @unittest.expectedFailure for a specific test, so if it fails, it counts as an error/warning. There is a poc in a nose ticket located in http://code.google.com/p/python-nose/issues/detail?id=428 , not sure how much time it takes to implement it as a plugin, or is it even worth, because if this is implemented, we could also use this feature when eg. DNS is not configured, this is why RFC. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0009-1-CA-less-tests-generate-failure.patch Type: text/x-patch Size: 3753 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 4 09:57:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Apr 2014 11:57:14 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add wait_for_dns option to default.conf In-Reply-To: <533C04C3.5040602@redhat.com> References: <533C0455.9010101@redhat.com> <533C04C3.5040602@redhat.com> Message-ID: <533E81FA.2080602@redhat.com> On 04/02/2014 02:38 PM, Petr Spacek wrote: > On 2.4.2014 14:36, Petr Spacek wrote: >> Hello, >> >> Add wait_for_dns option to default.conf. >> >> This option makes record changes in DNS tree synchronous. >> IPA calls will wait until new data are visible over DNS protocol >> or until timeout. >> >> It is intended only for testing. It should prevent tests from >> failing if there is bigger delay between changes in LDAP and DNS. >> >> My personal recommendation is to use value "5" (for testing!). > > Ah, my hands were faster than head :-) > > This patch was supersedes patch my patch 0015 and should apply to > vanilla master (at the moment). Looks good to me. ACK, pushed to master: 34fc447c00189d53ccf44184cfd5ed48cde6bf86 -- Petr? From pviktori at redhat.com Fri Apr 4 10:07:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Apr 2014 12:07:41 +0200 Subject: [Freeipa-devel] [PATCHES 163-166] Various ipatests fixes In-Reply-To: <533D3E18.9050704@redhat.com> References: <533D3B1D.1060606@redhat.com> <533D3E18.9050704@redhat.com> Message-ID: <533E846D.8070400@redhat.com> On 04/03/2014 12:55 PM, Petr Viktorin wrote: > On 04/03/2014 12:42 PM, Tomas Babej wrote: >> Hi. >> >> these fix the following: >> >> * not properly removed PKI instance on IPA uninstall >> * improper usage of external hostname of AD subdomain in the legacy >> client tests >> * relax regex checks in legacy client tests >> * put 2 seconds of sleep after restart of SSSD when clearing the cache > > I will take the review. > > ACK, thanks, pushed to: master: 50a6316d16f3cb9fcdcab03a1f205a678e2fb154 ipa-3-3: 075f9e59a859b2d53dead6b4610a417a4277fdcd -- Petr? From pviktori at redhat.com Fri Apr 4 10:24:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Apr 2014 12:24:45 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: References: <1395912216.2269.5.camel@unused-4-145.brq.redhat.com> <5333F056.2030100@redhat.com> <1395915293.2269.7.camel@unused-4-145.brq.redhat.com> <533526DC.1080803@redhat.com> Message-ID: <533E886D.6040805@redhat.com> On 03/29/2014 12:22 AM, Gabe Alford wrote: > Changed 127.0.0.1 to 192.0.2.1 > > > On Fri, Mar 28, 2014 at 1:38 AM, Petr Spacek > wrote: > > On 28.3.2014 02:09, Gabe Alford wrote: > > I believe that Martin is right about the server installer no > longer putting > 127.0.0.1 in the resolv.conf. Here is a mod patch to address > Martin's > concern if the note needs to be changed to show a real IP address. > > > Okay, that is new for me :-) > > Conditional ACK. Please change the IP address before push to > something from: > http://tools.ietf.org/html/__rfc5737#section-3 > > > 192.0.2.1 sounds like a good candidate. > > Thanks! > > Petr^2 Spacek Pushed to docs master: e0c2758f20b4fd73715e320dbfa09c202ad5b142 -- Petr? From pspacek at redhat.com Fri Apr 4 10:59:29 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Apr 2014 12:59:29 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <533D639B.50901@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> Message-ID: <533E9091.9020900@redhat.com> On 3.4.2014 15:35, Jan Cholasta wrote: > On 2.4.2014 14:07, Martin Basti wrote: > Patch 30: > 2) > > + if isinstance(labels, str): > + if not labels: > + raise ValueError('empty string') > ... > + elif isinstance(labels, unicode): > + if not labels: > + raise ValueError('empty string') > > It might be nicer to: > > + if isinstance(labels, basestring) and not labels: > + raise ValueError('empty string') > + > + if isinstance(labels, str): > ... > + elif isinstance(labels, unicode): Is it expected that you can't create root name? I would like to imitate dns-python semantics as much as possible. In [2]: dns.name.from_text("") Out[2]: In [4]: dns.name.Name([]) Out[4]: In [5]: dns.name.Name([""]) Out[5]: I would like to see more descriptive error texts if you insist on current semantics. > 4) > > + @staticmethod > + def get_root(): > + return DNSName(dns.name.root) > + > + @staticmethod > + def get_origin_sign(): > + return DNSName(u'@') > + > + @staticmethod > + def get_rev_zone(): > + return DNSName(u'in-addr.arpa.') > + > + @staticmethod > + def get_ip6_rev_zone(): > + return DNSName(u'ip6.arpa.') > > I think you should either drop the "get_" prefix from the name, or (even > better) make these global constants. > > I would shorten "origin_sign" to just "sign". Sign of what? Decay? :-) I don't think that sign is descriptive enough, I would personally stick with origin_sign. > Can you please use tuples of str objects (i.e. what dns.name.Name uses > internally) instead of unicode objects for the initialization? I think it > should be the preferred style of initializing DNSName objects (DN objects do > the same). Please don't forget to consult dns-python3 and try to make migration from dns-python to dns-python3 easy. > 6) > > + def ToASCII(self, omit_final_dot=False): > + return super(DNSName, > self).to_text(omit_final_dot=omit_final_dot).decode('ascii') > + > + def ToUnicode(self, omit_final_dot=False): > + return super(DNSName, > self).to_unicode(omit_final_dot=omit_final_dot).decode('utf-8') > > What was the reason for the unusual naming again? I would prefer PEP-8 > compatible names (e.g. "to_ascii" and "to_unicode"), but if the current names > absolutely have to stay, please add a comment with explanation. > > I don't like the "omit_final_dot" flag. IMHO it should be dropped and whether > the result includes a final dot or not should depend solely on whether the > name is absolute or relative. You can still use e.g. > "name.derelativize(root).ToUnicode()" to drop the final dot, which is more > explanatory. Generally, I agree. We can get rid of the relative/absolute name madness by using final dot everywhere. > 8) > > + def is_ip_reverse(self): Please use is_ip4_reverse() instead. That name will always remind developer not to forgot to IPv6 :-) > + if self.is_subdomain(self.get_rev_zone()): > + return True > + return False > Patch 31: 2b) + except dns.name.NameTooLong: + raise ValueError(_('domain name cannot be longer than 255 characters')) Personally, I would say '255 bytes' instead of '255 characters'. Characters are tricky when IDN is involved etc. Patch freeipa-mbasti-0036-DNSName-conversion-in-ipaldap.patch: @@ -255,6 +256,10 @@ class IPASimpleLDAPObject(object): 'managedtemplate': DN, 'managedbase': DN, 'originscope': DN, + 'idnsname': DNSName, + 'idnssoamname': DNSName, + 'idnssoarname': DNSName, + 'dnszoneidnsname': DNSName, }) Maybe you can add following attributes too: CNAMERecord DNAMERecord MDRecord NSRecord PTRRecord > Patch 38: > > 1) > > +_dns_zone_record = DNSName(u'@') > > You know you already defined a constant for this in patch 30, right? It seems that both constants are unnecessary because IMHO DNSName(u'@') is more readable and you don't need to dig into code to find out what the cryptic name means. > 4) > > +def _hostname_validator_idn(ugettext, value): > + assert isinstance(value, DNSName) > + > + req_len = 2 > + if value.is_absolute(): > + req_len = 3 > + if len(value.labels) < req_len: > + return _('invalid domain-name: not fully qualified') This test is not correct because FQDN = an absolute name. This code tries to guess if the name is FQDN or not but we can directly use is_absolute() test. 4b) def is_forward_record(zone, str_address): addr = netaddr.IPAddress(str_address) @@ -461,6 +444,7 @@ def is_forward_record(zone, str_address): def add_forward_record(zone, name, str_address): addr = netaddr.IPAddress(str_address) + try: if addr.version == 4: api.Command['dnsrecord_add'](zone, name, arecord=str_address) Personally, I think that 'forward' is confusing (in this context). Could you rename *_forward_record() functions to *_ipaddr_record(), please? (Maybe in a separate patch...) 4c) def add_records_for_host(host, domain, ip_addresses, add_forward=True, add_reverse=True): + assert isinstance(host, DNSName) + assert isinstance(domain, DNSName) The same applies to all places with: + assert isinstance(value, DNSName) scattered all over the patch. Is this really necessary? I thought that Python usually uses http://en.wikipedia.org/wiki/Duck_typing It seems like leftovers from development phase. (Maybe it is not the case for IPA framework, correct me if I'm wrong :-) > Patch 39: > > 1) > > - Str('hostname', > - _hostname_validator, > - normalizer=_normalize_hostname, > + DNSNameParam('hostname', > + #RFC 2317 section 5.2 -- don't have to be FQDN > > It seems you are changing behavior here. Such things belong in separate patches. Note: This is (mostly) related to classless reverse zones. freeipa-mbasti-0040-Modified-record-and-zone-class-to-support-IDN.patch > * Records data are always returned as string > * Attributes idnsname, idnssoamname, idnssoarname are returned as DNSName, with > option --raw as string > * option --raw returns all IDN domains punycoded I have mentioned CNAMERecord DNAMERecord MDRecord NSRecord PTRRecord above. Their are also pure DNS names ... > def get_name_in_zone(self, zone, hostname): [snip] > - be added to a zone > + be added to a zone. Returns '@' when the hostname is directly in the zone I would replace "in the zone" with "at zone apex". Technically, all records with suffix = zone are "in" the zone. freeipa-mbasti-0046-DNS-new-tests.patch +idnzone1_ip = u'192.168.11.1' [snip] +revidnzone1 = u'15.168.192.in-addr.arpa.' Please use addresses from 172.16/12 prefix so IPA tests don't consume more than one prefix. More prefixes we use => higher probability that it will clash with somebody's environment. I'm looking forward to see this is IPA! Good work! -- Petr^2 Spacek From pspacek at redhat.com Fri Apr 4 11:19:35 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Apr 2014 13:19:35 +0200 Subject: [Freeipa-devel] questions regarding ldap schema for pkcs11 In-Reply-To: <533E6B3E.60808@redhat.com> References: <533E6B3E.60808@redhat.com> Message-ID: <533E9547.6010309@redhat.com> On 4.4.2014 10:20, Ludwig Krispenz wrote: > In the review discussion for the ldap schema for pkcs11 there was one topic, > which we wanted to get the opinion from a broader audience before making a > final decision. I'll add my opinion for the record: > In pkcs11 there are many boolean attributes, like CKA_EXTRACTABLE, CKA_DERIVE, > CKA_VERIFY and there are two suggestions how to represent them in ldap. > > > 1] one ldap attribute for each pkcs11 attribute. > This was my initial proposal to define a ldap attribute with boolean syntax. > Most attributes have default values and need not to be present > > example: > pkcs11extractable: true > pkcs11derive: false > pkcs11verify: true > > 2] one ldap attribute with pkcs11 attributes as values > During the review Simo suggested to have a single attribute (or a few of them, > key,cert,...) and for each pkcs11 attribute with value true add it as a value > > example: > pkcs11keyFlags: CKA_EXTRACTABLE > pkcs11keyFlags: CKA_VERIFY > > > Pros & Cons > > pro 1] : one ldap attribute for each pkcs11 attribute. > * direct mapping of pkcs11attributes > * required or allowed attributes are defined in an objectclass > > con 1]: > * huge number of schema attributes, which will probably not be needed I don't think it is a problem. We have *huge* schema full of almost never-used attributes. Look at printerAbstract objectClass ... > pro 2]: one ldap attribute with pkcs11 attributes as values > * smaller schema definition IPA schema + all the RFCs created a huge pile of schema definitions already and 389 can cope with it. (We are speaking about adding tens of attributes, not hundreds or thousands!) > * possible to add new attributes/flags without extending the schema Schema change is a little problem in comparison with updating clients (to get any value from the new flag). Note that we are talking about booleans defined by PKCS#11 standard so we can't add any boolean anyway. IMHO any IPA-specific booleans should go to a separate object class to separate them from pure PKCS#11 schema. > con 2]: > * no input validation, application could set undefined flags > * since presence of a flag means TRUE, and absence FALSE all default > true values need to be present To conclude it - I like approach [1]: One ldap attribute for each pkcs11 attribute. -- Petr^2 Spacek From mkosek at redhat.com Fri Apr 4 11:50:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Apr 2014 13:50:01 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add wait_for_dns option to default.conf In-Reply-To: <533E81FA.2080602@redhat.com> References: <533C0455.9010101@redhat.com> <533C04C3.5040602@redhat.com> <533E81FA.2080602@redhat.com> Message-ID: <533E9C69.7030902@redhat.com> On 04/04/2014 11:57 AM, Petr Viktorin wrote: > On 04/02/2014 02:38 PM, Petr Spacek wrote: >> On 2.4.2014 14:36, Petr Spacek wrote: >>> Hello, >>> >>> Add wait_for_dns option to default.conf. >>> >>> This option makes record changes in DNS tree synchronous. >>> IPA calls will wait until new data are visible over DNS protocol >>> or until timeout. >>> >>> It is intended only for testing. It should prevent tests from >>> failing if there is bigger delay between changes in LDAP and DNS. >>> >>> My personal recommendation is to use value "5" (for testing!). >> >> Ah, my hands were faster than head :-) >> >> This patch was supersedes patch my patch 0015 and should apply to >> vanilla master (at the moment). > > Looks good to me. > ACK, pushed to master: 34fc447c00189d53ccf44184cfd5ed48cde6bf86 > > Petr, can we now enable wait_for_dns for our tests then? Hopefully it will solve the unit test failures we saw. Martin From pviktori at redhat.com Fri Apr 4 12:11:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Apr 2014 14:11:53 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add wait_for_dns option to default.conf In-Reply-To: <533E9C69.7030902@redhat.com> References: <533C0455.9010101@redhat.com> <533C04C3.5040602@redhat.com> <533E81FA.2080602@redhat.com> <533E9C69.7030902@redhat.com> Message-ID: <533EA189.3070800@redhat.com> On 04/04/2014 01:50 PM, Martin Kosek wrote: > On 04/04/2014 11:57 AM, Petr Viktorin wrote: >> On 04/02/2014 02:38 PM, Petr Spacek wrote: >>> On 2.4.2014 14:36, Petr Spacek wrote: >>>> Hello, >>>> >>>> Add wait_for_dns option to default.conf. >>>> >>>> This option makes record changes in DNS tree synchronous. >>>> IPA calls will wait until new data are visible over DNS protocol >>>> or until timeout. >>>> >>>> It is intended only for testing. It should prevent tests from >>>> failing if there is bigger delay between changes in LDAP and DNS. >>>> >>>> My personal recommendation is to use value "5" (for testing!). >>> >>> Ah, my hands were faster than head :-) >>> >>> This patch was supersedes patch my patch 0015 and should apply to >>> vanilla master (at the moment). >> >> Looks good to me. >> ACK, pushed to master: 34fc447c00189d53ccf44184cfd5ed48cde6bf86 >> >> > > Petr, can we now enable wait_for_dns for our tests then? Hopefully it will > solve the unit test failures we saw. > > Martin > Here it is: https://github.com/encukou/freeipa-ci/commit/d36aa4fb54e4b56c040ecbe886a1156c18863023 I generally wait for a successful build before pushing to the ci config repo. -- Petr? From mkosek at redhat.com Fri Apr 4 12:35:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Apr 2014 14:35:05 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add wait_for_dns option to default.conf In-Reply-To: <533EA189.3070800@redhat.com> References: <533C0455.9010101@redhat.com> <533C04C3.5040602@redhat.com> <533E81FA.2080602@redhat.com> <533E9C69.7030902@redhat.com> <533EA189.3070800@redhat.com> Message-ID: <533EA6F9.7040101@redhat.com> On 04/04/2014 02:11 PM, Petr Viktorin wrote: > On 04/04/2014 01:50 PM, Martin Kosek wrote: >> On 04/04/2014 11:57 AM, Petr Viktorin wrote: >>> On 04/02/2014 02:38 PM, Petr Spacek wrote: >>>> On 2.4.2014 14:36, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> Add wait_for_dns option to default.conf. >>>>> >>>>> This option makes record changes in DNS tree synchronous. >>>>> IPA calls will wait until new data are visible over DNS protocol >>>>> or until timeout. >>>>> >>>>> It is intended only for testing. It should prevent tests from >>>>> failing if there is bigger delay between changes in LDAP and DNS. >>>>> >>>>> My personal recommendation is to use value "5" (for testing!). >>>> >>>> Ah, my hands were faster than head :-) >>>> >>>> This patch was supersedes patch my patch 0015 and should apply to >>>> vanilla master (at the moment). >>> >>> Looks good to me. >>> ACK, pushed to master: 34fc447c00189d53ccf44184cfd5ed48cde6bf86 >>> >>> >> >> Petr, can we now enable wait_for_dns for our tests then? Hopefully it will >> solve the unit test failures we saw. >> >> Martin >> > > Here it is: > https://github.com/encukou/freeipa-ci/commit/d36aa4fb54e4b56c040ecbe886a1156c18863023 > > I generally wait for a successful build before pushing to the ci config repo. Ok - ACK :) Martin From simo at redhat.com Fri Apr 4 12:55:13 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 04 Apr 2014 08:55:13 -0400 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers In-Reply-To: <533E7337.6060307@redhat.com> References: <533D472B.1010807@redhat.com> <1396529611.18479.13.camel@willson.li.ssimo.org> <533D5FF1.3000409@redhat.com> <1396531695.18479.16.camel@willson.li.ssimo.org> <533E7337.6060307@redhat.com> Message-ID: <1396616113.18479.47.camel@willson.li.ssimo.org> On Fri, 2014-04-04 at 10:54 +0200, Petr Viktorin wrote: > On 04/03/2014 03:28 PM, Simo Sorce wrote: > > On Thu, 2014-04-03 at 15:19 +0200, Petr Viktorin wrote: > >> On 04/03/2014 02:53 PM, Simo Sorce wrote: > >>> On Thu, 2014-04-03 at 13:34 +0200, Petr Viktorin wrote: > >>>> Hello, > >>>> This adds anonymous read access to containers, as discussed in this > >>>> thread: > >>>> https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html > >>>> > >>>> Additionally access is granted for $SUFFIX itself with targetfilter > >>>> "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, > >>>> associatedDomain. > >>>> > >>>> These are raw ACIs, not permission-based ones. > >>>> > >>> > >>> Why is this not set in default-aci.ldif as well ? > >>> > >>> Simo. > >> > >> Because we don't want to duplicate information. > > > > So are we removing default-aci.ldif completely ? > > I think we already mentioned this, but I can hardly recall the > > discussion, sorry. > > > > Simo. > > > > Sorry for the brief answer, I was just leaving for the day. > > Storing the data in both the LDIFs and update files is unnecessary, and > the two files will get out of sync so one would need to look at both of > them to get the full picture anyway. > So now the plan is to put new data only in update files (except for > schema which has a special LDIF-based updater). > > default-aci.ldif might end up being removed completely but it doesn't > really bring us anything except being "cleaner", so it's not a priority. > > I found the discussion: > http://www.redhat.com/archives/freeipa-devel/2013-September/msg00106.html; > the relevant part is: > > Rob: > > The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened. > Petr: > > Good to know. Is it still the plan? Do I only need to change the update files? > Rob: > > It would be my preference. It goes beyond only changing one set of files. The existing ldif that duplicate things need to be deprecated. We can't get to a zero-ldif install, but it can be reduced significantly. Ok however at the moment this is confusing for someone searching the code. Can we schedule an effort to clean up and remove as many ldif files as possible? Also do we need to call updates earlier if we do this ? Should we add warnings in the remaining ldif files about not adding content there unless explicitly required in early installation steps and redirect people to the update files ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Apr 4 13:10:21 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Apr 2014 15:10:21 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <533D639B.50901@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> Message-ID: <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> On Thu, 2014-04-03 at 15:35 +0200, Jan Cholasta wrote: > On 2.4.2014 14:07, Martin Basti wrote: > > Helo list, > > > > this patchset allows to use internationalized domian in DNS plugin. > > - dns names are stored in ACE form(punycoded) in LDAP > > - raw option shows dns data in ACE form, otherwise dns names are > > converted to unicode > > - plugin allow all characters in domain name, which are valid by IDN > > RFCs (almost everything including non-printable), should be validation > > more restrictive? (there is bug in dnspython with special characters, > > will be fixed soon) > > - TODO update WebUI to support DNSName objects > > > > Required patches: > > freeipa-jcholast-255-Allow-primary-keys-to-use-different-type-than-unicod.patch > > freeipa-jcholast-256-Support-API-version-specific-RPC-marshalling.patch > > freeipa-jcholast-257-Replace-get_syntax-method-of-IPASimpleObject-with-ne.patch > > freeipa-jcholast-258-Use-raw-attribute-values-in-command-result-when-raw-.patch > > freeipa-jcholast-259-Keep-original-name-when-setting-attribute-in-LDAPEnt.patch > > > > > > Patches attached. > > > > First batch of comments, so far I have only read the code/patches, > without doing actual testing. > > > Patch 30: > > 1) > > It might make sense to put all of this into a new module (e.g. > dnsutil.py) rather than ipautil. > I will move it > > 2) > > + if isinstance(labels, str): > + if not labels: > + raise ValueError('empty string') > ... > + elif isinstance(labels, unicode): > + if not labels: > + raise ValueError('empty string') > > It might be nicer to: > > + if isinstance(labels, basestring) and not labels: > + raise ValueError('empty string') > + > + if isinstance(labels, str): > ... > + elif isinstance(labels, unicode): > Ok I will use basestring > > 3) > > + def __nonzero__(self): > + return True > > It would be nice to include a comment about why DNSName always evaluates > to True (mention "@"). > I will add comment > > 4) > > + @staticmethod > + def get_root(): > + return DNSName(dns.name.root) > + > + @staticmethod > + def get_origin_sign(): > + return DNSName(u'@') > + > + @staticmethod > + def get_rev_zone(): > + return DNSName(u'in-addr.arpa.') > + > + @staticmethod > + def get_ip6_rev_zone(): > + return DNSName(u'ip6.arpa.') > > I think you should either drop the "get_" prefix from the name, or (even > better) make these global constants. > > I would shorten "origin_sign" to just "sign". IMHO only "sign" is not enough. > > Can you please use tuples of str objects (i.e. what dns.name.Name uses > internally) instead of unicode objects for the initialization? I think > it should be the preferred style of initializing DNSName objects (DN > objects do the same). > I will fix it. > > 5) > > + def __str__(self): > + return super(DNSName, self).to_text() > > You don't need to use super here. > I will fix it. > > 6) > > + def ToASCII(self, omit_final_dot=False): > + return super(DNSName, > self).to_text(omit_final_dot=omit_final_dot).decode('ascii') > + > + def ToUnicode(self, omit_final_dot=False): > + return super(DNSName, > self).to_unicode(omit_final_dot=omit_final_dot).decode('utf-8') > > What was the reason for the unusual naming again? I would prefer PEP-8 > compatible names (e.g. "to_ascii" and "to_unicode"), but if the current > names absolutely have to stay, please add a comment with explanation. > I used .ToUnicode .ToASCII because, python standard library uses this naming(https://docs.python.org/2/library/codecs.html#module-encodings.idna) and also RFC3490 section 4 specifiy it in that way. > I don't like the "omit_final_dot" flag. IMHO it should be dropped and > whether the result includes a final dot or not should depend solely on > whether the name is absolute or relative. You can still use e.g. > "name.derelativize(root).ToUnicode()" to drop the final dot, which is > more explanatory. > > In ToUnicode, the call to dns.name.Name.to_unicode already returns a > unicode object, no need to call decode on it. > I will remove the flag > > 7) > > + def concatenate(self, other): > + return DNSName(super(DNSName, self).concatenate(other).labels) > + > + def relativize(self, origin): > + return DNSName(super(DNSName, self).relativize(origin).labels) > + > + def derelativize(self, origin): > + return DNSName(super(DNSName, self).derelativize(origin).labels) > + > + def choose_relativity(self, origin=None, relativize=True): > + return DNSName(super(DNSName, > self).choose_relativity(origin=origin, relativize=relativize).labels) > > Why use ".labels" here? The DNSName constructor knows how to deal with > dns.name.Name objects, right? Right, I will fix it. > > 8) > > + def is_ip_reverse(self): > + if self.is_subdomain(self.get_rev_zone()): > + return True > + return False > + > + def is_ip6_reverse(self): > + if self.is_subdomain(self.get_ip6_rev_zone()): > + return True > + return False > + > + def is_reverse(self): > + if self.is_ip_reverse() or self.is_ip6_reverse(): > + return True > + return False > > The ifs are all redundant. Return the result of the check directly > ("return self.is_subdomain ..." etc.) Ok, I will fix it. > > Patch 31: > > 1) > > + kwargs = Param.kwargs + ( > + ('require_absolute', bool, False), > + ('require_relative', bool, False), > + ) > > What about renaming these to 'only_absolute' and 'only_relative'? IMO it > better captures the meaning (yes I know we already discussed the naming > in length :-) IMO there is still confusion only_absolute -> makes a relative name absolute, only_relative -> raise error if a name is absolute What about to_absolute, only_relative, (only_absolute maybe?) > > > 2) > > + except (dns.name.LabelTooLong, UnicodeError): > + #dnspython bug?, punycoded label longer than 63 > ASCII-chars returns Unicode Error > + #instead of LabelTooLong > > If that's true, it should be handled in DNSName constructor, not here. > Yes it is special case when name is shorter than 63 chars but after conversion to ACE form is longer. I will move it > > 3) > > All of the dns.name exceptions inherit from dns.exception.SyntaxError, I > think you should add an except for it as well. > I will add this except. > > 4) > > + #compare if IDN normalized and original domain match > + normalized_domain_name = encodings.idna.nameprep(value) > + if(value != normalized_domain_name): > + raise ValueError( _("domain name '%(domain)s' and > normalized domain name " > + "'%(normalized)s' do not > match. Please use only " > + "normalized domains") % > {'domain':value, > + 'normalized':normalized_domain_name}) > > Can we instead try to normalize the name in the beginning of > _convert_scalar rather than raise an error later? I'm not sure what you mean, I need pure string without any normalization to compare it. > > > 5) > > + except Exception as e: > + raise ValidationError(name=self.name, > + value=value, > + index=index, > + error=unicode(e)) > > Since this is _convert_scalar, I think this should be ConversionError > (even if the errors are technically validation errors). Okay I will raise ValidationError. > > Also, use self.get_param_name() instead of self.name. OK. > > > 6) > > I'm not a fan of the layout of _convert_scalar, can you please use > something like this instead (includes changes requested in the previous > comments): > > def _convert_scalar(self, value, index): > if isinstance(value, unicode): > value = encodings.idna.nameprep(value) > > error = None > try: > value = DNSName(value) > except dns.name.BadEscape: > error = _("invalid escape code") > ... > except dns.exception.SyntaxError: > error = _("invalid syntax") > > if error: > raise ConversionError( > name=self.get_param_name(), index=index, error=error) > > return super(DNSNameParam, self)._convert_scalar(value, index) I will. > > > Patch 33: > > Why is this patch necessary? It does not seem right to me. > It has to be there. Without this patch I'm getting conversion errors, values are returned in tuples instead of list Str()._convert_scalar is called somewhere out of dns I have to take deep inspect where it occurs. > > Patch 34: > > This patch should be squashed with patch 32. They don't make sense > without each other. > I will do it. > Patch 37: > > 1) > > -def _rname_validator(ugettext, zonemgr): > > What's up with this renaming of everything? Don't do it please, unless > absolutely necessary. Cos I used both at start, IDN aware and unaware, some external plugins also call those functions (not in this case) > > 2) > > You don't need to redefine has_output for dnszone_add, dnszone_mod, > dnszone_show, dnsrecord_add, dnsrecord_mod and dnsrecord_show. They > already use standard_entry. > > > 3) > > + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): > + assert isinstance(dn, DN) > + _ns_zone_post_convert(entry_attrs, **options) > + return dn > + > > Please don't use stuff that is not defined in this or previous patches. > IPA should be at least buildable after each patch is applied. > My bad sorry, I added it to wrong patch after rebase > > 4) > > has_output = output.standard_value > + > msg_summary = _('Disabled DNS zone "%(value)s"') > > No new whitespace please (seen 2 times in the patch). I will remove it. > > Patch 38: > > 1) > > +_dns_zone_record = DNSName(u'@') > > You know you already defined a constant for this in patch 30, right? > > > 2) > > No new whitespace please (seen 2 times in the patch). I will remove it > > 3) > > + #TODO This is used by realmdomains.py (but it shouldnt allow > classless), not used in DNS > > + #TODO This is used by Host.py > > I don't think you should add these comments, since they are resolved in > patches 41 and 42. I forgot to remove them. > > 4) > > +def _hostname_validator_idn(ugettext, value): > + assert isinstance(value, DNSName) > + > + req_len = 2 > + if value.is_absolute(): > + req_len = 3 > + if len(value.labels) < req_len: > + return _('invalid domain-name: not fully qualified') > + > + return None > > Why the "_idn" postfix? It does not seem to be related to IDN. > > However, it does seem like it does the same thing as > _hostname_validator, so I think they should be merged. I will change all names to original in DNS plugin. > > 5) > > zonename = zone['idnsname'][0] > - if revdns.endswith(zonename) and len(zonename) > len(revzone): > - revzone = zonename > + if revdns.is_subdomain(zonename.make_absolute()): > + if revzone is None: > + revzone = zonename > + elif zonename.is_subdomain(revzone): > + revzone = zonename > > The idnsname returned from dnszone_find should already be absolute, so > why "zonename.make_absolute()"? > > You can shorten the condition to: > > if revdns.is_subdomain(zonename) and (revzone is None or > zonename.is_subdomain(revzone)) > No, it depends what is stored in LDAP, dnszone_find could return relative domain name (it should make sure everywhere that zone are absolute before comparation due to compatibility to older versions (or manual changes in LDAP)) > > 6) > > - revzone = u'.'.join(items[pos:]) > + revzone = DNSName(u'.'.join(items[pos:])) > > You join the items here into string which is split again in DNSName. Use > this instead: > > revzone = DNSName(items[pos:]) Sorry I just add add constructor there. I will fix it. > > 7) > > - return revzone, revname > + return DNSName(revzone), DNSName(revname) > > Aren't both revzone and revname DNSName objects already? They are, sorry, I forgot to remove it > > 8) > > - reason=_('DNS zone %(zone)s not found') % dict(zone=domain) > + reason=_('DNS zone %(zone)s not found') % > dict(zone=domain.ToUnicode()) > > Is the ".ToUnicode()" necessary? (seen 4 times in the patch) If strings are Unicode, then not. I will fix it. > > 9) > > IMO normalize_zonemgr_idn and validate_zonemgr_idn should be merged into > normalize_zonemgr and validate_zonemgr, respectively. Ok > > 10) > > def zone_is_reverse(zone_name): > - zone_name = normalize_zone(zone_name) > - if any(zone_name.endswith(name) for name in REVERSE_DNS_ZONES): > - return True > + if(isinstance(zone_name, DNSName)): > + if any(zone_name.is_subdomain(DNSName(name)) for name in > REVERSE_DNS_ZONES): > + return True > + else: > + zone_name = normalize_zone(zone_name) > + if any(zone_name.endswith(name) for name in REVERSE_DNS_ZONES): > + return True > > return False > > Something like this would definitely be better: > > def zone_is_reverse(zone_name): > if not isinstance(zone_name, DNSName): > zone_name = DNSName(zone_name) > return zone_name.is_reverse() Thank you, I will replace it. > > Patch 39: > > 1) > > - Str('hostname', > - _hostname_validator, > - normalizer=_normalize_hostname, > + DNSNameParam('hostname', > + #RFC 2317 section 5.2 -- don't have to be FQDN > > It seems you are changing behavior here. Such things belong in separate > patches. I will move it on extra patch. > > Patch 40: > > 1) > > + addr = DNSName(u'') > > This will always raise ValueError with the current implementation of > DNSName. My bad, there should be zone_record constant (@), it works before I changed validation to not support empty strings > > 2) > > No new whitespace please (seen 5 times in the patch). Sorry for that > > Patch 43: > > I think this patch should be squashed into patch 38. I will do that > > Patch 44: > > This patch should be squashed into patch 39. I will do that > > 1) > > +<<<<<<< HEAD > output: PrimaryKey('value', None, None) > +======= > +output: Output('value', , None) > +>>>>>>> 5df7ed2... API change > > It seems you overlooked this. Shame on me! > This is all for now. Expect more later ;-) > > > Honza > Thank you very much for your time. -- Martin^2 Basti From simo at redhat.com Fri Apr 4 13:20:21 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 04 Apr 2014 09:20:21 -0400 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <533E6665.6000402@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> Message-ID: <1396617621.18479.64.camel@willson.li.ssimo.org> On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote: > On 4.4.2014 09:17, Martin Kosek wrote: > > On 04/04/2014 09:04 AM, Justin Brown wrote: > >>> I would actually do it the opposite way and open the ports after the FreeIPA server is fully configured. After all, I do not think we want to open the ports when the server is just half-configured and for example some ACIs are missing. > >> > >> My thinking was that nothing would be listening on these ports if the > >> install doesn't succeed, but there's really necessity to modify the > >> firewall configuration early. (All of the internal install > >> communication will be over a local interface (to netfilter) and > >> unblock anyways. I don't have any problem in delaying firewall > >> configuration to the end of install. > > > > If ipa-server-install does succeed without configuring the firewalld, then we > > will indeed have no other option than to do it early. > > > > I am thinking that we may want to put all the firewalld configuration in > > ipaserver/install/firewalldinstance.py, > > and then make the firewalld configuration the actual step of the installation. > > Something like: > > > > ... > > Configuring Firewall (firewalld) > > [1/2]: looking up the right zone > > [2/2]: allowing ports > > Done configuring Firewall (firewalld). > > ... > > > > The Service class derived object can be really simple, we would just reuse the > > functionality it already has + let us properly hook into it in > > ipa-{server,replica}-install and the uninstallation. > > > > It would also make it easier to split this functionality to > > freeipa-server-firewalld if we chose to in a future. > > In general I agree with the idea, thank you Justin for working on that! > > I would like to emphasis the necessity to work without NetworkManager and > FirewallD. New dependencies make Debian folks unhappy ... > > On the other hand, it is perfectly fine to skip firewall configuration if > NM/FirewallD/DBus is not available. > > Have a nice day! Should be easy, probe for the dbus firewalld service and just skip (not error out) if it is not there. Set a variable in that case that will cause the installer to throw the classic banner we have now which warns you about what ports need to be opened at the end of the install. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Apr 4 13:26:01 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 04 Apr 2014 09:26:01 -0400 Subject: [Freeipa-devel] questions regarding ldap schema for pkcs11 In-Reply-To: <533E9547.6010309@redhat.com> References: <533E6B3E.60808@redhat.com> <533E9547.6010309@redhat.com> Message-ID: <1396617961.18479.67.camel@willson.li.ssimo.org> On Fri, 2014-04-04 at 13:19 +0200, Petr Spacek wrote: > On 4.4.2014 10:20, Ludwig Krispenz wrote: > > In the review discussion for the ldap schema for pkcs11 there was one topic, > > which we wanted to get the opinion from a broader audience before making a > > final decision. > I'll add my opinion for the record: > > > In pkcs11 there are many boolean attributes, like CKA_EXTRACTABLE, CKA_DERIVE, > > CKA_VERIFY and there are two suggestions how to represent them in ldap. > > > > > > 1] one ldap attribute for each pkcs11 attribute. > > This was my initial proposal to define a ldap attribute with boolean syntax. > > Most attributes have default values and need not to be present > > > > example: > > pkcs11extractable: true > > pkcs11derive: false > > pkcs11verify: true > > > > 2] one ldap attribute with pkcs11 attributes as values > > During the review Simo suggested to have a single attribute (or a few of them, > > key,cert,...) and for each pkcs11 attribute with value true add it as a value > > > > example: > > pkcs11keyFlags: CKA_EXTRACTABLE > > pkcs11keyFlags: CKA_VERIFY > > > > > > Pros & Cons > > > > pro 1] : one ldap attribute for each pkcs11 attribute. > > * direct mapping of pkcs11attributes > > * required or allowed attributes are defined in an objectclass > > > > con 1]: > > * huge number of schema attributes, which will probably not be needed > I don't think it is a problem. We have *huge* schema full of almost never-used > attributes. Look at printerAbstract objectClass ... > > > pro 2]: one ldap attribute with pkcs11 attributes as values > > * smaller schema definition > IPA schema + all the RFCs created a huge pile of schema definitions already > and 389 can cope with it. (We are speaking about adding tens of attributes, > not hundreds or thousands!) > > > * possible to add new attributes/flags without extending the schema > Schema change is a little problem in comparison with updating clients (to get > any value from the new flag). Note that we are talking about booleans defined > by PKCS#11 standard so we can't add any boolean anyway. > > IMHO any IPA-specific booleans should go to a separate object class to > separate them from pure PKCS#11 schema. > > > > con 2]: > > * no input validation, application could set undefined flags > > * since presence of a flag means TRUE, and absence FALSE all default > > true values need to be present > > To conclude it - I like approach [1]: One ldap attribute for each pkcs11 > attribute. > After much consideration I think one attribute per boolean is ok, I think the most convincing argument came from Honza when he said sometimes the default may depend on additional factors not explicit in the object, in that case setting or not setting a string would always be wrong and we would need to end up with additional definitions like: CKA_VERIFY_TRUE/CKA_VERIFY_FALSE as opposed to them missing which could indicate default (or we end up adding also CKA_VERIFY_DEFAULT ...). Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Fri Apr 4 13:46:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Apr 2014 15:46:54 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <533E9091.9020900@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> Message-ID: <1396619214.2795.66.camel@unused-4-145.brq.redhat.com> On Fri, 2014-04-04 at 12:59 +0200, Petr Spacek wrote: > On 3.4.2014 15:35, Jan Cholasta wrote: > > On 2.4.2014 14:07, Martin Basti wrote: > > Patch 30: > > 2) > > > > + if isinstance(labels, str): > > + if not labels: > > + raise ValueError('empty string') > > ... > > + elif isinstance(labels, unicode): > > + if not labels: > > + raise ValueError('empty string') > > > > It might be nicer to: > > > > + if isinstance(labels, basestring) and not labels: > > + raise ValueError('empty string') > > + > > + if isinstance(labels, str): > > ... > > + elif isinstance(labels, unicode): > Is it expected that you can't create root name? > > I would like to imitate dns-python semantics as much as possible. > > In [2]: dns.name.from_text("") > Out[2]: > > In [4]: dns.name.Name([]) > Out[4]: > > In [5]: dns.name.Name([""]) > Out[5]: Cos we need to keep if user added domain with/without zone, we use origin=None, and there is allowed to add only '.' as domain name => root In [3]: a = dns.name.from_unicode(u'.', origin=None) In [4]: a.labels Out[4]: ('',) That is more clearly to user add . as root domain, instead of empty string > I would like to see more descriptive error texts if you insist on current > semantics. > > > 4) > > > > + @staticmethod > > + def get_root(): > > + return DNSName(dns.name.root) > > + > > + @staticmethod > > + def get_origin_sign(): > > + return DNSName(u'@') > > + > > + @staticmethod > > + def get_rev_zone(): > > + return DNSName(u'in-addr.arpa.') > > + > > + @staticmethod > > + def get_ip6_rev_zone(): > > + return DNSName(u'ip6.arpa.') > > > > I think you should either drop the "get_" prefix from the name, or (even > > better) make these global constants. > > > > I would shorten "origin_sign" to just "sign". > Sign of what? Decay? :-) I don't think that sign is descriptive enough, I > would personally stick with origin_sign. I agree with origin_sing, or zone_record, or origin, not sign. > > > Can you please use tuples of str objects (i.e. what dns.name.Name uses > > internally) instead of unicode objects for the initialization? I think it > > should be the preferred style of initializing DNSName objects (DN objects do > > the same). > Please don't forget to consult dns-python3 and try to make migration from > dns-python to dns-python3 easy. I will take look at dns-python3. > > 6) > > > > + def ToASCII(self, omit_final_dot=False): > > + return super(DNSName, > > self).to_text(omit_final_dot=omit_final_dot).decode('ascii') > > + > > + def ToUnicode(self, omit_final_dot=False): > > + return super(DNSName, > > self).to_unicode(omit_final_dot=omit_final_dot).decode('utf-8') > > > > What was the reason for the unusual naming again? I would prefer PEP-8 > > compatible names (e.g. "to_ascii" and "to_unicode"), but if the current names > > absolutely have to stay, please add a comment with explanation. > > > > I don't like the "omit_final_dot" flag. IMHO it should be dropped and whether > > the result includes a final dot or not should depend solely on whether the > > name is absolute or relative. You can still use e.g. > > "name.derelativize(root).ToUnicode()" to drop the final dot, which is more > > explanatory. > Generally, I agree. We can get rid of the relative/absolute name madness by > using final dot everywhere. Ok I will remove it. > > 8) > > > > + def is_ip_reverse(self): > Please use is_ip4_reverse() instead. That name will always remind developer > not to forgot to IPv6 :-) As you wish. > > + if self.is_subdomain(self.get_rev_zone()): > > + return True > > + return False > > > > > Patch 31: > 2b) > + except dns.name.NameTooLong: > + raise ValueError(_('domain name cannot be longer than 255 > characters')) > > Personally, I would say '255 bytes' instead of '255 characters'. Characters > are tricky when IDN is involved etc. Okay, bytes then. I will reword it. > > > Patch freeipa-mbasti-0036-DNSName-conversion-in-ipaldap.patch: > > @@ -255,6 +256,10 @@ class IPASimpleLDAPObject(object): > 'managedtemplate': DN, > 'managedbase': DN, > 'originscope': DN, > + 'idnsname': DNSName, > + 'idnssoamname': DNSName, > + 'idnssoarname': DNSName, > + 'dnszoneidnsname': DNSName, > }) > > Maybe you can add following attributes too: > CNAMERecord > DNAMERecord > MDRecord > NSRecord > PTRRecord > I'm not sure with that. Now all record data are returned as string, only domain names and domain related attributes in zone are returned as DNSName. It could be mess if half of records be returned as DNSName and second as string. > > > > Patch 38: > > > > 1) > > > > +_dns_zone_record = DNSName(u'@') > > > > You know you already defined a constant for this in patch 30, right? > It seems that both constants are unnecessary because IMHO > DNSName(u'@') > is more readable and you don't need to dig into code to find out what the > cryptic name means. I like constants :-). I'm not sure if making new object, when in the most cases want only to compare, is good idea. > > 4) > > > > +def _hostname_validator_idn(ugettext, value): > > + assert isinstance(value, DNSName) > > + > > + req_len = 2 > > + if value.is_absolute(): > > + req_len = 3 > > + if len(value.labels) < req_len: > > + return _('invalid domain-name: not fully qualified') > This test is not correct because FQDN = an absolute name. > > This code tries to guess if the name is FQDN or not but we can directly use > is_absolute() test. I know, but in this IPA case is FQDN something like 'example.domain', not 'domain.' . I kept behavior of original function. > > 4b) > def is_forward_record(zone, str_address): > addr = netaddr.IPAddress(str_address) > @@ -461,6 +444,7 @@ def is_forward_record(zone, str_address): > > def add_forward_record(zone, name, str_address): > addr = netaddr.IPAddress(str_address) > + > try: > if addr.version == 4: > api.Command['dnsrecord_add'](zone, name, arecord=str_address) > > Personally, I think that 'forward' is confusing (in this context). Could you > rename *_forward_record() functions to *_ipaddr_record(), please? (Maybe in a > separate patch...) I was confused too, maybe later, now I'm almost lost in all these changes. > > 4c) > def add_records_for_host(host, domain, ip_addresses, add_forward=True, > add_reverse=True): > + assert isinstance(host, DNSName) > + assert isinstance(domain, DNSName) > > The same applies to all places with: > + assert isinstance(value, DNSName) > scattered all over the patch. > > Is this really necessary? I thought that Python usually uses > http://en.wikipedia.org/wiki/Duck_typing > > It seems like leftovers from development phase. (Maybe it is not the case for > IPA framework, correct me if I'm wrong :-) I used in development phase, but it should be clear that these functions/methods dont work with unicode, some of them are used in other plugins (include 'private' functions) > > Patch 39: > > > > 1) > > > > - Str('hostname', > > - _hostname_validator, > > - normalizer=_normalize_hostname, > > + DNSNameParam('hostname', > > + #RFC 2317 section 5.2 -- don't have to be FQDN > > > > It seems you are changing behavior here. Such things belong in separate patches. > Note: This is (mostly) related to classless reverse zones. > freeipa-mbasti-0040-Modified-record-and-zone-class-to-support-IDN.patch > > * Records data are always returned as string > > * Attributes idnsname, idnssoamname, idnssoarname are returned as DNSName, with > > option --raw as string > > * option --raw returns all IDN domains punycoded > > I have mentioned > CNAMERecord > DNAMERecord > MDRecord > NSRecord > PTRRecord > > above. Their are also pure DNS names ... As I wrote above, it could be mayhem. > > def get_name_in_zone(self, zone, hostname): > [snip] > > - be added to a zone > > + be added to a zone. Returns '@' when the hostname is directly in the zone > > I would replace "in the zone" with "at zone apex". Technically, all records > with suffix = zone are "in" the zone. I would use zone record instead. Is it okay? > > > freeipa-mbasti-0046-DNS-new-tests.patch > +idnzone1_ip = u'192.168.11.1' > [snip] > +revidnzone1 = u'15.168.192.in-addr.arpa.' > > Please use addresses from 172.16/12 prefix so IPA tests don't consume more > than one prefix. > > More prefixes we use => higher probability that it will clash with somebody's > environment. Thank you for make it clear for me. I though the private address is enough. > > I'm looking forward to see this is IPA! Good work! > Thank you for your review. -- Martin^2 Basti From mbasti at redhat.com Fri Apr 4 13:51:28 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Apr 2014 15:51:28 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <1396619214.2795.66.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <1396619214.2795.66.camel@unused-4-145.brq.redhat.com> Message-ID: <1396619488.2795.67.camel@unused-4-145.brq.redhat.com> On Fri, 2014-04-04 at 15:46 +0200, Martin Basti wrote: > On Fri, 2014-04-04 at 12:59 +0200, Petr Spacek wrote: > > On 3.4.2014 15:35, Jan Cholasta wrote: > > > On 2.4.2014 14:07, Martin Basti wrote: > > > Patch 30: > > > 2) > > > > > > + if isinstance(labels, str): > > > + if not labels: > > > + raise ValueError('empty string') > > > ... > > > + elif isinstance(labels, unicode): > > > + if not labels: > > > + raise ValueError('empty string') > > > > > > It might be nicer to: > > > > > > + if isinstance(labels, basestring) and not labels: > > > + raise ValueError('empty string') > > > + > > > + if isinstance(labels, str): > > > ... > > > + elif isinstance(labels, unicode): > > Is it expected that you can't create root name? > > > > I would like to imitate dns-python semantics as much as possible. > > > > In [2]: dns.name.from_text("") > > Out[2]: > > > > In [4]: dns.name.Name([]) > > Out[4]: > > > > In [5]: dns.name.Name([""]) > > Out[5]: > > Cos we need to keep if user added domain with/without zone, we use I mean end dot not zone. > origin=None, and there is allowed to add only '.' as domain name => root > In [3]: a = dns.name.from_unicode(u'.', origin=None) > > In [4]: a.labels > Out[4]: ('',) > > That is more clearly to user add . as root domain, instead of empty > string > > > I would like to see more descriptive error texts if you insist on current > > semantics. > > > > > 4) > > > > > > + @staticmethod > > > + def get_root(): > > > + return DNSName(dns.name.root) > > > + > > > + @staticmethod > > > + def get_origin_sign(): > > > + return DNSName(u'@') > > > + > > > + @staticmethod > > > + def get_rev_zone(): > > > + return DNSName(u'in-addr.arpa.') > > > + > > > + @staticmethod > > > + def get_ip6_rev_zone(): > > > + return DNSName(u'ip6.arpa.') > > > > > > I think you should either drop the "get_" prefix from the name, or (even > > > better) make these global constants. > > > > > > I would shorten "origin_sign" to just "sign". > > Sign of what? Decay? :-) I don't think that sign is descriptive enough, I > > would personally stick with origin_sign. > I agree with origin_sing, or zone_record, or origin, not sign. > > > > > Can you please use tuples of str objects (i.e. what dns.name.Name uses > > > internally) instead of unicode objects for the initialization? I think it > > > should be the preferred style of initializing DNSName objects (DN objects do > > > the same). > > Please don't forget to consult dns-python3 and try to make migration from > > dns-python to dns-python3 easy. > I will take look at dns-python3. > > > > 6) > > > > > > + def ToASCII(self, omit_final_dot=False): > > > + return super(DNSName, > > > self).to_text(omit_final_dot=omit_final_dot).decode('ascii') > > > + > > > + def ToUnicode(self, omit_final_dot=False): > > > + return super(DNSName, > > > self).to_unicode(omit_final_dot=omit_final_dot).decode('utf-8') > > > > > > What was the reason for the unusual naming again? I would prefer PEP-8 > > > compatible names (e.g. "to_ascii" and "to_unicode"), but if the current names > > > absolutely have to stay, please add a comment with explanation. > > > > > > I don't like the "omit_final_dot" flag. IMHO it should be dropped and whether > > > the result includes a final dot or not should depend solely on whether the > > > name is absolute or relative. You can still use e.g. > > > "name.derelativize(root).ToUnicode()" to drop the final dot, which is more > > > explanatory. > > Generally, I agree. We can get rid of the relative/absolute name madness by > > using final dot everywhere. > Ok I will remove it. > > > > 8) > > > > > > + def is_ip_reverse(self): > > Please use is_ip4_reverse() instead. That name will always remind developer > > not to forgot to IPv6 :-) > As you wish. > > > + if self.is_subdomain(self.get_rev_zone()): > > > + return True > > > + return False > > > > > > > > > Patch 31: > > 2b) > > + except dns.name.NameTooLong: > > + raise ValueError(_('domain name cannot be longer than 255 > > characters')) > > > > Personally, I would say '255 bytes' instead of '255 characters'. Characters > > are tricky when IDN is involved etc. > Okay, bytes then. I will reword it. > > > > > > Patch freeipa-mbasti-0036-DNSName-conversion-in-ipaldap.patch: > > > > @@ -255,6 +256,10 @@ class IPASimpleLDAPObject(object): > > 'managedtemplate': DN, > > 'managedbase': DN, > > 'originscope': DN, > > + 'idnsname': DNSName, > > + 'idnssoamname': DNSName, > > + 'idnssoarname': DNSName, > > + 'dnszoneidnsname': DNSName, > > }) > > > > Maybe you can add following attributes too: > > CNAMERecord > > DNAMERecord > > MDRecord > > NSRecord > > PTRRecord > > > I'm not sure with that. Now all record data are returned as string, only > domain names and domain related attributes in zone are returned as > DNSName. It could be mess if half of records be returned as DNSName and > second as string. > > > > > > > Patch 38: > > > > > > 1) > > > > > > +_dns_zone_record = DNSName(u'@') > > > > > > You know you already defined a constant for this in patch 30, right? > > It seems that both constants are unnecessary because IMHO > > DNSName(u'@') > > is more readable and you don't need to dig into code to find out what the > > cryptic name means. > I like constants :-). I'm not sure if making new object, when in the most cases want only to compare, is good idea. > > > > 4) > > > > > > +def _hostname_validator_idn(ugettext, value): > > > + assert isinstance(value, DNSName) > > > + > > > + req_len = 2 > > > + if value.is_absolute(): > > > + req_len = 3 > > > + if len(value.labels) < req_len: > > > + return _('invalid domain-name: not fully qualified') > > This test is not correct because FQDN = an absolute name. > > > > This code tries to guess if the name is FQDN or not but we can directly use > > is_absolute() test. > I know, but in this IPA case is FQDN something like 'example.domain', not 'domain.' . > I kept behavior of original function. > > > > > 4b) > > def is_forward_record(zone, str_address): > > addr = netaddr.IPAddress(str_address) > > @@ -461,6 +444,7 @@ def is_forward_record(zone, str_address): > > > > def add_forward_record(zone, name, str_address): > > addr = netaddr.IPAddress(str_address) > > + > > try: > > if addr.version == 4: > > api.Command['dnsrecord_add'](zone, name, arecord=str_address) > > > > Personally, I think that 'forward' is confusing (in this context). Could you > > rename *_forward_record() functions to *_ipaddr_record(), please? (Maybe in a > > separate patch...) > I was confused too, maybe later, now I'm almost lost in all these > changes. > > > > 4c) > > def add_records_for_host(host, domain, ip_addresses, add_forward=True, > > add_reverse=True): > > + assert isinstance(host, DNSName) > > + assert isinstance(domain, DNSName) > > > > The same applies to all places with: > > + assert isinstance(value, DNSName) > > scattered all over the patch. > > > > Is this really necessary? I thought that Python usually uses > > http://en.wikipedia.org/wiki/Duck_typing > > > > It seems like leftovers from development phase. (Maybe it is not the case for > > IPA framework, correct me if I'm wrong :-) > I used in development phase, but it should be clear that these functions/methods dont work with unicode, some of them are used in other plugins (include 'private' functions) > > > > Patch 39: > > > > > > 1) > > > > > > - Str('hostname', > > > - _hostname_validator, > > > - normalizer=_normalize_hostname, > > > + DNSNameParam('hostname', > > > + #RFC 2317 section 5.2 -- don't have to be FQDN > > > > > > It seems you are changing behavior here. Such things belong in separate patches. > > Note: This is (mostly) related to classless reverse zones. > > > freeipa-mbasti-0040-Modified-record-and-zone-class-to-support-IDN.patch > > > * Records data are always returned as string > > > * Attributes idnsname, idnssoamname, idnssoarname are returned as DNSName, with > > > option --raw as string > > > * option --raw returns all IDN domains punycoded > > > > I have mentioned > > CNAMERecord > > DNAMERecord > > MDRecord > > NSRecord > > PTRRecord > > > > above. Their are also pure DNS names ... > As I wrote above, it could be mayhem. > > > > def get_name_in_zone(self, zone, hostname): > > [snip] > > > - be added to a zone > > > + be added to a zone. Returns '@' when the hostname is directly in the zone > > > > I would replace "in the zone" with "at zone apex". Technically, all records > > with suffix = zone are "in" the zone. > I would use zone record instead. Is it okay? > > > > > > freeipa-mbasti-0046-DNS-new-tests.patch > > +idnzone1_ip = u'192.168.11.1' > > [snip] > > +revidnzone1 = u'15.168.192.in-addr.arpa.' > > > > Please use addresses from 172.16/12 prefix so IPA tests don't consume more > > than one prefix. > > > > More prefixes we use => higher probability that it will clash with somebody's > > environment. > Thank you for make it clear for me. I though the private address is enough. > > > > > I'm looking forward to see this is IPA! Good work! > > > > Thank you for your review. -- Martin^2 Basti From alee at redhat.com Fri Apr 4 18:50:32 2014 From: alee at redhat.com (Ade Lee) Date: Fri, 04 Apr 2014 14:50:32 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA Message-ID: <1396637432.8149.30.camel@aleeredhat.laptop> This patch adds the capability of installing a Dogtag DRM to an IPA instance. With this patch, when ipa-server-install is run, a Dogtag CA and a Dogtag DRM are created. The DRM shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. It is also possible to clone the DRM. When the IPA instance is cloned, if --enable-ca and --enable-drm are specified, the DRM is cloned as well. Installing a DRM requires the user to have a Dogtag CA instance. We can look into possibly relaxing that requirement in a later patch. I am still working on patches for a ipa-drm-install script, which would be used to add a DRM to an existing master (that includes a dogtag CA), or an existing clone. Please review, Thanks, Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 40124 bytes Desc: not available URL: From pviktori at redhat.com Mon Apr 7 07:43:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Apr 2014 09:43:10 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> Message-ID: <5342570E.6040207@redhat.com> On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: > On Wed, 26 Mar 2014 13:15:55 +0100 > Petr Viktorin wrote: [...] >> >> Looks great! I'm just concerned about the error returned when the >> task takes too long: >> $ ipa automember-rebuild --type group >> ipa: ERROR: LDAP timeout >> I don't think it's sufficiently clear from this that waiting for the >> task timed out, but the task was actually started successfully. A >> custom error with a more descriptive message would be useful. >> >> >> Also I've noticed that the "nstaskstatus" of a successful task is: >> Automember rebuild task finished. Processed (1) entries. >> This looks helpful; we could return it as the summary. >> > > Hi, > both fixed. > Greets > Adam > Sorry for the delay! 'Automember' is a translatable string, so please wrap it in _() when raising TaskTimeout. Also please update the tests. Otherwise with a little rebase it's good to go. -- Petr? From mkosek at redhat.com Mon Apr 7 07:48:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 07 Apr 2014 09:48:51 +0200 Subject: [Freeipa-devel] Random Certificate Serial Numbers Message-ID: <53425863.1030602@redhat.com> Hi Rob, Ade and others, In the past, Rob was investigating enabling random certificate serial numbers for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. Can we simply switch it on for PKI with pkispawn attribute: [CA] pki_random_serial_numbers_enable=True or is there any drawback or risk we should investigate. I am just thinking, does PKI handle collisions anyhow? When for example two PKI masters generate 2 certificates of the same serial (unlikely though it could happen)? Currently, we assign different slice of serial range to different PKI masters, do we want to do that also for random serial? Thanks for info [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers [2] https://fedorahosted.org/freeipa/ticket/2016 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Mon Apr 7 08:55:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 07 Apr 2014 10:55:44 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <5314D51E.9040402@redhat.com> References: <5243F02D.9020005@redhat.com> <5284B9E2.3000007@redhat.com> <5314D51E.9040402@redhat.com> Message-ID: <53426810.6060205@redhat.com> On 03/03/2014 08:16 PM, Tomas Babej wrote: > The updated patch addresses all the mentioned issues. > > Also enables systemd's specific domainname service instead of relying > ypbind being present on the system. > > Please note that nisdomainname is not configured on boot time at the > moment. The following bug is the cause: > > https://bugzilla.redhat.com/show_bug.cgi?id=1071951 > > On 11/14/2013 12:54 PM, Ana Krivokapic wrote: >> On 09/26/2013 10:28 AM, Tomas Babej wrote: >>> + if options.no_nisdomain and not options.nisdomain: >> This should be `if options.no_nisdomain and options.nisdomain:`. >>> + parser.error("--no-nisdomain cannot be used together with --nisdomain") >> >> Shouldn't we also revert the nisdomain authconfig setting on client uninstall? This set the NIS domain correctly after the restart. However, it did not set it *before* the restart. Thus, after I installed IPA server/client, NIS domain was not set and thus SUDO would not work. Martin From lkrispen at redhat.com Mon Apr 7 09:35:05 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 07 Apr 2014 11:35:05 +0200 Subject: [Freeipa-devel] global account lockout Message-ID: <53427149.2010908@redhat.com> Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout From mkosek at redhat.com Mon Apr 7 11:28:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 07 Apr 2014 13:28:00 +0200 Subject: [Freeipa-devel] [PATCH] 0505 Default read ACIs for HBAC objects In-Reply-To: <533D3362.3060208@redhat.com> References: <533D3362.3060208@redhat.com> Message-ID: <53428BC0.40004@redhat.com> On 04/03/2014 12:09 PM, Petr Viktorin wrote: > Hello, > This adds read permissions to read HBAC rules, services, and service groups. > > Read access is given to all authenticated users. So far looked OK in my tests. What about the ACIs like the following one? (targetattr = "*")(version 3.0; acl "No anonymous access to hbac"; deny (read,search,compare) userdn != "ldap:///all";) Do we want to remove them together with this patch to have the change grouped together with allow ACIs or do you plan to remove all similar deny ACIs at once? (together with the master read ACI) Martin From pviktori at redhat.com Mon Apr 7 11:34:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Apr 2014 13:34:04 +0200 Subject: [Freeipa-devel] [PATCH] 0505 Default read ACIs for HBAC objects In-Reply-To: <53428BC0.40004@redhat.com> References: <533D3362.3060208@redhat.com> <53428BC0.40004@redhat.com> Message-ID: <53428D2C.4070601@redhat.com> On 04/07/2014 01:28 PM, Martin Kosek wrote: > On 04/03/2014 12:09 PM, Petr Viktorin wrote: >> Hello, >> This adds read permissions to read HBAC rules, services, and service groups. >> >> Read access is given to all authenticated users. > > So far looked OK in my tests. What about the ACIs like the following one? > > (targetattr = "*")(version 3.0; acl "No anonymous access to hbac"; deny > (read,search,compare) userdn != "ldap:///all";) > > Do we want to remove them together with this patch to have the change grouped > together with allow ACIs or do you plan to remove all similar deny ACIs at > once? (together with the master read ACI) > > Martin > I want to remove them after removing the global read ACI, so that in the mean time we're not allowing more access than we should. -- Petr? From mkosek at redhat.com Mon Apr 7 11:30:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 07 Apr 2014 13:30:02 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects In-Reply-To: <533D3360.7080106@redhat.com> References: <533D3360.7080106@redhat.com> Message-ID: <53428C3A.1000003@redhat.com> On 04/03/2014 12:09 PM, Petr Viktorin wrote: > Hello, > This adds read permissions to read Sudo commands, command groups, rules. > > Read access is given to all authenticated users. Looks good. What about "ou=sudoers"? I think we should also allow it in this patch for authenticated users. This is the tree that clients use to read sudo. Martin From rcritten at redhat.com Mon Apr 7 13:00:59 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2014 09:00:59 -0400 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <1396617621.18479.64.camel@willson.li.ssimo.org> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> Message-ID: <5342A18B.7070701@redhat.com> Simo Sorce wrote: > On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote: >> On 4.4.2014 09:17, Martin Kosek wrote: >>> On 04/04/2014 09:04 AM, Justin Brown wrote: >>>>> I would actually do it the opposite way and open the ports after the FreeIPA server is fully configured. After all, I do not think we want to open the ports when the server is just half-configured and for example some ACIs are missing. >>>> >>>> My thinking was that nothing would be listening on these ports if the >>>> install doesn't succeed, but there's really necessity to modify the >>>> firewall configuration early. (All of the internal install >>>> communication will be over a local interface (to netfilter) and >>>> unblock anyways. I don't have any problem in delaying firewall >>>> configuration to the end of install. >>> >>> If ipa-server-install does succeed without configuring the firewalld, then we >>> will indeed have no other option than to do it early. >>> >>> I am thinking that we may want to put all the firewalld configuration in >>> ipaserver/install/firewalldinstance.py, >>> and then make the firewalld configuration the actual step of the installation. >>> Something like: >>> >>> ... >>> Configuring Firewall (firewalld) >>> [1/2]: looking up the right zone >>> [2/2]: allowing ports >>> Done configuring Firewall (firewalld). >>> ... >>> >>> The Service class derived object can be really simple, we would just reuse the >>> functionality it already has + let us properly hook into it in >>> ipa-{server,replica}-install and the uninstallation. >>> >>> It would also make it easier to split this functionality to >>> freeipa-server-firewalld if we chose to in a future. >> >> In general I agree with the idea, thank you Justin for working on that! >> >> I would like to emphasis the necessity to work without NetworkManager and >> FirewallD. New dependencies make Debian folks unhappy ... >> >> On the other hand, it is perfectly fine to skip firewall configuration if >> NM/FirewallD/DBus is not available. >> >> Have a nice day! > > Should be easy, probe for the dbus firewalld service and just skip (not > error out) if it is not there. > Set a variable in that case that will cause the installer to throw the > classic banner we have now which warns you about what ports need to be > opened at the end of the install. Probably just need to spit out a large, preferably flashing warning that the firewall has not been automatically configured. Perhaps even multiple times: one in-line and one at the install summary at the end. rob From rcritten at redhat.com Mon Apr 7 13:07:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2014 09:07:24 -0400 Subject: [Freeipa-devel] questions regarding ldap schema for pkcs11 In-Reply-To: <1396617961.18479.67.camel@willson.li.ssimo.org> References: <533E6B3E.60808@redhat.com> <533E9547.6010309@redhat.com> <1396617961.18479.67.camel@willson.li.ssimo.org> Message-ID: <5342A30C.4040607@redhat.com> Simo Sorce wrote: > On Fri, 2014-04-04 at 13:19 +0200, Petr Spacek wrote: >> On 4.4.2014 10:20, Ludwig Krispenz wrote: >>> In the review discussion for the ldap schema for pkcs11 there was one topic, >>> which we wanted to get the opinion from a broader audience before making a >>> final decision. >> I'll add my opinion for the record: >> >>> In pkcs11 there are many boolean attributes, like CKA_EXTRACTABLE, CKA_DERIVE, >>> CKA_VERIFY and there are two suggestions how to represent them in ldap. >>> >>> >>> 1] one ldap attribute for each pkcs11 attribute. >>> This was my initial proposal to define a ldap attribute with boolean syntax. >>> Most attributes have default values and need not to be present >>> >>> example: >>> pkcs11extractable: true >>> pkcs11derive: false >>> pkcs11verify: true >>> >>> 2] one ldap attribute with pkcs11 attributes as values >>> During the review Simo suggested to have a single attribute (or a few of them, >>> key,cert,...) and for each pkcs11 attribute with value true add it as a value >>> >>> example: >>> pkcs11keyFlags: CKA_EXTRACTABLE >>> pkcs11keyFlags: CKA_VERIFY >>> >>> >>> Pros & Cons >>> >>> pro 1] : one ldap attribute for each pkcs11 attribute. >>> * direct mapping of pkcs11attributes >>> * required or allowed attributes are defined in an objectclass >>> >>> con 1]: >>> * huge number of schema attributes, which will probably not be needed >> I don't think it is a problem. We have *huge* schema full of almost never-used >> attributes. Look at printerAbstract objectClass ... >> >>> pro 2]: one ldap attribute with pkcs11 attributes as values >>> * smaller schema definition >> IPA schema + all the RFCs created a huge pile of schema definitions already >> and 389 can cope with it. (We are speaking about adding tens of attributes, >> not hundreds or thousands!) >> >>> * possible to add new attributes/flags without extending the schema >> Schema change is a little problem in comparison with updating clients (to get >> any value from the new flag). Note that we are talking about booleans defined >> by PKCS#11 standard so we can't add any boolean anyway. >> >> IMHO any IPA-specific booleans should go to a separate object class to >> separate them from pure PKCS#11 schema. >> >> >>> con 2]: >>> * no input validation, application could set undefined flags >>> * since presence of a flag means TRUE, and absence FALSE all default >>> true values need to be present >> >> To conclude it - I like approach [1]: One ldap attribute for each pkcs11 >> attribute. >> > > After much consideration I think one attribute per boolean is ok, I > think the most convincing argument came from Honza when he said > sometimes the default may depend on additional factors not explicit in > the object, in that case setting or not setting a string would always be > wrong and we would need to end up with additional definitions like: > CKA_VERIFY_TRUE/CKA_VERIFY_FALSE as opposed to them missing which could > indicate default (or we end up adding also CKA_VERIFY_DEFAULT ...). I prefer the one-per-boolean as well and for the same reason: it doesn't require magic values defined elsewhere. rob From tbabej at redhat.com Mon Apr 7 14:08:43 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 07 Apr 2014 16:08:43 +0200 Subject: [Freeipa-devel] [PATCH 0002] Use job prefix in install-built-rpms Message-ID: <5342B16B.1060308@redhat.com> Hi, this patch fixes the issue with using freeipa specific rpms when defining custom jobs. Tomas -- 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-ci-tbabej-0002-Use-job-prefix-in-install-built-rpms.patch Type: text/x-patch Size: 2076 bytes Desc: not available URL: From pviktori at redhat.com Mon Apr 7 14:27:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Apr 2014 16:27:33 +0200 Subject: [Freeipa-devel] [PATCH 0002] Use job prefix in install-built-rpms In-Reply-To: <5342B16B.1060308@redhat.com> References: <5342B16B.1060308@redhat.com> Message-ID: <5342B5D5.9040804@redhat.com> On 04/07/2014 04:08 PM, Tomas Babej wrote: > Hi, > > this patch fixes the issue with using freeipa specific rpms when > defining custom jobs. > > Tomas Thanks! Pushed to https://github.com/encukou/freeipa-ci.git as 01778989306e19e53b98d4acc72772631a8bb9dd -- Petr? From mkosek at redhat.com Mon Apr 7 14:43:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 07 Apr 2014 16:43:32 +0200 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers In-Reply-To: <533D472B.1010807@redhat.com> References: <533D472B.1010807@redhat.com> Message-ID: <5342B994.9070108@redhat.com> On 04/03/2014 01:34 PM, Petr Viktorin wrote: > Hello, > This adds anonymous read access to containers, as discussed in this thread: > https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html > > Additionally access is granted for $SUFFIX itself with targetfilter > "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, > associatedDomain. > > These are raw ACIs, not permission-based ones. Starting a new sub-thread to differential from the LDIF/update file fixes. I tested the new ACI and it worked ok for me (is a prerequisite for easy testing of the subsequent ACI patches). I assume you plan to handle cn=etc tree in other patch. ACK from me in that case (not pushing right now to let Simo raise any concerns he may have). Martin From simo at redhat.com Mon Apr 7 15:00:54 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2014 11:00:54 -0400 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers In-Reply-To: <5342B994.9070108@redhat.com> References: <533D472B.1010807@redhat.com> <5342B994.9070108@redhat.com> Message-ID: <1396882854.14203.48.camel@willson.li.ssimo.org> On Mon, 2014-04-07 at 16:43 +0200, Martin Kosek wrote: > On 04/03/2014 01:34 PM, Petr Viktorin wrote: > > Hello, > > This adds anonymous read access to containers, as discussed in this thread: > > https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html > > > > Additionally access is granted for $SUFFIX itself with targetfilter > > "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, > > associatedDomain. > > > > These are raw ACIs, not permission-based ones. > > Starting a new sub-thread to differential from the LDIF/update file fixes. > > I tested the new ACI and it worked ok for me (is a prerequisite for easy > testing of the subsequent ACI patches). I assume you plan to handle cn=etc tree > in other patch. > > ACK from me in that case (not pushing right now to let Simo raise any concerns > he may have). > > Martin I do not have any concern on the ACI itself, I only mused about ldif +update vs update only, sorry if I gave the worng impression. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Apr 7 15:26:26 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2014 11:26:26 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <53427149.2010908@redhat.com> References: <53427149.2010908@redhat.com> Message-ID: <5342C3A2.9070706@redhat.com> Ludwig Krispenz wrote: > Hi, > > please review the following feature design. It introduces a global > account lockout, while trying to keep the replication traffic minimal. > In my opinion for a real global account lockout the basic lockout > attributes have to be replicated otherwise the benefit is minimal: an > attacker could perform (maxFailedcount -1) login attempts on every > server before the global lockout is set. But the design page describes > how it could be done if it should be implemented - maybe the side effect > that accounts could the be unlocked on any replica has its own benefit. > > http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. rob From simo at redhat.com Mon Apr 7 16:01:05 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2014 12:01:05 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <5342C3A2.9070706@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> Message-ID: <1396886465.14203.61.camel@willson.li.ssimo.org> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: > Ludwig Krispenz wrote: > > Hi, > > > > please review the following feature design. It introduces a global > > account lockout, while trying to keep the replication traffic minimal. > > In my opinion for a real global account lockout the basic lockout > > attributes have to be replicated otherwise the benefit is minimal: an > > attacker could perform (maxFailedcount -1) login attempts on every > > server before the global lockout is set. But the design page describes > > how it could be done if it should be implemented - maybe the side effect > > that accounts could the be unlocked on any replica has its own benefit. > > > > http://www.freeipa.org/page/V4/Replicated_lockout > > One weakness with this is there is still a window for extra password > attempts if one is clever, (m * (f-1))+1 to be exact, where m is the > number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up "earlier". Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Apr 7 16:10:23 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2014 12:10:23 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1396886465.14203.61.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> Message-ID: <1396887023.14203.70.camel@willson.li.ssimo.org> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: > On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: > > Ludwig Krispenz wrote: > > > Hi, > > > > > > please review the following feature design. It introduces a global > > > account lockout, while trying to keep the replication traffic minimal. > > > In my opinion for a real global account lockout the basic lockout > > > attributes have to be replicated otherwise the benefit is minimal: an > > > attacker could perform (maxFailedcount -1) login attempts on every > > > server before the global lockout is set. But the design page describes > > > how it could be done if it should be implemented - maybe the side effect > > > that accounts could the be unlocked on any replica has its own benefit. > > > > > > http://www.freeipa.org/page/V4/Replicated_lockout > > > > One weakness with this is there is still a window for extra password > > attempts if one is clever, (m * (f-1))+1 to be exact, where m is the > > number of masters and f is the # of allowed failed logins. > > Yes, but that is a problem that cannot be solved w/o full replication at > every authentication attempt. > > What we tried to achieve is a middle ground to at least ease > administration and still lock em up "earlier". Let me add that we "could" have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is > 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Apr 7 16:13:42 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2014 12:13:42 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1396887023.14203.70.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> Message-ID: <1396887223.14203.73.camel@willson.li.ssimo.org> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: > On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: > > On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: > > > Ludwig Krispenz wrote: > > > > Hi, > > > > > > > > please review the following feature design. It introduces a global > > > > account lockout, while trying to keep the replication traffic minimal. > > > > In my opinion for a real global account lockout the basic lockout > > > > attributes have to be replicated otherwise the benefit is minimal: an > > > > attacker could perform (maxFailedcount -1) login attempts on every > > > > server before the global lockout is set. But the design page describes > > > > how it could be done if it should be implemented - maybe the side effect > > > > that accounts could the be unlocked on any replica has its own benefit. > > > > > > > > http://www.freeipa.org/page/V4/Replicated_lockout > > > > > > One weakness with this is there is still a window for extra password > > > attempts if one is clever, (m * (f-1))+1 to be exact, where m is the > > > number of masters and f is the # of allowed failed logins. > > > > Yes, but that is a problem that cannot be solved w/o full replication at > > every authentication attempt. > > > > What we tried to achieve is a middle ground to at least ease > > administration and still lock em up "earlier". > > Let me add that we "could" have yet another closer step by finding a way > to replicate only failed attempts and not successful attempts in some > case. Assuming a setup where most people do not fail to enter their > password it would make for a decent compromise. > > That could be achieved by not storing lastsuccessful auth except when > that is needed to clear failed logon attempts (ie when the failed logon > counter is > 0) > > If we did that then we would not need a new attribute actually, as > failed logins would always be replicated. > However it would mean that last Successful auth would never be accurate > on any server. > > Or perhaps we could have a local last successful auth and a global one > by adding one new attribute, and keeping masking only the successful > auth. > > The main issue about all these possibilities is how do we present them ? > And how do we make a good default ? > > I think a good default is defined by these 2 characteristics: > 1. lockouts can be dealt with on any replica w/o having the admin hunt > down where a user is locked. > 2. at least successful authentications will not cause replication storms > > If we can afford to cause replications on failed authentication by > default, then we could open up replication for failedauth and > failedcount attributes but still bar the successful auth attribute. > Unlock would simply consist in forcibly setting failed count to 0 (which > is replicated so it would unlock all servers). > This would work w/o introducing new attributes and only with minimal > logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Mon Apr 7 16:22:22 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 07 Apr 2014 10:22:22 -0600 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1396887223.14203.73.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> Message-ID: <5342D0BE.1090802@redhat.com> On 04/07/2014 10:13 AM, Simo Sorce wrote: > On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: >> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: >>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: >>>> Ludwig Krispenz wrote: >>>>> Hi, >>>>> >>>>> please review the following feature design. It introduces a global >>>>> account lockout, while trying to keep the replication traffic minimal. >>>>> In my opinion for a real global account lockout the basic lockout >>>>> attributes have to be replicated otherwise the benefit is minimal: an >>>>> attacker could perform (maxFailedcount -1) login attempts on every >>>>> server before the global lockout is set. But the design page describes >>>>> how it could be done if it should be implemented - maybe the side effect >>>>> that accounts could the be unlocked on any replica has its own benefit. >>>>> >>>>> http://www.freeipa.org/page/V4/Replicated_lockout >>>> One weakness with this is there is still a window for extra password >>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m is the >>>> number of masters and f is the # of allowed failed logins. >>> Yes, but that is a problem that cannot be solved w/o full replication at >>> every authentication attempt. >>> >>> What we tried to achieve is a middle ground to at least ease >>> administration and still lock em up "earlier". >> Let me add that we "could" have yet another closer step by finding a way >> to replicate only failed attempts and not successful attempts in some >> case. Assuming a setup where most people do not fail to enter their >> password it would make for a decent compromise. >> >> That could be achieved by not storing lastsuccessful auth except when >> that is needed to clear failed logon attempts (ie when the failed logon >> counter is > 0) >> >> If we did that then we would not need a new attribute actually, as >> failed logins would always be replicated. >> However it would mean that last Successful auth would never be accurate >> on any server. >> >> Or perhaps we could have a local last successful auth and a global one >> by adding one new attribute, and keeping masking only the successful >> auth. >> >> The main issue about all these possibilities is how do we present them ? >> And how do we make a good default ? >> >> I think a good default is defined by these 2 characteristics: >> 1. lockouts can be dealt with on any replica w/o having the admin hunt >> down where a user is locked. >> 2. at least successful authentications will not cause replication storms >> >> If we can afford to cause replications on failed authentication by >> default, then we could open up replication for failedauth and >> failedcount attributes but still bar the successful auth attribute. >> Unlock would simply consist in forcibly setting failed count to 0 (which >> is replicated so it would unlock all servers). >> This would work w/o introducing new attributes and only with minimal >> logic changes in the KDC/pwd-extop plugins I think. > Sigh re[plying again to myself. > note that the main issue with replicating failed accounts is that you > can cause replication storms by simply probing all user accounts with > failed binds or AS requests. In some environments that may cause DoSs > (if you have slow/high latency links on which replication runs for > example). > So I think we should always give the option to turn off failed > date/count attributes replication, which in turn would mean we still > require a new attribute to replicate for when a user is finally locked > out on one of the servers or we fail requirement 1. > > Simo. > Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say "only keep last N CSNs" or maybe even "don't keep CSNs for these attributes". From rcritten at redhat.com Mon Apr 7 18:09:33 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2014 14:09:33 -0400 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <533C97B4.4030100@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> Message-ID: <5342E9DD.2070307@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> the attached patches implement automatic CA certificate renewal as well >> as the initial version of the CA certificate management tool. >> >> Requires my patches 172-196. >> >> In order to test, you must install current git version of certmonger >> (see ) and set SELinux to >> permissive (see ). >> Make sure you install certmonger before running >> ipa-server-install/ipa-replica-install. On F20 you can use RPMs located >> at . >> >> To test automatic renewal, move system time forward (see >> for more info >> about certificate renewal testing, nickname of the CA certificate is >> "caSigningCert cert-pki-ca"). In CA-full installs the renewal should be >> fully automatic, in CA-less installs you should be alerted via syslog to >> renew the certificate using ipa-cacert-manage. >> >> To test manual renewal, run "ipa-cacert-manage renew". You can run it on >> any CA master. To make the renewed certificate available on other CA >> masters, you must run "getcert resubmit -d /etc/pki/pki-tomcat/alias -n >> 'caSigningCert cert-pki-ca'" on each of them. Note that currently you >> can't change the chaining of the CA certificate. > > 241 > > Not to be too anal, but would it be too outlandish to compare the > Authority Key Identifier (if there is one) with the Subject Key ID to > see if the cert is self-signed? Same subject then yeah, it is probably > self-signed. The keys match? Definitely. > > 242 > > I wonder if it would be clearer to use variables instead of a raw list > in the return value for these handlers: (result, message) = handler(...) > rather than examining result[0], etc. That may be beyond the scope of > this patch though. > > x509.normalize_certificate() can raise an exception, there should be a > try/except around it. > > For an invalid cookie, please include the values seen in the environment > in the error message. > > 243 > > You are going to end up with a lot of acis with the same comment value. > Perhaps add the host in there as well. > > These are not removed when a master is deleted. > > 244 > > There are now several different places where the caCertificate value is > updated. I wonder if it's time for a function. I found it it in > dsinstance.py, upload_cacert and now renew_ca_cert. > > 246 > > caRenewalMaster should be checked when a replica is deleted and moved to > another master. This is a good idea. I wonder if a ticket should be > opened to do something similar for CRL generation. > > 247 > > We've been burned by hardcoded timeouts in the past. Should this be > configurable? This module doesn't currently do any logging but it might > be worth spitting out a "waiting" message, at least for debugging. > > 249 > > nss_init() is always scary to me since we can only have one. I didn't > see anything blow up, just wondering if this should be wrapped with an > is_initialized()->shutdown() at the top. > > The find_cert_from_nickname() should be in a try/except in case the cert > is not found for some reason. > > 251 > > The tool should provide some feedback while it's running. For the > impatient (me) it takes a really long time and it's hard to know what is > going on, something in between nothing and full debug output. > > The man page needs some more work too. I think some more explanation is > needed and an example would probably be really helpful as well. I think > particularly an example for external certs and a description of what you > mean by Self-signed CA (I assume you mean IPA-provided). I don't think > it really matters how many steps there are unless you are going to > provide progress output. > > Got a backtrace when running as non-root: > > $ ipa-cacert-manage -v renew > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 168, in > execute > self.validate_options() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", > line 62, in validate_options > super(CACertManage, self).validate_options(needs_root=True) > File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line > 189, in validate_options > raise ScriptError('Must be root to run %s' % self.command_name, 1) > > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The > ipa-cacert-manage command failed, exception: ScriptError: Must be root > to run ipa-cacert-manage > ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be > root to run ipa-cacert-manage > > 252 > > In what context would this be executing? My guess is that certmonger is > trying to do the renewal but a new cert hasn't been issued yet, so this > gets sysloged? > > Still doing functional testing. My current scenario: 1. Newly installed IPA master with these patches. 2. Replica using IPA 3.3.4 (yeah, I cheated) While doing time travel I had a single cert fail on the initial master with this: ca-error: Server at https://lyra.example.com/ipa/xml failed request, will retry: 4204 (RPC failed at server. limits exceeded for this query). Mar 21 11:00:22 lyra ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm 'EXAMPLE.COM') Mar 21 11:00:22 lyra certmonger: 2016-03-21 11:00:22 [28676] Server at https://lyra.example.com/ipa/xml failed request, will retry: 4204 (RPC failed at server. limits exceeded for this query). From the access log: [21/Mar/2016:11:00:21 -0400] conn=49 op=5 SRCH base="krbprincipalname=HTTP/lyra.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="userCertificate krbPrincipalName * ipaKrbAuthzData managedBy aci" [21/Mar/2016:11:00:21 -0400] conn=49 op=5 RESULT err=3 tag=101 nentries=0 etime=17 So yeah, 17 seconds is a long time. A resubmit fixed it and certmonger would have done this automatically if I had the patience, so not too worried about that. After moving time forward on the replica these certificates are in CA_WORKING: ipaCert auditSigningCert cert-pki-ca ocspSigningCert cert-pki-ca subsystemCert cert-pki-ca cn=ca_renewal is completely empty on the replica. On the master it only has the subsystemCert. I'm guessing this is at least partly due to my switching time one system at a time rather than (somewhat) simultaneously, but it still would have blown up with 3 missing certs. rob From simo at redhat.com Mon Apr 7 18:31:32 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2014 14:31:32 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <5342D0BE.1090802@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> Message-ID: <1396895492.14203.106.camel@willson.li.ssimo.org> On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: > On 04/07/2014 10:13 AM, Simo Sorce wrote: > > On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: > >> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: > >>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: > >>>> Ludwig Krispenz wrote: > >>>>> Hi, > >>>>> > >>>>> please review the following feature design. It introduces a global > >>>>> account lockout, while trying to keep the replication traffic minimal. > >>>>> In my opinion for a real global account lockout the basic lockout > >>>>> attributes have to be replicated otherwise the benefit is minimal: an > >>>>> attacker could perform (maxFailedcount -1) login attempts on every > >>>>> server before the global lockout is set. But the design page describes > >>>>> how it could be done if it should be implemented - maybe the side effect > >>>>> that accounts could the be unlocked on any replica has its own benefit. > >>>>> > >>>>> http://www.freeipa.org/page/V4/Replicated_lockout > >>>> One weakness with this is there is still a window for extra password > >>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m is the > >>>> number of masters and f is the # of allowed failed logins. > >>> Yes, but that is a problem that cannot be solved w/o full replication at > >>> every authentication attempt. > >>> > >>> What we tried to achieve is a middle ground to at least ease > >>> administration and still lock em up "earlier". > >> Let me add that we "could" have yet another closer step by finding a way > >> to replicate only failed attempts and not successful attempts in some > >> case. Assuming a setup where most people do not fail to enter their > >> password it would make for a decent compromise. > >> > >> That could be achieved by not storing lastsuccessful auth except when > >> that is needed to clear failed logon attempts (ie when the failed logon > >> counter is > 0) > >> > >> If we did that then we would not need a new attribute actually, as > >> failed logins would always be replicated. > >> However it would mean that last Successful auth would never be accurate > >> on any server. > >> > >> Or perhaps we could have a local last successful auth and a global one > >> by adding one new attribute, and keeping masking only the successful > >> auth. > >> > >> The main issue about all these possibilities is how do we present them ? > >> And how do we make a good default ? > >> > >> I think a good default is defined by these 2 characteristics: > >> 1. lockouts can be dealt with on any replica w/o having the admin hunt > >> down where a user is locked. > >> 2. at least successful authentications will not cause replication storms > >> > >> If we can afford to cause replications on failed authentication by > >> default, then we could open up replication for failedauth and > >> failedcount attributes but still bar the successful auth attribute. > >> Unlock would simply consist in forcibly setting failed count to 0 (which > >> is replicated so it would unlock all servers). > >> This would work w/o introducing new attributes and only with minimal > >> logic changes in the KDC/pwd-extop plugins I think. > > Sigh re[plying again to myself. > > note that the main issue with replicating failed accounts is that you > > can cause replication storms by simply probing all user accounts with > > failed binds or AS requests. In some environments that may cause DoSs > > (if you have slow/high latency links on which replication runs for > > example). > > So I think we should always give the option to turn off failed > > date/count attributes replication, which in turn would mean we still > > require a new attribute to replicate for when a user is finally locked > > out on one of the servers or we fail requirement 1. > > > > Simo. > > > Another problem with keeping track of bind attributes in a replicated > environment is the sheer size of the replication metadata. Replicating > 1 failed bind attempt might be 100kbytes or more data to all servers. > We should have a way to perhaps say "only keep last N CSNs" or maybe > even "don't keep CSNs for these attributes". Yes, but this look a lot like general replication improvement (would also be cool to have "better" conflict resolution), not lockout specific. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Mon Apr 7 18:47:25 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 07 Apr 2014 12:47:25 -0600 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1396895492.14203.106.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> Message-ID: <5342F2BD.1030407@redhat.com> On 04/07/2014 12:31 PM, Simo Sorce wrote: > On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: >> On 04/07/2014 10:13 AM, Simo Sorce wrote: >>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: >>>> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: >>>>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: >>>>>> Ludwig Krispenz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review the following feature design. It introduces a global >>>>>>> account lockout, while trying to keep the replication traffic minimal. >>>>>>> In my opinion for a real global account lockout the basic lockout >>>>>>> attributes have to be replicated otherwise the benefit is minimal: an >>>>>>> attacker could perform (maxFailedcount -1) login attempts on every >>>>>>> server before the global lockout is set. But the design page describes >>>>>>> how it could be done if it should be implemented - maybe the side effect >>>>>>> that accounts could the be unlocked on any replica has its own benefit. >>>>>>> >>>>>>> http://www.freeipa.org/page/V4/Replicated_lockout >>>>>> One weakness with this is there is still a window for extra password >>>>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m is the >>>>>> number of masters and f is the # of allowed failed logins. >>>>> Yes, but that is a problem that cannot be solved w/o full replication at >>>>> every authentication attempt. >>>>> >>>>> What we tried to achieve is a middle ground to at least ease >>>>> administration and still lock em up "earlier". >>>> Let me add that we "could" have yet another closer step by finding a way >>>> to replicate only failed attempts and not successful attempts in some >>>> case. Assuming a setup where most people do not fail to enter their >>>> password it would make for a decent compromise. >>>> >>>> That could be achieved by not storing lastsuccessful auth except when >>>> that is needed to clear failed logon attempts (ie when the failed logon >>>> counter is > 0) >>>> >>>> If we did that then we would not need a new attribute actually, as >>>> failed logins would always be replicated. >>>> However it would mean that last Successful auth would never be accurate >>>> on any server. >>>> >>>> Or perhaps we could have a local last successful auth and a global one >>>> by adding one new attribute, and keeping masking only the successful >>>> auth. >>>> >>>> The main issue about all these possibilities is how do we present them ? >>>> And how do we make a good default ? >>>> >>>> I think a good default is defined by these 2 characteristics: >>>> 1. lockouts can be dealt with on any replica w/o having the admin hunt >>>> down where a user is locked. >>>> 2. at least successful authentications will not cause replication storms >>>> >>>> If we can afford to cause replications on failed authentication by >>>> default, then we could open up replication for failedauth and >>>> failedcount attributes but still bar the successful auth attribute. >>>> Unlock would simply consist in forcibly setting failed count to 0 (which >>>> is replicated so it would unlock all servers). >>>> This would work w/o introducing new attributes and only with minimal >>>> logic changes in the KDC/pwd-extop plugins I think. >>> Sigh re[plying again to myself. >>> note that the main issue with replicating failed accounts is that you >>> can cause replication storms by simply probing all user accounts with >>> failed binds or AS requests. In some environments that may cause DoSs >>> (if you have slow/high latency links on which replication runs for >>> example). >>> So I think we should always give the option to turn off failed >>> date/count attributes replication, which in turn would mean we still >>> require a new attribute to replicate for when a user is finally locked >>> out on one of the servers or we fail requirement 1. >>> >>> Simo. >>> >> Another problem with keeping track of bind attributes in a replicated >> environment is the sheer size of the replication metadata. Replicating >> 1 failed bind attempt might be 100kbytes or more data to all servers. >> We should have a way to perhaps say "only keep last N CSNs" or maybe >> even "don't keep CSNs for these attributes". > Yes, but this look a lot like general replication improvement (would > also be cool to have "better" conflict resolution), Ludwig has made some improvements with how 389 stores replication metadata for conflict resolution, but in this case it's not nearly enough. > not lockout > specific. > > Simo. > From dpal at redhat.com Mon Apr 7 18:47:27 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 07 Apr 2014 14:47:27 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1396895492.14203.106.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> Message-ID: <5342F2BF.9090000@redhat.com> On 04/07/2014 02:31 PM, Simo Sorce wrote: > On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: >> On 04/07/2014 10:13 AM, Simo Sorce wrote: >>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: >>>> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: >>>>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: >>>>>> Ludwig Krispenz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review the following feature design. It introduces a global >>>>>>> account lockout, while trying to keep the replication traffic minimal. >>>>>>> In my opinion for a real global account lockout the basic lockout >>>>>>> attributes have to be replicated otherwise the benefit is minimal: an >>>>>>> attacker could perform (maxFailedcount -1) login attempts on every >>>>>>> server before the global lockout is set. But the design page describes >>>>>>> how it could be done if it should be implemented - maybe the side effect >>>>>>> that accounts could the be unlocked on any replica has its own benefit. >>>>>>> >>>>>>> http://www.freeipa.org/page/V4/Replicated_lockout >>>>>> One weakness with this is there is still a window for extra password >>>>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m is the >>>>>> number of masters and f is the # of allowed failed logins. >>>>> Yes, but that is a problem that cannot be solved w/o full replication at >>>>> every authentication attempt. >>>>> >>>>> What we tried to achieve is a middle ground to at least ease >>>>> administration and still lock em up "earlier". >>>> Let me add that we "could" have yet another closer step by finding a way >>>> to replicate only failed attempts and not successful attempts in some >>>> case. Assuming a setup where most people do not fail to enter their >>>> password it would make for a decent compromise. >>>> >>>> That could be achieved by not storing lastsuccessful auth except when >>>> that is needed to clear failed logon attempts (ie when the failed logon >>>> counter is > 0) >>>> >>>> If we did that then we would not need a new attribute actually, as >>>> failed logins would always be replicated. >>>> However it would mean that last Successful auth would never be accurate >>>> on any server. >>>> >>>> Or perhaps we could have a local last successful auth and a global one >>>> by adding one new attribute, and keeping masking only the successful >>>> auth. >>>> >>>> The main issue about all these possibilities is how do we present them ? >>>> And how do we make a good default ? >>>> >>>> I think a good default is defined by these 2 characteristics: >>>> 1. lockouts can be dealt with on any replica w/o having the admin hunt >>>> down where a user is locked. >>>> 2. at least successful authentications will not cause replication storms >>>> >>>> If we can afford to cause replications on failed authentication by >>>> default, then we could open up replication for failedauth and >>>> failedcount attributes but still bar the successful auth attribute. >>>> Unlock would simply consist in forcibly setting failed count to 0 (which >>>> is replicated so it would unlock all servers). >>>> This would work w/o introducing new attributes and only with minimal >>>> logic changes in the KDC/pwd-extop plugins I think. >>> Sigh re[plying again to myself. >>> note that the main issue with replicating failed accounts is that you >>> can cause replication storms by simply probing all user accounts with >>> failed binds or AS requests. In some environments that may cause DoSs >>> (if you have slow/high latency links on which replication runs for >>> example). >>> So I think we should always give the option to turn off failed >>> date/count attributes replication, which in turn would mean we still >>> require a new attribute to replicate for when a user is finally locked >>> out on one of the servers or we fail requirement 1. >>> >>> Simo. >>> >> Another problem with keeping track of bind attributes in a replicated >> environment is the sheer size of the replication metadata. Replicating >> 1 failed bind attempt might be 100kbytes or more data to all servers. >> We should have a way to perhaps say "only keep last N CSNs" or maybe >> even "don't keep CSNs for these attributes". > Yes, but this look a lot like general replication improvement (would > also be cool to have "better" conflict resolution), not lockout > specific. > > Simo. > My only comment is actually about conflict resolution. What would happen if I attack (flood) two replicas at the same time beating the replication. It would mean both servers would generate the global attributes and try to replicate to each other. If the replicas are on the edges of topology it might take some time and it might even happen that admin already unlocked the account while the old lock is still trying to propagate. IMO we need collisions resolution logic taken care of first. I suspect that any real attack would lead to collisions and if it would leave the deployment unstable even after the attack ended we lost. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Apr 7 18:51:14 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 07 Apr 2014 14:51:14 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <1396637432.8149.30.camel@aleeredhat.laptop> References: <1396637432.8149.30.camel@aleeredhat.laptop> Message-ID: <5342F3A2.1070809@redhat.com> On 04/04/2014 02:50 PM, Ade Lee wrote: > This patch adds the capability of installing a Dogtag DRM > to an IPA instance. With this patch, when ipa-server-install > is run, a Dogtag CA and a Dogtag DRM are created. The DRM > shares the same tomcat instance and DS instance as the Dogtag CA. > Moreover, the same admin user/agent (and agent cert) can be used > for both subsystems. Certmonger is also confgured to monitor the > new subsystem certificates. > > It is also possible to clone the DRM. When the IPA instance is > cloned, if --enable-ca and --enable-drm are specified, the DRM > is cloned as well. > > Installing a DRM requires the user to have a Dogtag CA instance. > We can look into possibly relaxing that requirement in a later patch. > > I am still working on patches for a ipa-drm-install script, which > would be used to add a DRM to an existing master (that includes > a dogtag CA), or an existing clone. > > Please review, > > Thanks, > Ade > Any takers? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Apr 7 18:58:03 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2014 14:58:03 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <5342F3A2.1070809@redhat.com> References: <1396637432.8149.30.camel@aleeredhat.laptop> <5342F3A2.1070809@redhat.com> Message-ID: <5342F53B.2090108@redhat.com> Dmitri Pal wrote: > On 04/04/2014 02:50 PM, Ade Lee wrote: >> This patch adds the capability of installing a Dogtag DRM >> to an IPA instance. With this patch, when ipa-server-install >> is run, a Dogtag CA and a Dogtag DRM are created. The DRM >> shares the same tomcat instance and DS instance as the Dogtag CA. >> Moreover, the same admin user/agent (and agent cert) can be used >> for both subsystems. Certmonger is also confgured to monitor the >> new subsystem certificates. >> >> It is also possible to clone the DRM. When the IPA instance is >> cloned, if --enable-ca and --enable-drm are specified, the DRM >> is cloned as well. >> >> Installing a DRM requires the user to have a Dogtag CA instance. >> We can look into possibly relaxing that requirement in a later patch. >> >> I am still working on patches for a ipa-drm-install script, which >> would be used to add a DRM to an existing master (that includes >> a dogtag CA), or an existing clone. >> >> Please review, >> >> Thanks, >> Ade >> > > > Any takers? I'm going to look at it. Ade has provided a COPR build of the dogtag bits we'll need at http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/ rob From simo at redhat.com Mon Apr 7 19:00:15 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2014 15:00:15 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <5342F2BF.9090000@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> Message-ID: <1396897215.14203.109.camel@willson.li.ssimo.org> On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote: > On 04/07/2014 02:31 PM, Simo Sorce wrote: > > On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: > >> On 04/07/2014 10:13 AM, Simo Sorce wrote: > >>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: > >>>> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: > >>>>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: > >>>>>> Ludwig Krispenz wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> please review the following feature design. It introduces a global > >>>>>>> account lockout, while trying to keep the replication traffic minimal. > >>>>>>> In my opinion for a real global account lockout the basic lockout > >>>>>>> attributes have to be replicated otherwise the benefit is minimal: an > >>>>>>> attacker could perform (maxFailedcount -1) login attempts on every > >>>>>>> server before the global lockout is set. But the design page describes > >>>>>>> how it could be done if it should be implemented - maybe the side effect > >>>>>>> that accounts could the be unlocked on any replica has its own benefit. > >>>>>>> > >>>>>>> http://www.freeipa.org/page/V4/Replicated_lockout > >>>>>> One weakness with this is there is still a window for extra password > >>>>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m is the > >>>>>> number of masters and f is the # of allowed failed logins. > >>>>> Yes, but that is a problem that cannot be solved w/o full replication at > >>>>> every authentication attempt. > >>>>> > >>>>> What we tried to achieve is a middle ground to at least ease > >>>>> administration and still lock em up "earlier". > >>>> Let me add that we "could" have yet another closer step by finding a way > >>>> to replicate only failed attempts and not successful attempts in some > >>>> case. Assuming a setup where most people do not fail to enter their > >>>> password it would make for a decent compromise. > >>>> > >>>> That could be achieved by not storing lastsuccessful auth except when > >>>> that is needed to clear failed logon attempts (ie when the failed logon > >>>> counter is > 0) > >>>> > >>>> If we did that then we would not need a new attribute actually, as > >>>> failed logins would always be replicated. > >>>> However it would mean that last Successful auth would never be accurate > >>>> on any server. > >>>> > >>>> Or perhaps we could have a local last successful auth and a global one > >>>> by adding one new attribute, and keeping masking only the successful > >>>> auth. > >>>> > >>>> The main issue about all these possibilities is how do we present them ? > >>>> And how do we make a good default ? > >>>> > >>>> I think a good default is defined by these 2 characteristics: > >>>> 1. lockouts can be dealt with on any replica w/o having the admin hunt > >>>> down where a user is locked. > >>>> 2. at least successful authentications will not cause replication storms > >>>> > >>>> If we can afford to cause replications on failed authentication by > >>>> default, then we could open up replication for failedauth and > >>>> failedcount attributes but still bar the successful auth attribute. > >>>> Unlock would simply consist in forcibly setting failed count to 0 (which > >>>> is replicated so it would unlock all servers). > >>>> This would work w/o introducing new attributes and only with minimal > >>>> logic changes in the KDC/pwd-extop plugins I think. > >>> Sigh re[plying again to myself. > >>> note that the main issue with replicating failed accounts is that you > >>> can cause replication storms by simply probing all user accounts with > >>> failed binds or AS requests. In some environments that may cause DoSs > >>> (if you have slow/high latency links on which replication runs for > >>> example). > >>> So I think we should always give the option to turn off failed > >>> date/count attributes replication, which in turn would mean we still > >>> require a new attribute to replicate for when a user is finally locked > >>> out on one of the servers or we fail requirement 1. > >>> > >>> Simo. > >>> > >> Another problem with keeping track of bind attributes in a replicated > >> environment is the sheer size of the replication metadata. Replicating > >> 1 failed bind attempt might be 100kbytes or more data to all servers. > >> We should have a way to perhaps say "only keep last N CSNs" or maybe > >> even "don't keep CSNs for these attributes". > > Yes, but this look a lot like general replication improvement (would > > also be cool to have "better" conflict resolution), not lockout > > specific. > > > > Simo. > > > My only comment is actually about conflict resolution. What would happen > if I attack (flood) two replicas at the same time beating the > replication. It would mean both servers would generate the global > attributes and try to replicate to each other. If the replicas are on > the edges of topology it might take some time and it might even happen > that admin already unlocked the account while the old lock is still > trying to propagate. IMO we need collisions resolution logic taken care > of first. I suspect that any real attack would lead to collisions and if > it would leave the deployment unstable even after the attack ended we lost. Yes, this is a valid concern. We need a last-wins conflict resolution strategy for some cases. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Mon Apr 7 20:28:04 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 07 Apr 2014 14:28:04 -0600 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1396897215.14203.109.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> Message-ID: <53430A54.1080205@redhat.com> On 04/07/2014 01:00 PM, Simo Sorce wrote: > On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote: >> On 04/07/2014 02:31 PM, Simo Sorce wrote: >>> On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: >>>> On 04/07/2014 10:13 AM, Simo Sorce wrote: >>>>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: >>>>>> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: >>>>>>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: >>>>>>>> Ludwig Krispenz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please review the following feature design. It introduces a global >>>>>>>>> account lockout, while trying to keep the replication traffic minimal. >>>>>>>>> In my opinion for a real global account lockout the basic lockout >>>>>>>>> attributes have to be replicated otherwise the benefit is minimal: an >>>>>>>>> attacker could perform (maxFailedcount -1) login attempts on every >>>>>>>>> server before the global lockout is set. But the design page describes >>>>>>>>> how it could be done if it should be implemented - maybe the side effect >>>>>>>>> that accounts could the be unlocked on any replica has its own benefit. >>>>>>>>> >>>>>>>>> http://www.freeipa.org/page/V4/Replicated_lockout >>>>>>>> One weakness with this is there is still a window for extra password >>>>>>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m is the >>>>>>>> number of masters and f is the # of allowed failed logins. >>>>>>> Yes, but that is a problem that cannot be solved w/o full replication at >>>>>>> every authentication attempt. >>>>>>> >>>>>>> What we tried to achieve is a middle ground to at least ease >>>>>>> administration and still lock em up "earlier". >>>>>> Let me add that we "could" have yet another closer step by finding a way >>>>>> to replicate only failed attempts and not successful attempts in some >>>>>> case. Assuming a setup where most people do not fail to enter their >>>>>> password it would make for a decent compromise. >>>>>> >>>>>> That could be achieved by not storing lastsuccessful auth except when >>>>>> that is needed to clear failed logon attempts (ie when the failed logon >>>>>> counter is > 0) >>>>>> >>>>>> If we did that then we would not need a new attribute actually, as >>>>>> failed logins would always be replicated. >>>>>> However it would mean that last Successful auth would never be accurate >>>>>> on any server. >>>>>> >>>>>> Or perhaps we could have a local last successful auth and a global one >>>>>> by adding one new attribute, and keeping masking only the successful >>>>>> auth. >>>>>> >>>>>> The main issue about all these possibilities is how do we present them ? >>>>>> And how do we make a good default ? >>>>>> >>>>>> I think a good default is defined by these 2 characteristics: >>>>>> 1. lockouts can be dealt with on any replica w/o having the admin hunt >>>>>> down where a user is locked. >>>>>> 2. at least successful authentications will not cause replication storms >>>>>> >>>>>> If we can afford to cause replications on failed authentication by >>>>>> default, then we could open up replication for failedauth and >>>>>> failedcount attributes but still bar the successful auth attribute. >>>>>> Unlock would simply consist in forcibly setting failed count to 0 (which >>>>>> is replicated so it would unlock all servers). >>>>>> This would work w/o introducing new attributes and only with minimal >>>>>> logic changes in the KDC/pwd-extop plugins I think. >>>>> Sigh re[plying again to myself. >>>>> note that the main issue with replicating failed accounts is that you >>>>> can cause replication storms by simply probing all user accounts with >>>>> failed binds or AS requests. In some environments that may cause DoSs >>>>> (if you have slow/high latency links on which replication runs for >>>>> example). >>>>> So I think we should always give the option to turn off failed >>>>> date/count attributes replication, which in turn would mean we still >>>>> require a new attribute to replicate for when a user is finally locked >>>>> out on one of the servers or we fail requirement 1. >>>>> >>>>> Simo. >>>>> >>>> Another problem with keeping track of bind attributes in a replicated >>>> environment is the sheer size of the replication metadata. Replicating >>>> 1 failed bind attempt might be 100kbytes or more data to all servers. >>>> We should have a way to perhaps say "only keep last N CSNs" or maybe >>>> even "don't keep CSNs for these attributes". >>> Yes, but this look a lot like general replication improvement (would >>> also be cool to have "better" conflict resolution), not lockout >>> specific. >>> >>> Simo. >>> >> My only comment is actually about conflict resolution. What would happen >> if I attack (flood) two replicas at the same time beating the >> replication. It would mean both servers would generate the global >> attributes and try to replicate to each other. If the replicas are on >> the edges of topology it might take some time and it might even happen >> that admin already unlocked the account while the old lock is still >> trying to propagate. IMO we need collisions resolution logic taken care >> of first. I suspect that any real attack would lead to collisions and if >> it would leave the deployment unstable even after the attack ended we lost. > Yes, this is a valid concern. We need a last-wins conflict resolution > strategy for some cases. I'm not sure what you mean. The 389 conflict resolution strategy is "last-wins" already. Or do you mean "for some cases, but not all cases"? > > Simo. > From rcritten at redhat.com Mon Apr 7 20:40:47 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2014 16:40:47 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <1396637432.8149.30.camel@aleeredhat.laptop> References: <1396637432.8149.30.camel@aleeredhat.laptop> Message-ID: <53430D4F.4000903@redhat.com> Ade Lee wrote: > This patch adds the capability of installing a Dogtag DRM > to an IPA instance. With this patch, when ipa-server-install > is run, a Dogtag CA and a Dogtag DRM are created. The DRM > shares the same tomcat instance and DS instance as the Dogtag CA. > Moreover, the same admin user/agent (and agent cert) can be used > for both subsystems. Certmonger is also confgured to monitor the > new subsystem certificates. > > It is also possible to clone the DRM. When the IPA instance is > cloned, if --enable-ca and --enable-drm are specified, the DRM > is cloned as well. > > Installing a DRM requires the user to have a Dogtag CA instance. > We can look into possibly relaxing that requirement in a later patch. > > I am still working on patches for a ipa-drm-install script, which > would be used to add a DRM to an existing master (that includes > a dogtag CA), or an existing clone. > > Please review, > > Thanks, > Ade Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be pushed ASAP. freeipa-spec.in needs a dependency on pki-kra. Is it necessary to check for pkispawn/destroy in check_inst()? That should be handled by the CA install, right? You need to bump the version in ipa-pki-proxy.conf so that upgrades get the new configuration. Rather than this: + if setup_drm: + fd.write("enable_drm=True\n") + else: + fd.write("enable_drm=False\n") Why not: fd.write("enable_drm=%s\n" % setup_drm) If o=ipadrm is a new root we'll need to backup/restore it right? You should import PKI_USER and HTTPD_CONFD from cainstance.py rather than redefining them. You should probably call the is_installed() from cainstance.py rather than redefining this. The function might be ok but I'd replace the contents with: ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR) return ca.is_installed() If the DRM is already installed we don't have a way to uninstall it so we shouldn't recommend that as an option. The value for pki_issuing_ca_uri doesn't create a valid URL (missing //). You should use this form instead: config.set("KRA", "pki_issuing_ca_uri", "https://%s" % ipautil.format_netloc(self.fqdn, 443)) I think that update_people_entry() should probably be moved into installutils.py and used for both the CA and DRM instances. It makes a certain amount of sense to use /etc/ipa/default.conf. It may be outside the scope here but it if we're including it, but would it be better to use that for everything rather than splitting between two files? The install failed for me. I've attached the KRA debug log. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.gz Type: application/x-gzip Size: 6055 bytes Desc: not available URL: From rcritten at redhat.com Mon Apr 7 20:41:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2014 16:41:56 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <53430A54.1080205@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> Message-ID: <53430D94.4060304@redhat.com> Rich Megginson wrote: > On 04/07/2014 01:00 PM, Simo Sorce wrote: >> On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote: >>> On 04/07/2014 02:31 PM, Simo Sorce wrote: >>>> On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: >>>>> On 04/07/2014 10:13 AM, Simo Sorce wrote: >>>>>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: >>>>>>> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: >>>>>>>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: >>>>>>>>> Ludwig Krispenz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please review the following feature design. It introduces a >>>>>>>>>> global >>>>>>>>>> account lockout, while trying to keep the replication traffic >>>>>>>>>> minimal. >>>>>>>>>> In my opinion for a real global account lockout the basic lockout >>>>>>>>>> attributes have to be replicated otherwise the benefit is >>>>>>>>>> minimal: an >>>>>>>>>> attacker could perform (maxFailedcount -1) login attempts on >>>>>>>>>> every >>>>>>>>>> server before the global lockout is set. But the design page >>>>>>>>>> describes >>>>>>>>>> how it could be done if it should be implemented - maybe the >>>>>>>>>> side effect >>>>>>>>>> that accounts could the be unlocked on any replica has its own >>>>>>>>>> benefit. >>>>>>>>>> >>>>>>>>>> http://www.freeipa.org/page/V4/Replicated_lockout >>>>>>>>> One weakness with this is there is still a window for extra >>>>>>>>> password >>>>>>>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m >>>>>>>>> is the >>>>>>>>> number of masters and f is the # of allowed failed logins. >>>>>>>> Yes, but that is a problem that cannot be solved w/o full >>>>>>>> replication at >>>>>>>> every authentication attempt. >>>>>>>> >>>>>>>> What we tried to achieve is a middle ground to at least ease >>>>>>>> administration and still lock em up "earlier". >>>>>>> Let me add that we "could" have yet another closer step by >>>>>>> finding a way >>>>>>> to replicate only failed attempts and not successful attempts in >>>>>>> some >>>>>>> case. Assuming a setup where most people do not fail to enter their >>>>>>> password it would make for a decent compromise. >>>>>>> >>>>>>> That could be achieved by not storing lastsuccessful auth except >>>>>>> when >>>>>>> that is needed to clear failed logon attempts (ie when the failed >>>>>>> logon >>>>>>> counter is > 0) >>>>>>> >>>>>>> If we did that then we would not need a new attribute actually, as >>>>>>> failed logins would always be replicated. >>>>>>> However it would mean that last Successful auth would never be >>>>>>> accurate >>>>>>> on any server. >>>>>>> >>>>>>> Or perhaps we could have a local last successful auth and a >>>>>>> global one >>>>>>> by adding one new attribute, and keeping masking only the successful >>>>>>> auth. >>>>>>> >>>>>>> The main issue about all these possibilities is how do we present >>>>>>> them ? >>>>>>> And how do we make a good default ? >>>>>>> >>>>>>> I think a good default is defined by these 2 characteristics: >>>>>>> 1. lockouts can be dealt with on any replica w/o having the admin >>>>>>> hunt >>>>>>> down where a user is locked. >>>>>>> 2. at least successful authentications will not cause replication >>>>>>> storms >>>>>>> >>>>>>> If we can afford to cause replications on failed authentication by >>>>>>> default, then we could open up replication for failedauth and >>>>>>> failedcount attributes but still bar the successful auth attribute. >>>>>>> Unlock would simply consist in forcibly setting failed count to 0 >>>>>>> (which >>>>>>> is replicated so it would unlock all servers). >>>>>>> This would work w/o introducing new attributes and only with minimal >>>>>>> logic changes in the KDC/pwd-extop plugins I think. >>>>>> Sigh re[plying again to myself. >>>>>> note that the main issue with replicating failed accounts is that you >>>>>> can cause replication storms by simply probing all user accounts with >>>>>> failed binds or AS requests. In some environments that may cause DoSs >>>>>> (if you have slow/high latency links on which replication runs for >>>>>> example). >>>>>> So I think we should always give the option to turn off failed >>>>>> date/count attributes replication, which in turn would mean we still >>>>>> require a new attribute to replicate for when a user is finally >>>>>> locked >>>>>> out on one of the servers or we fail requirement 1. >>>>>> >>>>>> Simo. >>>>>> >>>>> Another problem with keeping track of bind attributes in a replicated >>>>> environment is the sheer size of the replication metadata. >>>>> Replicating >>>>> 1 failed bind attempt might be 100kbytes or more data to all servers. >>>>> We should have a way to perhaps say "only keep last N CSNs" or maybe >>>>> even "don't keep CSNs for these attributes". >>>> Yes, but this look a lot like general replication improvement (would >>>> also be cool to have "better" conflict resolution), not lockout >>>> specific. >>>> >>>> Simo. >>>> >>> My only comment is actually about conflict resolution. What would happen >>> if I attack (flood) two replicas at the same time beating the >>> replication. It would mean both servers would generate the global >>> attributes and try to replicate to each other. If the replicas are on >>> the edges of topology it might take some time and it might even happen >>> that admin already unlocked the account while the old lock is still >>> trying to propagate. IMO we need collisions resolution logic taken care >>> of first. I suspect that any real attack would lead to collisions and if >>> it would leave the deployment unstable even after the attack ended we >>> lost. >> Yes, this is a valid concern. We need a last-wins conflict resolution >> strategy for some cases. > > I'm not sure what you mean. The 389 conflict resolution strategy is > "last-wins" already. Or do you mean "for some cases, but not all cases"? He may be thinking entry vs attribute reconciliation. We definitely wouldn't want a replication conflict entry created in case there were conflicting updates. rob From simo at redhat.com Mon Apr 7 22:56:59 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2014 18:56:59 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <53430A54.1080205@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> Message-ID: <1396911419.14203.126.camel@willson.li.ssimo.org> On Mon, 2014-04-07 at 14:28 -0600, Rich Megginson wrote: > On 04/07/2014 01:00 PM, Simo Sorce wrote: > > On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote: > >> On 04/07/2014 02:31 PM, Simo Sorce wrote: > >>> On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: > >>>> On 04/07/2014 10:13 AM, Simo Sorce wrote: > >>>>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: > >>>>>> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: > >>>>>>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: > >>>>>>>> Ludwig Krispenz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> please review the following feature design. It introduces a global > >>>>>>>>> account lockout, while trying to keep the replication traffic minimal. > >>>>>>>>> In my opinion for a real global account lockout the basic lockout > >>>>>>>>> attributes have to be replicated otherwise the benefit is minimal: an > >>>>>>>>> attacker could perform (maxFailedcount -1) login attempts on every > >>>>>>>>> server before the global lockout is set. But the design page describes > >>>>>>>>> how it could be done if it should be implemented - maybe the side effect > >>>>>>>>> that accounts could the be unlocked on any replica has its own benefit. > >>>>>>>>> > >>>>>>>>> http://www.freeipa.org/page/V4/Replicated_lockout > >>>>>>>> One weakness with this is there is still a window for extra password > >>>>>>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m is the > >>>>>>>> number of masters and f is the # of allowed failed logins. > >>>>>>> Yes, but that is a problem that cannot be solved w/o full replication at > >>>>>>> every authentication attempt. > >>>>>>> > >>>>>>> What we tried to achieve is a middle ground to at least ease > >>>>>>> administration and still lock em up "earlier". > >>>>>> Let me add that we "could" have yet another closer step by finding a way > >>>>>> to replicate only failed attempts and not successful attempts in some > >>>>>> case. Assuming a setup where most people do not fail to enter their > >>>>>> password it would make for a decent compromise. > >>>>>> > >>>>>> That could be achieved by not storing lastsuccessful auth except when > >>>>>> that is needed to clear failed logon attempts (ie when the failed logon > >>>>>> counter is > 0) > >>>>>> > >>>>>> If we did that then we would not need a new attribute actually, as > >>>>>> failed logins would always be replicated. > >>>>>> However it would mean that last Successful auth would never be accurate > >>>>>> on any server. > >>>>>> > >>>>>> Or perhaps we could have a local last successful auth and a global one > >>>>>> by adding one new attribute, and keeping masking only the successful > >>>>>> auth. > >>>>>> > >>>>>> The main issue about all these possibilities is how do we present them ? > >>>>>> And how do we make a good default ? > >>>>>> > >>>>>> I think a good default is defined by these 2 characteristics: > >>>>>> 1. lockouts can be dealt with on any replica w/o having the admin hunt > >>>>>> down where a user is locked. > >>>>>> 2. at least successful authentications will not cause replication storms > >>>>>> > >>>>>> If we can afford to cause replications on failed authentication by > >>>>>> default, then we could open up replication for failedauth and > >>>>>> failedcount attributes but still bar the successful auth attribute. > >>>>>> Unlock would simply consist in forcibly setting failed count to 0 (which > >>>>>> is replicated so it would unlock all servers). > >>>>>> This would work w/o introducing new attributes and only with minimal > >>>>>> logic changes in the KDC/pwd-extop plugins I think. > >>>>> Sigh re[plying again to myself. > >>>>> note that the main issue with replicating failed accounts is that you > >>>>> can cause replication storms by simply probing all user accounts with > >>>>> failed binds or AS requests. In some environments that may cause DoSs > >>>>> (if you have slow/high latency links on which replication runs for > >>>>> example). > >>>>> So I think we should always give the option to turn off failed > >>>>> date/count attributes replication, which in turn would mean we still > >>>>> require a new attribute to replicate for when a user is finally locked > >>>>> out on one of the servers or we fail requirement 1. > >>>>> > >>>>> Simo. > >>>>> > >>>> Another problem with keeping track of bind attributes in a replicated > >>>> environment is the sheer size of the replication metadata. Replicating > >>>> 1 failed bind attempt might be 100kbytes or more data to all servers. > >>>> We should have a way to perhaps say "only keep last N CSNs" or maybe > >>>> even "don't keep CSNs for these attributes". > >>> Yes, but this look a lot like general replication improvement (would > >>> also be cool to have "better" conflict resolution), not lockout > >>> specific. > >>> > >>> Simo. > >>> > >> My only comment is actually about conflict resolution. What would happen > >> if I attack (flood) two replicas at the same time beating the > >> replication. It would mean both servers would generate the global > >> attributes and try to replicate to each other. If the replicas are on > >> the edges of topology it might take some time and it might even happen > >> that admin already unlocked the account while the old lock is still > >> trying to propagate. IMO we need collisions resolution logic taken care > >> of first. I suspect that any real attack would lead to collisions and if > >> it would leave the deployment unstable even after the attack ended we lost. > > Yes, this is a valid concern. We need a last-wins conflict resolution > > strategy for some cases. > > I'm not sure what you mean. The 389 conflict resolution strategy is > "last-wins" already. Or do you mean "for some cases, but not all cases"? I am thinking about those case when we end up with duplicate objects. In many (most ?) case we should just throw away one of the 2 and keep the other, not end up with 2 objects. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Apr 7 23:51:25 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 07 Apr 2014 19:51:25 -0400 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <5342A18B.7070701@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> Message-ID: <534339FD.3090901@redhat.com> On 04/07/2014 09:00 AM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote: >>> On 4.4.2014 09:17, Martin Kosek wrote: >>>> On 04/04/2014 09:04 AM, Justin Brown wrote: >>>>>> I would actually do it the opposite way and open the ports after >>>>>> the FreeIPA server is fully configured. After all, I do not think >>>>>> we want to open the ports when the server is just half-configured >>>>>> and for example some ACIs are missing. >>>>> >>>>> My thinking was that nothing would be listening on these ports if the >>>>> install doesn't succeed, but there's really necessity to modify the >>>>> firewall configuration early. (All of the internal install >>>>> communication will be over a local interface (to netfilter) and >>>>> unblock anyways. I don't have any problem in delaying firewall >>>>> configuration to the end of install. >>>> >>>> If ipa-server-install does succeed without configuring the >>>> firewalld, then we >>>> will indeed have no other option than to do it early. >>>> >>>> I am thinking that we may want to put all the firewalld >>>> configuration in >>>> ipaserver/install/firewalldinstance.py, >>>> and then make the firewalld configuration the actual step of the >>>> installation. >>>> Something like: >>>> >>>> ... >>>> Configuring Firewall (firewalld) >>>> [1/2]: looking up the right zone >>>> [2/2]: allowing ports >>>> Done configuring Firewall (firewalld). >>>> ... >>>> >>>> The Service class derived object can be really simple, we would >>>> just reuse the >>>> functionality it already has + let us properly hook into it in >>>> ipa-{server,replica}-install and the uninstallation. >>>> >>>> It would also make it easier to split this functionality to >>>> freeipa-server-firewalld if we chose to in a future. >>> >>> In general I agree with the idea, thank you Justin for working on that! >>> >>> I would like to emphasis the necessity to work without >>> NetworkManager and >>> FirewallD. New dependencies make Debian folks unhappy ... >>> >>> On the other hand, it is perfectly fine to skip firewall >>> configuration if >>> NM/FirewallD/DBus is not available. >>> >>> Have a nice day! >> >> Should be easy, probe for the dbus firewalld service and just skip (not >> error out) if it is not there. >> Set a variable in that case that will cause the installer to throw the >> classic banner we have now which warns you about what ports need to be >> opened at the end of the install. > > Probably just need to spit out a large, preferably flashing warning > that the firewall has not been automatically configured. Perhaps even > multiple times: one in-line and one at the install summary at the end. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Thanks for looking into this! Would it be possible to summarize this thread in a design page on the wiki? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Apr 7 23:53:16 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 07 Apr 2014 19:53:16 -0400 Subject: [Freeipa-devel] Random Certificate Serial Numbers In-Reply-To: <53425863.1030602@redhat.com> References: <53425863.1030602@redhat.com> Message-ID: <53433A6C.3060903@redhat.com> On 04/07/2014 03:48 AM, Martin Kosek wrote: > Hi Rob, Ade and others, > > In the past, Rob was investigating enabling random certificate serial numbers > for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. > Can we simply switch it on for PKI with pkispawn attribute: > > [CA] > pki_random_serial_numbers_enable=True > > or is there any drawback or risk we should investigate. I am just thinking, > does PKI handle collisions anyhow? When for example two PKI masters generate 2 > certificates of the same serial (unlikely though it could happen)? > > Currently, we assign different slice of serial range to different PKI masters, > do we want to do that also for random serial? > > Thanks for info > > [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers > [2] https://fedorahosted.org/freeipa/ticket/2016 > Any impact on upgrades? Any impact on certmonger? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Tue Apr 8 06:50:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 08:50:53 +0200 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <53430D4F.4000903@redhat.com> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> Message-ID: <53439C4D.6060108@redhat.com> On 04/07/2014 10:40 PM, Rob Crittenden wrote: > Ade Lee wrote: >> This patch adds the capability of installing a Dogtag DRM >> to an IPA instance. With this patch, when ipa-server-install >> is run, a Dogtag CA and a Dogtag DRM are created. The DRM >> shares the same tomcat instance and DS instance as the Dogtag CA. >> Moreover, the same admin user/agent (and agent cert) can be used >> for both subsystems. Certmonger is also confgured to monitor the >> new subsystem certificates. >> >> It is also possible to clone the DRM. When the IPA instance is >> cloned, if --enable-ca and --enable-drm are specified, the DRM >> is cloned as well. >> >> Installing a DRM requires the user to have a Dogtag CA instance. >> We can look into possibly relaxing that requirement in a later patch. >> >> I am still working on patches for a ipa-drm-install script, which >> would be used to add a DRM to an existing master (that includes >> a dogtag CA), or an existing clone. >> >> Please review, >> >> Thanks, >> Ade > > Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be > pushed ASAP. Oops, looks like a change that should go to IPA 3.3.x. What is the implication? > freeipa-spec.in needs a dependency on pki-kra. Let us stop here. Please see a following RFE I filed: https://fedorahosted.org/freeipa/ticket/4058 I would prefer it KRA files and specifics would be in a new subpackage like freeipa-server-kra. Otherwise we will need to rework it again when we would be splitting CA to freeipa-server-pki in 4.1. I would prefer to start the right modularization now as I do not think that every FreeIPA server needs to run CA/KRA, i.e. it does not need to have the bits installed either. I am also quite worried about the duplication that the new drminstance.py introduces. There is a lot of functions which do more or less the same thing and have most of the handling code the same with only a very small and predictable pki/kra change. For example __http_proxy function seems to be exactly the same. It would be great to avoid this duplication and rather have some common ground utilized by both PKI and KRA. Otherwise it will be very difficult to maintain the new code. Martin From jcholast at redhat.com Tue Apr 8 07:22:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Apr 2014 09:22:05 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <533E9091.9020900@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> Message-ID: <5343A39D.2000808@redhat.com> On 4.4.2014 12:59, Petr Spacek wrote: > On 3.4.2014 15:35, Jan Cholasta wrote: >> I would shorten "origin_sign" to just "sign". > Sign of what? Decay? :-) I don't think that sign is descriptive enough, > I would personally stick with origin_sign. Whoops, I meant "origin". The "_sign" bit seems a little bit redundant to me. -- Jan Cholasta From jcholast at redhat.com Tue Apr 8 07:31:08 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Apr 2014 09:31:08 +0200 Subject: [Freeipa-devel] questions regarding ldap schema for pkcs11 In-Reply-To: <5342A30C.4040607@redhat.com> References: <533E6B3E.60808@redhat.com> <533E9547.6010309@redhat.com> <1396617961.18479.67.camel@willson.li.ssimo.org> <5342A30C.4040607@redhat.com> Message-ID: <5343A5BC.8090304@redhat.com> On 7.4.2014 15:07, Rob Crittenden wrote: > Simo Sorce wrote: >> On Fri, 2014-04-04 at 13:19 +0200, Petr Spacek wrote: >>> On 4.4.2014 10:20, Ludwig Krispenz wrote: >>>> In the review discussion for the ldap schema for pkcs11 there was >>>> one topic, >>>> which we wanted to get the opinion from a broader audience before >>>> making a >>>> final decision. >>> I'll add my opinion for the record: >>> >>>> In pkcs11 there are many boolean attributes, like CKA_EXTRACTABLE, >>>> CKA_DERIVE, >>>> CKA_VERIFY and there are two suggestions how to represent them in ldap. >>>> >>>> >>>> 1] one ldap attribute for each pkcs11 attribute. >>>> This was my initial proposal to define a ldap attribute with boolean >>>> syntax. >>>> Most attributes have default values and need not to be present >>>> >>>> example: >>>> pkcs11extractable: true >>>> pkcs11derive: false >>>> pkcs11verify: true >>>> >>>> 2] one ldap attribute with pkcs11 attributes as values >>>> During the review Simo suggested to have a single attribute (or a >>>> few of them, >>>> key,cert,...) and for each pkcs11 attribute with value true add it >>>> as a value >>>> >>>> example: >>>> pkcs11keyFlags: CKA_EXTRACTABLE >>>> pkcs11keyFlags: CKA_VERIFY >>>> >>>> >>>> Pros & Cons >>>> >>>> pro 1] : one ldap attribute for each pkcs11 attribute. >>>> * direct mapping of pkcs11attributes >>>> * required or allowed attributes are defined in an objectclass >>>> >>>> con 1]: >>>> * huge number of schema attributes, which will probably not be >>>> needed >>> I don't think it is a problem. We have *huge* schema full of almost >>> never-used >>> attributes. Look at printerAbstract objectClass ... >>> >>>> pro 2]: one ldap attribute with pkcs11 attributes as values >>>> * smaller schema definition >>> IPA schema + all the RFCs created a huge pile of schema definitions >>> already >>> and 389 can cope with it. (We are speaking about adding tens of >>> attributes, >>> not hundreds or thousands!) >>> >>>> * possible to add new attributes/flags without extending the schema >>> Schema change is a little problem in comparison with updating clients >>> (to get >>> any value from the new flag). Note that we are talking about booleans >>> defined >>> by PKCS#11 standard so we can't add any boolean anyway. >>> >>> IMHO any IPA-specific booleans should go to a separate object class to >>> separate them from pure PKCS#11 schema. >>> >>> >>>> con 2]: >>>> * no input validation, application could set undefined flags >>>> * since presence of a flag means TRUE, and absence FALSE all default >>>> true values need to be present >>> >>> To conclude it - I like approach [1]: One ldap attribute for each pkcs11 >>> attribute. >>> >> >> After much consideration I think one attribute per boolean is ok, I >> think the most convincing argument came from Honza when he said >> sometimes the default may depend on additional factors not explicit in >> the object, in that case setting or not setting a string would always be >> wrong and we would need to end up with additional definitions like: >> CKA_VERIFY_TRUE/CKA_VERIFY_FALSE as opposed to them missing which could >> indicate default (or we end up adding also CKA_VERIFY_DEFAULT ...). > > I prefer the one-per-boolean as well and for the same reason: it doesn't > require magic values defined elsewhere. Over the weekend I prepared a great argument about this and look, I am sick for one day and suddenly don't have to post it anymore :-) Glad we reached an agreement on this. Honza -- Jan Cholasta From pspacek at redhat.com Tue Apr 8 07:50:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 08 Apr 2014 09:50:48 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343A39D.2000808@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> Message-ID: <5343AA58.6080800@redhat.com> On 8.4.2014 09:22, Jan Cholasta wrote: > On 4.4.2014 12:59, Petr Spacek wrote: >> On 3.4.2014 15:35, Jan Cholasta wrote: >>> I would shorten "origin_sign" to just "sign". >> Sign of what? Decay? :-) I don't think that sign is descriptive enough, >> I would personally stick with origin_sign. > > Whoops, I meant "origin". The "_sign" bit seems a little bit redundant to me. "Origin" is an established term for the name of the parent. name = "blabla.example." origin of "name" = "example." Anyway, I still think that DNSName('@') is better than any constant with cryptic name. Honza, can you see any problem with this? I know this creates instance again and again, but is it a real problem? I would like to avoid premature optimization... :-) -- Petr^2 Spacek From jcholast at redhat.com Tue Apr 8 08:01:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Apr 2014 10:01:20 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343AA58.6080800@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> Message-ID: <5343ACD0.1000904@redhat.com> On 8.4.2014 09:50, Petr Spacek wrote: > On 8.4.2014 09:22, Jan Cholasta wrote: >> On 4.4.2014 12:59, Petr Spacek wrote: >>> On 3.4.2014 15:35, Jan Cholasta wrote: >>>> I would shorten "origin_sign" to just "sign". >>> Sign of what? Decay? :-) I don't think that sign is descriptive enough, >>> I would personally stick with origin_sign. >> >> Whoops, I meant "origin". The "_sign" bit seems a little bit redundant >> to me. > > "Origin" is an established term for the name of the parent. > > name = "blabla.example." > origin of "name" = "example." > > Anyway, I still think that DNSName('@') is better than any constant with > cryptic name. > > Honza, can you see any problem with this? I know this creates instance > again and again, but is it a real problem? I would like to avoid > premature optimization... :-) > I don't have a strong opinion on this, but I think a constant *is* useful, if we can agree on a good name for it. -- Jan Cholasta From abokovoy at redhat.com Tue Apr 8 08:01:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Apr 2014 11:01:03 +0300 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343AA58.6080800@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> Message-ID: <20140408080103.GM20958@redhat.com> On Tue, 08 Apr 2014, Petr Spacek wrote: >On 8.4.2014 09:22, Jan Cholasta wrote: >>On 4.4.2014 12:59, Petr Spacek wrote: >>>On 3.4.2014 15:35, Jan Cholasta wrote: >>>>I would shorten "origin_sign" to just "sign". >>>Sign of what? Decay? :-) I don't think that sign is descriptive enough, >>>I would personally stick with origin_sign. >> >>Whoops, I meant "origin". The "_sign" bit seems a little bit redundant to me. > >"Origin" is an established term for the name of the parent. > >name = "blabla.example." >origin of "name" = "example." > >Anyway, I still think that DNSName('@') is better than any constant >with cryptic name. > >Honza, can you see any problem with this? I know this creates >instance again and again, but is it a real problem? I would like to >avoid premature optimization... :-) What about making all these fixed names as constants and then simply return those? class DNSName: DNS_ORIGIN = DNSName('@') ... @staticmethod ... def ... return DNS_ORIGIN they would be singletons... -- / Alexander Bokovoy From jcholast at redhat.com Tue Apr 8 08:05:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Apr 2014 10:05:32 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <20140408080103.GM20958@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> Message-ID: <5343ADCC.20700@redhat.com> On 8.4.2014 10:01, Alexander Bokovoy wrote: > On Tue, 08 Apr 2014, Petr Spacek wrote: >> On 8.4.2014 09:22, Jan Cholasta wrote: >>> On 4.4.2014 12:59, Petr Spacek wrote: >>>> On 3.4.2014 15:35, Jan Cholasta wrote: >>>>> I would shorten "origin_sign" to just "sign". >>>> Sign of what? Decay? :-) I don't think that sign is descriptive enough, >>>> I would personally stick with origin_sign. >>> >>> Whoops, I meant "origin". The "_sign" bit seems a little bit >>> redundant to me. >> >> "Origin" is an established term for the name of the parent. >> >> name = "blabla.example." >> origin of "name" = "example." >> >> Anyway, I still think that DNSName('@') is better than any constant >> with cryptic name. >> >> Honza, can you see any problem with this? I know this creates instance >> again and again, but is it a real problem? I would like to avoid >> premature optimization... :-) > What about making all these fixed names as constants and then simply > return those? > > class DNSName: > DNS_ORIGIN = DNSName('@') > ... > > @staticmethod ... > def ... > return DNS_ORIGIN > > they would be singletons... Unfortunately you can't do that, because at the time DNSName is parsed, it is not defined yet: >>> class X: ... x = X() ... Traceback (most recent call last): File "", line 1, in File "", line 2, in X NameError: name 'X' is not defined -- Jan Cholasta From abokovoy at redhat.com Tue Apr 8 08:09:56 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Apr 2014 11:09:56 +0300 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343ADCC.20700@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> Message-ID: <20140408080956.GN20958@redhat.com> On Tue, 08 Apr 2014, Jan Cholasta wrote: >On 8.4.2014 10:01, Alexander Bokovoy wrote: >>On Tue, 08 Apr 2014, Petr Spacek wrote: >>>On 8.4.2014 09:22, Jan Cholasta wrote: >>>>On 4.4.2014 12:59, Petr Spacek wrote: >>>>>On 3.4.2014 15:35, Jan Cholasta wrote: >>>>>>I would shorten "origin_sign" to just "sign". >>>>>Sign of what? Decay? :-) I don't think that sign is descriptive enough, >>>>>I would personally stick with origin_sign. >>>> >>>>Whoops, I meant "origin". The "_sign" bit seems a little bit >>>>redundant to me. >>> >>>"Origin" is an established term for the name of the parent. >>> >>>name = "blabla.example." >>>origin of "name" = "example." >>> >>>Anyway, I still think that DNSName('@') is better than any constant >>>with cryptic name. >>> >>>Honza, can you see any problem with this? I know this creates instance >>>again and again, but is it a real problem? I would like to avoid >>>premature optimization... :-) >>What about making all these fixed names as constants and then simply >>return those? >> >>class DNSName: >> DNS_ORIGIN = DNSName('@') >> ... >> >> @staticmethod ... >> def ... >> return DNS_ORIGIN >> >>they would be singletons... > >Unfortunately you can't do that, because at the time DNSName is >parsed, it is not defined yet: > >>>> class X: >... x = X() >... >Traceback (most recent call last): > File "", line 1, in > File "", line 2, in X >NameError: name 'X' is not defined Then we can split these classes: define DNSName with purely static methods as child of DNSNameBase which would have all the expected methods. DNSName can then have constants of DNSNameBase() and return those. -- / Alexander Bokovoy From jcholast at redhat.com Tue Apr 8 08:14:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Apr 2014 10:14:32 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <20140408080956.GN20958@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> <20140408080956.GN20958@redhat.com> Message-ID: <5343AFE8.3090309@redhat.com> On 8.4.2014 10:09, Alexander Bokovoy wrote: > On Tue, 08 Apr 2014, Jan Cholasta wrote: >> On 8.4.2014 10:01, Alexander Bokovoy wrote: >>> On Tue, 08 Apr 2014, Petr Spacek wrote: >>>> On 8.4.2014 09:22, Jan Cholasta wrote: >>>>> On 4.4.2014 12:59, Petr Spacek wrote: >>>>>> On 3.4.2014 15:35, Jan Cholasta wrote: >>>>>>> I would shorten "origin_sign" to just "sign". >>>>>> Sign of what? Decay? :-) I don't think that sign is descriptive >>>>>> enough, >>>>>> I would personally stick with origin_sign. >>>>> >>>>> Whoops, I meant "origin". The "_sign" bit seems a little bit >>>>> redundant to me. >>>> >>>> "Origin" is an established term for the name of the parent. >>>> >>>> name = "blabla.example." >>>> origin of "name" = "example." >>>> >>>> Anyway, I still think that DNSName('@') is better than any constant >>>> with cryptic name. >>>> >>>> Honza, can you see any problem with this? I know this creates instance >>>> again and again, but is it a real problem? I would like to avoid >>>> premature optimization... :-) >>> What about making all these fixed names as constants and then simply >>> return those? >>> >>> class DNSName: >>> DNS_ORIGIN = DNSName('@') >>> ... >>> >>> @staticmethod ... >>> def ... >>> return DNS_ORIGIN >>> >>> they would be singletons... >> >> Unfortunately you can't do that, because at the time DNSName is >> parsed, it is not defined yet: >> >>>>> class X: >> ... x = X() >> ... >> Traceback (most recent call last): >> File "", line 1, in >> File "", line 2, in X >> NameError: name 'X' is not defined > Then we can split these classes: define DNSName with purely static > methods as child of DNSNameBase which would have all the expected > methods. DNSName can then have constants of DNSNameBase() and return > those. > IMO this is an overkill. I would prefer if we did what I suggested earlier: put DNSName into a new module dnsutil and make the constants global for the module. -- Jan Cholasta From abokovoy at redhat.com Tue Apr 8 08:18:22 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Apr 2014 11:18:22 +0300 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343AFE8.3090309@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> <20140408080956.GN20958@redhat.com> <5343AFE8.3090309@redhat.com> Message-ID: <20140408081822.GO20958@redhat.com> On Tue, 08 Apr 2014, Jan Cholasta wrote: >On 8.4.2014 10:09, Alexander Bokovoy wrote: >>On Tue, 08 Apr 2014, Jan Cholasta wrote: >>>On 8.4.2014 10:01, Alexander Bokovoy wrote: >>>>On Tue, 08 Apr 2014, Petr Spacek wrote: >>>>>On 8.4.2014 09:22, Jan Cholasta wrote: >>>>>>On 4.4.2014 12:59, Petr Spacek wrote: >>>>>>>On 3.4.2014 15:35, Jan Cholasta wrote: >>>>>>>>I would shorten "origin_sign" to just "sign". >>>>>>>Sign of what? Decay? :-) I don't think that sign is descriptive >>>>>>>enough, >>>>>>>I would personally stick with origin_sign. >>>>>> >>>>>>Whoops, I meant "origin". The "_sign" bit seems a little bit >>>>>>redundant to me. >>>>> >>>>>"Origin" is an established term for the name of the parent. >>>>> >>>>>name = "blabla.example." >>>>>origin of "name" = "example." >>>>> >>>>>Anyway, I still think that DNSName('@') is better than any constant >>>>>with cryptic name. >>>>> >>>>>Honza, can you see any problem with this? I know this creates instance >>>>>again and again, but is it a real problem? I would like to avoid >>>>>premature optimization... :-) >>>>What about making all these fixed names as constants and then simply >>>>return those? >>>> >>>>class DNSName: >>>> DNS_ORIGIN = DNSName('@') >>>> ... >>>> >>>> @staticmethod ... >>>> def ... >>>> return DNS_ORIGIN >>>> >>>>they would be singletons... >>> >>>Unfortunately you can't do that, because at the time DNSName is >>>parsed, it is not defined yet: >>> >>>>>>class X: >>>... x = X() >>>... >>>Traceback (most recent call last): >>> File "", line 1, in >>> File "", line 2, in X >>>NameError: name 'X' is not defined >>Then we can split these classes: define DNSName with purely static >>methods as child of DNSNameBase which would have all the expected >>methods. DNSName can then have constants of DNSNameBase() and return >>those. >> > >IMO this is an overkill. I would prefer if we did what I suggested >earlier: put DNSName into a new module dnsutil and make the constants >global for the module. That would work too. -- / Alexander Bokovoy From pspacek at redhat.com Tue Apr 8 08:19:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 08 Apr 2014 10:19:01 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343AFE8.3090309@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> <20140408080956.GN20958@redhat.com> <5343AFE8.3090309@redhat.com> Message-ID: <5343B0F5.2010505@redhat.com> On 8.4.2014 10:14, Jan Cholasta wrote: > On 8.4.2014 10:09, Alexander Bokovoy wrote: >> On Tue, 08 Apr 2014, Jan Cholasta wrote: >>> On 8.4.2014 10:01, Alexander Bokovoy wrote: >>>> On Tue, 08 Apr 2014, Petr Spacek wrote: >>>>> On 8.4.2014 09:22, Jan Cholasta wrote: >>>>>> On 4.4.2014 12:59, Petr Spacek wrote: >>>>>>> On 3.4.2014 15:35, Jan Cholasta wrote: >>>>>>>> I would shorten "origin_sign" to just "sign". >>>>>>> Sign of what? Decay? :-) I don't think that sign is descriptive >>>>>>> enough, >>>>>>> I would personally stick with origin_sign. >>>>>> >>>>>> Whoops, I meant "origin". The "_sign" bit seems a little bit >>>>>> redundant to me. >>>>> >>>>> "Origin" is an established term for the name of the parent. >>>>> >>>>> name = "blabla.example." >>>>> origin of "name" = "example." >>>>> >>>>> Anyway, I still think that DNSName('@') is better than any constant >>>>> with cryptic name. >>>>> >>>>> Honza, can you see any problem with this? I know this creates instance >>>>> again and again, but is it a real problem? I would like to avoid >>>>> premature optimization... :-) >>>> What about making all these fixed names as constants and then simply >>>> return those? >>>> >>>> class DNSName: >>>> DNS_ORIGIN = DNSName('@') >>>> ... >>>> >>>> @staticmethod ... >>>> def ... >>>> return DNS_ORIGIN >>>> >>>> they would be singletons... >>> >>> Unfortunately you can't do that, because at the time DNSName is >>> parsed, it is not defined yet: >>> >>>>>> class X: >>> ... x = X() >>> ... >>> Traceback (most recent call last): >>> File "", line 1, in >>> File "", line 2, in X >>> NameError: name 'X' is not defined >> Then we can split these classes: define DNSName with purely static >> methods as child of DNSNameBase which would have all the expected >> methods. DNSName can then have constants of DNSNameBase() and return >> those. >> > > IMO this is an overkill. I would prefer if we did what I suggested earlier: > put DNSName into a new module dnsutil and make the constants global for the > module. I consider this less readable but I'm not Python expert so I'm fine this approach. Note: The difference between @ and real "origin" is like "pointer to origin" and "origin value" in C. -- Petr^2 Spacek From jcholast at redhat.com Tue Apr 8 08:29:19 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Apr 2014 10:29:19 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343B0F5.2010505@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> <20140408080956.GN20958@redhat.com> <5343AFE8.3090309@redhat.com> <5343B0F5.2010505@redhat.com> Message-ID: <5343B35F.3030007@redhat.com> On 8.4.2014 10:19, Petr Spacek wrote: > On 8.4.2014 10:14, Jan Cholasta wrote: >> On 8.4.2014 10:09, Alexander Bokovoy wrote: >>> On Tue, 08 Apr 2014, Jan Cholasta wrote: >>>> On 8.4.2014 10:01, Alexander Bokovoy wrote: >>>>> On Tue, 08 Apr 2014, Petr Spacek wrote: >>>>>> On 8.4.2014 09:22, Jan Cholasta wrote: >>>>>>> On 4.4.2014 12:59, Petr Spacek wrote: >>>>>>>> On 3.4.2014 15:35, Jan Cholasta wrote: >>>>>>>>> I would shorten "origin_sign" to just "sign". >>>>>>>> Sign of what? Decay? :-) I don't think that sign is descriptive >>>>>>>> enough, >>>>>>>> I would personally stick with origin_sign. >>>>>>> >>>>>>> Whoops, I meant "origin". The "_sign" bit seems a little bit >>>>>>> redundant to me. >>>>>> >>>>>> "Origin" is an established term for the name of the parent. >>>>>> >>>>>> name = "blabla.example." >>>>>> origin of "name" = "example." >>>>>> >>>>>> Anyway, I still think that DNSName('@') is better than any constant >>>>>> with cryptic name. >>>>>> >>>>>> Honza, can you see any problem with this? I know this creates >>>>>> instance >>>>>> again and again, but is it a real problem? I would like to avoid >>>>>> premature optimization... :-) >>>>> What about making all these fixed names as constants and then simply >>>>> return those? >>>>> >>>>> class DNSName: >>>>> DNS_ORIGIN = DNSName('@') >>>>> ... >>>>> >>>>> @staticmethod ... >>>>> def ... >>>>> return DNS_ORIGIN >>>>> >>>>> they would be singletons... >>>> >>>> Unfortunately you can't do that, because at the time DNSName is >>>> parsed, it is not defined yet: >>>> >>>>>>> class X: >>>> ... x = X() >>>> ... >>>> Traceback (most recent call last): >>>> File "", line 1, in >>>> File "", line 2, in X >>>> NameError: name 'X' is not defined >>> Then we can split these classes: define DNSName with purely static >>> methods as child of DNSNameBase which would have all the expected >>> methods. DNSName can then have constants of DNSNameBase() and return >>> those. >>> >> >> IMO this is an overkill. I would prefer if we did what I suggested >> earlier: >> put DNSName into a new module dnsutil and make the constants global >> for the >> module. > > I consider this less readable but I'm not Python expert so I'm fine this > approach. Well, it's the same thing python-dns does: dns.name.Name, dns.name.root, ... > > Note: The difference between @ and real "origin" is like "pointer to > origin" and "origin value" in C. > I think a good name would be "self", but that doesn't work very well in Python :-) Perhaps "self_origin" is better? -- Jan Cholasta From pspacek at redhat.com Tue Apr 8 08:31:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 08 Apr 2014 10:31:43 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343B35F.3030007@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> <20140408080956.GN20958@redhat.com> <5343AFE8.3090309@redhat.com> <5343B0F5.2010505@redhat.com> <5343B35F.3030007@redhat.com> Message-ID: <5343B3EF.4050404@redhat.com> On 8.4.2014 10:29, Jan Cholasta wrote: > On 8.4.2014 10:19, Petr Spacek wrote: >> On 8.4.2014 10:14, Jan Cholasta wrote: >>> On 8.4.2014 10:09, Alexander Bokovoy wrote: >>>> On Tue, 08 Apr 2014, Jan Cholasta wrote: >>>>> On 8.4.2014 10:01, Alexander Bokovoy wrote: >>>>>> On Tue, 08 Apr 2014, Petr Spacek wrote: >>>>>>> On 8.4.2014 09:22, Jan Cholasta wrote: >>>>>>>> On 4.4.2014 12:59, Petr Spacek wrote: >>>>>>>>> On 3.4.2014 15:35, Jan Cholasta wrote: >>>>>>>>>> I would shorten "origin_sign" to just "sign". >>>>>>>>> Sign of what? Decay? :-) I don't think that sign is descriptive >>>>>>>>> enough, >>>>>>>>> I would personally stick with origin_sign. >>>>>>>> >>>>>>>> Whoops, I meant "origin". The "_sign" bit seems a little bit >>>>>>>> redundant to me. >>>>>>> >>>>>>> "Origin" is an established term for the name of the parent. >>>>>>> >>>>>>> name = "blabla.example." >>>>>>> origin of "name" = "example." >>>>>>> >>>>>>> Anyway, I still think that DNSName('@') is better than any constant >>>>>>> with cryptic name. >>>>>>> >>>>>>> Honza, can you see any problem with this? I know this creates >>>>>>> instance >>>>>>> again and again, but is it a real problem? I would like to avoid >>>>>>> premature optimization... :-) >>>>>> What about making all these fixed names as constants and then simply >>>>>> return those? >>>>>> >>>>>> class DNSName: >>>>>> DNS_ORIGIN = DNSName('@') >>>>>> ... >>>>>> >>>>>> @staticmethod ... >>>>>> def ... >>>>>> return DNS_ORIGIN >>>>>> >>>>>> they would be singletons... >>>>> >>>>> Unfortunately you can't do that, because at the time DNSName is >>>>> parsed, it is not defined yet: >>>>> >>>>>>>> class X: >>>>> ... x = X() >>>>> ... >>>>> Traceback (most recent call last): >>>>> File "", line 1, in >>>>> File "", line 2, in X >>>>> NameError: name 'X' is not defined >>>> Then we can split these classes: define DNSName with purely static >>>> methods as child of DNSNameBase which would have all the expected >>>> methods. DNSName can then have constants of DNSNameBase() and return >>>> those. >>>> >>> >>> IMO this is an overkill. I would prefer if we did what I suggested >>> earlier: >>> put DNSName into a new module dnsutil and make the constants global >>> for the >>> module. >> >> I consider this less readable but I'm not Python expert so I'm fine this >> approach. > > Well, it's the same thing python-dns does: dns.name.Name, dns.name.root, ... > >> >> Note: The difference between @ and real "origin" is like "pointer to >> origin" and "origin value" in C. >> > > I think a good name would be "self", but that doesn't work very well in Python > :-) Perhaps "self_origin" is better? I'm not big fan of SELF :-) What is wrong with origin_sign? It seems more understandable than self_origin to me. -- Petr^2 Spacek From pviktori at redhat.com Tue Apr 8 08:34:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Apr 2014 10:34:52 +0200 Subject: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers In-Reply-To: <1396882854.14203.48.camel@willson.li.ssimo.org> References: <533D472B.1010807@redhat.com> <5342B994.9070108@redhat.com> <1396882854.14203.48.camel@willson.li.ssimo.org> Message-ID: <5343B4AC.2050809@redhat.com> On 04/07/2014 05:00 PM, Simo Sorce wrote: > On Mon, 2014-04-07 at 16:43 +0200, Martin Kosek wrote: >> On 04/03/2014 01:34 PM, Petr Viktorin wrote: >>> Hello, >>> This adds anonymous read access to containers, as discussed in this thread: >>> https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html >>> >>> Additionally access is granted for $SUFFIX itself with targetfilter >>> "(objectclass=domain)", and attributes objectclass, dc, info, nisDomain, >>> associatedDomain. >>> >>> These are raw ACIs, not permission-based ones. >> >> Starting a new sub-thread to differential from the LDIF/update file fixes. >> >> I tested the new ACI and it worked ok for me (is a prerequisite for easy >> testing of the subsequent ACI patches). I assume you plan to handle cn=etc tree >> in other patch. >> >> ACK from me in that case (not pushing right now to let Simo raise any concerns >> he may have). Thanks, pushed to master: 0e659983a6454370021a748d7534cad9febd6cc1 >> >> Martin > > I do not have any concern on the ACI itself, I only mused about ldif > +update vs update only, sorry if I gave the worng impression. > > Simo. > -- Petr? From jcholast at redhat.com Tue Apr 8 08:49:14 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Apr 2014 10:49:14 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343B3EF.4050404@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> <20140408080956.GN20958@redhat.com> <5343AFE8.3090309@redhat.com> <5343B0F5.2010505@redhat.com> <5343B35F.3030007@redhat.com> <5343B3EF.4050404@redhat.com> Message-ID: <5343B80A.20801@redhat.com> On 8.4.2014 10:31, Petr Spacek wrote: > On 8.4.2014 10:29, Jan Cholasta wrote: >> On 8.4.2014 10:19, Petr Spacek wrote: >>> On 8.4.2014 10:14, Jan Cholasta wrote: >>>> On 8.4.2014 10:09, Alexander Bokovoy wrote: >>>>> On Tue, 08 Apr 2014, Jan Cholasta wrote: >>>>>> On 8.4.2014 10:01, Alexander Bokovoy wrote: >>>>>>> On Tue, 08 Apr 2014, Petr Spacek wrote: >>>>>>>> On 8.4.2014 09:22, Jan Cholasta wrote: >>>>>>>>> On 4.4.2014 12:59, Petr Spacek wrote: >>>>>>>>>> On 3.4.2014 15:35, Jan Cholasta wrote: >>>>>>>>>>> I would shorten "origin_sign" to just "sign". >>>>>>>>>> Sign of what? Decay? :-) I don't think that sign is descriptive >>>>>>>>>> enough, >>>>>>>>>> I would personally stick with origin_sign. >>>>>>>>> >>>>>>>>> Whoops, I meant "origin". The "_sign" bit seems a little bit >>>>>>>>> redundant to me. >>>>>>>> >>>>>>>> "Origin" is an established term for the name of the parent. >>>>>>>> >>>>>>>> name = "blabla.example." >>>>>>>> origin of "name" = "example." >>>>>>>> >>>>>>>> Anyway, I still think that DNSName('@') is better than any constant >>>>>>>> with cryptic name. >>>>>>>> >>>>>>>> Honza, can you see any problem with this? I know this creates >>>>>>>> instance >>>>>>>> again and again, but is it a real problem? I would like to avoid >>>>>>>> premature optimization... :-) >>>>>>> What about making all these fixed names as constants and then simply >>>>>>> return those? >>>>>>> >>>>>>> class DNSName: >>>>>>> DNS_ORIGIN = DNSName('@') >>>>>>> ... >>>>>>> >>>>>>> @staticmethod ... >>>>>>> def ... >>>>>>> return DNS_ORIGIN >>>>>>> >>>>>>> they would be singletons... >>>>>> >>>>>> Unfortunately you can't do that, because at the time DNSName is >>>>>> parsed, it is not defined yet: >>>>>> >>>>>>>>> class X: >>>>>> ... x = X() >>>>>> ... >>>>>> Traceback (most recent call last): >>>>>> File "", line 1, in >>>>>> File "", line 2, in X >>>>>> NameError: name 'X' is not defined >>>>> Then we can split these classes: define DNSName with purely static >>>>> methods as child of DNSNameBase which would have all the expected >>>>> methods. DNSName can then have constants of DNSNameBase() and return >>>>> those. >>>>> >>>> >>>> IMO this is an overkill. I would prefer if we did what I suggested >>>> earlier: >>>> put DNSName into a new module dnsutil and make the constants global >>>> for the >>>> module. >>> >>> I consider this less readable but I'm not Python expert so I'm fine this >>> approach. >> >> Well, it's the same thing python-dns does: dns.name.Name, >> dns.name.root, ... >> >>> >>> Note: The difference between @ and real "origin" is like "pointer to >>> origin" and "origin value" in C. >>> >> >> I think a good name would be "self", but that doesn't work very well >> in Python >> :-) Perhaps "self_origin" is better? > > I'm not big fan of SELF :-) > > What is wrong with origin_sign? It seems more understandable than > self_origin to me. > The word "sign" does not really capture the meaning of it. It is a sign as long as you look at it in text form, but it has a specific meaning and IMO we should capture that meaning in the name rather than what it looks like in text. The constant is named "empty" in python-dns, IMO we should name it the same. -- Jan Cholasta From pspacek at redhat.com Tue Apr 8 09:01:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 08 Apr 2014 11:01:11 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343B80A.20801@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> <20140408080956.GN20958@redhat.com> <5343AFE8.3090309@redhat.com> <5343B0F5.2010505@redhat.com> <5343B35F.3030007@redhat.com> <5343B3EF.4050404@redhat.com> <5343B80A.20801@redhat.com> Message-ID: <5343BAD7.10802@redhat.com> On 8.4.2014 10:49, Jan Cholasta wrote: > On 8.4.2014 10:31, Petr Spacek wrote: >> On 8.4.2014 10:29, Jan Cholasta wrote: >>> On 8.4.2014 10:19, Petr Spacek wrote: >>>> On 8.4.2014 10:14, Jan Cholasta wrote: >>>>> On 8.4.2014 10:09, Alexander Bokovoy wrote: >>>>>> On Tue, 08 Apr 2014, Jan Cholasta wrote: >>>>>>> On 8.4.2014 10:01, Alexander Bokovoy wrote: >>>>>>>> On Tue, 08 Apr 2014, Petr Spacek wrote: >>>>>>>>> On 8.4.2014 09:22, Jan Cholasta wrote: >>>>>>>>>> On 4.4.2014 12:59, Petr Spacek wrote: >>>>>>>>>>> On 3.4.2014 15:35, Jan Cholasta wrote: >>>>>>>>>>>> I would shorten "origin_sign" to just "sign". >>>>>>>>>>> Sign of what? Decay? :-) I don't think that sign is descriptive >>>>>>>>>>> enough, >>>>>>>>>>> I would personally stick with origin_sign. >>>>>>>>>> >>>>>>>>>> Whoops, I meant "origin". The "_sign" bit seems a little bit >>>>>>>>>> redundant to me. >>>>>>>>> >>>>>>>>> "Origin" is an established term for the name of the parent. >>>>>>>>> >>>>>>>>> name = "blabla.example." >>>>>>>>> origin of "name" = "example." >>>>>>>>> >>>>>>>>> Anyway, I still think that DNSName('@') is better than any constant >>>>>>>>> with cryptic name. >>>>>>>>> >>>>>>>>> Honza, can you see any problem with this? I know this creates >>>>>>>>> instance >>>>>>>>> again and again, but is it a real problem? I would like to avoid >>>>>>>>> premature optimization... :-) >>>>>>>> What about making all these fixed names as constants and then simply >>>>>>>> return those? >>>>>>>> >>>>>>>> class DNSName: >>>>>>>> DNS_ORIGIN = DNSName('@') >>>>>>>> ... >>>>>>>> >>>>>>>> @staticmethod ... >>>>>>>> def ... >>>>>>>> return DNS_ORIGIN >>>>>>>> >>>>>>>> they would be singletons... >>>>>>> >>>>>>> Unfortunately you can't do that, because at the time DNSName is >>>>>>> parsed, it is not defined yet: >>>>>>> >>>>>>>>>> class X: >>>>>>> ... x = X() >>>>>>> ... >>>>>>> Traceback (most recent call last): >>>>>>> File "", line 1, in >>>>>>> File "", line 2, in X >>>>>>> NameError: name 'X' is not defined >>>>>> Then we can split these classes: define DNSName with purely static >>>>>> methods as child of DNSNameBase which would have all the expected >>>>>> methods. DNSName can then have constants of DNSNameBase() and return >>>>>> those. >>>>>> >>>>> >>>>> IMO this is an overkill. I would prefer if we did what I suggested >>>>> earlier: >>>>> put DNSName into a new module dnsutil and make the constants global >>>>> for the >>>>> module. >>>> >>>> I consider this less readable but I'm not Python expert so I'm fine this >>>> approach. >>> >>> Well, it's the same thing python-dns does: dns.name.Name, >>> dns.name.root, ... >>> >>>> >>>> Note: The difference between @ and real "origin" is like "pointer to >>>> origin" and "origin value" in C. >>>> >>> >>> I think a good name would be "self", but that doesn't work very well >>> in Python >>> :-) Perhaps "self_origin" is better? >> >> I'm not big fan of SELF :-) >> >> What is wrong with origin_sign? It seems more understandable than >> self_origin to me. >> > > The word "sign" does not really capture the meaning of it. It is a sign as > long as you look at it in text form, but it has a specific meaning and IMO we > should capture that meaning in the name rather than what it looks like in text. > > The constant is named "empty" in python-dns, IMO we should name it the same. Okay, use whatever and please add comment # invented by jcholast :-) -- Petr^2 Spacek From pviktori at redhat.com Tue Apr 8 09:03:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Apr 2014 11:03:17 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects In-Reply-To: <53428C3A.1000003@redhat.com> References: <533D3360.7080106@redhat.com> <53428C3A.1000003@redhat.com> Message-ID: <5343BB55.9000800@redhat.com> On 04/07/2014 01:30 PM, Martin Kosek wrote: > On 04/03/2014 12:09 PM, Petr Viktorin wrote: >> Hello, >> This adds read permissions to read Sudo commands, command groups, rules. >> >> Read access is given to all authenticated users. > > Looks good. What about "ou=sudoers"? I think we should also allow it in this > patch for authenticated users. This is the tree that clients use to read sudo. This new version does that. It needs my patches 0508-0509 since the ou=sudoers permission is not tied to a specific Object plugin. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0504.2-Add-managed-read-permissions-to-Sudo-objects-and-ou-.patch Type: text/x-patch Size: 5968 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 8 09:03:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Apr 2014 11:03:26 +0200 Subject: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions Message-ID: <5343BB5E.3030504@redhat.com> Patch 0508: This documents the inputs for the permission updater in the module itself. This is taken from the design page. I expect it'll need an addition now and then, so I think it's better to have this near the code it corresponds to. Patch 0509: So far the new default permissions have been tied to an Object plugin, and took the ACI location and objectclass filter from the object. However there are some permissions that are not tied to an IPA object, for instance ones dealing with a compat tree. However, these permissions should behave similarly to the Object-based ones, so it makes sense to use the same updater with them. A question is where the non-Object permissions should be stored. I can think of several alternatives: a) in a special data file, like .update files b) in a new plugin type c) somewhere in the code I went for c) for simplicity, but feel free to discuss. (CCing Rob since he had some strong opinions in this area.) This patch makes ipapermlocation, ipapermtargetfilter and other Permission attributes overridable, and adds a central list of non-object permissions to the updater module. (For now, the list is empty). My patch 0504.2 (Default read ACIs for Sudo objects) will add a non-object permission for ou=sudoers. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0508-Document-the-managed-permission-updater-operation.patch Type: text/x-patch Size: 2478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0509-Add-support-for-non-object-default-permissions.patch Type: text/x-patch Size: 5666 bytes Desc: not available URL: From lkrispen at redhat.com Tue Apr 8 10:00:37 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 08 Apr 2014 12:00:37 +0200 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1396911419.14203.126.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> Message-ID: <5343C8C5.8020708@redhat.com> Looks like there was a great discussion while I was away :-) There seem to be great concerns (and mybe confusion) about replication update resoultions, conflicts and amount of meta data stored. I think it's not as bad as you may think. Large amounts of metadata can only accumulate for multivalued attributes, for single valued attributes only the latest value and in some cases one! previous value is stored. For multivalued attributes the amount of data were considerably reduced with the fix for #569 The replication protocol and its update resolution is designed to follow a single master model: the final result should be the same as if the modifications were applied in the order of the csns on a single master, this implies that the last change wins. T There are some cases where conflicting entries or conflict attributes are generated. conflict entries should only be generated if the same entry (dn) is concurrently added on different masters. Conflict attribute are only genrated in some rare corner cases. In the case of krbLastFailedAuth or krbFailedLoginCount always the value with the highest csn will win, no scenario for a conflict. Replication storms. In my opinion the replication of a mod of one or two attribute in a entry will be faster than the bind itself. If an attacker knows all the dns of the entries in a server the denial of service could be that it just does a sequence of failed logins for any user and nobody will be able to login any more, replication would help to propagate this to other servers, but not prevent it. This would also be the case if only the final lockout state is replicated. I like the idea of replicating the attributes changed at failed logins (or reset) only. Regards, Ludwig On 04/08/2014 12:56 AM, Simo Sorce wrote: > On Mon, 2014-04-07 at 14:28 -0600, Rich Megginson wrote: >> On 04/07/2014 01:00 PM, Simo Sorce wrote: >>> On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote: >>>> On 04/07/2014 02:31 PM, Simo Sorce wrote: >>>>> On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: >>>>>> On 04/07/2014 10:13 AM, Simo Sorce wrote: >>>>>>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: >>>>>>>> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: >>>>>>>>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: >>>>>>>>>> Ludwig Krispenz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review the following feature design. It introduces a global >>>>>>>>>>> account lockout, while trying to keep the replication traffic minimal. >>>>>>>>>>> In my opinion for a real global account lockout the basic lockout >>>>>>>>>>> attributes have to be replicated otherwise the benefit is minimal: an >>>>>>>>>>> attacker could perform (maxFailedcount -1) login attempts on every >>>>>>>>>>> server before the global lockout is set. But the design page describes >>>>>>>>>>> how it could be done if it should be implemented - maybe the side effect >>>>>>>>>>> that accounts could the be unlocked on any replica has its own benefit. >>>>>>>>>>> >>>>>>>>>>> http://www.freeipa.org/page/V4/Replicated_lockout >>>>>>>>>> One weakness with this is there is still a window for extra password >>>>>>>>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m is the >>>>>>>>>> number of masters and f is the # of allowed failed logins. >>>>>>>>> Yes, but that is a problem that cannot be solved w/o full replication at >>>>>>>>> every authentication attempt. >>>>>>>>> >>>>>>>>> What we tried to achieve is a middle ground to at least ease >>>>>>>>> administration and still lock em up "earlier". >>>>>>>> Let me add that we "could" have yet another closer step by finding a way >>>>>>>> to replicate only failed attempts and not successful attempts in some >>>>>>>> case. Assuming a setup where most people do not fail to enter their >>>>>>>> password it would make for a decent compromise. >>>>>>>> >>>>>>>> That could be achieved by not storing lastsuccessful auth except when >>>>>>>> that is needed to clear failed logon attempts (ie when the failed logon >>>>>>>> counter is > 0) >>>>>>>> >>>>>>>> If we did that then we would not need a new attribute actually, as >>>>>>>> failed logins would always be replicated. >>>>>>>> However it would mean that last Successful auth would never be accurate >>>>>>>> on any server. >>>>>>>> >>>>>>>> Or perhaps we could have a local last successful auth and a global one >>>>>>>> by adding one new attribute, and keeping masking only the successful >>>>>>>> auth. >>>>>>>> >>>>>>>> The main issue about all these possibilities is how do we present them ? >>>>>>>> And how do we make a good default ? >>>>>>>> >>>>>>>> I think a good default is defined by these 2 characteristics: >>>>>>>> 1. lockouts can be dealt with on any replica w/o having the admin hunt >>>>>>>> down where a user is locked. >>>>>>>> 2. at least successful authentications will not cause replication storms >>>>>>>> >>>>>>>> If we can afford to cause replications on failed authentication by >>>>>>>> default, then we could open up replication for failedauth and >>>>>>>> failedcount attributes but still bar the successful auth attribute. >>>>>>>> Unlock would simply consist in forcibly setting failed count to 0 (which >>>>>>>> is replicated so it would unlock all servers). >>>>>>>> This would work w/o introducing new attributes and only with minimal >>>>>>>> logic changes in the KDC/pwd-extop plugins I think. >>>>>>> Sigh re[plying again to myself. >>>>>>> note that the main issue with replicating failed accounts is that you >>>>>>> can cause replication storms by simply probing all user accounts with >>>>>>> failed binds or AS requests. In some environments that may cause DoSs >>>>>>> (if you have slow/high latency links on which replication runs for >>>>>>> example). >>>>>>> So I think we should always give the option to turn off failed >>>>>>> date/count attributes replication, which in turn would mean we still >>>>>>> require a new attribute to replicate for when a user is finally locked >>>>>>> out on one of the servers or we fail requirement 1. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> Another problem with keeping track of bind attributes in a replicated >>>>>> environment is the sheer size of the replication metadata. Replicating >>>>>> 1 failed bind attempt might be 100kbytes or more data to all servers. >>>>>> We should have a way to perhaps say "only keep last N CSNs" or maybe >>>>>> even "don't keep CSNs for these attributes". >>>>> Yes, but this look a lot like general replication improvement (would >>>>> also be cool to have "better" conflict resolution), not lockout >>>>> specific. >>>>> >>>>> Simo. >>>>> >>>> My only comment is actually about conflict resolution. What would happen >>>> if I attack (flood) two replicas at the same time beating the >>>> replication. It would mean both servers would generate the global >>>> attributes and try to replicate to each other. If the replicas are on >>>> the edges of topology it might take some time and it might even happen >>>> that admin already unlocked the account while the old lock is still >>>> trying to propagate. IMO we need collisions resolution logic taken care >>>> of first. I suspect that any real attack would lead to collisions and if >>>> it would leave the deployment unstable even after the attack ended we lost. >>> Yes, this is a valid concern. We need a last-wins conflict resolution >>> strategy for some cases. >> I'm not sure what you mean. The 389 conflict resolution strategy is >> "last-wins" already. Or do you mean "for some cases, but not all cases"? > I am thinking about those case when we end up with duplicate objects. > In many (most ?) case we should just throw away one of the 2 and keep > the other, not end up with 2 objects. > > Simo. > From mkosek at redhat.com Tue Apr 8 10:46:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 12:46:07 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects In-Reply-To: <5343BB55.9000800@redhat.com> References: <533D3360.7080106@redhat.com> <53428C3A.1000003@redhat.com> <5343BB55.9000800@redhat.com> Message-ID: <5343D36F.7040401@redhat.com> On 04/08/2014 11:03 AM, Petr Viktorin wrote: > On 04/07/2014 01:30 PM, Martin Kosek wrote: >> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>> Hello, >>> This adds read permissions to read Sudo commands, command groups, rules. >>> >>> Read access is given to all authenticated users. >> >> Looks good. What about "ou=sudoers"? I think we should also allow it in this >> patch for authenticated users. This is the tree that clients use to read sudo. > > This new version does that. It needs my patches 0508-0509 since the ou=sudoers > permission is not tied to a specific Object plugin. > I would also allow 'ou', otherwise an authenticated user cannot read the ou=sudoers RDN. I will comment on NONOBJECT_PERMISSIONS in the other thread. Martin From mkosek at redhat.com Tue Apr 8 10:53:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 12:53:26 +0200 Subject: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions In-Reply-To: <5343BB5E.3030504@redhat.com> References: <5343BB5E.3030504@redhat.com> Message-ID: <5343D526.5040204@redhat.com> On 04/08/2014 11:03 AM, Petr Viktorin wrote: > > Patch 0508: > This documents the inputs for the permission updater in the module itself. This > is taken from the design page. I expect it'll need an addition now and then, so > I think it's better to have this near the code it corresponds to. > > > Patch 0509: > So far the new default permissions have been tied to an Object plugin, and took > the ACI location and objectclass filter from the object. However there are some > permissions that are not tied to an IPA object, for instance ones dealing with > a compat tree. However, these permissions should behave similarly to the > Object-based ones, so it makes sense to use the same updater with them. > > A question is where the non-Object permissions should be stored. I can think of > several alternatives: > a) in a special data file, like .update files > b) in a new plugin type > c) somewhere in the code > > I went for c) for simplicity, but feel free to discuss. (CCing Rob since he had > some strong opinions in this area.) > > This patch makes ipapermlocation, ipapermtargetfilter and other Permission > attributes overridable, and adds a central list of non-object permissions to > the updater module. (For now, the list is empty). > > > My patch 0504.2 (Default read ACIs for Sudo objects) will add a non-object > permission for ou=sudoers. The patch is functional, but I am not really a big fan of placing it in the plugin. I would prefer if the ACI definition is also in the sudo plugin together with other definition. It would be then much easier to audit all sudo-related ACIs. Why can't we add this ACI to sudorule object managed permissions and just override the location and target? I am not insisting on a specific format, I would simply prefer to have all plugin object related ACIs close together. Martin From pviktori at redhat.com Tue Apr 8 11:14:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Apr 2014 13:14:02 +0200 Subject: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions In-Reply-To: <5343D526.5040204@redhat.com> References: <5343BB5E.3030504@redhat.com> <5343D526.5040204@redhat.com> Message-ID: <5343D9FA.4080207@redhat.com> On 04/08/2014 12:53 PM, Martin Kosek wrote: > On 04/08/2014 11:03 AM, Petr Viktorin wrote: >> >> Patch 0508: >> This documents the inputs for the permission updater in the module itself. This >> is taken from the design page. I expect it'll need an addition now and then, so >> I think it's better to have this near the code it corresponds to. >> >> >> Patch 0509: >> So far the new default permissions have been tied to an Object plugin, and took >> the ACI location and objectclass filter from the object. However there are some >> permissions that are not tied to an IPA object, for instance ones dealing with >> a compat tree. However, these permissions should behave similarly to the >> Object-based ones, so it makes sense to use the same updater with them. >> >> A question is where the non-Object permissions should be stored. I can think of >> several alternatives: >> a) in a special data file, like .update files >> b) in a new plugin type >> c) somewhere in the code >> >> I went for c) for simplicity, but feel free to discuss. (CCing Rob since he had >> some strong opinions in this area.) >> >> This patch makes ipapermlocation, ipapermtargetfilter and other Permission >> attributes overridable, and adds a central list of non-object permissions to >> the updater module. (For now, the list is empty). >> >> >> My patch 0504.2 (Default read ACIs for Sudo objects) will add a non-object >> permission for ou=sudoers. > > The patch is functional, but I am not really a big fan of placing it in the > plugin. I would prefer if the ACI definition is also in the sudo plugin > together with other definition. It would be then much easier to audit all > sudo-related ACIs. > > Why can't we add this ACI to sudorule object managed permissions and just > override the location and target? I can do that. Most of the changes make this overriding possible, where the permission is actually defined is a detail. > I am not insisting on a specific format, I would simply prefer to have all > plugin object related ACIs close together. My reasoning is that finding the definition would not be straightforward. All the object-specific permissions so far are defined in "their" plugins, as determined by --type. This one won't have --type, and it's not clear if it should be in sudorule, sudocmd or sudocmdgroup. But, I don't have a strong preference. A `git grep` will always show the definition. -- Petr? From jcholast at redhat.com Tue Apr 8 11:16:00 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Apr 2014 13:16:00 +0200 Subject: [Freeipa-devel] [PATCH] 261 Fix upload of CA certificate to LDAP in CA-less install Message-ID: <5343DA70.20008@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-261-Fix-upload-of-CA-certificate-to-LDAP-in-CA-less-inst.patch Type: text/x-patch Size: 1614 bytes Desc: not available URL: From sbose at redhat.com Tue Apr 8 11:15:22 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 8 Apr 2014 13:15:22 +0200 Subject: [Freeipa-devel] [PATCH] 0148: ipa-sam: when deleting subtree, deal with possible LDAP errors In-Reply-To: <531F203D.8030500@redhat.com> References: <20140311143258.GF16644@redhat.com> <531F203D.8030500@redhat.com> Message-ID: <20140408111522.GM26337@localhost.localdomain> On Tue, Mar 11, 2014 at 03:39:57PM +0100, Petr Spacek wrote: > On 11.3.2014 15:32, Alexander Bokovoy wrote: > >after discussing with Petr Spacek, following patch fixes ticket 4224. > > Code seems okay but I didn't do functional test. To just close this tread the changes form this patch are already applied by 'ipa-sam: cache gid to sid and uid to sid requests in idmap cache' master: d6a7923f71eb69bac53d6ff904086a9abd103dbc ipa-3-3: 13cd4faf551d7781d27c36bef0e7cbf515e072d2 bye, Sumit > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Tue Apr 8 12:08:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 14:08:30 +0200 Subject: [Freeipa-devel] [PATCH] 261 Fix upload of CA certificate to LDAP in CA-less install In-Reply-To: <5343DA70.20008@redhat.com> References: <5343DA70.20008@redhat.com> Message-ID: <5343E6BE.8010307@redhat.com> On 04/08/2014 01:16 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Works for me, ACK. Pushed to master: 915cd6942c0acb00688ba7a8b0d2519be9a47fb3 Martin From mkosek at redhat.com Tue Apr 8 12:14:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 14:14:18 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 9 CA-less tests generate failure In-Reply-To: <20140404105911.7742aac0@unused-4-246.brq.redhat.com> References: <20140404105911.7742aac0@unused-4-246.brq.redhat.com> Message-ID: <5343E81A.4020709@redhat.com> On 04/04/2014 10:59 AM, Misnyovszki Adam wrote: > Hi, > > CA-less test suite always generate failures when installing revoked > certificates. This is a known issue, described in > https://fedorahosted.org/freeipa/ticket/4270 , this fix skips these > tests, outputting a notification message for the ticket. > Now it outputs this: > > [amisnyov at host freeipa]$ ./make-test > ipatests/test_integration/test_caless.py:TestServerInstall.test_revoked_http > /usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins > ipatests/test_integration/test_caless.py:TestServerInstall.test_revoked_http > IPA server install with revoked HTTP certificate ... SKIP: Known > CA-less installation defect, see > https://fedorahosted.org/freeipa/ticket/4270 > > ---------------------------------------------------------------------- > Ran 1 test in 1020.253s > > OK (SKIP=1) > ====================================================================== > passed under '/usr/bin/python2.7' > > ** pass ** > > > https://fedorahosted.org/freeipa/ticket/4271 > > There could be another possible solution, I could write a nose plugin to > enable raising warnings instead of skipping a test. This could be > achieved by adding a @unittest.expectedFailure for a specific test, so > if it fails, it counts as an error/warning. There is a poc in a nose > ticket located in > http://code.google.com/p/python-nose/issues/detail?id=428 , not sure > how much time it takes to implement it as a plugin, or is it even > worth, because if this is implemented, we could also use this feature > when eg. DNS is not configured, this is why RFC. > > Thanks > Adam Thanks for question. I personally think this solution is good enough for now. We may even chose to switch to pytest in the future, so I would not invest too much in python-nose specific plugins at this point. ACK. Pushed to master, ipa-3-3. Martin From pviktori at redhat.com Tue Apr 8 12:25:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Apr 2014 14:25:38 +0200 Subject: [Freeipa-devel] [PATCHES] 0510-0511 Add managed read permissions to group & hostgroup Message-ID: <5343EAC2.6030409@redhat.com> Hello, These add read permissions to read user groups and hostgroups. For most attributes, anonymous read access is given. For member, memberOf, memberUID, read access is given only to authenticated users. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0510-Add-managed-read-permissions-to-group.patch Type: text/x-patch Size: 1585 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0511-Add-managed-read-permission-to-hostgroup.patch Type: text/x-patch Size: 1602 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 8 12:25:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 14:25:48 +0200 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object In-Reply-To: <20140403143140.GU3094@redhat.com> References: <5334163C.7060007@redhat.com> <20140401064904.GB3872@redhat.com> <20140401071155.GA17186@redhat.com> <533A6810.7020008@redhat.com> <533A7353.7040909@redhat.com> <20140401100312.GG3872@redhat.com> <533BFAE8.2030906@redhat.com> <20140403143140.GU3094@redhat.com> Message-ID: <5343EACC.9000502@redhat.com> On 04/03/2014 04:31 PM, Alexander Bokovoy wrote: > On Wed, 02 Apr 2014, Martin Kosek wrote: >> On 04/01/2014 12:03 PM, Jan Pazdziora wrote: >>> On Tue, Apr 01, 2014 at 10:05:39AM +0200, Tomas Babej wrote: >>>> >>>>> Yes, that was the intention. Mistake on my part, I'll send updated patches. >>>>> >>>> >>>> Updated patch attached. >>> >>> Ack based on reading the code and documentation for >>> slapi_ch_free_string. >>> >> >> Ok, thanks. Though I would like this patch to be also functionally tested that >> it does not break anything, ideally together with your other ipa-range patches. > ACK to 0162, 0161, 0158 (should be applied in this order). > > # ipa idrange-find > ---------------- > 2 ranges matched > ---------------- > Range name: AD.TEST_id_range > First Posix ID of the range: 1115000000 > 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-2275361654-3393353068-3720134936 > Range type: Active Directory domain range > > Range name: T.VDA.LI_id_range > First Posix ID of the range: 917400000 > 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 > ---------------------------- > Number of entries returned 2 > ---------------------------- > # ipa idrange-add AD.TEST_1_id_range > First Posix ID of the range: 1119000000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 0 > First RID of the secondary RID range: 1000000 > ipa: ERROR: Constraint violation: New primary rid range overlaps with existing > primary rid range. > > the message comes from the ipa-range-check plugin. > > Pushed all 3 to master. Martin From mkosek at redhat.com Tue Apr 8 12:26:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 14:26:32 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <533A7E49.604@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> <53341563.9050204@redhat.com> <533A73E0.9030707@redhat.com> <20140401084016.GI3094@redhat.com> <533A7E49.604@redhat.com> Message-ID: <5343EAF8.8060209@redhat.com> On 04/01/2014 10:52 AM, Tomas Babej wrote: > > On 04/01/2014 10:40 AM, Alexander Bokovoy wrote: >> On Tue, 01 Apr 2014, Tomas Babej wrote: >>> From 736b3f747188696fd4a46ca63d91a6cca942fd56 Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Wed, 5 Mar 2014 12:28:18 +0100 >>> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >>> >>> The ipa-range-check plugin used to determine the range type depending >>> on the value of the attributes such as RID or secondary RID base. This >>> approached caused variety of issues since the portfolio of ID range >>> types expanded. >>> >>> The patch makes sure the following rules are implemented: >>> * No ID range pair can overlap on base ranges, with exception >>> of two ipa-ad-trust-posix ranges belonging to the same forest >>> * For any ID range pair of ranges belonging to the same domain: >>> * Both ID ranges must be of the same type >>> * For ranges of ipa-ad-trust type or ipa-local type: >>> * Primary RID ranges can not overlap >>> * For ranges of ipa-local type: >>> * Primary and secondary RID ranges can not overlap >>> * Secondary RID ranges cannot overlap >>> >>> For the implementation part, the plugin was extended with a domain ID >>> to forest root domain ID mapping derivation capabilities. >>> >>> https://fedorahosted.org/freeipa/ticket/4137 >>> >>> -static int slapi_entry_to_range_info(struct slapi_entry *entry, >>> +struct domain_info { >>> + char *domain_id; >>> + char *forest_root_id; >>> + struct domain_info *next; >>> +}; >>> + >>> +static void free_domain_info(struct domain_info *info) { >>> + if (info != NULL) { >>> + slapi_ch_free_string(&(info->domain_id)); >>> + slapi_ch_free_string(&(info->forest_root_id)); >>> + free_domain_info(info->next); >>> + free(info); >>> + } >>> +} >> Please, don't use recursion in the freeing part, there is really no >> pressing need to do so. Just use while() like you do in >> get_forest_root_id(): >> >>> +/* Searches for the domain_info struct with the specified domain_id >>> + * in the linked list. Returns the forest root domain's ID, or NULL for >>> + * local ranges. */ >>> + >>> +static char* get_forest_root_id(struct domain_info *head, char* >>> domain_id) { >>> + >>> + /* For local ranges there is no forest root domain, >>> + * so consider only ranges with domain_id set */ >>> + if (domain_id != NULL) { >>> + while(head) { >>> + if (strcasecmp(head->domain_id, domain_id) == 0) { >>> + return head->forest_root_id; >>> + } >>> + head = head->next; >>> + } >>> + } >>> + >>> + return NULL; >>> +} >>> + >> >> > > Fixed, updated patch attached. > Pushed to master based on Alexander's ACK in patch 161. Martin From mkosek at redhat.com Tue Apr 8 12:26:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 14:26:55 +0200 Subject: [Freeipa-devel] [PATCH 0162] ipa-pwd-extop: Fix memory leak in ipapwd_pre_bind In-Reply-To: <20140401115942.GK3094@redhat.com> References: <533A9C5F.9090300@redhat.com> <20140401115942.GK3094@redhat.com> Message-ID: <5343EB0F.3020408@redhat.com> On 04/01/2014 01:59 PM, Alexander Bokovoy wrote: > On Tue, 01 Apr 2014, Tomas Babej wrote: >> Hi, >> >> We need to free the entry before returning from the function. >> >> https://fedorahosted.org/freeipa/ticket/4295 > ACK. Pushed to master. Martin From rcritten at redhat.com Tue Apr 8 13:39:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Apr 2014 09:39:36 -0400 Subject: [Freeipa-devel] Random Certificate Serial Numbers In-Reply-To: <53433A6C.3060903@redhat.com> References: <53425863.1030602@redhat.com> <53433A6C.3060903@redhat.com> Message-ID: <5343FC18.7070000@redhat.com> Dmitri Pal wrote: > On 04/07/2014 03:48 AM, Martin Kosek wrote: >> Hi Rob, Ade and others, >> >> In the past, Rob was investigating enabling random certificate serial >> numbers >> for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it >> for 4.0. >> Can we simply switch it on for PKI with pkispawn attribute: >> >> [CA] >> pki_random_serial_numbers_enable=True >> >> or is there any drawback or risk we should investigate. I am just >> thinking, >> does PKI handle collisions anyhow? When for example two PKI masters >> generate 2 >> certificates of the same serial (unlikely though it could happen)? >> >> Currently, we assign different slice of serial range to different PKI >> masters, >> do we want to do that also for random serial? >> >> Thanks for info >> >> [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers >> [2] https://fedorahosted.org/freeipa/ticket/2016 >> > Any impact on upgrades? It only affects new installs. > Any impact on certmonger? I seriously doubt it. The only potential issue is seriously long serial numbers but that isn't specific to random values. I had an install using this a year or so ago and I don't recall any major issues. Unfortunately that system has gone off the deep end so I no longer have the changes. rob From rcritten at redhat.com Tue Apr 8 13:52:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Apr 2014 09:52:49 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <53439C4D.6060108@redhat.com> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> <53439C4D.6060108@redhat.com> Message-ID: <5343FF31.8050206@redhat.com> Martin Kosek wrote: > On 04/07/2014 10:40 PM, Rob Crittenden wrote: >> Ade Lee wrote: >>> This patch adds the capability of installing a Dogtag DRM >>> to an IPA instance. With this patch, when ipa-server-install >>> is run, a Dogtag CA and a Dogtag DRM are created. The DRM >>> shares the same tomcat instance and DS instance as the Dogtag CA. >>> Moreover, the same admin user/agent (and agent cert) can be used >>> for both subsystems. Certmonger is also confgured to monitor the >>> new subsystem certificates. >>> >>> It is also possible to clone the DRM. When the IPA instance is >>> cloned, if --enable-ca and --enable-drm are specified, the DRM >>> is cloned as well. >>> >>> Installing a DRM requires the user to have a Dogtag CA instance. >>> We can look into possibly relaxing that requirement in a later patch. >>> >>> I am still working on patches for a ipa-drm-install script, which >>> would be used to add a DRM to an existing master (that includes >>> a dogtag CA), or an existing clone. >>> >>> Please review, >>> >>> Thanks, >>> Ade >> >> Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be >> pushed ASAP. > > Oops, looks like a change that should go to IPA 3.3.x. What is the implication? > >> freeipa-spec.in needs a dependency on pki-kra. > > Let us stop here. Please see a following RFE I filed: > https://fedorahosted.org/freeipa/ticket/4058 > > I would prefer it KRA files and specifics would be in a new subpackage like > freeipa-server-kra. Otherwise we will need to rework it again when we would be > splitting CA to freeipa-server-pki in 4.1. Yes, that is a question I didn't ask: Is the DRM going to be configured by default on all new installs? > I would prefer to start the right modularization now as I do not think that > every FreeIPA server needs to run CA/KRA, i.e. it does not need to have the > bits installed either. I think the decision on a separate sub-package will be dependent upon whether it is default or not, otherwise we can get away with freeipa-server-ca and just lump everything in there. > I am also quite worried about the duplication that the new drminstance.py > introduces. There is a lot of functions which do more or less the same thing > and have most of the handling code the same with only a very small and > predictable pki/kra change. For example __http_proxy function seems to be > exactly the same. > > It would be great to avoid this duplication and rather have some common ground > utilized by both PKI and KRA. Otherwise it will be very difficult to maintain > the new code. I touched on some of that too, but some of this is just inevitable I think which is why I didn't pound on it too hard. An abstraction would be nice, but I'm not sure abstracting for two things, and only in the installer, is worth the effort. I could be wrong. rob From alee at redhat.com Tue Apr 8 13:55:20 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 08 Apr 2014 09:55:20 -0400 Subject: [Freeipa-devel] Random Certificate Serial Numbers In-Reply-To: <53425863.1030602@redhat.com> References: <53425863.1030602@redhat.com> Message-ID: <1396965320.21643.14.camel@aleeredhat.laptop> On Mon, 2014-04-07 at 09:48 +0200, Martin Kosek wrote: > Hi Rob, Ade and others, > > In the past, Rob was investigating enabling random certificate serial numbers > for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. > Can we simply switch it on for PKI with pkispawn attribute: > > [CA] > pki_random_serial_numbers_enable=True > Putting in this parameter in pkispawn means changing the method of assigning serial numbers for the CA that is being installed (ie. a new master) Thus this will affect new masters only. When the CA is cloned, it will inherit its method of assigning serial numbers from the master. I need to check the code to see what happens if you specify the above directive in pkispawn for a clone. Are you considering changing the serial number assignment for existing masters? > or is there any drawback or risk we should investigate. I am just thinking, > does PKI handle collisions anyhow? When for example two PKI masters generate 2 > certificates of the same serial (unlikely though it could happen)? > Collisions are not supposed to happen. Range number assignment is automatically managed so that different masters are assigned different ranges so that collisions cannot happen. Collisions can occur if ranges overlap -- ie. if you are manually updating ranges and end up using overlapping ranges. > Currently, we assign different slice of serial range to different PKI masters, > do we want to do that also for random serial? > Yes. Range management is done automatically. Different masters are assigned different ranges to prevent collisions. Random serial numbers will be generated within the assigned range. > Thanks for info > > [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers > [2] https://fedorahosted.org/freeipa/ticket/2016 > From mkosek at redhat.com Tue Apr 8 14:16:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 16:16:08 +0200 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <53342A65.3070808@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> <53342A65.3070808@redhat.com> Message-ID: <534404A8.4040600@redhat.com> On 03/27/2014 02:40 PM, Martin Kosek wrote: > On 01/07/2014 01:47 PM, Tomas Babej wrote: >> >> On 01/07/2014 07:23 AM, Alexander Bokovoy wrote: >>> On Mon, 06 Jan 2014, Tomas Babej wrote: >>>> >>>> On 01/06/2014 12:16 PM, Tomas Babej wrote: >>>>> On 04/15/2013 12:43 PM, Tomas Babej wrote: >>>>>> On 04/08/2013 03:55 PM, Martin Kosek wrote: >>>>>>> On 04/01/2013 09:52 PM, Rob Crittenden wrote: >>>>>>>> Tomas Babej wrote: >>>>>>>>> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>>>>>>>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>>>>>>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>>>>>>>>> pre_bind operation >>>>>>>>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, >>>>>>>>>>>> auth is >>>>>>>>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error >>>>>>>>>>>> message is >>>>>>>>>>>> sent back to the client. Since krbprincipalexpiration >>>>>>>>>>>> attribute is >>>>>>>>>>> not >>>>>>>>>>>> mandatory, if there is no value set, the check is passed. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3305 >>>>>>>>>> Comments inline. >>>>>>>>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock >>>>>>>>>>> *pb) >>>>>>>>>>> goto done; >>>>>>>>>>> } >>>>>>>>>>> + /* check the krbPrincipalExpiration attribute is present */ >>>>>>>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>>>>>>> &attr); >>>>>>>>>>> + if (!ret) { >>>>>>>>>> ret is not a boolean so probably better ti use (ret != 0) >>>>>>>>>> >>>>>>>>>>> + /* if it is, check whether the principal has not >>>>>>>>>>> expired */ >>>>>>>>>>> + >>>>>>>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>>>>>>> + "krbprincipalexpiration"); >>>>>>>>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>>>>>>>>> + >>>>>>>>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>>>>>>>>>> &expire_tm)){ >>>>>>>>>> style issue missing space between ) and { >>>>>>>>>> >>>>>>>>>>> + expire_time = mktime(&expire_tm); >>>>>>>>>>> + /* this might have overflown on 32-bit system */ >>>>>>>>>> This comment does not help to point out what you want to put in >>>>>>>>>> evidence. >>>>>>>>>> if there is an overflow what is the consequence ? Or does it >>>>>>>>>> mean the >>>>>>>>>> next condition is taking that into account ? >>>>>>>>> Yeah, this was rather ill-worded. Replaced by a rather verbose >>>>>>>>> comment that hopefully clears things out. >>>>>>>>>>> + if (current_time > expire_time && expire_time > 0){ >>>>>>>>>> style issue missing space between ) and { >>>>>>>>>> >>>>>>>>>>> + LOG_FATAL("kerberos principal has expired in >>>>>>>>>>> user >>>>>>>>>>> entry: %s\n", >>>>>>>>>>> + dn); >>>>>>>>>> I think a better phrasing would be: "The kerberos principal on >>>>>>>>>> %s is >>>>>>>>>> expired\n" >>>>>>>>>> >>>>>>>>>>> + errMesg = "Kerberos principal has expired."; >>>>>>>>>> s/has/is/ >>>>>>>>>> >>>>>>>>>> The rest looks good to me. >>>>>>>>>> >>>>>>>>>> Simo. >>>>>>>>> Styling issues fixed and updated patch attached :) >>>>>>>> Small nit, the expiration error should probably use 'in' not 'on'. >>>>>>>> >>>>>>>> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This >>>>>>>> implies >>>>>>>> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM >>>>>>>> is probably >>>>>>>> more correct here. It is what we return on other policy failures. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> Additional findings: >>>>>>> >>>>>>> 1) Lets not try to get current_time every time, but only when its >>>>>>> needed (i.e. >>>>>>> krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: >>>>>>> >>>>>>> + /* get current time*/ >>>>>>> + current_time = time(NULL); >>>>>>> >>>>>>> 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find >>>>>>> the >>>>>>> attribute again when we already have a pointer for the attribute? >>>>>>> Would >>>>>>> slapi_attr_first_value following slapi_entry_attr_find be faster >>>>>>> approach? >>>>>>> >>>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>>> &attr); >>>>>>> + if (ret != 0) { >>>>>>> + /* if it is, check whether the principal has not expired */ >>>>>>> + >>>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>>> + "krbprincipalexpiration"); >>>>>>> >>>>>>> This way, we would not create a copy of this attribute value - we do >>>>>>> not need a >>>>>>> copy, we just do check against it. >>>>>>> >>>>>>> >>>>>>> 3) Shouldn't we return -1 in the end when the auth fails? We do that >>>>>>> in other >>>>>>> pre_callbacks. Otherwise we just return 0 (success): >>>>>>> >>>>>>> + if (auth_failed){ >>>>>>> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, >>>>>>> errMesg, >>>>>>> + 0, NULL); >>>>>>> + } >>>>>>> + >>>>>>> return 0; >>>>>>> >>>>>>> Martin >>>>>> Thank you both for the review. I updated and retested the patch, with >>>>>> your suggestions incorporated. >>>>>> >>>>>> Tomas >>>>>> >>>>> I rebased the patch on top of current master. >>>>> >>>>> Bumping, since this is planned as part of 3.4 (and there were some >>>>> requests for this feature). >>>>> >>>>> Tomas >>>>> >>>> >>>> I updated the commit message to reflect better what the current version >>>> of the patch implements. >>>> >>>> Tomas >>> >>>>> From a93d1ec3ca8c7b6e8e754b474257695ba9018e07 Mon Sep 17 00:00:00 2001 >>>> From: Tomas Babej >>>> Date: Mon, 6 Jan 2014 12:11:24 +0100 >>>> Subject: [PATCH] ipa-pwd-extop: Deny LDAP binds for user accounts >>>> with expired >>>> principal >>>> >>>> Adds a check for krbprincipalexpiration attribute to pre_bind operation >>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is >>>> denied and LDAP_UNWILLING_TO_PERFORM along with the error message is >>>> sent back to the client. Since krbprincipalexpiration attribute is not >>>> mandatory, if there is no value set, the check is passed. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3305 >>>> --- >>>> daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 45 >>>> ++++++++++++++++++++++- >>>> 1 file changed, 44 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>>> b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>>> index >>>> ef37b5e173359f9404b241c12d8a6dc6e77da128..568cba7189d1575d030b043daee61f713e9bac5f >>>> 100644 >>>> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>>> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>>> @@ -1389,13 +1389,17 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>>> Slapi_Value *value = NULL; >>>> Slapi_Attr *attr = NULL; >>>> struct tm expire_tm; >>>> + time_t current_time; >>>> + time_t expire_time; >>>> char *errMesg = "Internal operations error\n"; /* error message */ >>>> char *expire = NULL; /* passwordExpirationTime attribute value */ >>>> + char *principal_expire = NULL; /* krbPrincipalExpiration >>>> attribute value */ >>>> char *dn = NULL; /* bind DN */ >>>> Slapi_Value *objectclass; >>>> int method; /* authentication method */ >>>> int ret = 0; >>>> char *principal = NULL; >>>> + bool auth_failed = false; >>>> >>>> LOG_TRACE("=>\n"); >>>> >>>> @@ -1422,7 +1426,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>>> const char *attrs_list[] = {SLAPI_USERPWD_ATTR, >>>> "krbprincipalkey", "uid", >>>> "krbprincipalname", "objectclass", >>>> "passwordexpirationtime", >>>> "passwordhistory", >>>> - NULL}; >>>> + "krbprincipalexpiration", NULL}; >>>> >>>> /* retrieve user entry */ >>>> ret = ipapwd_getEntry(dn, &entry, (char **) attrs_list); >>>> @@ -1438,6 +1442,39 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>>> goto done; >>>> } >>>> >>>> + /* check the krbPrincipalExpiration attribute is present */ >>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>> &attr); >>>> + if (ret == 0) { >>>> + ret = slapi_attr_first_value(attr, &value); >>>> + >>>> + if (ret == 0) { >>>> + /* if it is, check whether the principal has not expired */ >>>> + principal_expire = slapi_value_get_string(value); >>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>> + >>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>>> &expire_tm)) { >>>> + expire_time = mktime(&expire_tm); >>>> + >>>> + /* get current time */ >>>> + current_time = time(NULL); >>>> + >>>> + /* mktime returns -1 if the tm struct cannot be >>>> represented as >>>> + * as calendar time (seconds since the Epoch). This >>>> might >>>> + * happen with tm structs that are ill-formated or >>>> on 32-bit >>>> + * platforms with dates that would cause overflow >>>> + * (year 2038 and later). >>>> + * In such cases, skip the expiration check. */ >>>> + >>>> + if (current_time > expire_time && expire_time > 0) { >>>> + LOG_FATAL("kerberos principal in %s is >>>> expired\n", dn); >>>> + errMesg = "Kerberos principal is expired."; >>>> + auth_failed = true; >>>> + goto done; >>>> + } >>>> + } >>> I think indenting is broken for these two brackets. >>> >>> >> >> Thanks Alexander, fixed. >> >> Updated version attached. >> >> Tomas >> > > Simo, Alexander - are you know OK with Tomas' patch? The patch review is now > taking more than a year, so I think it would be great to finish it :) > > Martin Resending, it seems the message fell between cracks. Martin From amisnyov at redhat.com Tue Apr 8 14:17:49 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 8 Apr 2014 16:17:49 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <5342570E.6040207@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> <5342570E.6040207@redhat.com> Message-ID: <20140408161749.64027b9a@unused-4-246.brq.redhat.com> On Mon, 07 Apr 2014 09:43:10 +0200 Petr Viktorin wrote: > On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: > > On Wed, 26 Mar 2014 13:15:55 +0100 > > Petr Viktorin wrote: > [...] > >> > >> Looks great! I'm just concerned about the error returned when the > >> task takes too long: > >> $ ipa automember-rebuild --type group > >> ipa: ERROR: LDAP timeout > >> I don't think it's sufficiently clear from this that waiting for > >> the task timed out, but the task was actually started > >> successfully. A custom error with a more descriptive message would > >> be useful. > >> > >> > >> Also I've noticed that the "nstaskstatus" of a successful task is: > >> Automember rebuild task finished. Processed (1) entries. > >> This looks helpful; we could return it as the summary. > >> > > > > Hi, > > both fixed. > > Greets > > Adam > > > > Sorry for the delay! > 'Automember' is a translatable string, so please wrap it in _() when > raising TaskTimeout. Also please update the tests. > Otherwise with a little rebase it's good to go. > > Hi, see the attached modifications, tests corrected, and added for no-wait, also rebased for current master. Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0007-7-automember-rebuild-nowait-feature-added.patch Type: text/x-patch Size: 11989 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0008-2-plugin-registration-refactoring-for-automembership.patch Type: text/x-patch Size: 4956 bytes Desc: not available URL: From abokovoy at redhat.com Tue Apr 8 14:23:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 8 Apr 2014 17:23:37 +0300 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <534404A8.4040600@redhat.com> References: <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> <53342A65.3070808@redhat.com> <534404A8.4040600@redhat.com> Message-ID: <20140408142337.GT20958@redhat.com> On Tue, 08 Apr 2014, Martin Kosek wrote: >>>>> + auth_failed = true; >>>>> + goto done; >>>>> + } >>>>> + } >>>> I think indenting is broken for these two brackets. >>>> >>>> >>> >>> Thanks Alexander, fixed. >>> >>> Updated version attached. >>> >>> Tomas >>> >> >> Simo, Alexander - are you know OK with Tomas' patch? The patch review is now >> taking more than a year, so I think it would be great to finish it :) >> >> Martin > >Resending, it seems the message fell between cracks. I think I've asked for a rebase and Simo asked for that too. And then there were comments from Simo's side. -- / Alexander Bokovoy From mkosek at redhat.com Tue Apr 8 14:26:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 16:26:46 +0200 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <20140408142337.GT20958@redhat.com> References: <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> <53342A65.3070808@redhat.com> <534404A8.4040600@redhat.com> <20140408142337.GT20958@redhat.com> Message-ID: <53440726.8030705@redhat.com> On 04/08/2014 04:23 PM, Alexander Bokovoy wrote: > On Tue, 08 Apr 2014, Martin Kosek wrote: >>>>>> + auth_failed = true; >>>>>> + goto done; >>>>>> + } >>>>>> + } >>>>> I think indenting is broken for these two brackets. >>>>> >>>>> >>>> >>>> Thanks Alexander, fixed. >>>> >>>> Updated version attached. >>>> >>>> Tomas >>>> >>> >>> Simo, Alexander - are you know OK with Tomas' patch? The patch review is now >>> taking more than a year, so I think it would be great to finish it :) >>> >>> Martin >> >> Resending, it seems the message fell between cracks. > I think I've asked for a rebase and Simo asked for that too. > And then there were comments from Simo's side. Ah, ok - thanks. I finally see it: http://www.redhat.com/archives/freeipa-devel/2014-March/msg00417.html It went to different sub-thread so I missed it. Well, Tomas - the ball is on your lawn then :) Martin From alee at redhat.com Tue Apr 8 14:38:30 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 08 Apr 2014 10:38:30 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <5343FF31.8050206@redhat.com> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> <53439C4D.6060108@redhat.com> <5343FF31.8050206@redhat.com> Message-ID: <1396967910.21643.37.camel@aleeredhat.laptop> On Tue, 2014-04-08 at 09:52 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On 04/07/2014 10:40 PM, Rob Crittenden wrote: > >> Ade Lee wrote: > >>> This patch adds the capability of installing a Dogtag DRM > >>> to an IPA instance. With this patch, when ipa-server-install > >>> is run, a Dogtag CA and a Dogtag DRM are created. The DRM > >>> shares the same tomcat instance and DS instance as the Dogtag CA. > >>> Moreover, the same admin user/agent (and agent cert) can be used > >>> for both subsystems. Certmonger is also confgured to monitor the > >>> new subsystem certificates. > >>> > >>> It is also possible to clone the DRM. When the IPA instance is > >>> cloned, if --enable-ca and --enable-drm are specified, the DRM > >>> is cloned as well. > >>> > >>> Installing a DRM requires the user to have a Dogtag CA instance. > >>> We can look into possibly relaxing that requirement in a later patch. > >>> > >>> I am still working on patches for a ipa-drm-install script, which > >>> would be used to add a DRM to an existing master (that includes > >>> a dogtag CA), or an existing clone. > >>> > >>> Please review, > >>> > >>> Thanks, > >>> Ade > >> > >> Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be > >> pushed ASAP. > > > > Oops, looks like a change that should go to IPA 3.3.x. What is the implication? > > This error is unlikely to have any real effect because when connecting to the database using client auth, we determine how to connect to the database through the parameter that defines the certificate nickname. So we're probably fine with just changing it in master. > >> freeipa-spec.in needs a dependency on pki-kra. > > > > Let us stop here. Please see a following RFE I filed: > > https://fedorahosted.org/freeipa/ticket/4058 > > > > I would prefer it KRA files and specifics would be in a new subpackage like > > freeipa-server-kra. Otherwise we will need to rework it again when we would be > > splitting CA to freeipa-server-pki in 4.1. > > Yes, that is a question I didn't ask: Is the DRM going to be configured > by default on all new installs? > The code I wrote presupposes this - but this is something that needs to be decided by IPA. Now given that the DRM is going to use the same tomcat instance and database as the CA - and given that we are probably going to want to have a DRM when we start issuing user certs, I see no reason not to add a DRM when we add a CA. To miminize complexity, I would suggest that we keep the requirement that DRM requires Dogtag CA. > > I would prefer to start the right modularization now as I do not think that > > every FreeIPA server needs to run CA/KRA, i.e. it does not need to have the > > bits installed either. > > I think the decision on a separate sub-package will be dependent upon > whether it is default or not, otherwise we can get away with > freeipa-server-ca and just lump everything in there. > For noted above, because we will likely want DRM for user certs, I would suggest that DRM be installed by default when we install a Dogtag CA. As far as package dependencies, there are in fact very few additional dependencies for the DRM as most of the Java code is in common libraries already required by the CA. In fact, there is only one new package pki-kra, which contains a few KRA specific java classes. > > I am also quite worried about the duplication that the new drminstance.py > > introduces. There is a lot of functions which do more or less the same thing > > and have most of the handling code the same with only a very small and > > predictable pki/kra change. For example __http_proxy function seems to be > > exactly the same. > > > > It would be great to avoid this duplication and rather have some common ground > > utilized by both PKI and KRA. Otherwise it will be very difficult to maintain > > the new code. > > I touched on some of that too, but some of this is just inevitable I > think which is why I didn't pound on it too hard. An abstraction would > be nice, but I'm not sure abstracting for two things, and only in the > installer, is worth the effort. I could be wrong. > This initial patch was to get things working and start some of these discussions. As we consider adding additional subsystems like the TKS and TPS, having some common ground will make things simpler to maintain. I will look into abstracting to reduce code duplication. > rob > From mkosek at redhat.com Tue Apr 8 14:39:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Apr 2014 16:39:42 +0200 Subject: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions In-Reply-To: <5343D9FA.4080207@redhat.com> References: <5343BB5E.3030504@redhat.com> <5343D526.5040204@redhat.com> <5343D9FA.4080207@redhat.com> Message-ID: <53440A2E.5080104@redhat.com> On 04/08/2014 01:14 PM, Petr Viktorin wrote: > On 04/08/2014 12:53 PM, Martin Kosek wrote: >> On 04/08/2014 11:03 AM, Petr Viktorin wrote: ... >> The patch is functional, but I am not really a big fan of placing it in the >> plugin. I would prefer if the ACI definition is also in the sudo plugin >> together with other definition. It would be then much easier to audit all >> sudo-related ACIs. >> >> Why can't we add this ACI to sudorule object managed permissions and just >> override the location and target? > > I can do that. Most of the changes make this overriding possible, where the > permission is actually defined is a detail. > >> I am not insisting on a specific format, I would simply prefer to have all >> plugin object related ACIs close together. > > My reasoning is that finding the definition would not be straightforward. All > the object-specific permissions so far are defined in "their" plugins, as > determined by --type. This one won't have --type, and it's not clear if it > should be in sudorule, sudocmd or sudocmdgroup. > > But, I don't have a strong preference. A `git grep` will always show the > definition. > IMO sudorule is fine, I personally see it as an overarching plugin for sudo, sudocmds and sudocmdgroups are just part of the sudorule. We may just want to somehow differentiate the non--type ACIs from the regular --type ones. Whether it is a different attribute in the Object or a setting in managed permission is something I will leave up to you. Martin From pviktori at redhat.com Tue Apr 8 15:17:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Apr 2014 17:17:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions In-Reply-To: <53440A2E.5080104@redhat.com> References: <5343BB5E.3030504@redhat.com> <5343D526.5040204@redhat.com> <5343D9FA.4080207@redhat.com> <53440A2E.5080104@redhat.com> Message-ID: <5344131A.4060001@redhat.com> On 04/08/2014 04:39 PM, Martin Kosek wrote: > On 04/08/2014 01:14 PM, Petr Viktorin wrote: >> On 04/08/2014 12:53 PM, Martin Kosek wrote: >>> On 04/08/2014 11:03 AM, Petr Viktorin wrote: > ... >>> The patch is functional, but I am not really a big fan of placing it in the >>> plugin. I would prefer if the ACI definition is also in the sudo plugin >>> together with other definition. It would be then much easier to audit all >>> sudo-related ACIs. >>> >>> Why can't we add this ACI to sudorule object managed permissions and just >>> override the location and target? >> >> I can do that. Most of the changes make this overriding possible, where the >> permission is actually defined is a detail. >> >>> I am not insisting on a specific format, I would simply prefer to have all >>> plugin object related ACIs close together. >> >> My reasoning is that finding the definition would not be straightforward. All >> the object-specific permissions so far are defined in "their" plugins, as >> determined by --type. This one won't have --type, and it's not clear if it >> should be in sudorule, sudocmd or sudocmdgroup. >> >> But, I don't have a strong preference. A `git grep` will always show the >> definition. >> > > IMO sudorule is fine, I personally see it as an overarching plugin for sudo, > sudocmds and sudocmdgroups are just part of the sudorule. > > We may just want to somehow differentiate the non--type ACIs from the regular > --type ones. Whether it is a different attribute in the Object or a setting in > managed permission is something I will leave up to you. I went with a "non_object" key in the managed permission info. Attaching new patches. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0508.2-Document-the-managed-permission-updater-operation.patch Type: text/x-patch Size: 2478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0509.2-Allow-overriding-all-attributes-of-default-permissio.patch Type: text/x-patch Size: 5459 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 8 15:19:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Apr 2014 17:19:03 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects In-Reply-To: <5343D36F.7040401@redhat.com> References: <533D3360.7080106@redhat.com> <53428C3A.1000003@redhat.com> <5343BB55.9000800@redhat.com> <5343D36F.7040401@redhat.com> Message-ID: <53441367.7050301@redhat.com> On 04/08/2014 12:46 PM, Martin Kosek wrote: > On 04/08/2014 11:03 AM, Petr Viktorin wrote: >> On 04/07/2014 01:30 PM, Martin Kosek wrote: >>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>> Hello, >>>> This adds read permissions to read Sudo commands, command groups, rules. >>>> >>>> Read access is given to all authenticated users. >>> >>> Looks good. What about "ou=sudoers"? I think we should also allow it in this >>> patch for authenticated users. This is the tree that clients use to read sudo. >> >> This new version does that. It needs my patches 0508-0509 since the ou=sudoers >> permission is not tied to a specific Object plugin. >> > > I would also allow 'ou', otherwise an authenticated user cannot read the > ou=sudoers RDN. I will comment on NONOBJECT_PERMISSIONS in the other thread. Right, I wonder how I missed that. New patch attached; it needs 0508-0509.2. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0504.3-Add-managed-read-permissions-to-Sudo-objects-and-ou-.patch Type: text/x-patch Size: 5207 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 8 15:31:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Apr 2014 17:31:25 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140408161749.64027b9a@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> <5342570E.6040207@redhat.com> <20140408161749.64027b9a@unused-4-246.brq.redhat.com> Message-ID: <5344164D.30302@redhat.com> On 04/08/2014 04:17 PM, Misnyovszki Adam wrote: > On Mon, 07 Apr 2014 09:43:10 +0200 > Petr Viktorin wrote: > >> On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: >>> On Wed, 26 Mar 2014 13:15:55 +0100 >>> Petr Viktorin wrote: >> [...] >>>> >>>> Looks great! I'm just concerned about the error returned when the >>>> task takes too long: >>>> $ ipa automember-rebuild --type group >>>> ipa: ERROR: LDAP timeout >>>> I don't think it's sufficiently clear from this that waiting for >>>> the task timed out, but the task was actually started >>>> successfully. A custom error with a more descriptive message would >>>> be useful. >>>> >>>> >>>> Also I've noticed that the "nstaskstatus" of a successful task is: >>>> Automember rebuild task finished. Processed (1) entries. >>>> This looks helpful; we could return it as the summary. >>>> >>> >>> Hi, >>> both fixed. >>> Greets >>> Adam >>> >> >> Sorry for the delay! >> 'Automember' is a translatable string, so please wrap it in _() when >> raising TaskTimeout. Also please update the tests. >> Otherwise with a little rebase it's good to go. >> >> > > Hi, > see the attached modifications, tests corrected, and added for no-wait, > also rebased for current master. > Greets > Adam > Looks good overall, but why do you now set `self.msg_summary`? Keep in mind that currently the same Command object is reused for every automember_rebuild command, including commands that run in parallel in different threads. It should never be modified. -- Petr? From purpleidea at gmail.com Tue Apr 8 15:51:07 2014 From: purpleidea at gmail.com (James) Date: Tue, 8 Apr 2014 11:51:07 -0400 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <534339FD.3090901@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> Message-ID: Not sure where to jump in but I had one comment: Puppet-IPA [1] + Shorewall make a lovely pair :) Cheers, James [1] https://github.com/purpleidea/puppet-ipa On Mon, Apr 7, 2014 at 7:51 PM, Dmitri Pal wrote: > On 04/07/2014 09:00 AM, Rob Crittenden wrote: >> >> Simo Sorce wrote: >>> >>> On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote: >>>> >>>> On 4.4.2014 09:17, Martin Kosek wrote: >>>>> >>>>> On 04/04/2014 09:04 AM, Justin Brown wrote: >>>>>>> >>>>>>> I would actually do it the opposite way and open the ports after the >>>>>>> FreeIPA server is fully configured. After all, I do not think we want to >>>>>>> open the ports when the server is just half-configured and for example some >>>>>>> ACIs are missing. >>>>>> >>>>>> >>>>>> My thinking was that nothing would be listening on these ports if the >>>>>> install doesn't succeed, but there's really necessity to modify the >>>>>> firewall configuration early. (All of the internal install >>>>>> communication will be over a local interface (to netfilter) and >>>>>> unblock anyways. I don't have any problem in delaying firewall >>>>>> configuration to the end of install. >>>>> >>>>> >>>>> If ipa-server-install does succeed without configuring the firewalld, >>>>> then we >>>>> will indeed have no other option than to do it early. >>>>> >>>>> I am thinking that we may want to put all the firewalld configuration >>>>> in >>>>> ipaserver/install/firewalldinstance.py, >>>>> and then make the firewalld configuration the actual step of the >>>>> installation. >>>>> Something like: >>>>> >>>>> ... >>>>> Configuring Firewall (firewalld) >>>>> [1/2]: looking up the right zone >>>>> [2/2]: allowing ports >>>>> Done configuring Firewall (firewalld). >>>>> ... >>>>> >>>>> The Service class derived object can be really simple, we would just >>>>> reuse the >>>>> functionality it already has + let us properly hook into it in >>>>> ipa-{server,replica}-install and the uninstallation. >>>>> >>>>> It would also make it easier to split this functionality to >>>>> freeipa-server-firewalld if we chose to in a future. >>>> >>>> >>>> In general I agree with the idea, thank you Justin for working on that! >>>> >>>> I would like to emphasis the necessity to work without NetworkManager >>>> and >>>> FirewallD. New dependencies make Debian folks unhappy ... >>>> >>>> On the other hand, it is perfectly fine to skip firewall configuration >>>> if >>>> NM/FirewallD/DBus is not available. >>>> >>>> Have a nice day! >>> >>> >>> Should be easy, probe for the dbus firewalld service and just skip (not >>> error out) if it is not there. >>> Set a variable in that case that will cause the installer to throw the >>> classic banner we have now which warns you about what ports need to be >>> opened at the end of the install. >> >> >> Probably just need to spit out a large, preferably flashing warning that >> the firewall has not been automatically configured. Perhaps even multiple >> times: one in-line and one at the install summary at the end. >> >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Thanks for looking into this! > > Would it be possible to summarize this thread in a design page on the wiki? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From justin.brown at fandingo.org Tue Apr 8 16:15:28 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Tue, 8 Apr 2014 11:15:28 -0500 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <534339FD.3090901@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> Message-ID: Dmitri, I'd be more than happy to, but I'm having trouble figuring out where it should go. Could you send me a link to a similar design page? Thanks, Justin On Mon, Apr 7, 2014 at 6:51 PM, Dmitri Pal wrote: > On 04/07/2014 09:00 AM, Rob Crittenden wrote: >> >> Simo Sorce wrote: >>> >>> On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote: >>>> >>>> On 4.4.2014 09:17, Martin Kosek wrote: >>>>> >>>>> On 04/04/2014 09:04 AM, Justin Brown wrote: >>>>>>> >>>>>>> I would actually do it the opposite way and open the ports after the >>>>>>> FreeIPA server is fully configured. After all, I do not think we want to >>>>>>> open the ports when the server is just half-configured and for example some >>>>>>> ACIs are missing. >>>>>> >>>>>> >>>>>> My thinking was that nothing would be listening on these ports if the >>>>>> install doesn't succeed, but there's really necessity to modify the >>>>>> firewall configuration early. (All of the internal install >>>>>> communication will be over a local interface (to netfilter) and >>>>>> unblock anyways. I don't have any problem in delaying firewall >>>>>> configuration to the end of install. >>>>> >>>>> >>>>> If ipa-server-install does succeed without configuring the firewalld, >>>>> then we >>>>> will indeed have no other option than to do it early. >>>>> >>>>> I am thinking that we may want to put all the firewalld configuration >>>>> in >>>>> ipaserver/install/firewalldinstance.py, >>>>> and then make the firewalld configuration the actual step of the >>>>> installation. >>>>> Something like: >>>>> >>>>> ... >>>>> Configuring Firewall (firewalld) >>>>> [1/2]: looking up the right zone >>>>> [2/2]: allowing ports >>>>> Done configuring Firewall (firewalld). >>>>> ... >>>>> >>>>> The Service class derived object can be really simple, we would just >>>>> reuse the >>>>> functionality it already has + let us properly hook into it in >>>>> ipa-{server,replica}-install and the uninstallation. >>>>> >>>>> It would also make it easier to split this functionality to >>>>> freeipa-server-firewalld if we chose to in a future. >>>> >>>> >>>> In general I agree with the idea, thank you Justin for working on that! >>>> >>>> I would like to emphasis the necessity to work without NetworkManager >>>> and >>>> FirewallD. New dependencies make Debian folks unhappy ... >>>> >>>> On the other hand, it is perfectly fine to skip firewall configuration >>>> if >>>> NM/FirewallD/DBus is not available. >>>> >>>> Have a nice day! >>> >>> >>> Should be easy, probe for the dbus firewalld service and just skip (not >>> error out) if it is not there. >>> Set a variable in that case that will cause the installer to throw the >>> classic banner we have now which warns you about what ports need to be >>> opened at the end of the install. >> >> >> Probably just need to spit out a large, preferably flashing warning that >> the firewall has not been automatically configured. Perhaps even multiple >> times: one in-line and one at the install summary at the end. >> >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > Thanks for looking into this! > > Would it be possible to summarize this thread in a design page on the wiki? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Tue Apr 8 18:42:02 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Apr 2014 14:42:02 -0400 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> Message-ID: <534442FA.1060709@redhat.com> Justin Brown wrote: > Dmitri, > > I'd be more than happy to, but I'm having trouble figuring out where > it should go. Could you send me a link to a similar design page? > I'd put it under here: http://www.freeipa.org/page/V4_Proposals There is a template at http://www.freeipa.org/page/Feature_template So maybe something like http://www.freeipa.org/page/V4/Firewalld rob > Thanks, > Justin > > On Mon, Apr 7, 2014 at 6:51 PM, Dmitri Pal wrote: >> On 04/07/2014 09:00 AM, Rob Crittenden wrote: >>> >>> Simo Sorce wrote: >>>> >>>> On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote: >>>>> >>>>> On 4.4.2014 09:17, Martin Kosek wrote: >>>>>> >>>>>> On 04/04/2014 09:04 AM, Justin Brown wrote: >>>>>>>> >>>>>>>> I would actually do it the opposite way and open the ports after the >>>>>>>> FreeIPA server is fully configured. After all, I do not think we want to >>>>>>>> open the ports when the server is just half-configured and for example some >>>>>>>> ACIs are missing. >>>>>>> >>>>>>> >>>>>>> My thinking was that nothing would be listening on these ports if the >>>>>>> install doesn't succeed, but there's really necessity to modify the >>>>>>> firewall configuration early. (All of the internal install >>>>>>> communication will be over a local interface (to netfilter) and >>>>>>> unblock anyways. I don't have any problem in delaying firewall >>>>>>> configuration to the end of install. >>>>>> >>>>>> >>>>>> If ipa-server-install does succeed without configuring the firewalld, >>>>>> then we >>>>>> will indeed have no other option than to do it early. >>>>>> >>>>>> I am thinking that we may want to put all the firewalld configuration >>>>>> in >>>>>> ipaserver/install/firewalldinstance.py, >>>>>> and then make the firewalld configuration the actual step of the >>>>>> installation. >>>>>> Something like: >>>>>> >>>>>> ... >>>>>> Configuring Firewall (firewalld) >>>>>> [1/2]: looking up the right zone >>>>>> [2/2]: allowing ports >>>>>> Done configuring Firewall (firewalld). >>>>>> ... >>>>>> >>>>>> The Service class derived object can be really simple, we would just >>>>>> reuse the >>>>>> functionality it already has + let us properly hook into it in >>>>>> ipa-{server,replica}-install and the uninstallation. >>>>>> >>>>>> It would also make it easier to split this functionality to >>>>>> freeipa-server-firewalld if we chose to in a future. >>>>> >>>>> >>>>> In general I agree with the idea, thank you Justin for working on that! >>>>> >>>>> I would like to emphasis the necessity to work without NetworkManager >>>>> and >>>>> FirewallD. New dependencies make Debian folks unhappy ... >>>>> >>>>> On the other hand, it is perfectly fine to skip firewall configuration >>>>> if >>>>> NM/FirewallD/DBus is not available. >>>>> >>>>> Have a nice day! >>>> >>>> >>>> Should be easy, probe for the dbus firewalld service and just skip (not >>>> error out) if it is not there. >>>> Set a variable in that case that will cause the installer to throw the >>>> classic banner we have now which warns you about what ports need to be >>>> opened at the end of the install. >>> >>> >>> Probably just need to spit out a large, preferably flashing warning that >>> the firewall has not been automatically configured. Perhaps even multiple >>> times: one in-line and one at the install summary at the end. >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> Thanks for looking into this! >> >> Would it be possible to summarize this thread in a design page on the wiki? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> _______________________________________________ >> 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 simo at redhat.com Tue Apr 8 22:31:53 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2014 18:31:53 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <5343C8C5.8020708@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> <5343C8C5.8020708@redhat.com> Message-ID: <1396996313.19767.15.camel@willson.li.ssimo.org> On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote: > Replication storms. In my opinion the replication of a mod of one or > two attribute in a entry will be faster than the bind itself. Think about the amplification effect in an environment with 20 replicas. 1 login attempt -> 20+ replication messages Now think about what happen bandwidth wise when a few thousand people all authenticate at the same time across the infrastructure, you deploy more servers to scale better and you get *more* traffic, at some point servers actually get slower as they are busy with replication related operations. Think what happen if one of these servers is in a satellite office on a relatively slow link and every morning it receives a flooding of replication data ... that is 99% useless because most of tat data is not relevant in that office. > If an attacker knows all the dns of the entries in a server the > denial of service could be that it just does a sequence of failed > logins for any user and nobody will be able to login any more, This is perfectly true which is why we do not permanently lockout users by default and which is why I personally dislike lockouts. A much better mechanism to deal with brute force attacks is throttling, but it is also somewhat harder to implement as you need to either have an async model to delay answers or you need to tie threads for the delay time. Still a far superior measure than replicating status around at all times. > replication would help to propagate this to other servers, but not > prevent it. This would also be the case if only the final lockout > state is replicated. Yes but the amount of replicated information would be far less. With our default 1/5th less on average as 5 is the number of failed attempts before the final lockout kicks in. So you save a lot of bandwidth. > I like the idea of replicating the attributes changed at failed logins > (or reset) only. I think this is reasonable indeed, the common case is that users tend to get their password right, and if you are under a password guessing attack you should stop it. The issue is though that sometimes you have misconfigured services with bad keytabs that will try over and over again to init, even if the account is locked, or maybe (even worse) they try a number of bad keys, but lower than the failed count, before getting to the right one (thus resetting the failed count). If they do this often you can still self-DoS even without a malicious attacker :-/ Something like this is what we have experienced for real and cause us to actually disable replication of all the lockout related attributes in the past. Simo. -- Simo Sorce * Red Hat, Inc * New York From redhatrises at gmail.com Wed Apr 9 03:19:34 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 8 Apr 2014 21:19:34 -0600 Subject: [Freeipa-devel] [PATCH] [DOC] document that wildcards are not supported in FreeIPA <= 3.2 Message-ID: Hello, Not sure how relevant this patch is to the current documentation considering (I believe) that wildcards are supported in versions 3.3 and up. Patch for https://fedorahosted.org/freeipa/ticket/3616 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0013-DOC-wildcards-are-not-supported-in-IPA-3.2.patch Type: text/x-patch Size: 1001 bytes Desc: not available URL: From thozza at redhat.com Wed Apr 9 08:03:39 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 09 Apr 2014 10:03:39 +0200 Subject: [Freeipa-devel] [PATCH 0231] Fix record parsing to prevent child zone corruption In-Reply-To: <533B0576.2090409@redhat.com> References: <533B0576.2090409@redhat.com> Message-ID: <5344FEDB.1020109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/01/2014 08:29 PM, Petr Spacek wrote: > Hello, > > Fix record parsing to prevent child zone corruption. > > Child zone hosted on the same server as parent zone was > corrupted by bug in update_record(). > Child zone's apex was modified by update_records() > instead of delegation records in the parent zone. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/134 > ACK Solves the problem described in the ticket. Regards, Tomas Hozza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRP7XAAoJEMWIetUdnzwt6sMH/1OABEPs2+4nat6gKn849dTR ZrfrBiAu6nKMyzAGNfEGMpoqUxm94OrvdGXdqVhu0zUAT7NLTlvnlDziCqTggVnI vG7BENtMR4XMCDp+6o0cS8YsQoipUw4RGGA9eMvqD73tTUPGJf1XEMrTd0QQ5HJy XpsbGNMeMH+tzrTn65rM2zTCYZDDyO/adbejWyn3/JUfTpSLWicAldyUW1FECYtN vH2miG4vjwr+4ivZxvGNds0GskM3GZBxPHz6dWXkrrI2mKtR3kFgaOTKNtlNwfBC tCXYnlDuBDwEYe1kRekiG4gYhjjLq9dq8DgTTqO5W/J1Bz3eNjlJ3i3fh6o6s7g= =nrmr -----END PGP SIGNATURE----- From mbasti at redhat.com Wed Apr 9 08:23:40 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 09 Apr 2014 10:23:40 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046] Internationalized domain names in DNS plugin In-Reply-To: <5343BAD7.10802@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <533E9091.9020900@redhat.com> <5343A39D.2000808@redhat.com> <5343AA58.6080800@redhat.com> <20140408080103.GM20958@redhat.com> <5343ADCC.20700@redhat.com> <20140408080956.GN20958@redhat.com> <5343AFE8.3090309@redhat.com> <5343B0F5.2010505@redhat.com> <5343B35F.3030007@redhat.com> <5343B3EF.4050404@redhat.com> <5343B80A.20801@redhat.com> <5343BAD7.10802@redhat.com> Message-ID: <1397031820.2318.2.camel@unused-4-145.brq.redhat.com> On Tue, 2014-04-08 at 11:01 +0200, Petr Spacek wrote: > On 8.4.2014 10:49, Jan Cholasta wrote: > > On 8.4.2014 10:31, Petr Spacek wrote: > >> On 8.4.2014 10:29, Jan Cholasta wrote: > >>> On 8.4.2014 10:19, Petr Spacek wrote: > >>>> On 8.4.2014 10:14, Jan Cholasta wrote: > >>>>> On 8.4.2014 10:09, Alexander Bokovoy wrote: > >>>>>> On Tue, 08 Apr 2014, Jan Cholasta wrote: > >>>>>>> On 8.4.2014 10:01, Alexander Bokovoy wrote: > >>>>>>>> On Tue, 08 Apr 2014, Petr Spacek wrote: > >>>>>>>>> On 8.4.2014 09:22, Jan Cholasta wrote: > >>>>>>>>>> On 4.4.2014 12:59, Petr Spacek wrote: > >>>>>>>>>>> On 3.4.2014 15:35, Jan Cholasta wrote: > >>>>>>>>>>>> I would shorten "origin_sign" to just "sign". > >>>>>>>>>>> Sign of what? Decay? :-) I don't think that sign is descriptive > >>>>>>>>>>> enough, > >>>>>>>>>>> I would personally stick with origin_sign. > >>>>>>>>>> > >>>>>>>>>> Whoops, I meant "origin". The "_sign" bit seems a little bit > >>>>>>>>>> redundant to me. > >>>>>>>>> > >>>>>>>>> "Origin" is an established term for the name of the parent. > >>>>>>>>> > >>>>>>>>> name = "blabla.example." > >>>>>>>>> origin of "name" = "example." > >>>>>>>>> > >>>>>>>>> Anyway, I still think that DNSName('@') is better than any constant > >>>>>>>>> with cryptic name. > >>>>>>>>> > >>>>>>>>> Honza, can you see any problem with this? I know this creates > >>>>>>>>> instance > >>>>>>>>> again and again, but is it a real problem? I would like to avoid > >>>>>>>>> premature optimization... :-) > >>>>>>>> What about making all these fixed names as constants and then simply > >>>>>>>> return those? > >>>>>>>> > >>>>>>>> class DNSName: > >>>>>>>> DNS_ORIGIN = DNSName('@') > >>>>>>>> ... > >>>>>>>> > >>>>>>>> @staticmethod ... > >>>>>>>> def ... > >>>>>>>> return DNS_ORIGIN > >>>>>>>> > >>>>>>>> they would be singletons... > >>>>>>> > >>>>>>> Unfortunately you can't do that, because at the time DNSName is > >>>>>>> parsed, it is not defined yet: > >>>>>>> > >>>>>>>>>> class X: > >>>>>>> ... x = X() > >>>>>>> ... > >>>>>>> Traceback (most recent call last): > >>>>>>> File "", line 1, in > >>>>>>> File "", line 2, in X > >>>>>>> NameError: name 'X' is not defined > >>>>>> Then we can split these classes: define DNSName with purely static > >>>>>> methods as child of DNSNameBase which would have all the expected > >>>>>> methods. DNSName can then have constants of DNSNameBase() and return > >>>>>> those. > >>>>>> > >>>>> > >>>>> IMO this is an overkill. I would prefer if we did what I suggested > >>>>> earlier: > >>>>> put DNSName into a new module dnsutil and make the constants global > >>>>> for the > >>>>> module. > >>>> > >>>> I consider this less readable but I'm not Python expert so I'm fine this > >>>> approach. > >>> > >>> Well, it's the same thing python-dns does: dns.name.Name, > >>> dns.name.root, ... > >>> > >>>> > >>>> Note: The difference between @ and real "origin" is like "pointer to > >>>> origin" and "origin value" in C. > >>>> > >>> > >>> I think a good name would be "self", but that doesn't work very well > >>> in Python > >>> :-) Perhaps "self_origin" is better? > >> > >> I'm not big fan of SELF :-) > >> > >> What is wrong with origin_sign? It seems more understandable than > >> self_origin to me. > >> > > > > The word "sign" does not really capture the meaning of it. It is a sign as > > long as you look at it in text form, but it has a specific meaning and IMO we > > should capture that meaning in the name rather than what it looks like in text. > > > > The constant is named "empty" in python-dns, IMO we should name it the same. > > Okay, use whatever and please add comment # invented by jcholast :-) > I vote for 'empty' as is used in dnspython or 'zone_record' as is used in FreeIPA dns plugin now I agree to make global constants in new dnsutil module -- Martin^2 Basti From mbasti at redhat.com Wed Apr 9 08:29:28 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 09 Apr 2014 10:29:28 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] document that wildcards are not supported in FreeIPA <= 3.2 In-Reply-To: References: Message-ID: <1397032168.2318.5.camel@unused-4-145.brq.redhat.com> On Tue, 2014-04-08 at 21:19 -0600, Gabe Alford wrote: > Hello, > > > Not sure how relevant this patch is to the current documentation > considering (I believe) that wildcards are supported in versions 3.3 > and up. Patch for https://fedorahosted.org/freeipa/ticket/3616 > > > Thanks, > > > Gabe > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Wildcards will be supported from version 4.0 . Curently are not supported in 3.x. -- Martin^2 Basti From mkosek at redhat.com Wed Apr 9 08:31:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 10:31:30 +0200 Subject: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions In-Reply-To: <5344131A.4060001@redhat.com> References: <5343BB5E.3030504@redhat.com> <5343D526.5040204@redhat.com> <5343D9FA.4080207@redhat.com> <53440A2E.5080104@redhat.com> <5344131A.4060001@redhat.com> Message-ID: <53450562.3020601@redhat.com> On 04/08/2014 05:17 PM, Petr Viktorin wrote: > On 04/08/2014 04:39 PM, Martin Kosek wrote: >> On 04/08/2014 01:14 PM, Petr Viktorin wrote: >>> On 04/08/2014 12:53 PM, Martin Kosek wrote: >>>> On 04/08/2014 11:03 AM, Petr Viktorin wrote: >> ... >>>> The patch is functional, but I am not really a big fan of placing it in the >>>> plugin. I would prefer if the ACI definition is also in the sudo plugin >>>> together with other definition. It would be then much easier to audit all >>>> sudo-related ACIs. >>>> >>>> Why can't we add this ACI to sudorule object managed permissions and just >>>> override the location and target? >>> >>> I can do that. Most of the changes make this overriding possible, where the >>> permission is actually defined is a detail. >>> >>>> I am not insisting on a specific format, I would simply prefer to have all >>>> plugin object related ACIs close together. >>> >>> My reasoning is that finding the definition would not be straightforward. All >>> the object-specific permissions so far are defined in "their" plugins, as >>> determined by --type. This one won't have --type, and it's not clear if it >>> should be in sudorule, sudocmd or sudocmdgroup. >>> >>> But, I don't have a strong preference. A `git grep` will always show the >>> definition. >>> >> >> IMO sudorule is fine, I personally see it as an overarching plugin for sudo, >> sudocmds and sudocmdgroups are just part of the sudorule. >> >> We may just want to somehow differentiate the non--type ACIs from the regular >> --type ones. Whether it is a different attribute in the Object or a setting in >> managed permission is something I will leave up to you. > > I went with a "non_object" key in the managed permission info. > > Attaching new patches. This looks good to me, ACK. Martin From mkosek at redhat.com Wed Apr 9 08:31:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 10:31:58 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects In-Reply-To: <53441367.7050301@redhat.com> References: <533D3360.7080106@redhat.com> <53428C3A.1000003@redhat.com> <5343BB55.9000800@redhat.com> <5343D36F.7040401@redhat.com> <53441367.7050301@redhat.com> Message-ID: <5345057E.1010402@redhat.com> On 04/08/2014 05:19 PM, Petr Viktorin wrote: > On 04/08/2014 12:46 PM, Martin Kosek wrote: >> On 04/08/2014 11:03 AM, Petr Viktorin wrote: >>> On 04/07/2014 01:30 PM, Martin Kosek wrote: >>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> This adds read permissions to read Sudo commands, command groups, rules. >>>>> >>>>> Read access is given to all authenticated users. >>>> >>>> Looks good. What about "ou=sudoers"? I think we should also allow it in this >>>> patch for authenticated users. This is the tree that clients use to read sudo. >>> >>> This new version does that. It needs my patches 0508-0509 since the ou=sudoers >>> permission is not tied to a specific Object plugin. >>> >> >> I would also allow 'ou', otherwise an authenticated user cannot read the >> ou=sudoers RDN. I will comment on NONOBJECT_PERMISSIONS in the other thread. > > Right, I wonder how I missed that. > > New patch attached; it needs 0508-0509.2. > Sorry for not spotting it earlier, but shouldn't we also add "sudoRunAs" attribute? It is part of sudoRole objectclass: objectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' DESC 'Sudoer Entries' SUP top STRUCTURAL MUST cn MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRun As $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAft er $ sudoOrder $ description ) X-ORIGIN 'SUDO' ) but we seem to not generate it in our compat plugin though. But as it is part of the objectclass, I would rather add it to avoid any mistakes. If you add it, it's an ACK from me. Martin From mkosek at redhat.com Wed Apr 9 08:53:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 10:53:39 +0200 Subject: [Freeipa-devel] [PATCHES] 0510-0511 Add managed read permissions to group & hostgroup In-Reply-To: <5343EAC2.6030409@redhat.com> References: <5343EAC2.6030409@redhat.com> Message-ID: <53450A93.7090803@redhat.com> On 04/08/2014 02:25 PM, Petr Viktorin wrote: > Hello, > These add read permissions to read user groups and hostgroups. > > For most attributes, anonymous read access is given. > For member, memberOf, memberUID, read access is given only to authenticated users. Didn't we agree that we want to make hostgroups read by authenticated users only? Just like we did with netgroups. CCing Simo to confirm. Besides the default bind type, the ACI looked ok. Martin From mkosek at redhat.com Wed Apr 9 08:59:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 10:59:42 +0200 Subject: [Freeipa-devel] [PATCH] 0505 Default read ACIs for HBAC objects In-Reply-To: <53428D2C.4070601@redhat.com> References: <533D3362.3060208@redhat.com> <53428BC0.40004@redhat.com> <53428D2C.4070601@redhat.com> Message-ID: <53450BFE.1070106@redhat.com> On 04/07/2014 01:34 PM, Petr Viktorin wrote: > On 04/07/2014 01:28 PM, Martin Kosek wrote: >> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>> Hello, >>> This adds read permissions to read HBAC rules, services, and service groups. >>> >>> Read access is given to all authenticated users. >> >> So far looked OK in my tests. What about the ACIs like the following one? >> >> (targetattr = "*")(version 3.0; acl "No anonymous access to hbac"; deny >> (read,search,compare) userdn != "ldap:///all";) >> >> Do we want to remove them together with this patch to have the change grouped >> together with allow ACIs or do you plan to remove all similar deny ACIs at >> once? (together with the master read ACI) >> >> Martin >> > > I want to remove them after removing the global read ACI, so that in the mean > time we're not allowing more access than we should. Ok, makes sense. I tested the patch again and it worked fine (after I removed the deny rule). ACK. Martin From tbabej at redhat.com Wed Apr 9 10:07:31 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 09 Apr 2014 12:07:31 +0200 Subject: [Freeipa-devel] Ipatests fixes Message-ID: <53451BE3.2070406@redhat.com> Hi, the following batch deals with the following: * cleans up apache's semaphores prior to installing IPA (CA install can get stuck when IPA is reinstalled many times) * allows to pass extra arguments to install_client task * uses trailing dot in the hostname as fqdn which should not be overridden by domain name * fixes incorrect assert for UIDs/GIDs in legacy client tests -- 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-0168-ipatests-Fix-apache-semaphores-prior-to-installing-I.patch Type: text/x-patch Size: 1605 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0169-ipatests-tasks-Accept-extra-arguments-when-installin.patch Type: text/x-patch Size: 1297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0170-ipatests-Allow-using-FQDN-with-trailing-dot-as-final.patch Type: text/x-patch Size: 1548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0171-ipatests-Fix-incorrect-UID-GID-reference-for-subdoma.patch Type: text/x-patch Size: 2294 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 9 10:20:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 12:20:52 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] document that wildcards are not supported in FreeIPA <= 3.2 In-Reply-To: <1397032168.2318.5.camel@unused-4-145.brq.redhat.com> References: <1397032168.2318.5.camel@unused-4-145.brq.redhat.com> Message-ID: <53451F04.2090904@redhat.com> On 9.4.2014 10:29, Martin Basti wrote: > On Tue, 2014-04-08 at 21:19 -0600, Gabe Alford wrote: >> Hello, >> >> >> Not sure how relevant this patch is to the current documentation >> considering (I believe) that wildcards are supported in versions 3.3 >> and up. Patch for https://fedorahosted.org/freeipa/ticket/3616 > > Wildcards will be supported from version 4.0 . > Curently are not supported in 3.x. I have modified version in the text & also changed to . IMHO it is not important enough, it is just one of limitations. Gabe, are you okay with that? -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0013-2-DOC-wildcards-are-not-supported-in-IPA-3.patch Type: text/x-patch Size: 976 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 9 10:25:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 12:25:15 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <533D3364.1010606@redhat.com> References: <533D3364.1010606@redhat.com> Message-ID: <5345200B.1010802@redhat.com> On 04/03/2014 12:09 PM, Petr Viktorin wrote: > Hello, > This adds read permissions to read hosts. > > Read access is given to all authenticated users. > For reading host membership info, there is a separate permission that also > defaults to all authenticated users. > > The userPassword attribute is not included for obvious reasons. 1) We decided to show hosts only to authenticated users by default. I am just thinking - should some portion of hosts be readable just like groups and users are? For example at least the host core defined by nsHost objectlass? objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) Are application supposed to be able to anonymously read that information? 2) Do we want to count enrolledBy and managedBy attribute to "System: Read Host Membership" permission or should it be included in the "Read Hosts" permission? If we want to stick with previous behavior, we would want to have only "memberOf" listed as this is how our original member handling ACI looks like: install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost || memberUser")(version 3.0; acl "No anonymous access to member information"; deny (read,search,compare) userdn != "ldap:///all"; 3) I could not functionally test if e.g. clients and replicas still enroll as we do not have an ACI for krbtpolicy/krbRealmContainer yet and ipa-client-install searches for it. Speaking of which, we will need to have an ACI for reading a portion of krbRealmContainer anonymously to enable IPA client autodiscovery (cn+objectclass should be sufficient). We can wait with the functional testing until you get to krbRealmContainer though. Martin From pspacek at redhat.com Wed Apr 9 10:49:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 12:49:48 +0200 Subject: [Freeipa-devel] [PATCH 0231] Fix record parsing to prevent child zone corruption In-Reply-To: <5344FEDB.1020109@redhat.com> References: <533B0576.2090409@redhat.com> <5344FEDB.1020109@redhat.com> Message-ID: <534525CC.4040306@redhat.com> On 9.4.2014 10:03, Tomas Hozza wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/01/2014 08:29 PM, Petr Spacek wrote: >> Hello, >> >> Fix record parsing to prevent child zone corruption. >> >> Child zone hosted on the same server as parent zone was >> corrupted by bug in update_record(). >> Child zone's apex was modified by update_records() >> instead of delegation records in the parent zone. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/134 >> > > ACK > > Solves the problem described in the ticket. Pushed to master: 5fe2ca4bb88376849996fc40fe9eecf6af09417e -- Petr^2 Spacek From pspacek at redhat.com Wed Apr 9 10:49:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 12:49:49 +0200 Subject: [Freeipa-devel] [PATCH 0232-0233] Bump NVR to 4.2 Message-ID: <534525CD.1050408@redhat.com> Hello, Add bind-lite-devel to BuildRequires. Pushed to master: 0a3160bd3a4195429d082d7d48ffa596212c4b82 Bump NVR to 4.2. Pushed to master: 2568801743900684e00cc466deef1c5919d3480f -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0232-Add-bind-lite-devel-to-BuildRequires.patch Type: text/x-patch Size: 1213 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0233-Bump-NVR-to-4.2.patch Type: text/x-patch Size: 1193 bytes Desc: not available URL: From massimiliano.perrone at tirasa.net Wed Apr 9 11:30:15 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Wed, 09 Apr 2014 13:30:15 +0200 Subject: [Freeipa-devel] User status Message-ID: <53452F47.4050003@tirasa.net> Hi guys, is there any way to check the user status on ldap server? Thanks and regards, Massi -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From pviktori at redhat.com Wed Apr 9 11:33:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 13:33:09 +0200 Subject: [Freeipa-devel] Ipatests fixes In-Reply-To: <53451BE3.2070406@redhat.com> References: <53451BE3.2070406@redhat.com> Message-ID: <53452FF5.1080601@redhat.com> On 04/09/2014 12:07 PM, Tomas Babej wrote: > Hi, > > the following batch deals with the following: > > * cleans up apache's semaphores prior to installing IPA (CA install can > get stuck when IPA is reinstalled many times) What happens if Apache is running for some reason? Should we also stop it before deleting the semaphores? > * allows to pass extra arguments to install_client task Please avoid mutable argument defaults; use `extra_args=()` and then `list(extra_args)` > * uses trailing dot in the hostname as fqdn which should not be > overridden by domain name ACK. > * fixes incorrect assert for UIDs/GIDs in legacy client tests ACK, this fixes a lot of failures (though not all of them yet). -- Petr? From pviktori at redhat.com Wed Apr 9 11:41:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 13:41:32 +0200 Subject: [Freeipa-devel] [PATCH] 0505 Default read ACIs for HBAC objects In-Reply-To: <53450BFE.1070106@redhat.com> References: <533D3362.3060208@redhat.com> <53428BC0.40004@redhat.com> <53428D2C.4070601@redhat.com> <53450BFE.1070106@redhat.com> Message-ID: <534531EC.6090800@redhat.com> On 04/09/2014 10:59 AM, Martin Kosek wrote: > On 04/07/2014 01:34 PM, Petr Viktorin wrote: >> On 04/07/2014 01:28 PM, Martin Kosek wrote: >>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>> Hello, >>>> This adds read permissions to read HBAC rules, services, and service groups. >>>> >>>> Read access is given to all authenticated users. >>> >>> So far looked OK in my tests. What about the ACIs like the following one? >>> >>> (targetattr = "*")(version 3.0; acl "No anonymous access to hbac"; deny >>> (read,search,compare) userdn != "ldap:///all";) >>> >>> Do we want to remove them together with this patch to have the change grouped >>> together with allow ACIs or do you plan to remove all similar deny ACIs at >>> once? (together with the master read ACI) >>> >>> Martin >>> >> >> I want to remove them after removing the global read ACI, so that in the mean >> time we're not allowing more access than we should. > > Ok, makes sense. I tested the patch again and it worked fine (after I removed > the deny rule). > > ACK. > > Martin > Thanks, pushed to master: 39327dbb75e92e4184bdda2dbd802cf349866861 -- Petr? From pviktori at redhat.com Wed Apr 9 11:41:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 13:41:51 +0200 Subject: [Freeipa-devel] [PATCHES] 0508-0509 Add support for "non-object" managed permissions In-Reply-To: <53450562.3020601@redhat.com> References: <5343BB5E.3030504@redhat.com> <5343D526.5040204@redhat.com> <5343D9FA.4080207@redhat.com> <53440A2E.5080104@redhat.com> <5344131A.4060001@redhat.com> <53450562.3020601@redhat.com> Message-ID: <534531FF.3010007@redhat.com> On 04/09/2014 10:31 AM, Martin Kosek wrote: > On 04/08/2014 05:17 PM, Petr Viktorin wrote: >> On 04/08/2014 04:39 PM, Martin Kosek wrote: >>> On 04/08/2014 01:14 PM, Petr Viktorin wrote: >>>> On 04/08/2014 12:53 PM, Martin Kosek wrote: >>>>> On 04/08/2014 11:03 AM, Petr Viktorin wrote: >>> ... >>>>> The patch is functional, but I am not really a big fan of placing it in the >>>>> plugin. I would prefer if the ACI definition is also in the sudo plugin >>>>> together with other definition. It would be then much easier to audit all >>>>> sudo-related ACIs. >>>>> >>>>> Why can't we add this ACI to sudorule object managed permissions and just >>>>> override the location and target? >>>> >>>> I can do that. Most of the changes make this overriding possible, where the >>>> permission is actually defined is a detail. >>>> >>>>> I am not insisting on a specific format, I would simply prefer to have all >>>>> plugin object related ACIs close together. >>>> >>>> My reasoning is that finding the definition would not be straightforward. All >>>> the object-specific permissions so far are defined in "their" plugins, as >>>> determined by --type. This one won't have --type, and it's not clear if it >>>> should be in sudorule, sudocmd or sudocmdgroup. >>>> >>>> But, I don't have a strong preference. A `git grep` will always show the >>>> definition. >>>> >>> >>> IMO sudorule is fine, I personally see it as an overarching plugin for sudo, >>> sudocmds and sudocmdgroups are just part of the sudorule. >>> >>> We may just want to somehow differentiate the non--type ACIs from the regular >>> --type ones. Whether it is a different attribute in the Object or a setting in >>> managed permission is something I will leave up to you. >> >> I went with a "non_object" key in the managed permission info. >> >> Attaching new patches. > > This looks good to me, ACK. > > Martin > Thanks, pushed to master: c58d6b2689acbfa36aec362b7de1ec7512d5f82a -- Petr? From amisnyov at redhat.com Wed Apr 9 11:43:46 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 9 Apr 2014 13:43:46 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <5344164D.30302@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> <5342570E.6040207@redhat.com> <20140408161749.64027b9a@unused-4-246.brq.redhat.com> <5344164D.30302@redhat.com> Message-ID: <20140409134346.73a82e2b@unused-4-246.brq.redhat.com> On Tue, 08 Apr 2014 17:31:25 +0200 Petr Viktorin wrote: > On 04/08/2014 04:17 PM, Misnyovszki Adam wrote: > > On Mon, 07 Apr 2014 09:43:10 +0200 > > Petr Viktorin wrote: > > > >> On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: > >>> On Wed, 26 Mar 2014 13:15:55 +0100 > >>> Petr Viktorin wrote: > >> [...] > >>>> > >>>> Looks great! I'm just concerned about the error returned when the > >>>> task takes too long: > >>>> $ ipa automember-rebuild --type group > >>>> ipa: ERROR: LDAP timeout > >>>> I don't think it's sufficiently clear from this that waiting for > >>>> the task timed out, but the task was actually started > >>>> successfully. A custom error with a more descriptive message > >>>> would be useful. > >>>> > >>>> > >>>> Also I've noticed that the "nstaskstatus" of a successful task > >>>> is: Automember rebuild task finished. Processed (1) entries. > >>>> This looks helpful; we could return it as the summary. > >>>> > >>> > >>> Hi, > >>> both fixed. > >>> Greets > >>> Adam > >>> > >> > >> Sorry for the delay! > >> 'Automember' is a translatable string, so please wrap it in _() > >> when raising TaskTimeout. Also please update the tests. > >> Otherwise with a little rebase it's good to go. > >> > >> > > > > Hi, > > see the attached modifications, tests corrected, and added for > > no-wait, also rebased for current master. > > Greets > > Adam > > > > Looks good overall, but why do you now set `self.msg_summary`? Keep > in mind that currently the same Command object is reused for every > automember_rebuild command, including commands that run in parallel > in different threads. It should never be modified. > Hi, corrected. Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0007-8-automember-rebuild-nowait-feature-added.patch Type: text/x-patch Size: 11982 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0008-3-plugin-registration-refactoring-for-automembership.patch Type: text/x-patch Size: 4977 bytes Desc: not available URL: From pviktori at redhat.com Wed Apr 9 11:45:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 13:45:53 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140409134346.73a82e2b@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> <5342570E.6040207@redhat.com> <20140408161749.64027b9a@unused-4-246.brq.redhat.com> <5344164D.30302@redhat.com> <20140409134346.73a82e2b@unused-4-246.brq.redhat.com> Message-ID: <534532F1.3000406@redhat.com> On 04/09/2014 01:43 PM, Misnyovszki Adam wrote: > On Tue, 08 Apr 2014 17:31:25 +0200 > Petr Viktorin wrote: > >> On 04/08/2014 04:17 PM, Misnyovszki Adam wrote: >>> On Mon, 07 Apr 2014 09:43:10 +0200 >>> Petr Viktorin wrote: >>> >>>> On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: >>>>> On Wed, 26 Mar 2014 13:15:55 +0100 >>>>> Petr Viktorin wrote: >>>> [...] >>>>>> >>>>>> Looks great! I'm just concerned about the error returned when the >>>>>> task takes too long: >>>>>> $ ipa automember-rebuild --type group >>>>>> ipa: ERROR: LDAP timeout >>>>>> I don't think it's sufficiently clear from this that waiting for >>>>>> the task timed out, but the task was actually started >>>>>> successfully. A custom error with a more descriptive message >>>>>> would be useful. >>>>>> >>>>>> >>>>>> Also I've noticed that the "nstaskstatus" of a successful task >>>>>> is: Automember rebuild task finished. Processed (1) entries. >>>>>> This looks helpful; we could return it as the summary. >>>>>> >>>>> >>>>> Hi, >>>>> both fixed. >>>>> Greets >>>>> Adam >>>>> >>>> >>>> Sorry for the delay! >>>> 'Automember' is a translatable string, so please wrap it in _() >>>> when raising TaskTimeout. Also please update the tests. >>>> Otherwise with a little rebase it's good to go. >>>> >>>> >>> >>> Hi, >>> see the attached modifications, tests corrected, and added for >>> no-wait, also rebased for current master. >>> Greets >>> Adam >>> >> >> Looks good overall, but why do you now set `self.msg_summary`? Keep >> in mind that currently the same Command object is reused for every >> automember_rebuild command, including commands that run in parallel >> in different threads. It should never be modified. >> > Hi, > corrected. > Greets > Adam > ACK Pushed to master: 3f61bbaef582ff42b151f2bb01f312a94a70632c -- Petr? From mkosek at redhat.com Wed Apr 9 12:01:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 14:01:07 +0200 Subject: [Freeipa-devel] User status In-Reply-To: <53452F47.4050003@tirasa.net> References: <53452F47.4050003@tirasa.net> Message-ID: <53453683.8090501@redhat.com> On 04/09/2014 01:30 PM, Massimiliano Perrone (tirasa.net) wrote: > Hi guys, > is there any way to check the user status on ldap server? > > Thanks and regards, > > Massi > Hello, It depends what you mean by status. We have a command to get a lock/auth status of a user with user-status command: # ipa user-status fbar ----------------------- Account disabled: False ----------------------- Server: ipa.example.com Failed logins: 0 Last successful authentication: 2014-04-09T12:00:39Z Last failed authentication: N/A Time now: 2014-04-09T12:00:42Z ---------------------------- Number of entries returned 1 ---------------------------- Martin From pspacek at redhat.com Wed Apr 9 12:07:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 14:07:10 +0200 Subject: [Freeipa-devel] [PATCH 0234] Prevent NULL dereference before sync_concurr_limit_signal() calls Message-ID: <534537EE.9070101@redhat.com> Hello, Prevent NULL dereference before sync_concurr_limit_signal() calls. Missing check was causing NULL dereference in case where manager_get_ldap_instance() failed. This typically happens when BIND is processing LDAP updates during shutdown. I noticed this crash during sanity testing 4.2 release... Please review it ASAP so I can release 4.3. How to reproduce the problem: Run BIND manually from console: $ named -4 -g -u named -m record -n 10 and press Ctrl+C "almost immediately". Sometimes it shutdowns cleanly and sometimes you can see a crash: Thank you for your time! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0234-Prevent-NULL-dereference-before-sync_concurr_limit_s.patch Type: text/x-patch Size: 2104 bytes Desc: not available URL: From massimiliano.perrone at tirasa.net Wed Apr 9 12:37:09 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Wed, 09 Apr 2014 14:37:09 +0200 Subject: [Freeipa-devel] User status In-Reply-To: <53453683.8090501@redhat.com> References: <53452F47.4050003@tirasa.net> <53453683.8090501@redhat.com> Message-ID: <53453EF5.8080707@tirasa.net> On 04/09/2014 02:01 PM, Martin Kosek wrote: > On 04/09/2014 01:30 PM, Massimiliano Perrone (tirasa.net) wrote: >> Hi guys, >> is there any way to check the user status on ldap server? >> >> Thanks and regards, >> >> Massi >> > Hello, > > It depends what you mean by status. We have a command to get a lock/auth status > of a user with user-status command: > > # ipa user-status fbar > ----------------------- > Account disabled: False > ----------------------- > Server: ipa.example.com > Failed logins: 0 > Last successful authentication: 2014-04-09T12:00:39Z > Last failed authentication: N/A > Time now: 2014-04-09T12:00:42Z > ---------------------------- > Number of entries returned 1 > ---------------------------- > > Martin Hi Martin, thanks for your quick reply and I'm sorry to have been unclear. For user status I mean only the value of "Account disabled" label pasted above. And if that value is also saved on as ldap server attribute. Massi -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From mkosek at redhat.com Wed Apr 9 12:40:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 14:40:51 +0200 Subject: [Freeipa-devel] User status In-Reply-To: <53453EF5.8080707@tirasa.net> References: <53452F47.4050003@tirasa.net> <53453683.8090501@redhat.com> <53453EF5.8080707@tirasa.net> Message-ID: <53453FD3.3040300@redhat.com> On 04/09/2014 02:37 PM, Massimiliano Perrone (tirasa.net) wrote: > On 04/09/2014 02:01 PM, Martin Kosek wrote: >> On 04/09/2014 01:30 PM, Massimiliano Perrone (tirasa.net) wrote: >>> Hi guys, >>> is there any way to check the user status on ldap server? >>> >>> Thanks and regards, >>> >>> Massi >>> >> Hello, >> >> It depends what you mean by status. We have a command to get a lock/auth status >> of a user with user-status command: >> >> # ipa user-status fbar >> ----------------------- >> Account disabled: False >> ----------------------- >> Server: ipa.example.com >> Failed logins: 0 >> Last successful authentication: 2014-04-09T12:00:39Z >> Last failed authentication: N/A >> Time now: 2014-04-09T12:00:42Z >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> Martin > > Hi Martin, > thanks for your quick reply and I'm sorry to have been unclear. > > For user status I mean only the value of "Account disabled" label pasted above. > And if that value is also saved on as ldap server attribute. > > Massi > You can either see nsaccountlock attribute in user entry in LDAP or a return value from FreeIPA API: # ipa user-disable fbar ---------------------------- Disabled user account "fbar" ---------------------------- # ipa user-show fbar ... Account disabled: True ... Martin From pviktori at redhat.com Wed Apr 9 12:53:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 14:53:34 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <534532F1.3000406@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> <5342570E.6040207@redhat.com> <20140408161749.64027b9a@unused-4-246.brq.redhat.com> <5344164D.30302@redhat.com> <20140409134346.73a82e2b@unused-4-246.brq.redhat.com> <534532F1.3000406@redhat.com> Message-ID: <534542CE.6000909@redhat.com> On 04/09/2014 01:45 PM, Petr Viktorin wrote: > On 04/09/2014 01:43 PM, Misnyovszki Adam wrote: >> On Tue, 08 Apr 2014 17:31:25 +0200 >> Petr Viktorin wrote: >> >>> On 04/08/2014 04:17 PM, Misnyovszki Adam wrote: >>>> On Mon, 07 Apr 2014 09:43:10 +0200 >>>> Petr Viktorin wrote: >>>> >>>>> On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: >>>>>> On Wed, 26 Mar 2014 13:15:55 +0100 >>>>>> Petr Viktorin wrote: >>>>> [...] >>>>>>> >>>>>>> Looks great! I'm just concerned about the error returned when the >>>>>>> task takes too long: >>>>>>> $ ipa automember-rebuild --type group >>>>>>> ipa: ERROR: LDAP timeout >>>>>>> I don't think it's sufficiently clear from this that waiting for >>>>>>> the task timed out, but the task was actually started >>>>>>> successfully. A custom error with a more descriptive message >>>>>>> would be useful. >>>>>>> >>>>>>> >>>>>>> Also I've noticed that the "nstaskstatus" of a successful task >>>>>>> is: Automember rebuild task finished. Processed (1) entries. >>>>>>> This looks helpful; we could return it as the summary. >>>>>>> >>>>>> >>>>>> Hi, >>>>>> both fixed. >>>>>> Greets >>>>>> Adam >>>>>> >>>>> >>>>> Sorry for the delay! >>>>> 'Automember' is a translatable string, so please wrap it in _() >>>>> when raising TaskTimeout. Also please update the tests. >>>>> Otherwise with a little rebase it's good to go. >>>>> >>>>> >>>> >>>> Hi, >>>> see the attached modifications, tests corrected, and added for >>>> no-wait, also rebased for current master. >>>> Greets >>>> Adam >>>> >>> >>> Looks good overall, but why do you now set `self.msg_summary`? Keep >>> in mind that currently the same Command object is reused for every >>> automember_rebuild command, including commands that run in parallel >>> in different threads. It should never be modified. >>> >> Hi, >> corrected. >> Greets >> Adam >> > > ACK > Pushed to master: 3f61bbaef582ff42b151f2bb01f312a94a70632c > I spoke too soon. There is one more doctest failure. This patch should fix it, can you review? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0511-ipalib.errors-Fix-TaskTimeout-doctest.patch Type: text/x-patch Size: 762 bytes Desc: not available URL: From redhatrises at gmail.com Wed Apr 9 12:58:19 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 9 Apr 2014 06:58:19 -0600 Subject: [Freeipa-devel] [PATCH] [DOC] document that wildcards are not supported in FreeIPA <= 3.2 In-Reply-To: <53451F04.2090904@redhat.com> References: <1397032168.2318.5.camel@unused-4-145.brq.redhat.com> <53451F04.2090904@redhat.com> Message-ID: I am good with it. Gabe On Wed, Apr 9, 2014 at 4:20 AM, Petr Spacek wrote: > On 9.4.2014 10:29, Martin Basti wrote: > >> On Tue, 2014-04-08 at 21:19 -0600, Gabe Alford wrote: >> >>> Hello, >>> >>> >>> Not sure how relevant this patch is to the current documentation >>> considering (I believe) that wildcards are supported in versions 3.3 >>> and up. Patch for https://fedorahosted.org/freeipa/ticket/3616 >>> >> >> Wildcards will be supported from version 4.0 . >> Curently are not supported in 3.x. >> > > I have modified version in the text & also changed to . > > IMHO it is not important enough, it is just one of limitations. > > Gabe, are you okay with that? > > -- > Petr^2 Spacek > > _______________________________________________ > 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 ssorce at redhat.com Wed Apr 9 13:04:37 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2014 09:04:37 -0400 Subject: [Freeipa-devel] [PATCHES] 0510-0511 Add managed read permissions to group & hostgroup In-Reply-To: <53450A93.7090803@redhat.com> References: <5343EAC2.6030409@redhat.com> <53450A93.7090803@redhat.com> Message-ID: <1397048677.19767.23.camel@willson.li.ssimo.org> On Wed, 2014-04-09 at 10:53 +0200, Martin Kosek wrote: > On 04/08/2014 02:25 PM, Petr Viktorin wrote: > > Hello, > > These add read permissions to read user groups and hostgroups. > > > > For most attributes, anonymous read access is given. > > For member, memberOf, memberUID, read access is given only to authenticated users. > > Didn't we agree that we want to make hostgroups read by authenticated users > only? Just like we did with netgroups. CCing Simo to confirm. > > Besides the default bind type, the ACI looked ok. I forgot if we decided anything about hostgroups, but they are not necessary for an anonymous reader so we may as well not server them in that case. Simo. From massimiliano.perrone at tirasa.net Wed Apr 9 13:15:17 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Wed, 09 Apr 2014 15:15:17 +0200 Subject: [Freeipa-devel] User status In-Reply-To: <53453FD3.3040300@redhat.com> References: <53452F47.4050003@tirasa.net> <53453683.8090501@redhat.com> <53453EF5.8080707@tirasa.net> <53453FD3.3040300@redhat.com> Message-ID: <534547E5.7060803@tirasa.net> On 04/09/2014 02:40 PM, Martin Kosek wrote: > On 04/09/2014 02:37 PM, Massimiliano Perrone (tirasa.net) wrote: >> On 04/09/2014 02:01 PM, Martin Kosek wrote: >>> On 04/09/2014 01:30 PM, Massimiliano Perrone (tirasa.net) wrote: >>>> Hi guys, >>>> is there any way to check the user status on ldap server? >>>> >>>> Thanks and regards, >>>> >>>> Massi >>>> >>> Hello, >>> >>> It depends what you mean by status. We have a command to get a lock/auth status >>> of a user with user-status command: >>> >>> # ipa user-status fbar >>> ----------------------- >>> Account disabled: False >>> ----------------------- >>> Server: ipa.example.com >>> Failed logins: 0 >>> Last successful authentication: 2014-04-09T12:00:39Z >>> Last failed authentication: N/A >>> Time now: 2014-04-09T12:00:42Z >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> Martin >> Hi Martin, >> thanks for your quick reply and I'm sorry to have been unclear. >> >> For user status I mean only the value of "Account disabled" label pasted above. >> And if that value is also saved on as ldap server attribute. >> >> Massi >> > You can either see nsaccountlock attribute in user entry in LDAP or a return > value from FreeIPA API: > > # ipa user-disable fbar > ---------------------------- > Disabled user account "fbar" > ---------------------------- > # ipa user-show fbar > ... > Account disabled: True > ... > > Martin Perfect Martin. From ldap point of view: a user is enabled when nsaccountlock is FALSE or is not present, whereas a user is disabled when nsaccountlock attribute is set to TRUE. Thanks, Massi -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From mkosek at redhat.com Wed Apr 9 13:17:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 15:17:48 +0200 Subject: [Freeipa-devel] User status In-Reply-To: <534547E5.7060803@tirasa.net> References: <53452F47.4050003@tirasa.net> <53453683.8090501@redhat.com> <53453EF5.8080707@tirasa.net> <53453FD3.3040300@redhat.com> <534547E5.7060803@tirasa.net> Message-ID: <5345487C.1090405@redhat.com> On 04/09/2014 03:15 PM, Massimiliano Perrone (tirasa.net) wrote: > On 04/09/2014 02:40 PM, Martin Kosek wrote: >> On 04/09/2014 02:37 PM, Massimiliano Perrone (tirasa.net) wrote: >>> On 04/09/2014 02:01 PM, Martin Kosek wrote: >>>> On 04/09/2014 01:30 PM, Massimiliano Perrone (tirasa.net) wrote: >>>>> Hi guys, >>>>> is there any way to check the user status on ldap server? >>>>> >>>>> Thanks and regards, >>>>> >>>>> Massi >>>>> >>>> Hello, >>>> >>>> It depends what you mean by status. We have a command to get a lock/auth >>>> status >>>> of a user with user-status command: >>>> >>>> # ipa user-status fbar >>>> ----------------------- >>>> Account disabled: False >>>> ----------------------- >>>> Server: ipa.example.com >>>> Failed logins: 0 >>>> Last successful authentication: 2014-04-09T12:00:39Z >>>> Last failed authentication: N/A >>>> Time now: 2014-04-09T12:00:42Z >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> Martin >>> Hi Martin, >>> thanks for your quick reply and I'm sorry to have been unclear. >>> >>> For user status I mean only the value of "Account disabled" label pasted above. >>> And if that value is also saved on as ldap server attribute. >>> >>> Massi >>> >> You can either see nsaccountlock attribute in user entry in LDAP or a return >> value from FreeIPA API: >> >> # ipa user-disable fbar >> ---------------------------- >> Disabled user account "fbar" >> ---------------------------- >> # ipa user-show fbar >> ... >> Account disabled: True >> ... >> >> Martin > > Perfect Martin. > > From ldap point of view: a user is enabled when nsaccountlock is FALSE or is > not present, whereas a user is disabled when nsaccountlock attribute is set to > TRUE. > > Thanks, > Massi > Exactly. Note that nsaccountlock is an LDAP operational attribute and you will need to explicitly specify it in your LDAP search to retrieve it. Martin From thozza at redhat.com Wed Apr 9 13:20:37 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 09 Apr 2014 15:20:37 +0200 Subject: [Freeipa-devel] [PATCH 0234] Prevent NULL dereference before sync_concurr_limit_signal() calls In-Reply-To: <534537EE.9070101@redhat.com> References: <534537EE.9070101@redhat.com> Message-ID: <53454925.3020800@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/09/2014 02:07 PM, Petr Spacek wrote: > Hello, > > Prevent NULL dereference before sync_concurr_limit_signal() calls. > > Missing check was causing NULL dereference in case where > manager_get_ldap_instance() failed. This typically happens when BIND > is processing LDAP updates during shutdown. > > I noticed this crash during sanity testing 4.2 release... > > Please review it ASAP so I can release 4.3. > > How to reproduce the problem: > Run BIND manually from console: > $ named -4 -g -u named -m record -n 10 > and press Ctrl+C "almost immediately". > > Sometimes it shutdowns cleanly and sometimes you can see a crash: > > Thank you for your time! > ACK. I'm not able to reproduce the issue, but the patch looks reasonable and should not break anything. Regards, Tomas Hozza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRUklAAoJEMWIetUdnzwtSSoH/0ZIz+MZfZ1O9JH5kGvJQKQo 3s1Fqeh601ReRKGnFu+nBt5hXzGzDOjsXM0x8bJH5r1cABn9XzYjupVQg0FjziM1 XIoJaDRB8L09sjLefjPoY87x0K6OsEQ/EmipDZPQB62MPpWJdGkJi6u2ug2gguRN fEdMeFdvm6T8faU/POd1D/1mEky2DqzNXViLf+6Pdi03b6lvUzoOvqsLwh4+Npvw NVUw7+SzwylCJQBcmZShCL6XRnaN4Qe9LCUG997HNwF/n3K1NjUgbwVqqmdLPGXh XAtcQxic5TQkKl2A1+52YFLMLSLY5gfAg/qBYmT1BQM+IuUIUYOe7fXL0fxr+A0= =TNAe -----END PGP SIGNATURE----- From amisnyov at redhat.com Wed Apr 9 13:21:54 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 9 Apr 2014 15:21:54 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <534542CE.6000909@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> <5342570E.6040207@redhat.com> <20140408161749.64027b9a@unused-4-246.brq.redhat.com> <5344164D.30302@redhat.com> <20140409134346.73a82e2b@unused-4-246.brq.redhat.com> <534532F1.3000406@redhat.com> <534542CE.6000909@redhat.com> Message-ID: <20140409152154.38f890dc@unused-4-246.brq.redhat.com> On Wed, 09 Apr 2014 14:53:34 +0200 Petr Viktorin wrote: > On 04/09/2014 01:45 PM, Petr Viktorin wrote: > > On 04/09/2014 01:43 PM, Misnyovszki Adam wrote: > >> On Tue, 08 Apr 2014 17:31:25 +0200 > >> Petr Viktorin wrote: > >> > >>> On 04/08/2014 04:17 PM, Misnyovszki Adam wrote: > >>>> On Mon, 07 Apr 2014 09:43:10 +0200 > >>>> Petr Viktorin wrote: > >>>> > >>>>> On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: > >>>>>> On Wed, 26 Mar 2014 13:15:55 +0100 > >>>>>> Petr Viktorin wrote: > >>>>> [...] > >>>>>>> > >>>>>>> Looks great! I'm just concerned about the error returned when > >>>>>>> the task takes too long: > >>>>>>> $ ipa automember-rebuild --type group > >>>>>>> ipa: ERROR: LDAP timeout > >>>>>>> I don't think it's sufficiently clear from this that waiting > >>>>>>> for the task timed out, but the task was actually started > >>>>>>> successfully. A custom error with a more descriptive message > >>>>>>> would be useful. > >>>>>>> > >>>>>>> > >>>>>>> Also I've noticed that the "nstaskstatus" of a successful task > >>>>>>> is: Automember rebuild task finished. Processed (1) entries. > >>>>>>> This looks helpful; we could return it as the summary. > >>>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> both fixed. > >>>>>> Greets > >>>>>> Adam > >>>>>> > >>>>> > >>>>> Sorry for the delay! > >>>>> 'Automember' is a translatable string, so please wrap it in _() > >>>>> when raising TaskTimeout. Also please update the tests. > >>>>> Otherwise with a little rebase it's good to go. > >>>>> > >>>>> > >>>> > >>>> Hi, > >>>> see the attached modifications, tests corrected, and added for > >>>> no-wait, also rebased for current master. > >>>> Greets > >>>> Adam > >>>> > >>> > >>> Looks good overall, but why do you now set `self.msg_summary`? > >>> Keep in mind that currently the same Command object is reused for > >>> every automember_rebuild command, including commands that run in > >>> parallel in different threads. It should never be modified. > >>> > >> Hi, > >> corrected. > >> Greets > >> Adam > >> > > > > ACK > > Pushed to master: 3f61bbaef582ff42b151f2bb01f312a94a70632c > > > > I spoke too soon. There is one more doctest failure. This patch > should fix it, can you review? > works for me, thanks! Adam From pviktori at redhat.com Wed Apr 9 13:25:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 15:25:02 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140409152154.38f890dc@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> <5342570E.6040207@redhat.com> <20140408161749.64027b9a@unused-4-246.brq.redhat.com> <5344164D.30302@redhat.com> <20140409134346.73a82e2b@unused-4-246.brq.redhat.com> <534532F1.3000406@redhat.com> <534542CE.6000909@redhat.com> <20140409152154.38f890dc@unused-4-246.brq.redhat.com> Message-ID: <53454A2E.8040409@redhat.com> On 04/09/2014 03:21 PM, Misnyovszki Adam wrote: > On Wed, 09 Apr 2014 14:53:34 +0200 > Petr Viktorin wrote: > >> On 04/09/2014 01:45 PM, Petr Viktorin wrote: >>> On 04/09/2014 01:43 PM, Misnyovszki Adam wrote: >>>> On Tue, 08 Apr 2014 17:31:25 +0200 >>>> Petr Viktorin wrote: >>>> >>>>> On 04/08/2014 04:17 PM, Misnyovszki Adam wrote: >>>>>> On Mon, 07 Apr 2014 09:43:10 +0200 >>>>>> Petr Viktorin wrote: >>>>>> >>>>>>> On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: >>>>>>>> On Wed, 26 Mar 2014 13:15:55 +0100 >>>>>>>> Petr Viktorin wrote: >>>>>>> [...] >>>>>>>>> >>>>>>>>> Looks great! I'm just concerned about the error returned when >>>>>>>>> the task takes too long: >>>>>>>>> $ ipa automember-rebuild --type group >>>>>>>>> ipa: ERROR: LDAP timeout >>>>>>>>> I don't think it's sufficiently clear from this that waiting >>>>>>>>> for the task timed out, but the task was actually started >>>>>>>>> successfully. A custom error with a more descriptive message >>>>>>>>> would be useful. >>>>>>>>> >>>>>>>>> >>>>>>>>> Also I've noticed that the "nstaskstatus" of a successful task >>>>>>>>> is: Automember rebuild task finished. Processed (1) entries. >>>>>>>>> This looks helpful; we could return it as the summary. >>>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> both fixed. >>>>>>>> Greets >>>>>>>> Adam >>>>>>>> >>>>>>> >>>>>>> Sorry for the delay! >>>>>>> 'Automember' is a translatable string, so please wrap it in _() >>>>>>> when raising TaskTimeout. Also please update the tests. >>>>>>> Otherwise with a little rebase it's good to go. >>>>>>> >>>>>>> >>>>>> >>>>>> Hi, >>>>>> see the attached modifications, tests corrected, and added for >>>>>> no-wait, also rebased for current master. >>>>>> Greets >>>>>> Adam >>>>>> >>>>> >>>>> Looks good overall, but why do you now set `self.msg_summary`? >>>>> Keep in mind that currently the same Command object is reused for >>>>> every automember_rebuild command, including commands that run in >>>>> parallel in different threads. It should never be modified. >>>>> >>>> Hi, >>>> corrected. >>>> Greets >>>> Adam >>>> >>> >>> ACK >>> Pushed to master: 3f61bbaef582ff42b151f2bb01f312a94a70632c >>> >> >> I spoke too soon. There is one more doctest failure. This patch >> should fix it, can you review? >> > > works for me, thanks! > Adam > Thanks, pushed to master: 22f0feba280824850ba3074b3fb44a36aff7fbf0 -- Petr? From mkosek at redhat.com Wed Apr 9 13:26:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 15:26:45 +0200 Subject: [Freeipa-devel] [PATCHES] 0510-0511 Add managed read permissions to group & hostgroup In-Reply-To: <1397048677.19767.23.camel@willson.li.ssimo.org> References: <5343EAC2.6030409@redhat.com> <53450A93.7090803@redhat.com> <1397048677.19767.23.camel@willson.li.ssimo.org> Message-ID: <53454A95.1040606@redhat.com> On 04/09/2014 03:04 PM, Simo Sorce wrote: > On Wed, 2014-04-09 at 10:53 +0200, Martin Kosek wrote: >> On 04/08/2014 02:25 PM, Petr Viktorin wrote: >>> Hello, >>> These add read permissions to read user groups and hostgroups. >>> >>> For most attributes, anonymous read access is given. >>> For member, memberOf, memberUID, read access is given only to authenticated users. >> >> Didn't we agree that we want to make hostgroups read by authenticated users >> only? Just like we did with netgroups. CCing Simo to confirm. >> >> Besides the default bind type, the ACI looked ok. > > I forgot if we decided anything about hostgroups, but they are not > necessary for an anonymous reader so we may as well not server them in > that case. > > Simo. > In that case Petr please consider changing 511 to only allow authenticated users to read hostgroups. Thanks, Martin From lkrispen at redhat.com Wed Apr 9 13:50:51 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 09 Apr 2014 15:50:51 +0200 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1396996313.19767.15.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> <5343C8C5.8020708@redhat.com> <1396996313.19767.15.camel@willson.li.ssimo.org> Message-ID: <5345503B.8030302@redhat.com> On 04/09/2014 12:31 AM, Simo Sorce wrote: > On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote: >> Replication storms. In my opinion the replication of a mod of one or >> two attribute in a entry will be faster than the bind itself. > Think about the amplification effect in an environment with 20 replicas. > 1 login attempt -> 20+ replication messages > > Now think about what happen bandwidth wise when a few thousand people > all authenticate at the same time across the infrastructure, you deploy > more servers to scale better and you get *more* traffic, at some point > servers actually get slower as they are busy with replication related > operations. > > Think what happen if one of these servers is in a satellite office on a > relatively slow link and every morning it receives a flooding of > replication data ... that is 99% useless because most of tat data is not > relevant in that office. ok, lets leave it with that, there might be scenarios where it becomes unacceptable and as long as we have an acceptable solution we need not enforce full replication > >> If an attacker knows all the dns of the entries in a server the >> denial of service could be that it just does a sequence of failed >> logins for any user and nobody will be able to login any more, > This is perfectly true which is why we do not permanently lockout users > by default and which is why I personally dislike lockouts. A much better > mechanism to deal with brute force attacks is throttling, but it is also > somewhat harder to implement as you need to either have an async model > to delay answers or you need to tie threads for the delay time. > Still a far superior measure than replicating status around at all > times. yes, that could be a good solution, but not trivial > >> replication would help to propagate this to other servers, but not >> prevent it. This would also be the case if only the final lockout >> state is replicated. > Yes but the amount of replicated information would be far less. With our > default 1/5th less on average as 5 is the number of failed attempts > before the final lockout kicks in. So you save a lot of bandwidth. > >> I like the idea of replicating the attributes changed at failed logins >> (or reset) only. > I think this is reasonable indeed, the common case is that users tend to > get their password right, and if you are under a password guessing > attack you should stop it. The issue is though that sometimes you have > misconfigured services with bad keytabs that will try over and over > again to init, even if the account is locked, or maybe (even worse) they > try a number of bad keys, but lower than the failed count, before > getting to the right one (thus resetting the failed count). If they do > this often you can still self-DoS even without a malicious attacker :-/ > > Something like this is what we have experienced for real and cause us to > actually disable replication of all the lockout related attributes in > the past. But also here it can get complicated, we cannot really use failedlogincount and replicate it, eg if it is "2" on each server an their are parallel login attempts, we would increment it to "3" and replicate, so we would have 3 on all servers, not what we wanted. We could replicate changes to lastfailedauth and when receiving an update for this attribute locally increase failedcount, but it would also have to be used for resets (deleting lastFailedAuth), but there could also be race conditions, maybe there are other local attrs needed. And the bad news: I claimed that the replication protocol ensures that the last change wins except for bugs, and looks like we have one bug for single valued attributes in some scenarios. I have to repeat the test to double check. The update resolution code for single valued attrs is a nightmare, Rich and I several times said we need to rewrite it :-( PS: Martin, if you are looking for subjects for a thesis, maybe some theoretical model for replication update resolution and what is required history could be a challenge. > > Simo. > From pviktori at redhat.com Wed Apr 9 13:56:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 15:56:34 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects In-Reply-To: <5345057E.1010402@redhat.com> References: <533D3360.7080106@redhat.com> <53428C3A.1000003@redhat.com> <5343BB55.9000800@redhat.com> <5343D36F.7040401@redhat.com> <53441367.7050301@redhat.com> <5345057E.1010402@redhat.com> Message-ID: <53455192.8020102@redhat.com> On 04/09/2014 10:31 AM, Martin Kosek wrote: > On 04/08/2014 05:19 PM, Petr Viktorin wrote: >> On 04/08/2014 12:46 PM, Martin Kosek wrote: >>> On 04/08/2014 11:03 AM, Petr Viktorin wrote: >>>> On 04/07/2014 01:30 PM, Martin Kosek wrote: >>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> This adds read permissions to read Sudo commands, command groups, rules. >>>>>> >>>>>> Read access is given to all authenticated users. >>>>> >>>>> Looks good. What about "ou=sudoers"? I think we should also allow it in this >>>>> patch for authenticated users. This is the tree that clients use to read sudo. >>>> >>>> This new version does that. It needs my patches 0508-0509 since the ou=sudoers >>>> permission is not tied to a specific Object plugin. >>>> >>> >>> I would also allow 'ou', otherwise an authenticated user cannot read the >>> ou=sudoers RDN. I will comment on NONOBJECT_PERMISSIONS in the other thread. >> >> Right, I wonder how I missed that. >> >> New patch attached; it needs 0508-0509.2. >> > > Sorry for not spotting it earlier, but shouldn't we also add "sudoRunAs" > attribute? It is part of sudoRole objectclass: > > objectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' DESC 'Sudoer Entries' > SUP top STRUCTURAL MUST cn MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRun > As $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAft > er $ sudoOrder $ description ) X-ORIGIN 'SUDO' ) > > but we seem to not generate it in our compat plugin though. But as it is part > of the objectclass, I would rather add it to avoid any mistakes. > > If you add it, it's an ACK from me. > > Martin > Thanks for the catch. Added, along with description. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0504.4-Add-managed-read-permissions-to-Sudo-objects.patch Type: text/x-patch Size: 5221 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 9 13:57:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 15:57:07 +0200 Subject: [Freeipa-devel] global account lockout In-Reply-To: <5345503B.8030302@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> <5343C8C5.8020708@redhat.com> <1396996313.19767.15.camel@willson.li.ssimo.org> <5345503B.8030302@redhat.com> Message-ID: <534551B3.3010908@redhat.com> On 9.4.2014 15:50, Ludwig Krispenz wrote: > > On 04/09/2014 12:31 AM, Simo Sorce wrote: >> On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote: >>> Replication storms. In my opinion the replication of a mod of one or >>> two attribute in a entry will be faster than the bind itself. >> Think about the amplification effect in an environment with 20 replicas. >> 1 login attempt -> 20+ replication messages >> >> Now think about what happen bandwidth wise when a few thousand people >> all authenticate at the same time across the infrastructure, you deploy >> more servers to scale better and you get *more* traffic, at some point >> servers actually get slower as they are busy with replication related >> operations. >> >> Think what happen if one of these servers is in a satellite office on a >> relatively slow link and every morning it receives a flooding of >> replication data ... that is 99% useless because most of tat data is not >> relevant in that office. > ok, lets leave it with that, there might be scenarios where it becomes > unacceptable and as long as we have an acceptable solution we need not enforce > full replication >> >>> If an attacker knows all the dns of the entries in a server the >>> denial of service could be that it just does a sequence of failed >>> logins for any user and nobody will be able to login any more, >> This is perfectly true which is why we do not permanently lockout users >> by default and which is why I personally dislike lockouts. A much better >> mechanism to deal with brute force attacks is throttling, but it is also >> somewhat harder to implement as you need to either have an async model >> to delay answers or you need to tie threads for the delay time. >> Still a far superior measure than replicating status around at all >> times. > yes, that could be a good solution, but not trivial >> >>> replication would help to propagate this to other servers, but not >>> prevent it. This would also be the case if only the final lockout >>> state is replicated. >> Yes but the amount of replicated information would be far less. With our >> default 1/5th less on average as 5 is the number of failed attempts >> before the final lockout kicks in. So you save a lot of bandwidth. >> >>> I like the idea of replicating the attributes changed at failed logins >>> (or reset) only. >> I think this is reasonable indeed, the common case is that users tend to >> get their password right, and if you are under a password guessing >> attack you should stop it. The issue is though that sometimes you have >> misconfigured services with bad keytabs that will try over and over >> again to init, even if the account is locked, or maybe (even worse) they >> try a number of bad keys, but lower than the failed count, before >> getting to the right one (thus resetting the failed count). If they do >> this often you can still self-DoS even without a malicious attacker :-/ >> >> Something like this is what we have experienced for real and cause us to >> actually disable replication of all the lockout related attributes in >> the past. > But also here it can get complicated, we cannot really use failedlogincount > and replicate it, eg if it is "2" on each server an their are parallel login > attempts, we would increment it to "3" and replicate, so we would have 3 on > all servers, not what we wanted. Maybe it is totally of topic, but ... could something like Modify-Increment Extension http://tools.ietf.org/html/rfc4525 help? (I don't know how replications works, this would help only if it replicates operations and not only results of modifications.) I meant - it would replicate an command to increment the value by 1 instead of replicating the new value. Petr^2 Spacek > We could replicate changes to lastfailedauth and when receiving an update for > this attribute locally increase failedcount, but it would also have to be used > for resets (deleting lastFailedAuth), but there could also be race conditions, > maybe there are other local attrs needed. > > And the bad news: I claimed that the replication protocol ensures that the > last change wins except for bugs, and looks like we have one bug for single > valued attributes in some scenarios. I have to repeat the test to double check. > The update resolution code for single valued attrs is a nightmare, Rich and I > several times said we need to rewrite it :-( > > PS: Martin, if you are looking for subjects for a thesis, maybe some > theoretical model for replication update resolution and what is required > history could be a challenge. >> >> Simo. From mkosek at redhat.com Wed Apr 9 14:02:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 16:02:33 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects In-Reply-To: <53455192.8020102@redhat.com> References: <533D3360.7080106@redhat.com> <53428C3A.1000003@redhat.com> <5343BB55.9000800@redhat.com> <5343D36F.7040401@redhat.com> <53441367.7050301@redhat.com> <5345057E.1010402@redhat.com> <53455192.8020102@redhat.com> Message-ID: <534552F9.9010701@redhat.com> On 04/09/2014 03:56 PM, Petr Viktorin wrote: > On 04/09/2014 10:31 AM, Martin Kosek wrote: >> On 04/08/2014 05:19 PM, Petr Viktorin wrote: >>> On 04/08/2014 12:46 PM, Martin Kosek wrote: >>>> On 04/08/2014 11:03 AM, Petr Viktorin wrote: >>>>> On 04/07/2014 01:30 PM, Martin Kosek wrote: >>>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> This adds read permissions to read Sudo commands, command groups, rules. >>>>>>> >>>>>>> Read access is given to all authenticated users. >>>>>> >>>>>> Looks good. What about "ou=sudoers"? I think we should also allow it in this >>>>>> patch for authenticated users. This is the tree that clients use to read >>>>>> sudo. >>>>> >>>>> This new version does that. It needs my patches 0508-0509 since the >>>>> ou=sudoers >>>>> permission is not tied to a specific Object plugin. >>>>> >>>> >>>> I would also allow 'ou', otherwise an authenticated user cannot read the >>>> ou=sudoers RDN. I will comment on NONOBJECT_PERMISSIONS in the other thread. >>> >>> Right, I wonder how I missed that. >>> >>> New patch attached; it needs 0508-0509.2. >>> >> >> Sorry for not spotting it earlier, but shouldn't we also add "sudoRunAs" >> attribute? It is part of sudoRole objectclass: >> >> objectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' DESC 'Sudoer Entries' >> SUP top STRUCTURAL MUST cn MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRun >> As $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAft >> er $ sudoOrder $ description ) X-ORIGIN 'SUDO' ) >> >> but we seem to not generate it in our compat plugin though. But as it is part >> of the objectclass, I would rather add it to avoid any mistakes. >> >> If you add it, it's an ACK from me. >> >> Martin >> > > Thanks for the catch. Added, along with description. > Great! I did not spot the description myself. ACK. Martin From rmeggins at redhat.com Wed Apr 9 14:04:26 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 09 Apr 2014 08:04:26 -0600 Subject: [Freeipa-devel] global account lockout In-Reply-To: <534551B3.3010908@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> <5343C8C5.8020708@redhat.com> <1396996313.19767.15.camel@willson.li.ssimo.org> <5345503B.8030302@redhat.com> <534551B3.3010908@redhat.com> Message-ID: <5345536A.3070602@redhat.com> On 04/09/2014 07:57 AM, Petr Spacek wrote: > On 9.4.2014 15:50, Ludwig Krispenz wrote: >> >> On 04/09/2014 12:31 AM, Simo Sorce wrote: >>> On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote: >>>> Replication storms. In my opinion the replication of a mod of one or >>>> two attribute in a entry will be faster than the bind itself. >>> Think about the amplification effect in an environment with 20 >>> replicas. >>> 1 login attempt -> 20+ replication messages >>> >>> Now think about what happen bandwidth wise when a few thousand people >>> all authenticate at the same time across the infrastructure, you deploy >>> more servers to scale better and you get *more* traffic, at some point >>> servers actually get slower as they are busy with replication related >>> operations. >>> >>> Think what happen if one of these servers is in a satellite office on a >>> relatively slow link and every morning it receives a flooding of >>> replication data ... that is 99% useless because most of tat data is >>> not >>> relevant in that office. >> ok, lets leave it with that, there might be scenarios where it becomes >> unacceptable and as long as we have an acceptable solution we need >> not enforce >> full replication >>> >>>> If an attacker knows all the dns of the entries in a server the >>>> denial of service could be that it just does a sequence of failed >>>> logins for any user and nobody will be able to login any more, >>> This is perfectly true which is why we do not permanently lockout users >>> by default and which is why I personally dislike lockouts. A much >>> better >>> mechanism to deal with brute force attacks is throttling, but it is >>> also >>> somewhat harder to implement as you need to either have an async model >>> to delay answers or you need to tie threads for the delay time. >>> Still a far superior measure than replicating status around at all >>> times. >> yes, that could be a good solution, but not trivial >>> >>>> replication would help to propagate this to other servers, but not >>>> prevent it. This would also be the case if only the final lockout >>>> state is replicated. >>> Yes but the amount of replicated information would be far less. With >>> our >>> default 1/5th less on average as 5 is the number of failed attempts >>> before the final lockout kicks in. So you save a lot of bandwidth. >>> >>>> I like the idea of replicating the attributes changed at failed logins >>>> (or reset) only. >>> I think this is reasonable indeed, the common case is that users >>> tend to >>> get their password right, and if you are under a password guessing >>> attack you should stop it. The issue is though that sometimes you have >>> misconfigured services with bad keytabs that will try over and over >>> again to init, even if the account is locked, or maybe (even worse) >>> they >>> try a number of bad keys, but lower than the failed count, before >>> getting to the right one (thus resetting the failed count). If they do >>> this often you can still self-DoS even without a malicious attacker :-/ >>> >>> Something like this is what we have experienced for real and cause >>> us to >>> actually disable replication of all the lockout related attributes in >>> the past. >> But also here it can get complicated, we cannot really use >> failedlogincount >> and replicate it, eg if it is "2" on each server an their are >> parallel login >> attempts, we would increment it to "3" and replicate, so we would >> have 3 on >> all servers, not what we wanted. > > Maybe it is totally of topic, but ... could something like > Modify-Increment Extension > http://tools.ietf.org/html/rfc4525 > help? > > (I don't know how replications works, this would help only if it > replicates operations and not only results of modifications.) Replication does replicate the operation. It essentially just "forwards" the modify operation received by the initial server, along with some replication meta-data. > > I meant - it would replicate an command to increment the value by 1 > instead of replicating the new value. The problem is that servers would quickly get out of sync. I'm not sure how we would ensure eventual convergence. > > Petr^2 Spacek > >> We could replicate changes to lastfailedauth and when receiving an >> update for >> this attribute locally increase failedcount, but it would also have >> to be used >> for resets (deleting lastFailedAuth), but there could also be race >> conditions, >> maybe there are other local attrs needed. >> >> And the bad news: I claimed that the replication protocol ensures >> that the >> last change wins except for bugs, and looks like we have one bug for >> single >> valued attributes in some scenarios. I have to repeat the test to >> double check. >> The update resolution code for single valued attrs is a nightmare, >> Rich and I >> several times said we need to rewrite it :-( >> >> PS: Martin, if you are looking for subjects for a thesis, maybe some >> theoretical model for replication update resolution and what is required >> history could be a challenge. >>> >>> Simo. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Wed Apr 9 14:09:02 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2014 10:09:02 -0400 Subject: [Freeipa-devel] global account lockout In-Reply-To: <5345503B.8030302@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> <5343C8C5.8020708@redhat.com> <1396996313.19767.15.camel@willson.li.ssimo.org> <5345503B.8030302@redhat.com> Message-ID: <1397052542.19767.34.camel@willson.li.ssimo.org> On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: > > Something like this is what we have experienced for real and cause > us to > > actually disable replication of all the lockout related attributes > in > > the past. > But also here it can get complicated, we cannot really use > failedlogincount and replicate it, eg if it is "2" on each server an > their are parallel login attempts, we would increment it to "3" and > replicate, so we would have 3 on all servers, not what we wanted. > We could replicate changes to lastfailedauth and when receiving an > update for this attribute locally increase failedcount, but it would > also have to be used for resets (deleting lastFailedAuth), but there > could also be race conditions, maybe there are other local attrs > needed. Yes, the current mechanism is deficient in many ways. For example the failedcount/lastfailedauth attibutes are really suboptimal, a better mechanism woul dbe to have a failedauths (not plural) multivalued attribute and just append dates there (perhaps pre/postfixed with the replica idto avoid any possible conflict). This way if 2 servers are being attacked simultaneously they still should replicate their own failure and each server can see that 5 dates are present in the last X minutes and quickly lock the user, nor failedcount would be necessary and no races incrementing it would occur. The only issue would be in cleaning up the attribute to not let it grow to much, but that could be accomplished by simply *not adding any more failed counts once the account is locked (only logging locally that someone tried to log in on a locked account) and deleting the attribute completely when the acocunt is unlocked, this again would reduce the attributes necessary for handling locking own to 1 from the current 3 (lastsuccessauth/lastafiledauth/failedcounter) however it still does nothing to solve replication issues and has other replication races problems (not sure what happens if a server try store a new failed auth date and the other is deleting the old values at the same time. Perhaps deleting by value is safe enough and won't cause issues, Deleting the whole attribute may cause issues instead). > And the bad news: I claimed that the replication protocol ensures that > the last change wins except for bugs, and looks like we have one bug > for single valued attributes in some scenarios. I have to repeat the > test to double check. > The update resolution code for single valued attrs is a nightmare, > Rich and I several times said we need to rewrite it :-( Is there a ticket that tracks this and explains the issue(s) ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Apr 9 14:09:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 16:09:45 +0200 Subject: [Freeipa-devel] [PATCHES] 0510-0511 Add managed read permissions to group & hostgroup In-Reply-To: <53454A95.1040606@redhat.com> References: <5343EAC2.6030409@redhat.com> <53450A93.7090803@redhat.com> <1397048677.19767.23.camel@willson.li.ssimo.org> <53454A95.1040606@redhat.com> Message-ID: <534554A9.2010407@redhat.com> On 04/09/2014 03:26 PM, Martin Kosek wrote: > On 04/09/2014 03:04 PM, Simo Sorce wrote: >> On Wed, 2014-04-09 at 10:53 +0200, Martin Kosek wrote: >>> On 04/08/2014 02:25 PM, Petr Viktorin wrote: >>>> Hello, >>>> These add read permissions to read user groups and hostgroups. >>>> >>>> For most attributes, anonymous read access is given. >>>> For member, memberOf, memberUID, read access is given only to authenticated users. >>> >>> Didn't we agree that we want to make hostgroups read by authenticated users >>> only? Just like we did with netgroups. CCing Simo to confirm. Apologies, I misread the agreement. >>> Besides the default bind type, the ACI looked ok. >> >> I forgot if we decided anything about hostgroups, but they are not >> necessary for an anonymous reader so we may as well not server them in >> that case. >> >> Simo. >> > > In that case Petr please consider changing 511 to only allow authenticated > users to read hostgroups. > > Thanks, > Martin > Fixed patches attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0510.2-Add-managed-read-permissions-to-group.patch Type: text/x-patch Size: 1585 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0511.2-Add-managed-read-permission-to-hostgroup.patch Type: text/x-patch Size: 1596 bytes Desc: not available URL: From pviktori at redhat.com Wed Apr 9 14:13:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 16:13:27 +0200 Subject: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects In-Reply-To: <534552F9.9010701@redhat.com> References: <533D3360.7080106@redhat.com> <53428C3A.1000003@redhat.com> <5343BB55.9000800@redhat.com> <5343D36F.7040401@redhat.com> <53441367.7050301@redhat.com> <5345057E.1010402@redhat.com> <53455192.8020102@redhat.com> <534552F9.9010701@redhat.com> Message-ID: <53455587.9030500@redhat.com> On 04/09/2014 04:02 PM, Martin Kosek wrote: > On 04/09/2014 03:56 PM, Petr Viktorin wrote: >> On 04/09/2014 10:31 AM, Martin Kosek wrote: >>> On 04/08/2014 05:19 PM, Petr Viktorin wrote: >>>> On 04/08/2014 12:46 PM, Martin Kosek wrote: >>>>> On 04/08/2014 11:03 AM, Petr Viktorin wrote: >>>>>> On 04/07/2014 01:30 PM, Martin Kosek wrote: >>>>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>>>>> Hello, >>>>>>>> This adds read permissions to read Sudo commands, command groups, rules. >>>>>>>> >>>>>>>> Read access is given to all authenticated users. >>>>>>> >>>>>>> Looks good. What about "ou=sudoers"? I think we should also allow it in this >>>>>>> patch for authenticated users. This is the tree that clients use to read >>>>>>> sudo. >>>>>> >>>>>> This new version does that. It needs my patches 0508-0509 since the >>>>>> ou=sudoers >>>>>> permission is not tied to a specific Object plugin. >>>>>> >>>>> >>>>> I would also allow 'ou', otherwise an authenticated user cannot read the >>>>> ou=sudoers RDN. I will comment on NONOBJECT_PERMISSIONS in the other thread. >>>> >>>> Right, I wonder how I missed that. >>>> >>>> New patch attached; it needs 0508-0509.2. >>>> >>> >>> Sorry for not spotting it earlier, but shouldn't we also add "sudoRunAs" >>> attribute? It is part of sudoRole objectclass: >>> >>> objectClasses: ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' DESC 'Sudoer Entries' >>> SUP top STRUCTURAL MUST cn MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRun >>> As $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAft >>> er $ sudoOrder $ description ) X-ORIGIN 'SUDO' ) >>> >>> but we seem to not generate it in our compat plugin though. But as it is part >>> of the objectclass, I would rather add it to avoid any mistakes. >>> >>> If you add it, it's an ACK from me. >>> >>> Martin >>> >> >> Thanks for the catch. Added, along with description. >> > > Great! I did not spot the description myself. > > ACK. Thanks, pushed to master: 7786ff694b098f44574f92b3bbf89db48438a20f -- Petr? From rmeggins at redhat.com Wed Apr 9 14:17:58 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 09 Apr 2014 08:17:58 -0600 Subject: [Freeipa-devel] global account lockout In-Reply-To: <1397052542.19767.34.camel@willson.li.ssimo.org> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> <5343C8C5.8020708@redhat.com> <1396996313.19767.15.camel@willson.li.ssimo.org> <5345503B.8030302@redhat.com> <1397052542.19767.34.camel@willson.li.ssimo.org> Message-ID: <53455696.4010607@redhat.com> On 04/09/2014 08:09 AM, Simo Sorce wrote: > On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: >>> Something like this is what we have experienced for real and cause >> us to >>> actually disable replication of all the lockout related attributes >> in >>> the past. >> But also here it can get complicated, we cannot really use >> failedlogincount and replicate it, eg if it is "2" on each server an >> their are parallel login attempts, we would increment it to "3" and >> replicate, so we would have 3 on all servers, not what we wanted. >> We could replicate changes to lastfailedauth and when receiving an >> update for this attribute locally increase failedcount, but it would >> also have to be used for resets (deleting lastFailedAuth), but there >> could also be race conditions, maybe there are other local attrs >> needed. > Yes, the current mechanism is deficient in many ways. For example the > failedcount/lastfailedauth attibutes are really suboptimal, a better > mechanism woul dbe to have a failedauths (not plural) multivalued > attribute and just append dates there (perhaps pre/postfixed with the > replica idto avoid any possible conflict). This way if 2 servers are > being attacked simultaneously they still should replicate their own > failure and each server can see that 5 dates are present in the last X > minutes and quickly lock the user, nor failedcount would be necessary > and no races incrementing it would occur. This is an interesting idea. Please file a ticket in the 389 trac explaining this. > > The only issue would be in cleaning up the attribute to not let it grow > to much, but that could be accomplished by simply *not adding any more > failed counts once the account is locked (only logging locally that > someone tried to log in on a locked account) and deleting the attribute > completely when the acocunt is unlocked, this again would reduce the > attributes necessary for handling locking own to 1 from the current 3 > (lastsuccessauth/lastafiledauth/failedcounter) however it still does > nothing to solve replication issues and has other replication races > problems (not sure what happens if a server try store a new failed auth > date and the other is deleting the old values at the same time. > Perhaps deleting by value is safe enough and won't cause issues, > Deleting the whole attribute may cause issues instead). Handling of simultaneous updates of multi-valued attributes and update resolution works well. > >> And the bad news: I claimed that the replication protocol ensures that >> the last change wins except for bugs, and looks like we have one bug >> for single valued attributes in some scenarios. I have to repeat the >> test to double check. >> The update resolution code for single valued attrs is a nightmare, >> Rich and I several times said we need to rewrite it :-( > Is there a ticket that tracks this and explains the issue(s) ? https://fedorahosted.org/389/ticket/47442 > > Simo. > From pviktori at redhat.com Wed Apr 9 14:24:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 16:24:36 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] document that wildcards are not supported in FreeIPA <= 3.2 In-Reply-To: References: <1397032168.2318.5.camel@unused-4-145.brq.redhat.com> <53451F04.2090904@redhat.com> Message-ID: <53455824.6010403@redhat.com> On 04/09/2014 02:58 PM, Gabe Alford wrote: > I am good with it. > > Gabe Pushed to docs master: be130d05c2111d31465e57238c5390a5c4ab9de2 > On Wed, Apr 9, 2014 at 4:20 AM, Petr Spacek > wrote: > > On 9.4.2014 10:29, Martin Basti wrote: > > On Tue, 2014-04-08 at 21:19 -0600, Gabe Alford wrote: > > Hello, > > > Not sure how relevant this patch is to the current documentation > considering (I believe) that wildcards are supported in > versions 3.3 > and up. Patch for > https://fedorahosted.org/__freeipa/ticket/3616 > > > > Wildcards will be supported from version 4.0 . > Curently are not supported in 3.x. > > > I have modified version in the text & also changed to > . > > IMHO it is not important enough, it is just one of limitations. > > Gabe, are you okay with that? -- Petr? From pspacek at redhat.com Wed Apr 9 14:38:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 16:38:24 +0200 Subject: [Freeipa-devel] [PATCH 0234] Prevent NULL dereference before sync_concurr_limit_signal() calls In-Reply-To: <53454925.3020800@redhat.com> References: <534537EE.9070101@redhat.com> <53454925.3020800@redhat.com> Message-ID: <53455B60.8070404@redhat.com> On 9.4.2014 15:20, Tomas Hozza wrote: > On 04/09/2014 02:07 PM, Petr Spacek wrote: >> Hello, >> >> Prevent NULL dereference before sync_concurr_limit_signal() calls. >> >> Missing check was causing NULL dereference in case where >> manager_get_ldap_instance() failed. This typically happens when BIND >> is processing LDAP updates during shutdown. >> >> I noticed this crash during sanity testing 4.2 release... >> >> Please review it ASAP so I can release 4.3. >> >> How to reproduce the problem: >> Run BIND manually from console: >> $ named -4 -g -u named -m record -n 10 >> and press Ctrl+C "almost immediately". >> >> Sometimes it shutdowns cleanly and sometimes you can see a crash: >> >> Thank you for your time! >> > > ACK. > > I'm not able to reproduce the issue, but the patch looks reasonable and > should not break anything. Thanks. I have modified the patch once again before push to silence Clang warnings about potential NULL-inst deference on following lines: if (dns_name_dynamic(&name)) dns_name_free(&name, inst->mctx); In reality the NULL dereference cannot happen because it is guarded by condition in dns_name_dynamic(). This is not a problem now but the behavior depends on internal implementation in BIND. It is definitely better to add explicit check to stay safe ... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0234-2-Prevent-NULL-dereference-before-sync_concurr_limit_s.patch Type: text/x-patch Size: 3268 bytes Desc: not available URL: From lkrispen at redhat.com Wed Apr 9 14:40:36 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 09 Apr 2014 16:40:36 +0200 Subject: [Freeipa-devel] global account lockout In-Reply-To: <53455696.4010607@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> <5343C8C5.8020708@redhat.com> <1396996313.19767.15.camel@willson.li.ssimo.org> <5345503B.8030302@redhat.com> <1397052542.19767.34.camel@willson.li.ssimo.org> <53455696.4010607@redhat.com> Message-ID: <53455BE4.3090405@redhat.com> On 04/09/2014 04:17 PM, Rich Megginson wrote: > On 04/09/2014 08:09 AM, Simo Sorce wrote: >> On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: >>>> Something like this is what we have experienced for real and cause >>> us to >>>> actually disable replication of all the lockout related attributes >>> in >>>> the past. >>> But also here it can get complicated, we cannot really use >>> failedlogincount and replicate it, eg if it is "2" on each server an >>> their are parallel login attempts, we would increment it to "3" and >>> replicate, so we would have 3 on all servers, not what we wanted. >>> We could replicate changes to lastfailedauth and when receiving an >>> update for this attribute locally increase failedcount, but it would >>> also have to be used for resets (deleting lastFailedAuth), but there >>> could also be race conditions, maybe there are other local attrs >>> needed. >> Yes, the current mechanism is deficient in many ways. For example the >> failedcount/lastfailedauth attibutes are really suboptimal, a better >> mechanism woul dbe to have a failedauths (not plural) multivalued >> attribute and just append dates there (perhaps pre/postfixed with the >> replica idto avoid any possible conflict). This way if 2 servers are >> being attacked simultaneously they still should replicate their own >> failure and each server can see that 5 dates are present in the last X >> minutes and quickly lock the user, nor failedcount would be necessary >> and no races incrementing it would occur. > > This is an interesting idea. Please file a ticket in the 389 trac > explaining this. > >> >> The only issue would be in cleaning up the attribute to not let it grow >> to much, but that could be accomplished by simply *not adding any more >> failed counts once the account is locked (only logging locally that >> someone tried to log in on a locked account) and deleting the attribute >> completely when the acocunt is unlocked, this again would reduce the >> attributes necessary for handling locking own to 1 from the current 3 >> (lastsuccessauth/lastafiledauth/failedcounter) however it still does >> nothing to solve replication issues and has other replication races >> problems (not sure what happens if a server try store a new failed auth >> date and the other is deleting the old values at the same time. >> Perhaps deleting by value is safe enough and won't cause issues, >> Deleting the whole attribute may cause issues instead). > > Handling of simultaneous updates of multi-valued attributes and update > resolution works well. > >> >>> And the bad news: I claimed that the replication protocol ensures that >>> the last change wins except for bugs, and looks like we have one bug >>> for single valued attributes in some scenarios. I have to repeat the >>> test to double check. >>> The update resolution code for single valued attrs is a nightmare, >>> Rich and I several times said we need to rewrite it :-( >> Is there a ticket that tracks this and explains the issue(s) ? > > https://fedorahosted.org/389/ticket/47442 my scenario was slightly differenent, without modrdn, but delete:oldvalue, add:newvalue[i] on three servers i=1,2,3 "simultaneously" > >> >> Simo. >> > From pviktori at redhat.com Wed Apr 9 14:54:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 16:54:12 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission Message-ID: <53455F14.2060505@redhat.com> The meta-permissions. Read access is given to all authenticated users. Reading membership info (i.e. privileges) is split into a separate permission. Another permission is added that allows read access to all ACIs. If we don't want to open that up for everyone, I could limit this to only ACIs containing "permission:". (Since old-style permissions store their information in ACIs, their ACIs need to be readable.) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0513-Add-managed-read-permissions-to-permission.patch Type: text/x-patch Size: 2796 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 9 15:08:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 17:08:12 +0200 Subject: [Freeipa-devel] [PATCHES] 0510-0511 Add managed read permissions to group & hostgroup In-Reply-To: <534554A9.2010407@redhat.com> References: <5343EAC2.6030409@redhat.com> <53450A93.7090803@redhat.com> <1397048677.19767.23.camel@willson.li.ssimo.org> <53454A95.1040606@redhat.com> <534554A9.2010407@redhat.com> Message-ID: <5345625C.40703@redhat.com> On 04/09/2014 04:09 PM, Petr Viktorin wrote: > On 04/09/2014 03:26 PM, Martin Kosek wrote: >> On 04/09/2014 03:04 PM, Simo Sorce wrote: >>> On Wed, 2014-04-09 at 10:53 +0200, Martin Kosek wrote: >>>> On 04/08/2014 02:25 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> These add read permissions to read user groups and hostgroups. >>>>> >>>>> For most attributes, anonymous read access is given. >>>>> For member, memberOf, memberUID, read access is given only to >>>>> authenticated users. >>>> >>>> Didn't we agree that we want to make hostgroups read by authenticated users >>>> only? Just like we did with netgroups. CCing Simo to confirm. > > Apologies, I misread the agreement. > >>>> Besides the default bind type, the ACI looked ok. >>> >>> I forgot if we decided anything about hostgroups, but they are not >>> necessary for an anonymous reader so we may as well not server them in >>> that case. >>> >>> Simo. >>> >> >> In that case Petr please consider changing 511 to only allow authenticated >> users to read hostgroups. >> >> Thanks, >> Martin >> > > Fixed patches attached. > Looks good. ACK! Martin From pviktori at redhat.com Wed Apr 9 15:14:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Apr 2014 17:14:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0510-0511 Add managed read permissions to group & hostgroup In-Reply-To: <5345625C.40703@redhat.com> References: <5343EAC2.6030409@redhat.com> <53450A93.7090803@redhat.com> <1397048677.19767.23.camel@willson.li.ssimo.org> <53454A95.1040606@redhat.com> <534554A9.2010407@redhat.com> <5345625C.40703@redhat.com> Message-ID: <534563EC.7090706@redhat.com> On 04/09/2014 05:08 PM, Martin Kosek wrote: > On 04/09/2014 04:09 PM, Petr Viktorin wrote: >> On 04/09/2014 03:26 PM, Martin Kosek wrote: >>> On 04/09/2014 03:04 PM, Simo Sorce wrote: >>>> On Wed, 2014-04-09 at 10:53 +0200, Martin Kosek wrote: >>>>> On 04/08/2014 02:25 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> These add read permissions to read user groups and hostgroups. >>>>>> >>>>>> For most attributes, anonymous read access is given. >>>>>> For member, memberOf, memberUID, read access is given only to >>>>>> authenticated users. >>>>> >>>>> Didn't we agree that we want to make hostgroups read by authenticated users >>>>> only? Just like we did with netgroups. CCing Simo to confirm. >> >> Apologies, I misread the agreement. >> >>>>> Besides the default bind type, the ACI looked ok. >>>> >>>> I forgot if we decided anything about hostgroups, but they are not >>>> necessary for an anonymous reader so we may as well not server them in >>>> that case. >>>> >>>> Simo. >>>> >>> >>> In that case Petr please consider changing 511 to only allow authenticated >>> users to read hostgroups. >>> >>> Thanks, >>> Martin >>> >> >> Fixed patches attached. >> > > Looks good. ACK! > > Martin > Thanks, pushed to master: 13f3ba5eb009a4af3bdb60a54e058fb5f62545dd -- Petr? From mkosek at redhat.com Wed Apr 9 15:17:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Apr 2014 17:17:31 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <53455F14.2060505@redhat.com> References: <53455F14.2060505@redhat.com> Message-ID: <5345648B.2000109@redhat.com> On 04/09/2014 04:54 PM, Petr Viktorin wrote: > The meta-permissions. :-) > Read access is given to all authenticated users. Reading membership info (i.e. > privileges) is split into a separate permission. > > Another permission is added that allows read access to all ACIs. > If we don't want to open that up for everyone, I could limit this to only ACIs > containing "permission:". (Since old-style permissions store their information > in ACIs, their ACIs need to be readable.) If I read the notes from our DevConf discussion correctly, there are some inconsistencies: 1) We decided to not do special membership permission for permission/privilege/role permissions. 2) We decided to give read access to permissions, privileges and roles only to member of a certain privilege. Is there any reason to not do that? IMO, regular users do not need to be able to read the permission/privilege/role configuration of a FreeIPA installation to use it for IdM. Martin From lslebodn at redhat.com Wed Apr 9 15:39:39 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 9 Apr 2014 17:39:39 +0200 Subject: [Freeipa-devel] [PATCH 0234] Prevent NULL dereference before sync_concurr_limit_signal() calls In-Reply-To: <53455B60.8070404@redhat.com> References: <534537EE.9070101@redhat.com> <53454925.3020800@redhat.com> <53455B60.8070404@redhat.com> Message-ID: <20140409153938.GE25035@mail.corp.redhat.com> On (09/04/14 16:38), Petr Spacek wrote: >On 9.4.2014 15:20, Tomas Hozza wrote: >>On 04/09/2014 02:07 PM, Petr Spacek wrote: >>>Hello, >>> >>>Prevent NULL dereference before sync_concurr_limit_signal() calls. >>> >>>Missing check was causing NULL dereference in case where >>>manager_get_ldap_instance() failed. This typically happens when BIND >>>is processing LDAP updates during shutdown. >>> >>>I noticed this crash during sanity testing 4.2 release... >>> >>>Please review it ASAP so I can release 4.3. >>> >>>How to reproduce the problem: >>>Run BIND manually from console: >>>$ named -4 -g -u named -m record -n 10 >>>and press Ctrl+C "almost immediately". >>> >>>Sometimes it shutdowns cleanly and sometimes you can see a crash: >>> >>>Thank you for your time! >>> >> >>ACK. >> >>I'm not able to reproduce the issue, but the patch looks reasonable and >>should not break anything. > >Thanks. I have modified the patch once again before push to silence >Clang warnings about potential NULL-inst deference on following >lines: > >if (dns_name_dynamic(&name)) > dns_name_free(&name, inst->mctx); > >In reality the NULL dereference cannot happen because it is guarded >by condition in dns_name_dynamic(). > >This is not a problem now but the behavior depends on internal >implementation in BIND. It is definitely better to add explicit check >to stay safe ... > >-- >Petr^2 Spacek >From cb9ed81e6b1fdd26a06739fe819b730eb4a70839 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Wed, 9 Apr 2014 14:01:00 +0200 >Subject: [PATCH] Prevent NULL dereference before sync_concurr_limit_signal() > calls. > >Missing check was causing NULL dereference in case where >manager_get_ldap_instance() failed. This typically happens when BIND >is processing LDAP updates during shutdown. > >Signed-off-by: Petr Spacek >--- scan-build: No bugs found. ACK LS From pspacek at redhat.com Wed Apr 9 15:43:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 17:43:18 +0200 Subject: [Freeipa-devel] [PATCH 0234] Prevent NULL dereference before sync_concurr_limit_signal() calls In-Reply-To: <20140409153938.GE25035@mail.corp.redhat.com> References: <534537EE.9070101@redhat.com> <53454925.3020800@redhat.com> <53455B60.8070404@redhat.com> <20140409153938.GE25035@mail.corp.redhat.com> Message-ID: <53456A96.3040107@redhat.com> On 9.4.2014 17:39, Lukas Slebodnik wrote: > On (09/04/14 16:38), Petr Spacek wrote: >> On 9.4.2014 15:20, Tomas Hozza wrote: >>> On 04/09/2014 02:07 PM, Petr Spacek wrote: >>>> Hello, >>>> >>>> Prevent NULL dereference before sync_concurr_limit_signal() calls. >>>> >>>> Missing check was causing NULL dereference in case where >>>> manager_get_ldap_instance() failed. This typically happens when BIND >>>> is processing LDAP updates during shutdown. >>>> >>>> I noticed this crash during sanity testing 4.2 release... >>>> >>>> Please review it ASAP so I can release 4.3. >>>> >>>> How to reproduce the problem: >>>> Run BIND manually from console: >>>> $ named -4 -g -u named -m record -n 10 >>>> and press Ctrl+C "almost immediately". >>>> >>>> Sometimes it shutdowns cleanly and sometimes you can see a crash: >>>> >>>> Thank you for your time! >>>> >>> >>> ACK. >>> >>> I'm not able to reproduce the issue, but the patch looks reasonable and >>> should not break anything. >> >> Thanks. I have modified the patch once again before push to silence >> Clang warnings about potential NULL-inst deference on following >> lines: >> >> if (dns_name_dynamic(&name)) >> dns_name_free(&name, inst->mctx); >> >> In reality the NULL dereference cannot happen because it is guarded >> by condition in dns_name_dynamic(). >> >> This is not a problem now but the behavior depends on internal >> implementation in BIND. It is definitely better to add explicit check >> to stay safe ... >> >> -- >> Petr^2 Spacek > >>From cb9ed81e6b1fdd26a06739fe819b730eb4a70839 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Wed, 9 Apr 2014 14:01:00 +0200 >> Subject: [PATCH] Prevent NULL dereference before sync_concurr_limit_signal() >> calls. >> >> Missing check was causing NULL dereference in case where >> manager_get_ldap_instance() failed. This typically happens when BIND >> is processing LDAP updates during shutdown. >> >> Signed-off-by: Petr Spacek >> --- > > scan-build: No bugs found. > > ACK Thanks! Pushed to master: cb9ed81e6b1fdd26a06739fe819b730eb4a70839 -- Petr^2 Spacek From redhatrises at gmail.com Wed Apr 9 15:43:30 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 9 Apr 2014 09:43:30 -0600 Subject: [Freeipa-devel] global account lockout In-Reply-To: <53455BE4.3090405@redhat.com> References: <53427149.2010908@redhat.com> <5342C3A2.9070706@redhat.com> <1396886465.14203.61.camel@willson.li.ssimo.org> <1396887023.14203.70.camel@willson.li.ssimo.org> <1396887223.14203.73.camel@willson.li.ssimo.org> <5342D0BE.1090802@redhat.com> <1396895492.14203.106.camel@willson.li.ssimo.org> <5342F2BF.9090000@redhat.com> <1396897215.14203.109.camel@willson.li.ssimo.org> <53430A54.1080205@redhat.com> <1396911419.14203.126.camel@willson.li.ssimo.org> <5343C8C5.8020708@redhat.com> <1396996313.19767.15.camel@willson.li.ssimo.org> <5345503B.8030302@redhat.com> <1397052542.19767.34.camel@willson.li.ssimo.org> <53455696.4010607@redhat.com> <53455BE4.3090405@redhat.com> Message-ID: I came across these articles that may be of some use in this topic. I humbly admit that I am no expert on this topic, and these may not be of any use. Plus, I am not a fan of the product, but maybe it helps? http://technet.microsoft.com/en-us/library/cc772726%28v=ws.10%29.aspx http://blogs.technet.com/b/askds/archive/2010/08/18/fine-grained-password-policy-and-urgent-replication.aspx Gabe On Wed, Apr 9, 2014 at 8:40 AM, Ludwig Krispenz wrote: > > On 04/09/2014 04:17 PM, Rich Megginson wrote: > >> On 04/09/2014 08:09 AM, Simo Sorce wrote: >> >>> On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: >>> >>>> Something like this is what we have experienced for real and cause >>>>> >>>> us to >>>> >>>>> actually disable replication of all the lockout related attributes >>>>> >>>> in >>>> >>>>> the past. >>>>> >>>> But also here it can get complicated, we cannot really use >>>> failedlogincount and replicate it, eg if it is "2" on each server an >>>> their are parallel login attempts, we would increment it to "3" and >>>> replicate, so we would have 3 on all servers, not what we wanted. >>>> We could replicate changes to lastfailedauth and when receiving an >>>> update for this attribute locally increase failedcount, but it would >>>> also have to be used for resets (deleting lastFailedAuth), but there >>>> could also be race conditions, maybe there are other local attrs >>>> needed. >>>> >>> Yes, the current mechanism is deficient in many ways. For example the >>> failedcount/lastfailedauth attibutes are really suboptimal, a better >>> mechanism woul dbe to have a failedauths (not plural) multivalued >>> attribute and just append dates there (perhaps pre/postfixed with the >>> replica idto avoid any possible conflict). This way if 2 servers are >>> being attacked simultaneously they still should replicate their own >>> failure and each server can see that 5 dates are present in the last X >>> minutes and quickly lock the user, nor failedcount would be necessary >>> and no races incrementing it would occur. >>> >> >> This is an interesting idea. Please file a ticket in the 389 trac >> explaining this. >> >> >>> The only issue would be in cleaning up the attribute to not let it grow >>> to much, but that could be accomplished by simply *not adding any more >>> failed counts once the account is locked (only logging locally that >>> someone tried to log in on a locked account) and deleting the attribute >>> completely when the acocunt is unlocked, this again would reduce the >>> attributes necessary for handling locking own to 1 from the current 3 >>> (lastsuccessauth/lastafiledauth/failedcounter) however it still does >>> nothing to solve replication issues and has other replication races >>> problems (not sure what happens if a server try store a new failed auth >>> date and the other is deleting the old values at the same time. >>> Perhaps deleting by value is safe enough and won't cause issues, >>> Deleting the whole attribute may cause issues instead). >>> >> >> Handling of simultaneous updates of multi-valued attributes and update >> resolution works well. >> >> >>> And the bad news: I claimed that the replication protocol ensures that >>>> the last change wins except for bugs, and looks like we have one bug >>>> for single valued attributes in some scenarios. I have to repeat the >>>> test to double check. >>>> The update resolution code for single valued attrs is a nightmare, >>>> Rich and I several times said we need to rewrite it :-( >>>> >>> Is there a ticket that tracks this and explains the issue(s) ? >>> >> >> https://fedorahosted.org/389/ticket/47442 >> > my scenario was slightly differenent, without modrdn, but delete:oldvalue, > add:newvalue[i] on three servers i=1,2,3 "simultaneously" > > >> >>> Simo. >>> >>> >> > _______________________________________________ > 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 pspacek at redhat.com Wed Apr 9 16:21:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 18:21:43 +0200 Subject: [Freeipa-devel] [PATCH 0235] Bump NVR to 4.3 Message-ID: <53457397.1070400@redhat.com> Hello, Bump NVR to 4.3. Pushed to master: 89f1751ff8f8582d628652060eff3bf5a9d7254a -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0235-Bump-NVR-to-4.3.patch Type: text/x-patch Size: 1193 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 9 17:06:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 09 Apr 2014 19:06:19 +0200 Subject: [Freeipa-devel] Announcing bind-dyndb-ldap version 4.3 Message-ID: <53457E0B.1080401@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 4.3. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 20 and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-4.3-1.fc20 == Changes in 4.3 and 4.2 == [1] LDAP update processing was fixed to prevent BIND from crashing during shutdown. [2] Record parsing was fixed to prevent child-zone data corruption in cases where parent zone example.com was hosted on the same server as child zone sub.example.com. (This bug was introduced in version 4.0.) == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. *Make sure that BIND can write to working directory as described in README* before you restart BIND. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 3.x version is supported as long as record types not supported by old version are not utilized. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek @ Red Hat From rcritten at redhat.com Wed Apr 9 19:42:44 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Apr 2014 15:42:44 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5326E2DE.3010006@redhat.com> References: <52D99F70.3060305@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> Message-ID: <5345A2B4.1000705@redhat.com> Petr Viktorin wrote: > On 03/14/2014 07:58 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: > [...] >>>> >>>> Here are a couple more enhancements I'm considering, this seems simpler >>>> than inter-diff since it is so small. >>> >>> Not really. Having a patch file with a sequence+revision number you can >>> refer to has its merits. Especially in a hairy thread like this one. >>> Also one of our MUAs wrapped the lines, I had to undo that manually. >>> >>>> Here is why I made the changes, in order: >>>> >>>> I doubled the calls to create the connection but one isn't in a >>>> try/except!? Remove the obvious one. >>>> >>>> We currently completely eat GSSAPI errors, I figure we should log >>>> failures. >>>> >>>> IPA stores the principal in the request context so using that will save >>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>> >>>> I included your content-type change. >>> >>> These changes look good. >>> I'm almost done testing but I need to call it a week. >> >> Awesome, thanks. > > ACK on the functionality. > >>> Sorry for not catching that last time, but your patch doesn't add a >>> *versioned* BuildRequres on python-kerberos, instead it adds a duplicate >>> unversioned one. So lint (and thus the build) will fail if the old >>> python-kerberos version is installed. >>> >>> A possible a solution to the build trouble would be to just add a lint >>> exception now, and open a ticket to remove it later. That way the build >>> succeeds despite the older version, and the new python-kerberos is only >>> needed when installing freeipa-server-foreman-smartproxy. >>> That should make everyone happy, including Martin. >>> Unfortunately our lint exception mechanism doesn't work on modules, so >>> this needs a somewhat nastier hack. >>> The attaching a patch that does this (and I'm pasting a simple diff >>> below). Does that look okay to push? >> >> I'm trying to find a better solution to all this. I may end up taking >> Martin's suggestion of rawhide-only to avoid this sort of thing. > > Looks like you'll still need to silence pylint on f20 in that case. > >> The deal with the smartproxy is that you can/should be able to run it on >> any IPA-enrolled client, so you can run it directly on the Foreman box, >> with the IPA server somewhere else. What this means is that someone >> could probably fairly easily package this up for other distributions and >> if we end up with a Fedora-only python-kerberos patch then smartproxy is >> Fedora-only as well. >> >> So I'm trying to get some movement out of upstream on this but it's been >> crickets for weeks. I think in the context of the calendar server >> PyKerberos is small potatoes so doesn't get much lovin'. I'll amp up the >> nagging to get some sort of response, even if it is "stop nagging us!" >> >> rob > > Good luck! Ok, taking a different tack on this. Rather than running it as a separate server process, run it as a WSGI app inside Apache. This required a fair bit of re-tooling and complicates the set up a little bit. I think I've got it all covered in the man page. On the python-kerberos front I've got bugs opened in Ubuntu and Debian to see if we can get the patch accepted their until (if) upstream ever takes a look. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-8-rest.patch Type: text/x-patch Size: 48947 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 9 21:29:15 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Apr 2014 17:29:15 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5345A2B4.1000705@redhat.com> References: <52D99F70.3060305@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> Message-ID: <5345BBAB.7010607@redhat.com> Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >> [...] >>>>> >>>>> Here are a couple more enhancements I'm considering, this seems >>>>> simpler >>>>> than inter-diff since it is so small. >>>> >>>> Not really. Having a patch file with a sequence+revision number you can >>>> refer to has its merits. Especially in a hairy thread like this one. >>>> Also one of our MUAs wrapped the lines, I had to undo that manually. >>>> >>>>> Here is why I made the changes, in order: >>>>> >>>>> I doubled the calls to create the connection but one isn't in a >>>>> try/except!? Remove the obvious one. >>>>> >>>>> We currently completely eat GSSAPI errors, I figure we should log >>>>> failures. >>>>> >>>>> IPA stores the principal in the request context so using that will >>>>> save >>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>> >>>>> I included your content-type change. >>>> >>>> These changes look good. >>>> I'm almost done testing but I need to call it a week. >>> >>> Awesome, thanks. >> >> ACK on the functionality. >> >>>> Sorry for not catching that last time, but your patch doesn't add a >>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>> duplicate >>>> unversioned one. So lint (and thus the build) will fail if the old >>>> python-kerberos version is installed. >>>> >>>> A possible a solution to the build trouble would be to just add a lint >>>> exception now, and open a ticket to remove it later. That way the build >>>> succeeds despite the older version, and the new python-kerberos is only >>>> needed when installing freeipa-server-foreman-smartproxy. >>>> That should make everyone happy, including Martin. >>>> Unfortunately our lint exception mechanism doesn't work on modules, so >>>> this needs a somewhat nastier hack. >>>> The attaching a patch that does this (and I'm pasting a simple diff >>>> below). Does that look okay to push? >>> >>> I'm trying to find a better solution to all this. I may end up taking >>> Martin's suggestion of rawhide-only to avoid this sort of thing. >> >> Looks like you'll still need to silence pylint on f20 in that case. >> >>> The deal with the smartproxy is that you can/should be able to run it on >>> any IPA-enrolled client, so you can run it directly on the Foreman box, >>> with the IPA server somewhere else. What this means is that someone >>> could probably fairly easily package this up for other distributions and >>> if we end up with a Fedora-only python-kerberos patch then smartproxy is >>> Fedora-only as well. >>> >>> So I'm trying to get some movement out of upstream on this but it's been >>> crickets for weeks. I think in the context of the calendar server >>> PyKerberos is small potatoes so doesn't get much lovin'. I'll amp up the >>> nagging to get some sort of response, even if it is "stop nagging us!" >>> >>> rob >> >> Good luck! > > Ok, taking a different tack on this. Rather than running it as a > separate server process, run it as a WSGI app inside Apache. This > required a fair bit of re-tooling and complicates the set up a little > bit. I think I've got it all covered in the man page. > > On the python-kerberos front I've got bugs opened in Ubuntu and Debian > to see if we can get the patch accepted their until (if) upstream ever > takes a look. I decided to run the new WSGI app in a different process group, using the smartproxy we use for delegation. This simplifies the connection code, rather than using ldap2 like I was using, we use the RPC interface. And it provides to process separation. As a side-effect it will make running this code on platforms without GSSProxy a bit easier. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-9-rest.patch Type: text/x-patch Size: 47399 bytes Desc: not available URL: From dpal at redhat.com Thu Apr 10 00:57:54 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Apr 2014 20:57:54 -0400 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <534442FA.1060709@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> <534442FA.1060709@redhat.com> Message-ID: <5345EC92.3010008@redhat.com> On 04/08/2014 02:42 PM, Rob Crittenden wrote: > Justin Brown wrote: >> Dmitri, >> >> I'd be more than happy to, but I'm having trouble figuring out where >> it should go. Could you send me a link to a similar design page? >> > > I'd put it under here: http://www.freeipa.org/page/V4_Proposals > > There is a template at http://www.freeipa.org/page/Feature_template > > So maybe something like http://www.freeipa.org/page/V4/Firewalld Rob has beaten me to it, sorry. I reviewed the page. Pretty informative, thank you. Couple comments: a) No replication impact. b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 --forwarder=192.168.0.3 I think you want to add the --firewall at the end c) Please be consistent in one place you use freeipa-.. in other just ipa-.. but this is minor d) No commands or config options. e) It would be really nice to have a bit more information about what kind of methods and calls you plan to use to interact with NetworkManager and FirewallD. If you can spell out something like: Logic: Call NM and get blah using method X For each port in the list call FirewallD method Y f) What would be error handling if something goes wrong? Would it abort or create a special message? g) How should it behave if some ports are already open? Will it print a message or do it silently? h) There is actually impact on restore, restore might also now check that ports are configured in the same way they have been. i) We should probably also record in the rollback log the ports that have been opened and close them back if we have to roll back installation or uninstall server. j) We should differentiate whether the CA is being installed and open CA ports only if the CA component is there. k) We are planning to add other components like DRM and TPS We need to figure out if we would have to do something on the upgades when we add those services to add additional ports. l) I suspect that there be cases where different tools and scripts in IPA would need to check and open ports. This means that we should probably create a reusble library that would provide check and update methods. This is so far what came to mind. Thanks for doing it! Really appreciated. Dmitri > > rob > >> Thanks, >> Justin >> >> On Mon, Apr 7, 2014 at 6:51 PM, Dmitri Pal wrote: >>> On 04/07/2014 09:00 AM, Rob Crittenden wrote: >>>> >>>> Simo Sorce wrote: >>>>> >>>>> On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote: >>>>>> >>>>>> On 4.4.2014 09:17, Martin Kosek wrote: >>>>>>> >>>>>>> On 04/04/2014 09:04 AM, Justin Brown wrote: >>>>>>>>> >>>>>>>>> I would actually do it the opposite way and open the ports >>>>>>>>> after the >>>>>>>>> FreeIPA server is fully configured. After all, I do not think >>>>>>>>> we want to >>>>>>>>> open the ports when the server is just half-configured and for >>>>>>>>> example some >>>>>>>>> ACIs are missing. >>>>>>>> >>>>>>>> >>>>>>>> My thinking was that nothing would be listening on these ports >>>>>>>> if the >>>>>>>> install doesn't succeed, but there's really necessity to modify >>>>>>>> the >>>>>>>> firewall configuration early. (All of the internal install >>>>>>>> communication will be over a local interface (to netfilter) and >>>>>>>> unblock anyways. I don't have any problem in delaying firewall >>>>>>>> configuration to the end of install. >>>>>>> >>>>>>> >>>>>>> If ipa-server-install does succeed without configuring the >>>>>>> firewalld, >>>>>>> then we >>>>>>> will indeed have no other option than to do it early. >>>>>>> >>>>>>> I am thinking that we may want to put all the firewalld >>>>>>> configuration >>>>>>> in >>>>>>> ipaserver/install/firewalldinstance.py, >>>>>>> and then make the firewalld configuration the actual step of the >>>>>>> installation. >>>>>>> Something like: >>>>>>> >>>>>>> ... >>>>>>> Configuring Firewall (firewalld) >>>>>>> [1/2]: looking up the right zone >>>>>>> [2/2]: allowing ports >>>>>>> Done configuring Firewall (firewalld). >>>>>>> ... >>>>>>> >>>>>>> The Service class derived object can be really simple, we would >>>>>>> just >>>>>>> reuse the >>>>>>> functionality it already has + let us properly hook into it in >>>>>>> ipa-{server,replica}-install and the uninstallation. >>>>>>> >>>>>>> It would also make it easier to split this functionality to >>>>>>> freeipa-server-firewalld if we chose to in a future. >>>>>> >>>>>> >>>>>> In general I agree with the idea, thank you Justin for working on >>>>>> that! >>>>>> >>>>>> I would like to emphasis the necessity to work without >>>>>> NetworkManager >>>>>> and >>>>>> FirewallD. New dependencies make Debian folks unhappy ... >>>>>> >>>>>> On the other hand, it is perfectly fine to skip firewall >>>>>> configuration >>>>>> if >>>>>> NM/FirewallD/DBus is not available. >>>>>> >>>>>> Have a nice day! >>>>> >>>>> >>>>> Should be easy, probe for the dbus firewalld service and just skip >>>>> (not >>>>> error out) if it is not there. >>>>> Set a variable in that case that will cause the installer to throw >>>>> the >>>>> classic banner we have now which warns you about what ports need >>>>> to be >>>>> opened at the end of the install. >>>> >>>> >>>> Probably just need to spit out a large, preferably flashing warning >>>> that >>>> the firewall has not been automatically configured. Perhaps even >>>> multiple >>>> times: one in-line and one at the install summary at the end. >>>> >>>> rob >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >>> Thanks for looking into this! >>> >>> Would it be possible to summarize this thread in a design page on >>> the wiki? >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> _______________________________________________ >>> 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 >> > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Thu Apr 10 06:48:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 08:48:49 +0200 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <5345EC92.3010008@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> <534442FA.1060709@redhat.com> <5345EC92.3010008@redhat.com> Message-ID: <53463ED1.4000206@redhat.com> On 04/10/2014 02:57 AM, Dmitri Pal wrote: > On 04/08/2014 02:42 PM, Rob Crittenden wrote: >> Justin Brown wrote: ... > b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 > --forwarder=192.168.0.3 Let's talk about CLI. Shouldn't we add just one option - "--no-firewall"? I would assume that we want to open the firewall ports by default *if* the firewalld is running. If firewalld is not running, ipa-server-install would detect it via DBUS and just simply print warning and would not configure anything and could just maybe spit out iptables configuration as Justin mentioned (optional). Martin From amisnyov at redhat.com Thu Apr 10 09:58:34 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 10 Apr 2014 11:58:34 +0200 Subject: [Freeipa-devel] [PATCH] 0454 Test fixes In-Reply-To: <53314B2C.10705@redhat.com> References: <52E11122.3060401@redhat.com> <52E7C017.3090407@redhat.com> <53314B2C.10705@redhat.com> Message-ID: <20140410115834.14c5f16d@unused-4-246.brq.redhat.com> On Tue, 25 Mar 2014 10:23:56 +0100 Petr Viktorin wrote: > On 01/28/2014 03:35 PM, Petr Viktorin wrote: > > On 01/23/2014 01:54 PM, Petr Viktorin wrote: > [...] > >> Patch 454 changes the cert generation script for CA-less tests to > >> use sequential serial numbers rather than random ones, to prevent > >> collisions. > > > > This one is still useful though. > > Ping, could someone review this? > > all tests ran clean, so ACK Greets Adam From pviktori at redhat.com Thu Apr 10 10:05:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 12:05:57 +0200 Subject: [Freeipa-devel] [PATCH] 0454 Test fixes In-Reply-To: <20140410115834.14c5f16d@unused-4-246.brq.redhat.com> References: <52E11122.3060401@redhat.com> <52E7C017.3090407@redhat.com> <53314B2C.10705@redhat.com> <20140410115834.14c5f16d@unused-4-246.brq.redhat.com> Message-ID: <53466D05.70705@redhat.com> On 04/10/2014 11:58 AM, Misnyovszki Adam wrote: > On Tue, 25 Mar 2014 10:23:56 +0100 > Petr Viktorin wrote: > >> On 01/28/2014 03:35 PM, Petr Viktorin wrote: >>> On 01/23/2014 01:54 PM, Petr Viktorin wrote: >> [...] >>>> Patch 454 changes the cert generation script for CA-less tests to >>>> use sequential serial numbers rather than random ones, to prevent >>>> collisions. >>> >>> This one is still useful though. >> >> Ping, could someone review this? >> >> > > all tests ran clean, so > ACK > > Greets > Adam > Thank you! Pushed to master: 85b8d8d5aeda0bedfab55a4a0e6d15ddc865d59f -- Petr? From pviktori at redhat.com Thu Apr 10 11:44:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 13:44:56 +0200 Subject: [Freeipa-devel] [PATCH] 0514 Add mechanism for adding default permissions to privileges Message-ID: <53468438.8030401@redhat.com> Hello, This allows adding default permissions to privileges. The privileges need to be created before the managed permission updater runs (e.g. via the file-based updater). My updated patch 0513 will use this. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0514-Add-mechanism-for-adding-default-permissions-to-priv.patch Type: text/x-patch Size: 1893 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 10 11:46:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 13:46:43 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <5345648B.2000109@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> Message-ID: <534684A3.4050502@redhat.com> On 04/09/2014 05:17 PM, Martin Kosek wrote: > On 04/09/2014 04:54 PM, Petr Viktorin wrote: >> The meta-permissions. > > :-) > >> Read access is given to all authenticated users. Reading membership info (i.e. >> privileges) is split into a separate permission. >> >> Another permission is added that allows read access to all ACIs. >> If we don't want to open that up for everyone, I could limit this to only ACIs >> containing "permission:". (Since old-style permissions store their information >> in ACIs, their ACIs need to be readable.) > > If I read the notes from our DevConf discussion correctly, there are some > inconsistencies: > > 1) We decided to not do special membership permission for > permission/privilege/role permissions. > > 2) We decided to give read access to permissions, privileges and roles only to > member of a certain privilege. Is there any reason to not do that? IMO, regular > users do not need to be able to read the permission/privilege/role > configuration of a FreeIPA installation to use it for IdM. > > Martin > Updated. I plan to add all the RBAC-related read permissions to a single privilege, "RBAC Readers". Or do we want more granularity by default? Requires my patch 0514. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0513.2-Add-managed-read-permissions-to-permission.patch Type: text/x-patch Size: 3622 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 10 11:56:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 13:56:06 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <5345200B.1010802@redhat.com> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> Message-ID: <534686D6.7010403@redhat.com> On 04/09/2014 12:25 PM, Martin Kosek wrote: > On 04/03/2014 12:09 PM, Petr Viktorin wrote: >> Hello, >> This adds read permissions to read hosts. >> >> Read access is given to all authenticated users. >> For reading host membership info, there is a separate permission that also >> defaults to all authenticated users. >> >> The userPassword attribute is not included for obvious reasons. > > 1) We decided to show hosts only to authenticated users by default. I am just > thinking - should some portion of hosts be readable just like groups and users > are? For example at least the host core defined by nsHost objectlass? > > objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' > SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc > ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) > > Are application supposed to be able to anonymously read that information? I'm not sure. Simo? > 2) Do we want to count enrolledBy and managedBy attribute to "System: Read Host > Membership" permission or should it be included in the "Read Hosts" permission? > > If we want to stick with previous behavior, we would want to have only > "memberOf" listed as this is how our original member handling ACI looks like: > > install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost || > memberUser")(version 3.0; acl "No anonymous access to member information"; deny > (read,search,compare) userdn != "ldap:///all"; What was the reasoning behind enrolledBy and managedBy? I got it from the notes from devconf; I don't think there was much discussion. > 3) I could not functionally test if e.g. clients and replicas still enroll as > we do not have an ACI for krbtpolicy/krbRealmContainer yet and > ipa-client-install searches for it. > > Speaking of which, we will need to have an ACI for reading a portion of > krbRealmContainer anonymously to enable IPA client autodiscovery > (cn+objectclass should be sufficient). > > We can wait with the functional testing until you get to krbRealmContainer though. Yes, it's still quite early for functional testing. -- Petr? From mkosek at redhat.com Thu Apr 10 12:49:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 14:49:58 +0200 Subject: [Freeipa-devel] [PATCH] 0514 Add mechanism for adding default permissions to privileges In-Reply-To: <53468438.8030401@redhat.com> References: <53468438.8030401@redhat.com> Message-ID: <53469376.60807@redhat.com> On 04/10/2014 01:44 PM, Petr Viktorin wrote: > Hello, > This allows adding default permissions to privileges. > The privileges need to be created before the managed permission updater runs > (e.g. via the file-based updater). > > My updated patch 0513 will use this. > ACK. Works fine. Pushed to master: 41607774bc6146f83496bd469d59595261e314a7 Martin From simo at redhat.com Thu Apr 10 12:52:24 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 10 Apr 2014 08:52:24 -0400 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <534686D6.7010403@redhat.com> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> Message-ID: <1397134344.19767.79.camel@willson.li.ssimo.org> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: > On 04/09/2014 12:25 PM, Martin Kosek wrote: > > On 04/03/2014 12:09 PM, Petr Viktorin wrote: > >> Hello, > >> This adds read permissions to read hosts. > >> > >> Read access is given to all authenticated users. > >> For reading host membership info, there is a separate permission that also > >> defaults to all authenticated users. > >> > >> The userPassword attribute is not included for obvious reasons. > > > > 1) We decided to show hosts only to authenticated users by default. I am just > > thinking - should some portion of hosts be readable just like groups and users > > are? For example at least the host core defined by nsHost objectlass? > > > > objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' > > SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc > > ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) > > > > Are application supposed to be able to anonymously read that information? > > I'm not sure. Simo? Good question, probably not by default, we offer DNS and do not recommend people to rely on exposed host maps. > > 2) Do we want to count enrolledBy and managedBy attribute to "System: Read Host > > Membership" permission or should it be included in the "Read Hosts" permission? > > > > If we want to stick with previous behavior, we would want to have only > > "memberOf" listed as this is how our original member handling ACI looks like: > > > > install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost || > > memberUser")(version 3.0; acl "No anonymous access to member information"; deny > > (read,search,compare) userdn != "ldap:///all"; > > What was the reasoning behind enrolledBy and managedBy? I got it from > the notes from devconf; I don't think there was much discussion. I have no recollection :( > > 3) I could not functionally test if e.g. clients and replicas still enroll as > > we do not have an ACI for krbtpolicy/krbRealmContainer yet and > > ipa-client-install searches for it. > > > > Speaking of which, we will need to have an ACI for reading a portion of > > krbRealmContainer anonymously to enable IPA client autodiscovery > > (cn+objectclass should be sufficient). Sad we ended up depending on this, I would have preferred to not depend on keeping this around if we ever want to change something. > > We can wait with the functional testing until you get to krbRealmContainer though. > > Yes, it's still quite early for functional testing. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Apr 10 12:58:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 14:58:04 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <534684A3.4050502@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> Message-ID: <5346955C.4080008@redhat.com> On 04/10/2014 01:46 PM, Petr Viktorin wrote: > On 04/09/2014 05:17 PM, Martin Kosek wrote: >> On 04/09/2014 04:54 PM, Petr Viktorin wrote: >>> The meta-permissions. >> >> :-) >> >>> Read access is given to all authenticated users. Reading membership info (i.e. >>> privileges) is split into a separate permission. >>> >>> Another permission is added that allows read access to all ACIs. >>> If we don't want to open that up for everyone, I could limit this to only ACIs >>> containing "permission:". (Since old-style permissions store their information >>> in ACIs, their ACIs need to be readable.) >> >> If I read the notes from our DevConf discussion correctly, there are some >> inconsistencies: >> >> 1) We decided to not do special membership permission for >> permission/privilege/role permissions. >> >> 2) We decided to give read access to permissions, privileges and roles only to >> member of a certain privilege. Is there any reason to not do that? IMO, regular >> users do not need to be able to read the permission/privilege/role >> configuration of a FreeIPA installation to use it for IdM. >> >> Martin >> > > Updated. I plan to add all the RBAC-related read permissions to a single > privilege, "RBAC Readers". Or do we want more granularity by default? > > Requires my patch 0514. I was looking at the granularity we currently have with privilege and it is mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per IPA object (Sudo Command Administrator, Sudo Rule Administrator). I would thus follow the same principle with RBAC and create RBAC Administrator privilege which will cover read permissions for... permissions... privileges and roles. In time, we will also add new write privileges there as they are currently missing. To sum it up, the patch works, I would just change the name of the privilege and not focus it just on reading. Martin From pviktori at redhat.com Thu Apr 10 13:02:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 15:02:02 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <5346955C.4080008@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> <5346955C.4080008@redhat.com> Message-ID: <5346964A.5000806@redhat.com> On 04/10/2014 02:58 PM, Martin Kosek wrote: > On 04/10/2014 01:46 PM, Petr Viktorin wrote: >> On 04/09/2014 05:17 PM, Martin Kosek wrote: >>> On 04/09/2014 04:54 PM, Petr Viktorin wrote: >>>> The meta-permissions. >>> >>> :-) >>> >>>> Read access is given to all authenticated users. Reading membership info (i.e. >>>> privileges) is split into a separate permission. >>>> >>>> Another permission is added that allows read access to all ACIs. >>>> If we don't want to open that up for everyone, I could limit this to only ACIs >>>> containing "permission:". (Since old-style permissions store their information >>>> in ACIs, their ACIs need to be readable.) >>> >>> If I read the notes from our DevConf discussion correctly, there are some >>> inconsistencies: >>> >>> 1) We decided to not do special membership permission for >>> permission/privilege/role permissions. >>> >>> 2) We decided to give read access to permissions, privileges and roles only to >>> member of a certain privilege. Is there any reason to not do that? IMO, regular >>> users do not need to be able to read the permission/privilege/role >>> configuration of a FreeIPA installation to use it for IdM. >>> >>> Martin >>> >> >> Updated. I plan to add all the RBAC-related read permissions to a single >> privilege, "RBAC Readers". Or do we want more granularity by default? >> >> Requires my patch 0514. > > I was looking at the granularity we currently have with privilege and it is > mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per > IPA object (Sudo Command Administrator, Sudo Rule Administrator). > > I would thus follow the same principle with RBAC and create RBAC Administrator > privilege which will cover read permissions for... permissions... privileges > and roles. In time, we will also add new write privileges there as they are > currently missing. > > To sum it up, the patch works, I would just change the name of the privilege > and not focus it just on reading. So to confirm, we want one privilege to cover both reading and writing? Should I add new read permissions to existing "Administrator" privileges only, instead of creating new "Reader" permissions? -- Petr? From mkosek at redhat.com Thu Apr 10 13:04:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 15:04:21 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <1397134344.19767.79.camel@willson.li.ssimo.org> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> <1397134344.19767.79.camel@willson.li.ssimo.org> Message-ID: <534696D5.8080000@redhat.com> On 04/10/2014 02:52 PM, Simo Sorce wrote: > On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: >> On 04/09/2014 12:25 PM, Martin Kosek wrote: >>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>> Hello, >>>> This adds read permissions to read hosts. >>>> >>>> Read access is given to all authenticated users. >>>> For reading host membership info, there is a separate permission that also >>>> defaults to all authenticated users. >>>> >>>> The userPassword attribute is not included for obvious reasons. >>> >>> 1) We decided to show hosts only to authenticated users by default. I am just >>> thinking - should some portion of hosts be readable just like groups and users >>> are? For example at least the host core defined by nsHost objectlass? >>> >>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' >>> SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc >>> ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) >>> >>> Are application supposed to be able to anonymously read that information? >> >> I'm not sure. Simo? > > Good question, probably not by default, we offer DNS and do not > recommend people to rely on exposed host maps. Question is if should have a separate permission like "System: Read Host Core Attributes", "System: Read Host", "System: Read Host Membership" or we are fine with just "System: Read Host", "System: Read Host Membership". If we do not expect people and programs to often read the list of host or the basic host information anonymously, I would stick with the latter. > >>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read Host >>> Membership" permission or should it be included in the "Read Hosts" permission? >>> >>> If we want to stick with previous behavior, we would want to have only >>> "memberOf" listed as this is how our original member handling ACI looks like: >>> >>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost || >>> memberUser")(version 3.0; acl "No anonymous access to member information"; deny >>> (read,search,compare) userdn != "ldap:///all"; >> >> What was the reasoning behind enrolledBy and managedBy? I got it from >> the notes from devconf; I don't think there was much discussion. > > I have no recollection :( There was no discussion about these particular attributes. I added then to Membership permission because they were DN-ish, but when I think more about it, it does not seem as a membership in the sense of the ACI above. I would personally only keep member/memberOf in the Membership attributes. >>> 3) I could not functionally test if e.g. clients and replicas still enroll as >>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and >>> ipa-client-install searches for it. >>> >>> Speaking of which, we will need to have an ACI for reading a portion of >>> krbRealmContainer anonymously to enable IPA client autodiscovery >>> (cn+objectclass should be sufficient). > > Sad we ended up depending on this, I would have preferred to not depend > on keeping this around if we ever want to change something. Yeah... But we should be OK with exposing just the CN which is not really a secret as we know what is the realm name... Martin From mkosek at redhat.com Thu Apr 10 13:07:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 15:07:36 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <5346964A.5000806@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> <5346955C.4080008@redhat.com> <5346964A.5000806@redhat.com> Message-ID: <53469798.8050907@redhat.com> On 04/10/2014 03:02 PM, Petr Viktorin wrote: > On 04/10/2014 02:58 PM, Martin Kosek wrote: >> On 04/10/2014 01:46 PM, Petr Viktorin wrote: >>> On 04/09/2014 05:17 PM, Martin Kosek wrote: >>>> On 04/09/2014 04:54 PM, Petr Viktorin wrote: >>>>> The meta-permissions. >>>> >>>> :-) >>>> >>>>> Read access is given to all authenticated users. Reading membership info >>>>> (i.e. >>>>> privileges) is split into a separate permission. >>>>> >>>>> Another permission is added that allows read access to all ACIs. >>>>> If we don't want to open that up for everyone, I could limit this to only >>>>> ACIs >>>>> containing "permission:". (Since old-style permissions store their >>>>> information >>>>> in ACIs, their ACIs need to be readable.) >>>> >>>> If I read the notes from our DevConf discussion correctly, there are some >>>> inconsistencies: >>>> >>>> 1) We decided to not do special membership permission for >>>> permission/privilege/role permissions. >>>> >>>> 2) We decided to give read access to permissions, privileges and roles only to >>>> member of a certain privilege. Is there any reason to not do that? IMO, >>>> regular >>>> users do not need to be able to read the permission/privilege/role >>>> configuration of a FreeIPA installation to use it for IdM. >>>> >>>> Martin >>>> >>> >>> Updated. I plan to add all the RBAC-related read permissions to a single >>> privilege, "RBAC Readers". Or do we want more granularity by default? >>> >>> Requires my patch 0514. >> >> I was looking at the granularity we currently have with privilege and it is >> mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per >> IPA object (Sudo Command Administrator, Sudo Rule Administrator). >> >> I would thus follow the same principle with RBAC and create RBAC Administrator >> privilege which will cover read permissions for... permissions... privileges >> and roles. In time, we will also add new write privileges there as they are >> currently missing. >> >> To sum it up, the patch works, I would just change the name of the privilege >> and not focus it just on reading. > > So to confirm, we want one privilege to cover both reading and writing? IMO, yes. > Should I add new read permissions to existing "Administrator" privileges only, > instead of creating new "Reader" permissions? I don't think so. The read permission we have been adding so far were targetted on anonymous/all binds, thus according to our design, they cannot be added to privilege anyway. But if someone wants to restrict an object, he is free to change the permission bind type to "group based" and assign it to a privilege. In our case, I would assign read permission to privilege only if we decided to make them group based, like RBAC or krbtpolicy ones. Martin From ssorce at redhat.com Thu Apr 10 13:07:41 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Apr 2014 09:07:41 -0400 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <5346964A.5000806@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> <5346955C.4080008@redhat.com> <5346964A.5000806@redhat.com> Message-ID: <1397135261.19767.80.camel@willson.li.ssimo.org> On Thu, 2014-04-10 at 15:02 +0200, Petr Viktorin wrote: > On 04/10/2014 02:58 PM, Martin Kosek wrote: > > On 04/10/2014 01:46 PM, Petr Viktorin wrote: > >> On 04/09/2014 05:17 PM, Martin Kosek wrote: > >>> On 04/09/2014 04:54 PM, Petr Viktorin wrote: > >>>> The meta-permissions. > >>> > >>> :-) > >>> > >>>> Read access is given to all authenticated users. Reading membership info (i.e. > >>>> privileges) is split into a separate permission. > >>>> > >>>> Another permission is added that allows read access to all ACIs. > >>>> If we don't want to open that up for everyone, I could limit this to only ACIs > >>>> containing "permission:". (Since old-style permissions store their information > >>>> in ACIs, their ACIs need to be readable.) > >>> > >>> If I read the notes from our DevConf discussion correctly, there are some > >>> inconsistencies: > >>> > >>> 1) We decided to not do special membership permission for > >>> permission/privilege/role permissions. > >>> > >>> 2) We decided to give read access to permissions, privileges and roles only to > >>> member of a certain privilege. Is there any reason to not do that? IMO, regular > >>> users do not need to be able to read the permission/privilege/role > >>> configuration of a FreeIPA installation to use it for IdM. > >>> > >>> Martin > >>> > >> > >> Updated. I plan to add all the RBAC-related read permissions to a single > >> privilege, "RBAC Readers". Or do we want more granularity by default? > >> > >> Requires my patch 0514. > > > > I was looking at the granularity we currently have with privilege and it is > > mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per > > IPA object (Sudo Command Administrator, Sudo Rule Administrator). > > > > I would thus follow the same principle with RBAC and create RBAC Administrator > > privilege which will cover read permissions for... permissions... privileges > > and roles. In time, we will also add new write privileges there as they are > > currently missing. > > > > To sum it up, the patch works, I would just change the name of the privilege > > and not focus it just on reading. > > So to confirm, we want one privilege to cover both reading and writing? > Should I add new read permissions to existing "Administrator" privileges > only, instead of creating new "Reader" permissions? There may be people that need only reading, so a separate privilege for just reading is usually a good idea. Simo. From mkosek at redhat.com Thu Apr 10 13:09:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 15:09:18 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <1397135261.19767.80.camel@willson.li.ssimo.org> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> <5346955C.4080008@redhat.com> <5346964A.5000806@redhat.com> <1397135261.19767.80.camel@willson.li.ssimo.org> Message-ID: <534697FE.2060200@redhat.com> On 04/10/2014 03:07 PM, Simo Sorce wrote: > On Thu, 2014-04-10 at 15:02 +0200, Petr Viktorin wrote: >> On 04/10/2014 02:58 PM, Martin Kosek wrote: >>> On 04/10/2014 01:46 PM, Petr Viktorin wrote: >>>> On 04/09/2014 05:17 PM, Martin Kosek wrote: >>>>> On 04/09/2014 04:54 PM, Petr Viktorin wrote: >>>>>> The meta-permissions. >>>>> >>>>> :-) >>>>> >>>>>> Read access is given to all authenticated users. Reading membership info (i.e. >>>>>> privileges) is split into a separate permission. >>>>>> >>>>>> Another permission is added that allows read access to all ACIs. >>>>>> If we don't want to open that up for everyone, I could limit this to only ACIs >>>>>> containing "permission:". (Since old-style permissions store their information >>>>>> in ACIs, their ACIs need to be readable.) >>>>> >>>>> If I read the notes from our DevConf discussion correctly, there are some >>>>> inconsistencies: >>>>> >>>>> 1) We decided to not do special membership permission for >>>>> permission/privilege/role permissions. >>>>> >>>>> 2) We decided to give read access to permissions, privileges and roles only to >>>>> member of a certain privilege. Is there any reason to not do that? IMO, regular >>>>> users do not need to be able to read the permission/privilege/role >>>>> configuration of a FreeIPA installation to use it for IdM. >>>>> >>>>> Martin >>>>> >>>> >>>> Updated. I plan to add all the RBAC-related read permissions to a single >>>> privilege, "RBAC Readers". Or do we want more granularity by default? >>>> >>>> Requires my patch 0514. >>> >>> I was looking at the granularity we currently have with privilege and it is >>> mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per >>> IPA object (Sudo Command Administrator, Sudo Rule Administrator). >>> >>> I would thus follow the same principle with RBAC and create RBAC Administrator >>> privilege which will cover read permissions for... permissions... privileges >>> and roles. In time, we will also add new write privileges there as they are >>> currently missing. >>> >>> To sum it up, the patch works, I would just change the name of the privilege >>> and not focus it just on reading. >> >> So to confirm, we want one privilege to cover both reading and writing? >> Should I add new read permissions to existing "Administrator" privileges >> only, instead of creating new "Reader" permissions? > > There may be people that need only reading, so a separate privilege for > just reading is usually a good idea. > > Simo. You were faster than me, see my other response in this thread. I would personally not spam our privilege list with unused privileges and let people create them when they really need it. Our default permission/privileges should be the one that fits the most people and is our recommended ACI model. Others may simply add privileges and change it. Martin From pviktori at redhat.com Thu Apr 10 13:10:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 15:10:34 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <53469798.8050907@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> <5346955C.4080008@redhat.com> <5346964A.5000806@redhat.com> <53469798.8050907@redhat.com> Message-ID: <5346984A.2030003@redhat.com> On 04/10/2014 03:07 PM, Martin Kosek wrote: > On 04/10/2014 03:02 PM, Petr Viktorin wrote: >> On 04/10/2014 02:58 PM, Martin Kosek wrote: >>> On 04/10/2014 01:46 PM, Petr Viktorin wrote: >>>> On 04/09/2014 05:17 PM, Martin Kosek wrote: >>>>> On 04/09/2014 04:54 PM, Petr Viktorin wrote: >>>>>> The meta-permissions. >>>>> >>>>> :-) >>>>> >>>>>> Read access is given to all authenticated users. Reading membership info >>>>>> (i.e. >>>>>> privileges) is split into a separate permission. >>>>>> >>>>>> Another permission is added that allows read access to all ACIs. >>>>>> If we don't want to open that up for everyone, I could limit this to only >>>>>> ACIs >>>>>> containing "permission:". (Since old-style permissions store their >>>>>> information >>>>>> in ACIs, their ACIs need to be readable.) >>>>> >>>>> If I read the notes from our DevConf discussion correctly, there are some >>>>> inconsistencies: >>>>> >>>>> 1) We decided to not do special membership permission for >>>>> permission/privilege/role permissions. >>>>> >>>>> 2) We decided to give read access to permissions, privileges and roles only to >>>>> member of a certain privilege. Is there any reason to not do that? IMO, >>>>> regular >>>>> users do not need to be able to read the permission/privilege/role >>>>> configuration of a FreeIPA installation to use it for IdM. >>>>> >>>>> Martin >>>>> >>>> >>>> Updated. I plan to add all the RBAC-related read permissions to a single >>>> privilege, "RBAC Readers". Or do we want more granularity by default? >>>> >>>> Requires my patch 0514. >>> >>> I was looking at the granularity we currently have with privilege and it is >>> mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per >>> IPA object (Sudo Command Administrator, Sudo Rule Administrator). >>> >>> I would thus follow the same principle with RBAC and create RBAC Administrator >>> privilege which will cover read permissions for... permissions... privileges >>> and roles. In time, we will also add new write privileges there as they are >>> currently missing. >>> >>> To sum it up, the patch works, I would just change the name of the privilege >>> and not focus it just on reading. >> >> So to confirm, we want one privilege to cover both reading and writing? > > IMO, yes. > >> Should I add new read permissions to existing "Administrator" privileges only, >> instead of creating new "Reader" permissions? > > I don't think so. The read permission we have been adding so far were targetted > on anonymous/all binds, thus according to our design, they cannot be added to > privilege anyway. > > But if someone wants to restrict an object, he is free to change the permission > bind type to "group based" and assign it to a privilege. > > In our case, I would assign read permission to privilege only if we decided to > make them group based, like RBAC or krbtpolicy ones. Right, that makes sense. I'm asking about not having separate read privileges when the permissions are group based. Based on Simo's other mail we should have separate "Read" privileges. Also IMO the read permissions should then be added both to the "Reader" and "Administrator" privileges, since it doesn't make sense to be able to write but not read. -- Petr? From mkosek at redhat.com Thu Apr 10 13:20:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 15:20:52 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to permission In-Reply-To: <5346984A.2030003@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> <5346955C.4080008@redhat.com> <5346964A.5000806@redhat.com> <53469798.8050907@redhat.com> <5346984A.2030003@redhat.com> Message-ID: <53469AB4.8050505@redhat.com> On 04/10/2014 03:10 PM, Petr Viktorin wrote: > On 04/10/2014 03:07 PM, Martin Kosek wrote: >> On 04/10/2014 03:02 PM, Petr Viktorin wrote: >>> On 04/10/2014 02:58 PM, Martin Kosek wrote: >>>> On 04/10/2014 01:46 PM, Petr Viktorin wrote: >>>>> On 04/09/2014 05:17 PM, Martin Kosek wrote: >>>>>> On 04/09/2014 04:54 PM, Petr Viktorin wrote: >>>>>>> The meta-permissions. >>>>>> >>>>>> :-) >>>>>> >>>>>>> Read access is given to all authenticated users. Reading membership info >>>>>>> (i.e. >>>>>>> privileges) is split into a separate permission. >>>>>>> >>>>>>> Another permission is added that allows read access to all ACIs. >>>>>>> If we don't want to open that up for everyone, I could limit this to only >>>>>>> ACIs >>>>>>> containing "permission:". (Since old-style permissions store their >>>>>>> information >>>>>>> in ACIs, their ACIs need to be readable.) >>>>>> >>>>>> If I read the notes from our DevConf discussion correctly, there are some >>>>>> inconsistencies: >>>>>> >>>>>> 1) We decided to not do special membership permission for >>>>>> permission/privilege/role permissions. >>>>>> >>>>>> 2) We decided to give read access to permissions, privileges and roles >>>>>> only to >>>>>> member of a certain privilege. Is there any reason to not do that? IMO, >>>>>> regular >>>>>> users do not need to be able to read the permission/privilege/role >>>>>> configuration of a FreeIPA installation to use it for IdM. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Updated. I plan to add all the RBAC-related read permissions to a single >>>>> privilege, "RBAC Readers". Or do we want more granularity by default? >>>>> >>>>> Requires my patch 0514. >>>> >>>> I was looking at the granularity we currently have with privilege and it is >>>> mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per >>>> IPA object (Sudo Command Administrator, Sudo Rule Administrator). >>>> >>>> I would thus follow the same principle with RBAC and create RBAC Administrator >>>> privilege which will cover read permissions for... permissions... privileges >>>> and roles. In time, we will also add new write privileges there as they are >>>> currently missing. >>>> >>>> To sum it up, the patch works, I would just change the name of the privilege >>>> and not focus it just on reading. >>> >>> So to confirm, we want one privilege to cover both reading and writing? >> >> IMO, yes. >> >>> Should I add new read permissions to existing "Administrator" privileges only, >>> instead of creating new "Reader" permissions? >> >> I don't think so. The read permission we have been adding so far were targetted >> on anonymous/all binds, thus according to our design, they cannot be added to >> privilege anyway. >> >> But if someone wants to restrict an object, he is free to change the permission >> bind type to "group based" and assign it to a privilege. >> >> In our case, I would assign read permission to privilege only if we decided to >> make them group based, like RBAC or krbtpolicy ones. > > Right, that makes sense. I'm asking about not having separate read privileges > when the permissions are group based. Based on Simo's other mail we should have > separate "Read" privileges. > > Also IMO the read permissions should then be added both to the "Reader" and > "Administrator" privileges, since it doesn't make sense to be able to write but > not read. Ah, I understand the question now. This assumes that people may often want to allow a certain group of people to read RBAC or to read ticket policy. I would assume that a more frequent usage would be that administrator would allow all authenticated users read an object (which makes Read group redundant). But I am not insisting, I am open to both approaches. Martin From pviktori at redhat.com Thu Apr 10 13:30:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 15:30:48 +0200 Subject: [Freeipa-devel] [PATCH] 0515 Add managed read permission for SELinux user map Message-ID: <53469D08.2040707@redhat.com> Read access is given to all authenticated users. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0515-Add-managed-read-permission-for-SELinux-user-map.patch Type: text/x-patch Size: 1791 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 10 13:55:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 15:55:49 +0200 Subject: [Freeipa-devel] [PATCH] 0516 Add managed read permissions to realmdomains Message-ID: <5346A2E5.9070207@redhat.com> Read access is given to all authenticated users. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0516-Add-managed-read-permissions-to-realmdomains.patch Type: text/x-patch Size: 1411 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 10 14:41:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Apr 2014 16:41:03 +0200 Subject: [Freeipa-devel] [PATCH] 260 Fix update_ca_renewal_master plugin on CA-less installs In-Reply-To: <533BD4AA.6040705@redhat.com> References: <533BD4AA.6040705@redhat.com> Message-ID: <5346AD7F.809@redhat.com> On 04/02/2014 11:13 AM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > Works for me in both CA-less and CA-ful, ACK. Pushed to master: 50c7f3b2366aa48a966a958a7f95941c917ad3fa Martin From jcholast at redhat.com Thu Apr 10 14:52:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Apr 2014 16:52:23 +0200 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <5342E9DD.2070307@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> Message-ID: <5346B027.5020407@redhat.com> On 7.4.2014 20:09, Rob Crittenden wrote: > Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches implement automatic CA certificate renewal as well >>> as the initial version of the CA certificate management tool. >>> >>> Requires my patches 172-196. >>> >>> In order to test, you must install current git version of certmonger >>> (see ) and set SELinux to >>> permissive (see ). >>> Make sure you install certmonger before running >>> ipa-server-install/ipa-replica-install. On F20 you can use RPMs located >>> at . >>> >>> To test automatic renewal, move system time forward (see >>> for more info >>> about certificate renewal testing, nickname of the CA certificate is >>> "caSigningCert cert-pki-ca"). In CA-full installs the renewal should be >>> fully automatic, in CA-less installs you should be alerted via syslog to >>> renew the certificate using ipa-cacert-manage. >>> >>> To test manual renewal, run "ipa-cacert-manage renew". You can run it on >>> any CA master. To make the renewed certificate available on other CA >>> masters, you must run "getcert resubmit -d /etc/pki/pki-tomcat/alias -n >>> 'caSigningCert cert-pki-ca'" on each of them. Note that currently you >>> can't change the chaining of the CA certificate. >> >> 241 >> >> Not to be too anal, but would it be too outlandish to compare the >> Authority Key Identifier (if there is one) with the Subject Key ID to >> see if the cert is self-signed? Same subject then yeah, it is probably >> self-signed. The keys match? Definitely. Authority key identifier is not mandatory, so it's not good enough. You could verify the certificate's signature with its public key, but I haven't figured out how to do that in python-nss. Also, if someone uses the subject name of the issuer for their CA certificate, I think they will run into all kinds of problems anyway. >> >> 242 >> >> I wonder if it would be clearer to use variables instead of a raw list >> in the return value for these handlers: (result, message) = handler(...) >> rather than examining result[0], etc. That may be beyond the scope of >> this patch though. Yes. It would be nice if certmonger included a Python module for helper scripts... >> >> x509.normalize_certificate() can raise an exception, there should be a >> try/except around it. If there is an exception, it will be caught in the try/except block at the end of the script. >> >> For an invalid cookie, please include the values seen in the environment >> in the error message. Added. >> >> 243 >> >> You are going to end up with a lot of acis with the same comment value. >> Perhaps add the host in there as well. >> >> These are not removed when a master is deleted. I merely did the same thing as the "Add CA Certificates for renewals" and "Modify CA Certificates for renewals" ACIs. I agree it's suboptimal, but IMO it should be fixed in the scope of (the "ipa masters hostgroup" part). >> >> 244 >> >> There are now several different places where the caCertificate value is >> updated. I wonder if it's time for a function. I found it it in >> dsinstance.py, upload_cacert and now renew_ca_cert. I have a patch for that, but I haven't posted it yet, since there are some other changes in it as well. >> >> 246 >> >> caRenewalMaster should be checked when a replica is deleted and moved to >> another master. This is a good idea. I wonder if a ticket should be >> opened to do something similar for CRL generation. Add new patch 262 for this. +1 on doing the same for CRL generation. >> >> 247 >> >> We've been burned by hardcoded timeouts in the past. Should this be >> configurable? This module doesn't currently do any logging but it might >> be worth spitting out a "waiting" message, at least for debugging. Added a timeout argument. I had logging in the code before, but I removed it when I moved the code to ipapython.certmonger. Silly me. Fixed. >> >> 249 >> >> nss_init() is always scary to me since we can only have one. I didn't >> see anything blow up, just wondering if this should be wrapped with an >> is_initialized()->shutdown() at the top. Fixed (also for verify_server_cert_validity). >> >> The find_cert_from_nickname() should be in a try/except in case the cert >> is not found for some reason. I want the exception to be propagated to the caller in such case. >> >> 251 >> >> The tool should provide some feedback while it's running. For the >> impatient (me) it takes a really long time and it's hard to know what is >> going on, something in between nothing and full debug output. Added some messages about what's going on. >> >> The man page needs some more work too. I think some more explanation is >> needed and an example would probably be really helpful as well. I think >> particularly an example for external certs and a description of what you >> mean by Self-signed CA (I assume you mean IPA-provided). I don't think >> it really matters how many steps there are unless you are going to >> provide progress output. Reworded the man page a little bit. >> >> Got a backtrace when running as non-root: >> >> $ ipa-cacert-manage -v renew >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 168, in >> execute >> self.validate_options() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >> >> line 62, in validate_options >> super(CACertManage, self).validate_options(needs_root=True) >> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >> 189, in validate_options >> raise ScriptError('Must be root to run %s' % self.command_name, 1) >> >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >> ipa-cacert-manage command failed, exception: ScriptError: Must be root >> to run ipa-cacert-manage >> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be >> root to run ipa-cacert-manage That's correct, you can run it only as root, because you can't resubmit certmonger requests as a regular user. >> >> 252 >> >> In what context would this be executing? My guess is that certmonger is >> trying to do the renewal but a new cert hasn't been issued yet, so this >> gets sysloged? If you have an externally signed CA that's about to expire and the renewed version of it is not available in LDAP, then the message gets syslogged. >> >> Still doing functional testing. > > My current scenario: > > 1. Newly installed IPA master with these patches. > 2. Replica using IPA 3.3.4 (yeah, I cheated) > > While doing time travel I had a single cert fail on the initial master > with this: > > ca-error: Server at https://lyra.example.com/ipa/xml failed > request, will retry: 4204 (RPC failed at server. limits exceeded for > this query). > > Mar 21 11:00:22 lyra ns-slapd: GSSAPI Error: Unspecified GSS failure. > Minor code may provide more information (Cannot contact any KDC for > realm 'EXAMPLE.COM') > Mar 21 11:00:22 lyra certmonger: 2016-03-21 11:00:22 [28676] Server at > https://lyra.example.com/ipa/xml failed request, will retry: 4204 (RPC > failed at server. limits exceeded for this query). > > From the access log: > > [21/Mar/2016:11:00:21 -0400] conn=49 op=5 SRCH > base="krbprincipalname=HTTP/lyra.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com" > scope=0 filter="(objectClass=*)" attrs="userCertificate krbPrincipalName > * ipaKrbAuthzData managedBy aci" > [21/Mar/2016:11:00:21 -0400] conn=49 op=5 RESULT err=3 tag=101 > nentries=0 etime=17 > > So yeah, 17 seconds is a long time. > > A resubmit fixed it and certmonger would have done this automatically if > I had the patience, so not too worried about that. OK. > > After moving time forward on the replica these certificates are in > CA_WORKING: > > ipaCert > auditSigningCert cert-pki-ca > ocspSigningCert cert-pki-ca > subsystemCert cert-pki-ca > > cn=ca_renewal is completely empty on the replica. On the master it only > has the subsystemCert. I'm guessing this is at least partly due to my > switching time one system at a time rather than (somewhat) > simultaneously, but it still would have blown up with 3 missing certs. Can you post the related log messages from /var/log/messages from the master somewhere? There's not much I can do about broken replication. I think you hit . > > rob Thanks for the review. Updated and rebased patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.1-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.1-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.1-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1130 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.1-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2304 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.1-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.1-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.1-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.1-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 6022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.1-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 2036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.1-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 2917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.1-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 16368 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.1-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1717 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.1-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3780 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 10 15:03:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 17:03:38 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to RBAC objects In-Reply-To: <53469AB4.8050505@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> <5346955C.4080008@redhat.com> <5346964A.5000806@redhat.com> <53469798.8050907@redhat.com> <5346984A.2030003@redhat.com> <53469AB4.8050505@redhat.com> Message-ID: <5346B2CA.5070902@redhat.com> On 04/10/2014 03:20 PM, Martin Kosek wrote: > On 04/10/2014 03:10 PM, Petr Viktorin wrote: >> On 04/10/2014 03:07 PM, Martin Kosek wrote: >>> On 04/10/2014 03:02 PM, Petr Viktorin wrote: >>>> On 04/10/2014 02:58 PM, Martin Kosek wrote: >>>>> On 04/10/2014 01:46 PM, Petr Viktorin wrote: >>>>>> On 04/09/2014 05:17 PM, Martin Kosek wrote: >>>>>>> On 04/09/2014 04:54 PM, Petr Viktorin wrote: >>>>>>>> The meta-permissions. >>>>>>> >>>>>>> :-) >>>>>>> >>>>>>>> Read access is given to all authenticated users. Reading membership info >>>>>>>> (i.e. >>>>>>>> privileges) is split into a separate permission. >>>>>>>> >>>>>>>> Another permission is added that allows read access to all ACIs. >>>>>>>> If we don't want to open that up for everyone, I could limit this to only >>>>>>>> ACIs >>>>>>>> containing "permission:". (Since old-style permissions store their >>>>>>>> information >>>>>>>> in ACIs, their ACIs need to be readable.) >>>>>>> >>>>>>> If I read the notes from our DevConf discussion correctly, there are some >>>>>>> inconsistencies: >>>>>>> >>>>>>> 1) We decided to not do special membership permission for >>>>>>> permission/privilege/role permissions. >>>>>>> >>>>>>> 2) We decided to give read access to permissions, privileges and roles >>>>>>> only to >>>>>>> member of a certain privilege. Is there any reason to not do that? IMO, >>>>>>> regular >>>>>>> users do not need to be able to read the permission/privilege/role >>>>>>> configuration of a FreeIPA installation to use it for IdM. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> Updated. I plan to add all the RBAC-related read permissions to a single >>>>>> privilege, "RBAC Readers". Or do we want more granularity by default? >>>>>> >>>>>> Requires my patch 0514. >>>>> >>>>> I was looking at the granularity we currently have with privilege and it is >>>>> mostly per FreeIPA function (Sudo Administrator or DNS Administrator), not per >>>>> IPA object (Sudo Command Administrator, Sudo Rule Administrator). >>>>> >>>>> I would thus follow the same principle with RBAC and create RBAC Administrator >>>>> privilege which will cover read permissions for... permissions... privileges >>>>> and roles. In time, we will also add new write privileges there as they are >>>>> currently missing. >>>>> >>>>> To sum it up, the patch works, I would just change the name of the privilege >>>>> and not focus it just on reading. >>>> >>>> So to confirm, we want one privilege to cover both reading and writing? >>> >>> IMO, yes. >>> >>>> Should I add new read permissions to existing "Administrator" privileges only, >>>> instead of creating new "Reader" permissions? >>> >>> I don't think so. The read permission we have been adding so far were targetted >>> on anonymous/all binds, thus according to our design, they cannot be added to >>> privilege anyway. >>> >>> But if someone wants to restrict an object, he is free to change the permission >>> bind type to "group based" and assign it to a privilege. >>> >>> In our case, I would assign read permission to privilege only if we decided to >>> make them group based, like RBAC or krbtpolicy ones. >> >> Right, that makes sense. I'm asking about not having separate read privileges >> when the permissions are group based. Based on Simo's other mail we should have >> separate "Read" privileges. >> >> Also IMO the read permissions should then be added both to the "Reader" and >> "Administrator" privileges, since it doesn't make sense to be able to write but >> not read. > > Ah, I understand the question now. This assumes that people may often want to > allow a certain group of people to read RBAC or to read ticket policy. > > I would assume that a more frequent usage would be that administrator would > allow all authenticated users read an object (which makes Read group > redundant). But I am not insisting, I am open to both approaches. I think it's reasonable to give read (but not write) access to lower-level admins only. Here is an updated patch. I've added read for privileges and roles too, so the 'RBAC Readers' privilege should be complete. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0513.3-Add-managed-read-permissions-to-RBAC-objects.patch Type: text/x-patch Size: 6303 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 10 15:29:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 17:29:18 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <534696D5.8080000@redhat.com> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> <1397134344.19767.79.camel@willson.li.ssimo.org> <534696D5.8080000@redhat.com> Message-ID: <5346B8CE.1030602@redhat.com> On 04/10/2014 03:04 PM, Martin Kosek wrote: > On 04/10/2014 02:52 PM, Simo Sorce wrote: >> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: >>> On 04/09/2014 12:25 PM, Martin Kosek wrote: >>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> This adds read permissions to read hosts. >>>>> >>>>> Read access is given to all authenticated users. >>>>> For reading host membership info, there is a separate permission that also >>>>> defaults to all authenticated users. >>>>> >>>>> The userPassword attribute is not included for obvious reasons. >>>> >>>> 1) We decided to show hosts only to authenticated users by default. I am just >>>> thinking - should some portion of hosts be readable just like groups and users >>>> are? For example at least the host core defined by nsHost objectlass? >>>> >>>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' >>>> SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLoc >>>> ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) >>>> >>>> Are application supposed to be able to anonymously read that information? >>> >>> I'm not sure. Simo? >> >> Good question, probably not by default, we offer DNS and do not >> recommend people to rely on exposed host maps. > > Question is if should have a separate permission like "System: Read Host Core > Attributes", "System: Read Host", "System: Read Host Membership" or we are fine > with just "System: Read Host", "System: Read Host Membership". > > If we do not expect people and programs to often read the list of host or the > basic host information anonymously, I would stick with the latter. Let's do that then. It's easy enough to add a custom permission. >>>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read Host >>>> Membership" permission or should it be included in the "Read Hosts" permission? >>>> >>>> If we want to stick with previous behavior, we would want to have only >>>> "memberOf" listed as this is how our original member handling ACI looks like: >>>> >>>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost || >>>> memberUser")(version 3.0; acl "No anonymous access to member information"; deny >>>> (read,search,compare) userdn != "ldap:///all"; >>> >>> What was the reasoning behind enrolledBy and managedBy? I got it from >>> the notes from devconf; I don't think there was much discussion. >> >> I have no recollection :( > > There was no discussion about these particular attributes. I added then to > Membership permission because they were DN-ish, but when I think more about it, > it does not seem as a membership in the sense of the ACI above. I would > personally only keep member/memberOf in the Membership attributes. Moved to Read Host. >>>> 3) I could not functionally test if e.g. clients and replicas still enroll as >>>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and >>>> ipa-client-install searches for it. >>>> >>>> Speaking of which, we will need to have an ACI for reading a portion of >>>> krbRealmContainer anonymously to enable IPA client autodiscovery >>>> (cn+objectclass should be sufficient). >> >> Sad we ended up depending on this, I would have preferred to not depend >> on keeping this around if we ever want to change something. > > Yeah... But we should be OK with exposing just the CN which is not really a > secret as we know what is the realm name... > > Martin > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0506.2-Add-managed-read-permissions-to-host.patch Type: text/x-patch Size: 1794 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 10 16:03:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 10 Apr 2014 18:03:11 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <5343EAF8.8060209@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> <53341563.9050204@redhat.com> <533A73E0.9030707@redhat.com> <20140401084016.GI3094@redhat.com> <533A7E49.604@redhat.com> <5343EAF8.8060209@redhat.com> Message-ID: <5346C0BF.5060801@redhat.com> On 04/08/2014 02:26 PM, Martin Kosek wrote: > On 04/01/2014 10:52 AM, Tomas Babej wrote: >> >> On 04/01/2014 10:40 AM, Alexander Bokovoy wrote: >>> On Tue, 01 Apr 2014, Tomas Babej wrote: >>>> From 736b3f747188696fd4a46ca63d91a6cca942fd56 Mon Sep 17 00:00:00 2001 >>>> From: Tomas Babej >>>> Date: Wed, 5 Mar 2014 12:28:18 +0100 >>>> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >>>> >>>> The ipa-range-check plugin used to determine the range type depending >>>> on the value of the attributes such as RID or secondary RID base. This >>>> approached caused variety of issues since the portfolio of ID range >>>> types expanded. >>>> >>>> The patch makes sure the following rules are implemented: >>>> * No ID range pair can overlap on base ranges, with exception >>>> of two ipa-ad-trust-posix ranges belonging to the same forest >>>> * For any ID range pair of ranges belonging to the same domain: >>>> * Both ID ranges must be of the same type >>>> * For ranges of ipa-ad-trust type or ipa-local type: >>>> * Primary RID ranges can not overlap >>>> * For ranges of ipa-local type: >>>> * Primary and secondary RID ranges can not overlap >>>> * Secondary RID ranges cannot overlap >>>> >>>> For the implementation part, the plugin was extended with a domain ID >>>> to forest root domain ID mapping derivation capabilities. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4137 >>>> >>>> -static int slapi_entry_to_range_info(struct slapi_entry *entry, >>>> +struct domain_info { >>>> + char *domain_id; >>>> + char *forest_root_id; >>>> + struct domain_info *next; >>>> +}; >>>> + >>>> +static void free_domain_info(struct domain_info *info) { >>>> + if (info != NULL) { >>>> + slapi_ch_free_string(&(info->domain_id)); >>>> + slapi_ch_free_string(&(info->forest_root_id)); >>>> + free_domain_info(info->next); >>>> + free(info); >>>> + } >>>> +} >>> Please, don't use recursion in the freeing part, there is really no >>> pressing need to do so. Just use while() like you do in >>> get_forest_root_id(): >>> >>>> +/* Searches for the domain_info struct with the specified domain_id >>>> + * in the linked list. Returns the forest root domain's ID, or NULL for >>>> + * local ranges. */ >>>> + >>>> +static char* get_forest_root_id(struct domain_info *head, char* >>>> domain_id) { >>>> + >>>> + /* For local ranges there is no forest root domain, >>>> + * so consider only ranges with domain_id set */ >>>> + if (domain_id != NULL) { >>>> + while(head) { >>>> + if (strcasecmp(head->domain_id, domain_id) == 0) { >>>> + return head->forest_root_id; >>>> + } >>>> + head = head->next; >>>> + } >>>> + } >>>> + >>>> + return NULL; >>>> +} >>>> + >>> >>> >> >> Fixed, updated patch attached. >> > > Pushed to master based on Alexander's ACK in patch 161. I keep seeing a test failure that's probably caused by this change: ====================================================================== ERROR: test suite for ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/suite.py", line 208, in run self.setUp() File "/usr/lib/python2.7/site-packages/nose/suite.py", line 291, in setUp self.setupContext(ancestor) File "/usr/lib/python2.7/site-packages/nose/suite.py", line 314, in setupContext try_run(context, names) File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in try_run return func() File "/var/lib/jenkins/workspace/freeipa-intree-tests-f20/ipatests/test_xmlrpc/test_range_plugin.py", line 163, in setUpClass cls.mockldap.add_entry(testrange9_dn, testrange9_add) File "/var/lib/jenkins/workspace/freeipa-intree-tests-f20/ipatests/util.py", line 650, in add_entry self.connection.add_s(dn, ldif) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 195, in add_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 458, in result resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 462, in result2 resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469, in result3 resp_ctrl_classes=resp_ctrl_classes File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call result = func(*args,**kwargs) OPERATIONS_ERROR: {'info': 'Range Check error', 'desc': 'Operations error'} -- Petr? From dpal at redhat.com Thu Apr 10 16:41:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Apr 2014 12:41:50 -0400 Subject: [Freeipa-devel] Random Certificate Serial Numbers In-Reply-To: <1396965320.21643.14.camel@aleeredhat.laptop> References: <53425863.1030602@redhat.com> <1396965320.21643.14.camel@aleeredhat.laptop> Message-ID: <5346C9CE.1030608@redhat.com> On 04/08/2014 09:55 AM, Ade Lee wrote: > On Mon, 2014-04-07 at 09:48 +0200, Martin Kosek wrote: >> Hi Rob, Ade and others, >> >> In the past, Rob was investigating enabling random certificate serial numbers >> for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. >> Can we simply switch it on for PKI with pkispawn attribute: >> >> [CA] >> pki_random_serial_numbers_enable=True >> > Putting in this parameter in pkispawn means changing the method of > assigning serial numbers for the CA that is being installed (ie. a new > master) > > Thus this will affect new masters only. When the CA is cloned, it will > inherit its method of assigning serial numbers from the master. > > I need to check the code to see what happens if you specify the above > directive in pkispawn for a clone. > > Are you considering changing the serial number assignment for existing > masters? No >> or is there any drawback or risk we should investigate. I am just thinking, >> does PKI handle collisions anyhow? When for example two PKI masters generate 2 >> certificates of the same serial (unlikely though it could happen)? >> > Collisions are not supposed to happen. Range number assignment is > automatically managed so that different masters are assigned different > ranges so that collisions cannot happen. > > Collisions can occur if ranges overlap -- ie. if you are > manually updating ranges and end up using overlapping ranges. > >> Currently, we assign different slice of serial range to different PKI masters, >> do we want to do that also for random serial? >> > Yes. Range management is done automatically. Different masters are > assigned different ranges to prevent collisions. Random serial numbers > will be generated within the assigned range. > >> Thanks for info >> >> [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers >> [2] https://fedorahosted.org/freeipa/ticket/2016 >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Thu Apr 10 20:06:08 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Apr 2014 16:06:08 -0400 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <5346B027.5020407@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> Message-ID: <5346F9B0.8060600@redhat.com> Some in-line, a whole ton of data appended to end. Jan Cholasta wrote: > On 7.4.2014 20:09, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches implement automatic CA certificate renewal as well >>>> as the initial version of the CA certificate management tool. >>>> >>>> Requires my patches 172-196. >>>> >>>> In order to test, you must install current git version of certmonger >>>> (see ) and set >>>> SELinux to >>>> permissive (see ). >>>> Make sure you install certmonger before running >>>> ipa-server-install/ipa-replica-install. On F20 you can use RPMs located >>>> at . >>>> >>>> To test automatic renewal, move system time forward (see >>>> for more info >>>> about certificate renewal testing, nickname of the CA certificate is >>>> "caSigningCert cert-pki-ca"). In CA-full installs the renewal should be >>>> fully automatic, in CA-less installs you should be alerted via >>>> syslog to >>>> renew the certificate using ipa-cacert-manage. >>>> >>>> To test manual renewal, run "ipa-cacert-manage renew". You can run >>>> it on >>>> any CA master. To make the renewed certificate available on other CA >>>> masters, you must run "getcert resubmit -d /etc/pki/pki-tomcat/alias -n >>>> 'caSigningCert cert-pki-ca'" on each of them. Note that currently you >>>> can't change the chaining of the CA certificate. >>> >>> 241 >>> >>> Not to be too anal, but would it be too outlandish to compare the >>> Authority Key Identifier (if there is one) with the Subject Key ID to >>> see if the cert is self-signed? Same subject then yeah, it is probably >>> self-signed. The keys match? Definitely. > > Authority key identifier is not mandatory, so it's not good enough. You > could verify the certificate's signature with its public key, but I > haven't figured out how to do that in python-nss. > > Also, if someone uses the subject name of the issuer for their CA > certificate, I think they will run into all kinds of problems anyway. Ok. > >>> >>> 242 >>> >>> I wonder if it would be clearer to use variables instead of a raw list >>> in the return value for these handlers: (result, message) = handler(...) >>> rather than examining result[0], etc. That may be beyond the scope of >>> this patch though. > > Yes. It would be nice if certmonger included a Python module for helper > scripts... Yes, but what I mean is the internal handling returns tuples of data with unique variable names, then plucks them out positionally. > >>> >>> x509.normalize_certificate() can raise an exception, there should be a >>> try/except around it. > > If there is an exception, it will be caught in the try/except block at > the end of the script. Well, ok. > >>> >>> For an invalid cookie, please include the values seen in the environment >>> in the error message. > > Added. > >>> >>> 243 >>> >>> You are going to end up with a lot of acis with the same comment value. >>> Perhaps add the host in there as well. >>> >>> These are not removed when a master is deleted. > > I merely did the same thing as the "Add CA Certificates for renewals" > and "Modify CA Certificates for renewals" ACIs. > > I agree it's suboptimal, but IMO it should be fixed in the scope of > (the "ipa masters > hostgroup" part). There is a replica_cleanup() method in replication.py. I don't know why this couldn't be added there. > >>> >>> 244 >>> >>> There are now several different places where the caCertificate value is >>> updated. I wonder if it's time for a function. I found it it in >>> dsinstance.py, upload_cacert and now renew_ca_cert. > > I have a patch for that, but I haven't posted it yet, since there are > some other changes in it as well. Ok. > >>> >>> 246 >>> >>> caRenewalMaster should be checked when a replica is deleted and moved to >>> another master. This is a good idea. I wonder if a ticket should be >>> opened to do something similar for CRL generation. > > Add new patch 262 for this. > > +1 on doing the same for CRL generation. > >>> >>> 247 >>> >>> We've been burned by hardcoded timeouts in the past. Should this be >>> configurable? This module doesn't currently do any logging but it might >>> be worth spitting out a "waiting" message, at least for debugging. > > Added a timeout argument. Did you forget to send this one, I didn't see an update to 247. > > I had logging in the code before, but I removed it when I moved the code > to ipapython.certmonger. Silly me. Fixed. > >>> >>> 249 >>> >>> nss_init() is always scary to me since we can only have one. I didn't >>> see anything blow up, just wondering if this should be wrapped with an >>> is_initialized()->shutdown() at the top. > > Fixed (also for verify_server_cert_validity). Ok. > >>> >>> The find_cert_from_nickname() should be in a try/except in case the cert >>> is not found for some reason. > > I want the exception to be propagated to the caller in such case. Ok. > >>> >>> 251 >>> >>> The tool should provide some feedback while it's running. For the >>> impatient (me) it takes a really long time and it's hard to know what is >>> going on, something in between nothing and full debug output. > > Added some messages about what's going on. I dpn't see an update to 251 either. >>> >>> The man page needs some more work too. I think some more explanation is >>> needed and an example would probably be really helpful as well. I think >>> particularly an example for external certs and a description of what you >>> mean by Self-signed CA (I assume you mean IPA-provided). I don't think >>> it really matters how many steps there are unless you are going to >>> provide progress output. > > Reworded the man page a little bit. > >>> >>> Got a backtrace when running as non-root: >>> >>> $ ipa-cacert-manage -v renew >>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 168, in >>> execute >>> self.validate_options() >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>> >>> >>> line 62, in validate_options >>> super(CACertManage, self).validate_options(needs_root=True) >>> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >>> 189, in validate_options >>> raise ScriptError('Must be root to run %s' % self.command_name, 1) >>> >>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >>> ipa-cacert-manage command failed, exception: ScriptError: Must be root >>> to run ipa-cacert-manage >>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be >>> root to run ipa-cacert-manage > > That's correct, you can run it only as root, because you can't resubmit > certmonger requests as a regular user. Yes but one shouldn't get a traceback! > >>> >>> 252 >>> >>> In what context would this be executing? My guess is that certmonger is >>> trying to do the renewal but a new cert hasn't been issued yet, so this >>> gets sysloged? > > If you have an externally signed CA that's about to expire and the > renewed version of it is not available in LDAP, then the message gets > syslogged. Ok. > >>> >>> Still doing functional testing. >> >> My current scenario: >> >> 1. Newly installed IPA master with these patches. >> 2. Replica using IPA 3.3.4 (yeah, I cheated) >> >> While doing time travel I had a single cert fail on the initial master >> with this: >> >> ca-error: Server at https://lyra.example.com/ipa/xml failed >> request, will retry: 4204 (RPC failed at server. limits exceeded for >> this query). >> >> Mar 21 11:00:22 lyra ns-slapd: GSSAPI Error: Unspecified GSS failure. >> Minor code may provide more information (Cannot contact any KDC for >> realm 'EXAMPLE.COM') >> Mar 21 11:00:22 lyra certmonger: 2016-03-21 11:00:22 [28676] Server at >> https://lyra.example.com/ipa/xml failed request, will retry: 4204 (RPC >> failed at server. limits exceeded for this query). >> >> From the access log: >> >> [21/Mar/2016:11:00:21 -0400] conn=49 op=5 SRCH >> base="krbprincipalname=HTTP/lyra.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com" >> >> scope=0 filter="(objectClass=*)" attrs="userCertificate krbPrincipalName >> * ipaKrbAuthzData managedBy aci" >> [21/Mar/2016:11:00:21 -0400] conn=49 op=5 RESULT err=3 tag=101 >> nentries=0 etime=17 >> >> So yeah, 17 seconds is a long time. >> >> A resubmit fixed it and certmonger would have done this automatically if >> I had the patience, so not too worried about that. > > OK. > >> >> After moving time forward on the replica these certificates are in >> CA_WORKING: >> >> ipaCert >> auditSigningCert cert-pki-ca >> ocspSigningCert cert-pki-ca >> subsystemCert cert-pki-ca >> >> cn=ca_renewal is completely empty on the replica. On the master it only >> has the subsystemCert. I'm guessing this is at least partly due to my >> switching time one system at a time rather than (somewhat) >> simultaneously, but it still would have blown up with 3 missing certs. > > Can you post the related log messages from /var/log/messages from the > master somewhere? > > There's not much I can do about broken replication. I think you hit > . > >> >> rob > > Thanks for the review. > > Updated and rebased patches attached. > Patch 262 has lots of lint errors because you're adding arguments to functions that don't currently define one, is_renewal_master() for example. I think the ipa-cacert-manage man page is missing one really important piece: why would you ever need to run this? And when? The renewal was failing on the replica due to SELinux failures: # ausearch -m AVC -ts recent ---- time->Mon Mar 21 11:00:05 2016 type=SYSCALL msg=audit(1458572405.859:828): arch=c000003e syscall=59 success=no exit=-13 a0=c687c0 a1=c688c0 a2=c66e40 a3=7ffff0a46120 items=0 ppid=4172 pid=4173 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572405.859:828): avc: denied { execute } for pid=4173 comm="sh" name="ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:00:05 2016 type=SYSCALL msg=audit(1458572405.859:829): arch=c000003e syscall=4 success=no exit=-13 a0=c687c0 a1=7ffff0a462b0 a2=7ffff0a462b0 a3=7ffff0a46120 items=0 ppid=4172 pid=4173 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572405.859:829): avc: denied { getattr } for pid=4173 comm="sh" path="/usr/sbin/ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:00:05 2016 type=SYSCALL msg=audit(1458572405.859:830): arch=c000003e syscall=4 success=no exit=-13 a0=c687c0 a1=7ffff0a46290 a2=7ffff0a46290 a3=7ffff0a46120 items=0 ppid=4172 pid=4173 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572405.859:830): avc: denied { getattr } for pid=4173 comm="sh" path="/usr/sbin/ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:00:06 2016 type=SYSCALL msg=audit(1458572406.271:831): arch=c000003e syscall=59 success=no exit=-13 a0=24aa7c0 a1=24aa8c0 a2=24a8e40 a3=7fffbd055ac0 items=0 ppid=4183 pid=4184 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572406.271:831): avc: denied { execute } for pid=4184 comm="sh" name="ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:00:06 2016 type=SYSCALL msg=audit(1458572406.272:832): arch=c000003e syscall=4 success=no exit=-13 a0=24aa7c0 a1=7fffbd055c50 a2=7fffbd055c50 a3=7fffbd055ac0 items=0 ppid=4183 pid=4184 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572406.272:832): avc: denied { getattr } for pid=4184 comm="sh" path="/usr/sbin/ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:00:06 2016 type=SYSCALL msg=audit(1458572406.272:833): arch=c000003e syscall=4 success=no exit=-13 a0=24aa7c0 a1=7fffbd055c30 a2=7fffbd055c30 a3=7fffbd055ac0 items=0 ppid=4183 pid=4184 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572406.272:833): avc: denied { getattr } for pid=4184 comm="sh" path="/usr/sbin/ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:00:06 2016 type=SYSCALL msg=audit(1458572406.334:834): arch=c000003e syscall=2 success=no exit=-13 a0=315f900 a1=0 a2=1b6 a3=7fffbfef2060 items=0 ppid=3672 pid=4168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572406.334:834): avc: denied { read } for pid=4168 comm="dogtag-ipa-ca-r" name="sysupgrade.state" dev="dm-1" ino=276510 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file ---- time->Mon Mar 21 11:00:07 2016 type=SYSCALL msg=audit(1458572407.378:835): arch=c000003e syscall=2 success=no exit=-13 a0=2c98030 a1=0 a2=1b6 a3=7fffbfef2450 items=0 ppid=3672 pid=4168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572407.378:835): avc: denied { read } for pid=4168 comm="dogtag-ipa-ca-r" name="sysrestore.state" dev="dm-1" ino=273976 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file ---- time->Mon Mar 21 11:00:07 2016 type=SYSCALL msg=audit(1458572407.385:836): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fffbfef24f0 a2=6e a3=7fffbfef24f2 items=0 ppid=3672 pid=4168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572407.385:836): avc: denied { write } for pid=4168 comm="dogtag-ipa-ca-r" name="slapd-GREYOAK-COM.socket" dev="tmpfs" ino=53896 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file ---- time->Mon Mar 21 11:00:07 2016 type=SYSCALL msg=audit(1458572407.385:837): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fffbfef2a80 a2=23 a3=0 items=0 ppid=3672 pid=4168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572407.385:837): avc: denied { write } for pid=4168 comm="dogtag-ipa-ca-r" name="slapd-GREYOAK-COM.socket" dev="tmpfs" ino=53896 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file ---- time->Mon Mar 21 11:06:58 2016 type=SYSCALL msg=audit(1458572818.975:851): arch=c000003e syscall=59 success=no exit=-13 a0=21807c0 a1=21808c0 a2=217ee40 a3=7fff9d88d0a0 items=0 ppid=4338 pid=4339 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572818.975:851): avc: denied { execute } for pid=4339 comm="sh" name="ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:06:58 2016 type=SYSCALL msg=audit(1458572818.975:852): arch=c000003e syscall=4 success=no exit=-13 a0=21807c0 a1=7fff9d88d230 a2=7fff9d88d230 a3=7fff9d88d0a0 items=0 ppid=4338 pid=4339 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572818.975:852): avc: denied { getattr } for pid=4339 comm="sh" path="/usr/sbin/ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:06:58 2016 type=SYSCALL msg=audit(1458572818.975:853): arch=c000003e syscall=4 success=no exit=-13 a0=21807c0 a1=7fff9d88d210 a2=7fff9d88d210 a3=7fff9d88d0a0 items=0 ppid=4338 pid=4339 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572818.975:853): avc: denied { getattr } for pid=4339 comm="sh" path="/usr/sbin/ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:06:59 2016 type=SYSCALL msg=audit(1458572819.001:854): arch=c000003e syscall=59 success=no exit=-13 a0=1b5b7c0 a1=1b5b8c0 a2=1b59e40 a3=7fff7a364d20 items=0 ppid=4348 pid=4349 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572819.001:854): avc: denied { execute } for pid=4349 comm="sh" name="ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:06:59 2016 type=SYSCALL msg=audit(1458572819.001:855): arch=c000003e syscall=4 success=no exit=-13 a0=1b5b7c0 a1=7fff7a364eb0 a2=7fff7a364eb0 a3=7fff7a364d20 items=0 ppid=4348 pid=4349 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572819.001:855): avc: denied { getattr } for pid=4349 comm="sh" path="/usr/sbin/ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:06:59 2016 type=SYSCALL msg=audit(1458572819.001:856): arch=c000003e syscall=4 success=no exit=-13 a0=1b5b7c0 a1=7fff7a364e90 a2=7fff7a364e90 a3=7fff7a364d20 items=0 ppid=4348 pid=4349 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572819.001:856): avc: denied { getattr } for pid=4349 comm="sh" path="/usr/sbin/ldconfig" dev="dm-1" ino=134149 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file ---- time->Mon Mar 21 11:06:59 2016 type=SYSCALL msg=audit(1458572819.032:857): arch=c000003e syscall=2 success=no exit=-13 a0=2630900 a1=0 a2=1b6 a3=7fff361b7be0 items=0 ppid=3672 pid=4337 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572819.032:857): avc: denied { read } for pid=4337 comm="dogtag-ipa-ca-r" name="sysupgrade.state" dev="dm-1" ino=276510 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file ---- time->Mon Mar 21 11:06:59 2016 type=SYSCALL msg=audit(1458572819.998:858): arch=c000003e syscall=2 success=no exit=-13 a0=26bdcc0 a1=0 a2=1b6 a3=7fff361b7fd0 items=0 ppid=3672 pid=4337 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572819.998:858): avc: denied { read } for pid=4337 comm="dogtag-ipa-ca-r" name="sysrestore.state" dev="dm-1" ino=273976 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file ---- time->Mon Mar 21 11:06:59 2016 type=SYSCALL msg=audit(1458572819.999:859): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fff361b8070 a2=6e a3=7fff361b8072 items=0 ppid=3672 pid=4337 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572819.999:859): avc: denied { write } for pid=4337 comm="dogtag-ipa-ca-r" name="slapd-GREYOAK-COM.socket" dev="tmpfs" ino=57178 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file ---- time->Mon Mar 21 11:06:59 2016 type=SYSCALL msg=audit(1458572819.999:860): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fff361b8600 a2=23 a3=0 items=0 ppid=3672 pid=4337 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1458572819.999:860): avc: denied { write } for pid=4337 comm="dogtag-ipa-ca-r" name="slapd-GREYOAK-COM.socket" dev="tmpfs" ino=57178 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file Mar 21 11:07:00 sif.greyoak.com dogtag-ipa-ca-renew-agent-submit[4337]: Traceback (most recent call last): File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 299, in sys.exit(main()) File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 288, in main if ca.is_renewal_master(): File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1548, in is_renewal_master self.ldap_connect() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 118, in ldap_connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1727, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1713, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1699, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, in wait_for_open_socket raise e error: [Errno 13] Permission denied Mar 21 11:07:00 sif.greyoak.com certmonger[3672]: 2016-03-21 11:07:00 [3672] Internal error I updated selinux-policy but I'm not seeing the certs added consistently to ca_renewal so there is nothing to do, so it sits in CA_WORKING. I verified it isn't a replication issue, the replication is working fine, the certs just weren't pushed. Here is what syslog on the initial master has to say about it. The reason strange part is the references to dogtag-ipa-renew-agent: Mar 21 11:00:00 lyra systemd: Time has been changed Mar 21 11:01:01 lyra systemd: Starting Session 323 of user root. Mar 21 11:01:01 lyra systemd: Started Session 323 of user root. Mar 21 11:02:13 lyra ntpd[6652]: 0.0.0.0 0618 08 no_sys_peer Mar 21 11:03:06 lyra certmonger: Certificate named "auditSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20160330184642. Mar 21 11:03:06 lyra certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20160330184640. Mar 21 11:03:06 lyra certmonger: Certificate named "subsystemCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20160330184641. Mar 21 11:03:06 lyra certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in database "/etc/httpd/alias" will not be valid after 20160330184711. Mar 21 11:03:06 lyra certmonger: Certificate named "Server-Cert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" will not be valid after 20160330184641. Mar 21 11:03:06 lyra certmonger: Certificate named "Server-Cert" in token "NSS Certificate DB" in database "/etc/dirsrv/slapd-GREYOAK-COM" will not be valid after 20160410184720. Mar 21 11:03:06 lyra certmonger: Certificate named "Server-Cert" in token "NSS Certificate DB" in database "/etc/httpd/alias" will not be valid after 20160410184810. Mar 21 11:03:11 lyra certmonger: Certificate named "Server-Cert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" issued by CA and saved. Mar 21 11:03:15 lyra dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent Mar 21 11:03:15 lyra dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent Mar 21 11:03:15 lyra dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent Mar 21 11:03:15 lyra dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent Mar 21 11:03:17 lyra dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 5 Mar 21 11:03:17 lyra dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 5 Mar 21 11:03:17 lyra dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 5 Mar 21 11:03:18 lyra dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 5 Mar 21 11:03:19 lyra restart_httpd: certmonger restarted httpd Mar 21 11:03:19 lyra systemd: Stopping The Apache HTTP Server... Mar 21 11:03:21 lyra systemd: Starting The Apache HTTP Server... Mar 21 11:03:22 lyra systemd: Started The Apache HTTP Server. Mar 21 11:03:22 lyra certmonger: Certificate named "Server-Cert" in token "NSS Certificate DB" in database "/etc/httpd/alias" issued by CA and saved. Mar 21 11:03:29 lyra dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent Mar 21 11:03:29 lyra dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent Mar 21 11:03:29 lyra dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent Mar 21 11:03:29 lyra dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent Mar 21 11:03:31 lyra restart_dirsrv: certmonger restarted dirsrv instance 'GREYOAK-COM' Mar 21 11:03:31 lyra systemd: Reloading. Mar 21 11:03:31 lyra systemd: Stopping 389 Directory Server GREYOAK-COM.... Mar 21 11:03:33 lyra dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 2 Mar 21 11:03:33 lyra dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 2 Mar 21 11:03:33 lyra dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 2 Mar 21 11:03:33 lyra dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 2 Mar 21 11:03:33 lyra certmonger: 2016-03-21 11:03:33 [8438] Server at "https://lyra.greyoak.com:8443/ca/agent/ca/profileProcess" replied: 1: Invalid Credential. Mar 21 11:03:33 lyra certmonger: 2016-03-21 11:03:33 [8438] Server at "https://lyra.greyoak.com:8443/ca/agent/ca/profileProcess" replied: 1: Invalid Credential. Mar 21 11:03:33 lyra certmonger: 2016-03-21 11:03:33 [8438] Server at "https://lyra.greyoak.com:8443/ca/agent/ca/profileProcess" replied: 1: Invalid Credential. Mar 21 11:03:33 lyra certmonger: 2016-03-21 11:03:33 [8438] Server at "https://lyra.greyoak.com:8443/ca/agent/ca/profileProcess" replied: 1: Invalid Credential. Mar 21 11:03:33 lyra systemd: Starting 389 Directory Server GREYOAK-COM.... Mar 21 11:03:34 lyra systemd: Started 389 Directory Server GREYOAK-COM.. Mar 21 11:03:34 lyra ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available) Mar 21 11:03:35 lyra certmonger: Certificate named "Server-Cert" in token "NSS Certificate DB" in database "/etc/dirsrv/slapd-GREYOAK-COM" issued by CA and saved. From mkosek at redhat.com Fri Apr 11 07:48:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Apr 2014 09:48:40 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <5346B8CE.1030602@redhat.com> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> <1397134344.19767.79.camel@willson.li.ssimo.org> <534696D5.8080000@redhat.com> <5346B8CE.1030602@redhat.com> Message-ID: <53479E58.5090606@redhat.com> On 04/10/2014 05:29 PM, Petr Viktorin wrote: > On 04/10/2014 03:04 PM, Martin Kosek wrote: >> On 04/10/2014 02:52 PM, Simo Sorce wrote: >>> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: >>>> On 04/09/2014 12:25 PM, Martin Kosek wrote: >>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> This adds read permissions to read hosts. >>>>>> >>>>>> Read access is given to all authenticated users. >>>>>> For reading host membership info, there is a separate permission that also >>>>>> defaults to all authenticated users. >>>>>> >>>>>> The userPassword attribute is not included for obvious reasons. >>>>> >>>>> 1) We decided to show hosts only to authenticated users by default. I am just >>>>> thinking - should some portion of hosts be readable just like groups and >>>>> users >>>>> are? For example at least the host core defined by nsHost objectlass? >>>>> >>>>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' >>>>> SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ >>>>> nsHostLoc >>>>> ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) >>>>> >>>>> Are application supposed to be able to anonymously read that information? >>>> >>>> I'm not sure. Simo? >>> >>> Good question, probably not by default, we offer DNS and do not >>> recommend people to rely on exposed host maps. >> >> Question is if should have a separate permission like "System: Read Host Core >> Attributes", "System: Read Host", "System: Read Host Membership" or we are fine >> with just "System: Read Host", "System: Read Host Membership". >> >> If we do not expect people and programs to often read the list of host or the >> basic host information anonymously, I would stick with the latter. > > Let's do that then. It's easy enough to add a custom permission. > >>>>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read >>>>> Host >>>>> Membership" permission or should it be included in the "Read Hosts" >>>>> permission? >>>>> >>>>> If we want to stick with previous behavior, we would want to have only >>>>> "memberOf" listed as this is how our original member handling ACI looks like: >>>>> >>>>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost || >>>>> memberUser")(version 3.0; acl "No anonymous access to member information"; >>>>> deny >>>>> (read,search,compare) userdn != "ldap:///all"; >>>> >>>> What was the reasoning behind enrolledBy and managedBy? I got it from >>>> the notes from devconf; I don't think there was much discussion. >>> >>> I have no recollection :( >> >> There was no discussion about these particular attributes. I added then to >> Membership permission because they were DN-ish, but when I think more about it, >> it does not seem as a membership in the sense of the ACI above. I would >> personally only keep member/memberOf in the Membership attributes. > > Moved to Read Host. > >>>>> 3) I could not functionally test if e.g. clients and replicas still enroll as >>>>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and >>>>> ipa-client-install searches for it. >>>>> >>>>> Speaking of which, we will need to have an ACI for reading a portion of >>>>> krbRealmContainer anonymously to enable IPA client autodiscovery >>>>> (cn+objectclass should be sufficient). >>> >>> Sad we ended up depending on this, I would have preferred to not depend >>> on keeping this around if we ever want to change something. >> >> Yeah... But we should be OK with exposing just the CN which is not really a >> secret as we know what is the realm name... >> >> Martin >> The basis looks good now. However, when I was checking host's objectclass and attributes we allow, I saw many attributes not listed in our DevConf meeting minutes, but which are now missing in the entry when I read it as authenticated used. krbPrincipalAux attributes like krbCanonicalName, krbExtraData, krbLastAdminUnlock, krbLastFailedAuth... We may want to list them all, except the ones we chose to now show, like krbPrincipalKey :) I would welcome Simo's recommendation in this place. krbTicketPolicyAux attributes like krbMaxRenewableAge Objectclasses for reference: objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 NAME 'krbTicketPolicyAux' AUXI LIARY MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) ) Martin From mkosek at redhat.com Fri Apr 11 08:19:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Apr 2014 10:19:03 +0200 Subject: [Freeipa-devel] [PATCH] 0516 Add managed read permissions to realmdomains In-Reply-To: <5346A2E5.9070207@redhat.com> References: <5346A2E5.9070207@redhat.com> Message-ID: <5347A577.8030908@redhat.com> On 04/10/2014 03:55 PM, Petr Viktorin wrote: > Read access is given to all authenticated users. > Works for me, ACK. Pushed to master, Martin From mkosek at redhat.com Fri Apr 11 08:20:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Apr 2014 10:20:36 +0200 Subject: [Freeipa-devel] [PATCH] 0513 Add managed read permissions to RBAC objects In-Reply-To: <5346B2CA.5070902@redhat.com> References: <53455F14.2060505@redhat.com> <5345648B.2000109@redhat.com> <534684A3.4050502@redhat.com> <5346955C.4080008@redhat.com> <5346964A.5000806@redhat.com> <53469798.8050907@redhat.com> <5346984A.2030003@redhat.com> <53469AB4.8050505@redhat.com> <5346B2CA.5070902@redhat.com> Message-ID: <5347A5D4.7040702@redhat.com> On 04/10/2014 05:03 PM, Petr Viktorin wrote: > On 04/10/2014 03:20 PM, Martin Kosek wrote: >> On 04/10/2014 03:10 PM, Petr Viktorin wrote: >>> On 04/10/2014 03:07 PM, Martin Kosek wrote: >>>> On 04/10/2014 03:02 PM, Petr Viktorin wrote: >>>>> On 04/10/2014 02:58 PM, Martin Kosek wrote: >>>>>> On 04/10/2014 01:46 PM, Petr Viktorin wrote: >>>>>>> On 04/09/2014 05:17 PM, Martin Kosek wrote: >>>>>>>> On 04/09/2014 04:54 PM, Petr Viktorin wrote: >>>>>>>>> The meta-permissions. >>>>>>>> >>>>>>>> :-) >>>>>>>> >>>>>>>>> Read access is given to all authenticated users. Reading membership info >>>>>>>>> (i.e. >>>>>>>>> privileges) is split into a separate permission. >>>>>>>>> >>>>>>>>> Another permission is added that allows read access to all ACIs. >>>>>>>>> If we don't want to open that up for everyone, I could limit this to only >>>>>>>>> ACIs >>>>>>>>> containing "permission:". (Since old-style permissions store their >>>>>>>>> information >>>>>>>>> in ACIs, their ACIs need to be readable.) >>>>>>>> >>>>>>>> If I read the notes from our DevConf discussion correctly, there are some >>>>>>>> inconsistencies: >>>>>>>> >>>>>>>> 1) We decided to not do special membership permission for >>>>>>>> permission/privilege/role permissions. >>>>>>>> >>>>>>>> 2) We decided to give read access to permissions, privileges and roles >>>>>>>> only to >>>>>>>> member of a certain privilege. Is there any reason to not do that? IMO, >>>>>>>> regular >>>>>>>> users do not need to be able to read the permission/privilege/role >>>>>>>> configuration of a FreeIPA installation to use it for IdM. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> Updated. I plan to add all the RBAC-related read permissions to a single >>>>>>> privilege, "RBAC Readers". Or do we want more granularity by default? >>>>>>> >>>>>>> Requires my patch 0514. >>>>>> >>>>>> I was looking at the granularity we currently have with privilege and it is >>>>>> mostly per FreeIPA function (Sudo Administrator or DNS Administrator), >>>>>> not per >>>>>> IPA object (Sudo Command Administrator, Sudo Rule Administrator). >>>>>> >>>>>> I would thus follow the same principle with RBAC and create RBAC >>>>>> Administrator >>>>>> privilege which will cover read permissions for... permissions... privileges >>>>>> and roles. In time, we will also add new write privileges there as they are >>>>>> currently missing. >>>>>> >>>>>> To sum it up, the patch works, I would just change the name of the privilege >>>>>> and not focus it just on reading. >>>>> >>>>> So to confirm, we want one privilege to cover both reading and writing? >>>> >>>> IMO, yes. >>>> >>>>> Should I add new read permissions to existing "Administrator" privileges >>>>> only, >>>>> instead of creating new "Reader" permissions? >>>> >>>> I don't think so. The read permission we have been adding so far were >>>> targetted >>>> on anonymous/all binds, thus according to our design, they cannot be added to >>>> privilege anyway. >>>> >>>> But if someone wants to restrict an object, he is free to change the >>>> permission >>>> bind type to "group based" and assign it to a privilege. >>>> >>>> In our case, I would assign read permission to privilege only if we decided to >>>> make them group based, like RBAC or krbtpolicy ones. >>> >>> Right, that makes sense. I'm asking about not having separate read privileges >>> when the permissions are group based. Based on Simo's other mail we should have >>> separate "Read" privileges. >>> >>> Also IMO the read permissions should then be added both to the "Reader" and >>> "Administrator" privileges, since it doesn't make sense to be able to write but >>> not read. >> >> Ah, I understand the question now. This assumes that people may often want to >> allow a certain group of people to read RBAC or to read ticket policy. >> >> I would assume that a more frequent usage would be that administrator would >> allow all authenticated users read an object (which makes Read group >> redundant). But I am not insisting, I am open to both approaches. > > I think it's reasonable to give read (but not write) access to lower-level > admins only. > > Here is an updated patch. I've added read for privileges and roles too, so the > 'RBAC Readers' privilege should be complete. > Thanks, works for me. ACK. Pushed to master. Martin From mkosek at redhat.com Fri Apr 11 08:28:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Apr 2014 10:28:54 +0200 Subject: [Freeipa-devel] [PATCH] 0515 Add managed read permission for SELinux user map In-Reply-To: <53469D08.2040707@redhat.com> References: <53469D08.2040707@redhat.com> Message-ID: <5347A7C6.8030909@redhat.com> On 04/10/2014 03:30 PM, Petr Viktorin wrote: > Read access is given to all authenticated users. > ACK, works fine. Pushed to master: 3db9ce320422a6cc57e1767a1e0cbf06d950a67e Martin From pviktori at redhat.com Fri Apr 11 10:41:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 11 Apr 2014 12:41:36 +0200 Subject: [Freeipa-devel] [PATCH] 0517 test_realmdomains_plugin: Add default ACI to expected output In-Reply-To: <5347A577.8030908@redhat.com> References: <5346A2E5.9070207@redhat.com> <5347A577.8030908@redhat.com> Message-ID: <5347C6E0.2080500@redhat.com> On 04/10/2014 03:55 PM, Petr Viktorin wrote: > Subject: [PATCH] 0516 Add managed read permissions to realmdomains > > Read access is given to all authenticated users. > Jenkins tells me this breaks tests. Since realmdomains ACIs are set on a single entry, not a container, realmdomains_show --all will include the ACI in the output. As it should, since we're asking for all LDAP attributes. Test fix attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0517-test_realmdomains_plugin-Add-default-ACI-to-expected.patch Type: text/x-patch Size: 1504 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 11 10:46:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Apr 2014 12:46:40 +0200 Subject: [Freeipa-devel] [PATCH] 0517 test_realmdomains_plugin: Add default ACI to expected output In-Reply-To: <5347C6E0.2080500@redhat.com> References: <5346A2E5.9070207@redhat.com> <5347A577.8030908@redhat.com> <5347C6E0.2080500@redhat.com> Message-ID: <5347C810.4090407@redhat.com> On 04/11/2014 12:41 PM, Petr Viktorin wrote: > On 04/10/2014 03:55 PM, Petr Viktorin wrote: >> Subject: [PATCH] 0516 Add managed read permissions to realmdomains >> >> Read access is given to all authenticated users. >> > > Jenkins tells me this breaks tests. Since realmdomains ACIs are set on a single > entry, not a container, realmdomains_show --all will include the ACI in the > output. As it should, since we're asking for all LDAP attributes. > Test fix attached. > Good boy Jenkins. I did not see this coming, I mostly test the patches in my LDAP browser and CLI as we did not step to the functional testing part yet. This fixed the test for me, ACK. Pushed to master: db85ea32c185fee270ed900b2c60353b234454d8 Martin From pviktori at redhat.com Fri Apr 11 11:31:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 11 Apr 2014 13:31:22 +0200 Subject: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions Message-ID: <5347D28A.2020300@redhat.com> One of the default_attributes of permission is memberofindirect, a virtual attribute manufactured by ldap2, which is set when a permission is part of a role. When update_entry is called on an entry with memberofindirect, ipaldap tries to add the attribute to LDAP and fails with an objectclass violation. Do not ask for memberindirect when retrieving the entry. CCing Honza since he designs ipaldap. Virtual attributes are often helpful, and in any case IPA uses them a lot and having to filter them out every time is error-prone. Maybe we should add support for them directly in ipaldap -- e.g. an attribute set by `entry.virtual[attr_name] = [x]` would be visible in entry[attr_name] but would not be synced back to LDAP? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0518-Do-not-ask-for-memberindirect-when-updating-managed-.patch Type: text/x-patch Size: 1533 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 11 12:26:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 11 Apr 2014 14:26:44 +0200 Subject: [Freeipa-devel] [PATCH] 0519 Add managed read permissions to pwpolicy and cosentry Message-ID: <5347DF84.1000509@redhat.com> Read access is given as a new privilege, 'Password Policy Readers', and also to the existing privilege 'Password Policy Administrator'. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0519-Add-managed-read-permissions-to-pwpolicy-and-cosentr.patch Type: text/x-patch Size: 3690 bytes Desc: not available URL: From amisnyov at redhat.com Fri Apr 11 12:31:10 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 11 Apr 2014 14:31:10 +0200 Subject: [Freeipa-devel] [PATCH] 569-583 New Login Screen In-Reply-To: <5335734D.9030300@redhat.com> References: <5335734D.9030300@redhat.com> Message-ID: <20140411143110.5bb2a674@unused-4-246.brq.redhat.com> On Fri, 28 Mar 2014 14:04:13 +0100 Petr Vobornik wrote: > Attached patches replace IPA.unauthorized dialog with new Login > Screen. > > To make it happen, a support for standalone facets had to be > developed because current framework was limited by facets dependent > on entities and a container with menu. This new feature was already > used for Load facet which is part of this patchset and also will be a > basis for API browser and OTP sync page. > > Patches should fix these tickets: > https://fedorahosted.org/freeipa/ticket/3903 > https://fedorahosted.org/freeipa/ticket/4017 > > Depends on patches #565-#568. > > > [PATCH] webui: facet container > ------------------------------ > A widget which servers as container for facets. FacetContainer is a > base class. App is specialization. > > Doing this abstraction will allow us to implement various facet > containers. > > [PATCH] webui: FormMixin > ------------------------ > a mixin used for fields validation. Basically implements a logic which > is already in details facet and dialog. > > Now this logic can be used in any component. > > The long term goal is to replace the logic in details facet and dialog > with this mixin. > > [PATCH] webui: ContainerMixin > ----------------------------- > A mixin which implements widget storing logic. Similar logic is > already implemented > in details facet and dialog. > > Long term goal is to replace that with this one. > > Separating the logic into mixin makes it usable in other components. > > [PATCH] webui: standalone facet > ------------------------------- > `facet.Facet` is a new base class for facets. It doesn't have any > dependencies > on entities so it's usable for general purpose facets, e.g., future > API browser, > load facet or login facet. > > [PATCH] webui: activity widget > ------------------------------ > A widget for showing ongoing activity. > > Displays a text with changing dots. > > It listens to `network-activity-start` and `network-activity-end` > topics. > > [PATCH] webui: publish network activity topics > ---------------------------------------------- > Network activity is now published through global topics. It allows > other components like activity_widget to listen to them. > > [PATCH] webui: load page > ------------------------ > Load page is a simple facet which is displayed up to 'runtime' phase. > > On application start it tells the user that there is ongoing activity. > > [PATCH] webui: validation summary widget > ---------------------------------------- > A widget which aggregates warnings and errors and shows them on one > place. > > [PATCH] webui: login screen widget > ---------------------------------- > Reimplementation of unauthorized dialog into separate widget. It uses > RCUE design. > > New features compared to unauthorized dialog: > > - reflects auth methods from `auth` module > - validation summary > - differentiates Kerberos auth failure with session expiration > - Caps Lock warning > - form based method doesn't allow password only submission > > https://fedorahosted.org/freeipa/ticket/4017 > https://fedorahosted.org/freeipa/ticket/3903 > > > [PATCH] webui: login page > ------------------------- > A facet with login sreen widget. > > [PATCH] webui: authentication module > ------------------------------------ > General purpose authentication interface and state. See doc of > 'freeipa/auth' module. > > [PATCH] webui: use asynchronous call for authentication > > Change `IPA.login_password` and `IPA.get_credentials` to use async > AJAX and to return promise instead of blocking the code. > > IPA.get_credentials is still partially blocking because of negotiate > process. > We can't do anything about that. > > It allows activity indicators to do their job. > > [PATCH] webui: fix combobox styles to work with selenium testing > [PATCH] webui-ci: adapt to new login screen > [PATCH] webui: remove IPA.unauthorized_dialog Hi, - Attached patch fixes weird combobox behaviour - opens automatically on facet load - When trying to log in with password only(username field is empty), there is an error message "Authentication with Kerberos failed", which is not the desired behaviour. It should sign that the username field is invalid. - When trying to log in with kerberos credentials, and the realm of the krb ticket is not the same as the realm of freeipa(eg freeipa realm is IPA.TEST.COM, and the ticket's is TEST.COM), firefox goes into an endless cycle calling the kerberos auth url. Currently it seems to me as a browser issue. Anyways, with correct krb ticket, authentication works fine. Although, unit tests ran, integration tests ran as expected, and browsing through the code manually was ok for me, so if that validation issue is corrected, than it will be an ACK. Thanks: Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0010-combobox-widget-fix.patch Type: text/x-patch Size: 1020 bytes Desc: not available URL: From simo at redhat.com Fri Apr 11 12:36:09 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 11 Apr 2014 08:36:09 -0400 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <53479E58.5090606@redhat.com> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> <1397134344.19767.79.camel@willson.li.ssimo.org> <534696D5.8080000@redhat.com> <5346B8CE.1030602@redhat.com> <53479E58.5090606@redhat.com> Message-ID: <1397219769.19767.95.camel@willson.li.ssimo.org> On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote: > On 04/10/2014 05:29 PM, Petr Viktorin wrote: > > On 04/10/2014 03:04 PM, Martin Kosek wrote: > >> On 04/10/2014 02:52 PM, Simo Sorce wrote: > >>> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: > >>>> On 04/09/2014 12:25 PM, Martin Kosek wrote: > >>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: > >>>>>> Hello, > >>>>>> This adds read permissions to read hosts. > >>>>>> > >>>>>> Read access is given to all authenticated users. > >>>>>> For reading host membership info, there is a separate permission that also > >>>>>> defaults to all authenticated users. > >>>>>> > >>>>>> The userPassword attribute is not included for obvious reasons. > >>>>> > >>>>> 1) We decided to show hosts only to authenticated users by default. I am just > >>>>> thinking - should some portion of hosts be readable just like groups and > >>>>> users > >>>>> are? For example at least the host core defined by nsHost objectlass? > >>>>> > >>>>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' > >>>>> SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ > >>>>> nsHostLoc > >>>>> ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) > >>>>> > >>>>> Are application supposed to be able to anonymously read that information? > >>>> > >>>> I'm not sure. Simo? > >>> > >>> Good question, probably not by default, we offer DNS and do not > >>> recommend people to rely on exposed host maps. > >> > >> Question is if should have a separate permission like "System: Read Host Core > >> Attributes", "System: Read Host", "System: Read Host Membership" or we are fine > >> with just "System: Read Host", "System: Read Host Membership". > >> > >> If we do not expect people and programs to often read the list of host or the > >> basic host information anonymously, I would stick with the latter. > > > > Let's do that then. It's easy enough to add a custom permission. > > > >>>>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read > >>>>> Host > >>>>> Membership" permission or should it be included in the "Read Hosts" > >>>>> permission? > >>>>> > >>>>> If we want to stick with previous behavior, we would want to have only > >>>>> "memberOf" listed as this is how our original member handling ACI looks like: > >>>>> > >>>>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost || > >>>>> memberUser")(version 3.0; acl "No anonymous access to member information"; > >>>>> deny > >>>>> (read,search,compare) userdn != "ldap:///all"; > >>>> > >>>> What was the reasoning behind enrolledBy and managedBy? I got it from > >>>> the notes from devconf; I don't think there was much discussion. > >>> > >>> I have no recollection :( > >> > >> There was no discussion about these particular attributes. I added then to > >> Membership permission because they were DN-ish, but when I think more about it, > >> it does not seem as a membership in the sense of the ACI above. I would > >> personally only keep member/memberOf in the Membership attributes. > > > > Moved to Read Host. > > > >>>>> 3) I could not functionally test if e.g. clients and replicas still enroll as > >>>>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and > >>>>> ipa-client-install searches for it. > >>>>> > >>>>> Speaking of which, we will need to have an ACI for reading a portion of > >>>>> krbRealmContainer anonymously to enable IPA client autodiscovery > >>>>> (cn+objectclass should be sufficient). > >>> > >>> Sad we ended up depending on this, I would have preferred to not depend > >>> on keeping this around if we ever want to change something. > >> > >> Yeah... But we should be OK with exposing just the CN which is not really a > >> secret as we know what is the realm name... > >> > >> Martin > >> > > The basis looks good now. However, when I was checking host's objectclass and > attributes we allow, I saw many attributes not listed in our DevConf meeting > minutes, but which are now missing in the entry when I read it as authenticated > used. As an admin, or as a regular user ? > krbPrincipalAux attributes like krbCanonicalName, krbExtraData, > krbLastAdminUnlock, krbLastFailedAuth... > We may want to list them all, except the ones we chose to now show, like > krbPrincipalKey :) I would welcome Simo's recommendation in this place. I do not think we necessarily need to expose most of them to regular users (which include keytab bearing services) by default. > krbTicketPolicyAux attributes like krbMaxRenewableAge > > Objectclasses for reference: > > objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR > Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey > $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ > krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange > $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF > ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) Of these we may want to show krbPrincipalName, krbCanonicalName, krbPrincipalAliases by default. I am uncertain about krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange, but they may be needed for clients like SSSD to do proper checking and for power users to figure out themselves when they need to change passwords or ask for an account validity extension etc.. We certainly should not expose: krbPrincipalKey, krbPwdHistory (though we do not use this IIRC, yet), krbExtraData The rest I lean more on the not showing by default, although they could be safely shown to authenticated users if necessary. > objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 NAME 'krbTicketPolicyAux' AUXI > LIARY MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) ) I do not think we need to expose these, although exposing them is not problematic, you can infer what they are by simply asking for tickets anyway. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Apr 11 12:39:01 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 11 Apr 2014 08:39:01 -0400 Subject: [Freeipa-devel] [PATCH] 0519 Add managed read permissions to pwpolicy and cosentry In-Reply-To: <5347DF84.1000509@redhat.com> References: <5347DF84.1000509@redhat.com> Message-ID: <1397219941.19767.96.camel@willson.li.ssimo.org> On Fri, 2014-04-11 at 14:26 +0200, Petr Viktorin wrote: > Read access is given as a new privilege, 'Password Policy Readers', and > also to the existing privilege 'Password Policy Administrator'. > LGTM Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Fri Apr 11 12:53:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 11 Apr 2014 14:53:00 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <1397219769.19767.95.camel@willson.li.ssimo.org> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> <1397134344.19767.79.camel@willson.li.ssimo.org> <534696D5.8080000@redhat.com> <5346B8CE.1030602@redhat.com> <53479E58.5090606@redhat.com> <1397219769.19767.95.camel@willson.li.ssimo.org> Message-ID: <5347E5AC.9050106@redhat.com> On 04/11/2014 02:36 PM, Simo Sorce wrote: > On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote: >> On 04/10/2014 05:29 PM, Petr Viktorin wrote: >>> On 04/10/2014 03:04 PM, Martin Kosek wrote: >>>> On 04/10/2014 02:52 PM, Simo Sorce wrote: >>>>> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: >>>>>> On 04/09/2014 12:25 PM, Martin Kosek wrote: >>>>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>>>>> Hello, >>>>>>>> This adds read permissions to read hosts. >>>>>>>> >>>>>>>> Read access is given to all authenticated users. >>>>>>>> For reading host membership info, there is a separate permission that also >>>>>>>> defaults to all authenticated users. >>>>>>>> >>>>>>>> The userPassword attribute is not included for obvious reasons. >>>>>>> >>>>>>> 1) We decided to show hosts only to authenticated users by default. I am just >>>>>>> thinking - should some portion of hosts be readable just like groups and >>>>>>> users >>>>>>> are? For example at least the host core defined by nsHost objectlass? >>>>>>> >>>>>>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' >>>>>>> SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ >>>>>>> nsHostLoc >>>>>>> ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) >>>>>>> >>>>>>> Are application supposed to be able to anonymously read that information? >>>>>> >>>>>> I'm not sure. Simo? >>>>> >>>>> Good question, probably not by default, we offer DNS and do not >>>>> recommend people to rely on exposed host maps. >>>> >>>> Question is if should have a separate permission like "System: Read Host Core >>>> Attributes", "System: Read Host", "System: Read Host Membership" or we are fine >>>> with just "System: Read Host", "System: Read Host Membership". >>>> >>>> If we do not expect people and programs to often read the list of host or the >>>> basic host information anonymously, I would stick with the latter. >>> >>> Let's do that then. It's easy enough to add a custom permission. >>> >>>>>>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read >>>>>>> Host >>>>>>> Membership" permission or should it be included in the "Read Hosts" >>>>>>> permission? >>>>>>> >>>>>>> If we want to stick with previous behavior, we would want to have only >>>>>>> "memberOf" listed as this is how our original member handling ACI looks like: >>>>>>> >>>>>>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || memberHost || >>>>>>> memberUser")(version 3.0; acl "No anonymous access to member information"; >>>>>>> deny >>>>>>> (read,search,compare) userdn != "ldap:///all"; >>>>>> >>>>>> What was the reasoning behind enrolledBy and managedBy? I got it from >>>>>> the notes from devconf; I don't think there was much discussion. >>>>> >>>>> I have no recollection :( >>>> >>>> There was no discussion about these particular attributes. I added then to >>>> Membership permission because they were DN-ish, but when I think more about it, >>>> it does not seem as a membership in the sense of the ACI above. I would >>>> personally only keep member/memberOf in the Membership attributes. >>> >>> Moved to Read Host. >>> >>>>>>> 3) I could not functionally test if e.g. clients and replicas still enroll as >>>>>>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and >>>>>>> ipa-client-install searches for it. >>>>>>> >>>>>>> Speaking of which, we will need to have an ACI for reading a portion of >>>>>>> krbRealmContainer anonymously to enable IPA client autodiscovery >>>>>>> (cn+objectclass should be sufficient). >>>>> >>>>> Sad we ended up depending on this, I would have preferred to not depend >>>>> on keeping this around if we ever want to change something. >>>> >>>> Yeah... But we should be OK with exposing just the CN which is not really a >>>> secret as we know what is the realm name... >>>> >>>> Martin >>>> >> >> The basis looks good now. However, when I was checking host's objectclass and >> attributes we allow, I saw many attributes not listed in our DevConf meeting >> minutes, but which are now missing in the entry when I read it as authenticated >> used. > > As an admin, or as a regular user ? > >> krbPrincipalAux attributes like krbCanonicalName, krbExtraData, >> krbLastAdminUnlock, krbLastFailedAuth... >> We may want to list them all, except the ones we chose to now show, like >> krbPrincipalKey :) I would welcome Simo's recommendation in this place. > > I do not think we necessarily need to expose most of them to regular > users (which include keytab bearing services) by default. > >> krbTicketPolicyAux attributes like krbMaxRenewableAge >> >> Objectclasses for reference: >> >> objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR >> Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey >> $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ >> krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange >> $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF >> ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) > > Of these we may want to show krbPrincipalName, krbCanonicalName, > krbPrincipalAliases by default. Added. > I am uncertain about krbPrincipalExpiration, krbPasswordExpiration, > krbLastPwdChange, but they may be needed for clients like SSSD to do > proper checking and for power users to figure out themselves when they > need to change passwords or ask for an account validity extension etc.. Let's show them then, to make their lives easier. Paranoid admins can always hide them. > We certainly should not expose: > krbPrincipalKey, krbPwdHistory (though we do not use this IIRC, yet), > krbExtraData > > The rest I lean more on the not showing by default, although they could > be safely shown to authenticated users if necessary. Similarly, generous admins can always give more access. I've not added these. >> objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 NAME 'krbTicketPolicyAux' AUXI >> LIARY MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) ) > > I do not think we need to expose these, although exposing them is not > problematic, you can infer what they are by simply asking for tickets > anyway. Not added. I assume the same will also apply to users and services? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0506.3-Add-managed-read-permissions-to-host.patch Type: text/x-patch Size: 1982 bytes Desc: not available URL: From mbasti at redhat.com Fri Apr 11 15:23:55 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 11 Apr 2014 17:23:55 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> Message-ID: <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> Updated patches attached. Patch 0047-1 should be applied between patches 0040-2 and 0041-2 Patch 0043-1 was squashed into 0038-2 Patch 0044-1 was squashed into 0039-2 Patch 0034-1 was squashed into 0032-2 Patch 0034-2 implements bug fix Patches should be applied in order: 0029-0040, 0047, 0041-0042, 0045-0046. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0029-2-Allows-to-sort-non-text-entries.patch Type: text/x-patch Size: 1818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0030-2-DNSName-type.patch Type: text/x-patch Size: 4124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0031-2-DNSNameParam-parameter.patch Type: text/x-patch Size: 5260 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0032-2-dns_name_values-capability-added.patch Type: text/x-patch Size: 4349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0033-2-Convert-DNSName-in-Str-class.patch Type: text/x-patch Size: 994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0034-2-get_ancestors_primary_keys-clone.patch Type: text/x-patch Size: 13077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0035-2-CLI-conversion-of-DNSName-type.patch Type: text/x-patch Size: 1069 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0036-2-DNSName-conversion-in-ipaldap.patch Type: text/x-patch Size: 1744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0037-2-Modified-has_output-attributes.patch Type: text/x-patch Size: 1721 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0038-2-Modified-dns-related-global-functions.patch Type: text/x-patch Size: 16434 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0039-2-Modified-records-and-zone-parameters-to-use-DNSNameP.patch Type: text/x-patch Size: 6232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0040-2-Modified-record-and-zone-class-to-support-IDN.patch Type: text/x-patch Size: 62098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0041-2-_domain_name_validatord-moved-from-DNS-to-realmdomai.patch Type: text/x-patch Size: 2237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0042-2-move-hostname-validation-from-DNS-to-hosts.patch Type: text/x-patch Size: 1840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0045-2-DNS-modified-tests.patch Type: text/x-patch Size: 57143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0046-2-DNS-new-tests.patch Type: text/x-patch Size: 34437 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0047-1-PTR-record-target-can-be-relative.patch Type: text/x-patch Size: 1384 bytes Desc: not available URL: From farzad.niazmand at gmail.com Sun Apr 13 08:53:11 2014 From: farzad.niazmand at gmail.com (farzad niazmand) Date: Sun, 13 Apr 2014 13:23:11 +0430 Subject: [Freeipa-devel] incorrect permission when creating home directory automatically Message-ID: Hi I enabled --enablemkhomedir option when configured Clients to automatically create home directories as user logs in. The problem I have is whenever a users logs in for the first time and a home directory creates for it, the permission of that home directory is 755 but I want the permission to be 700. How can i fix this?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Apr 14 08:31:34 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 14 Apr 2014 10:31:34 +0200 Subject: [Freeipa-devel] incorrect permission when creating home directory automatically In-Reply-To: References: Message-ID: <20140414083134.GB4938@hendrix.brq.redhat.com> On Sun, Apr 13, 2014 at 01:23:11PM +0430, farzad niazmand wrote: > Hi > I enabled --enablemkhomedir option when configured Clients to automatically > create home directories as user logs in. > The problem I have is whenever a users logs in for the first time and a > home directory creates for it, the permission of that home directory is 755 > but I want the permission to be 700. > How can i fix this? Set the permissions of your choice in /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf From mkosek at redhat.com Mon Apr 14 08:54:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Apr 2014 10:54:02 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <5347E5AC.9050106@redhat.com> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> <1397134344.19767.79.camel@willson.li.ssimo.org> <534696D5.8080000@redhat.com> <5346B8CE.1030602@redhat.com> <53479E58.5090606@redhat.com> <1397219769.19767.95.camel@willson.li.ssimo.org> <5347E5AC.9050106@redhat.com> Message-ID: <534BA22A.8080009@redhat.com> On 04/11/2014 02:53 PM, Petr Viktorin wrote: > On 04/11/2014 02:36 PM, Simo Sorce wrote: >> On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote: >>> On 04/10/2014 05:29 PM, Petr Viktorin wrote: >>>> On 04/10/2014 03:04 PM, Martin Kosek wrote: >>>>> On 04/10/2014 02:52 PM, Simo Sorce wrote: >>>>>> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: >>>>>>> On 04/09/2014 12:25 PM, Martin Kosek wrote: >>>>>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>>>>>> Hello, >>>>>>>>> This adds read permissions to read hosts. >>>>>>>>> >>>>>>>>> Read access is given to all authenticated users. >>>>>>>>> For reading host membership info, there is a separate permission that >>>>>>>>> also >>>>>>>>> defaults to all authenticated users. >>>>>>>>> >>>>>>>>> The userPassword attribute is not included for obvious reasons. >>>>>>>> >>>>>>>> 1) We decided to show hosts only to authenticated users by default. I >>>>>>>> am just >>>>>>>> thinking - should some portion of hosts be readable just like groups and >>>>>>>> users >>>>>>>> are? For example at least the host core defined by nsHost objectlass? >>>>>>>> >>>>>>>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined >>>>>>>> objectclass' >>>>>>>> SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ >>>>>>>> nsHostLoc >>>>>>>> ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) >>>>>>>> >>>>>>>> Are application supposed to be able to anonymously read that information? >>>>>>> >>>>>>> I'm not sure. Simo? >>>>>> >>>>>> Good question, probably not by default, we offer DNS and do not >>>>>> recommend people to rely on exposed host maps. >>>>> >>>>> Question is if should have a separate permission like "System: Read Host Core >>>>> Attributes", "System: Read Host", "System: Read Host Membership" or we are >>>>> fine >>>>> with just "System: Read Host", "System: Read Host Membership". >>>>> >>>>> If we do not expect people and programs to often read the list of host or the >>>>> basic host information anonymously, I would stick with the latter. >>>> >>>> Let's do that then. It's easy enough to add a custom permission. >>>> >>>>>>>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read >>>>>>>> Host >>>>>>>> Membership" permission or should it be included in the "Read Hosts" >>>>>>>> permission? >>>>>>>> >>>>>>>> If we want to stick with previous behavior, we would want to have only >>>>>>>> "memberOf" listed as this is how our original member handling ACI looks >>>>>>>> like: >>>>>>>> >>>>>>>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || >>>>>>>> memberHost || >>>>>>>> memberUser")(version 3.0; acl "No anonymous access to member information"; >>>>>>>> deny >>>>>>>> (read,search,compare) userdn != "ldap:///all"; >>>>>>> >>>>>>> What was the reasoning behind enrolledBy and managedBy? I got it from >>>>>>> the notes from devconf; I don't think there was much discussion. >>>>>> >>>>>> I have no recollection :( >>>>> >>>>> There was no discussion about these particular attributes. I added then to >>>>> Membership permission because they were DN-ish, but when I think more >>>>> about it, >>>>> it does not seem as a membership in the sense of the ACI above. I would >>>>> personally only keep member/memberOf in the Membership attributes. >>>> >>>> Moved to Read Host. >>>> >>>>>>>> 3) I could not functionally test if e.g. clients and replicas still >>>>>>>> enroll as >>>>>>>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and >>>>>>>> ipa-client-install searches for it. >>>>>>>> >>>>>>>> Speaking of which, we will need to have an ACI for reading a portion of >>>>>>>> krbRealmContainer anonymously to enable IPA client autodiscovery >>>>>>>> (cn+objectclass should be sufficient). >>>>>> >>>>>> Sad we ended up depending on this, I would have preferred to not depend >>>>>> on keeping this around if we ever want to change something. >>>>> >>>>> Yeah... But we should be OK with exposing just the CN which is not really a >>>>> secret as we know what is the realm name... >>>>> >>>>> Martin >>>>> >>> >>> The basis looks good now. However, when I was checking host's objectclass and >>> attributes we allow, I saw many attributes not listed in our DevConf meeting >>> minutes, but which are now missing in the entry when I read it as authenticated >>> used. >> >> As an admin, or as a regular user ? >> >>> krbPrincipalAux attributes like krbCanonicalName, krbExtraData, >>> krbLastAdminUnlock, krbLastFailedAuth... >>> We may want to list them all, except the ones we chose to now show, like >>> krbPrincipalKey :) I would welcome Simo's recommendation in this place. >> >> I do not think we necessarily need to expose most of them to regular >> users (which include keytab bearing services) by default. >> >>> krbTicketPolicyAux attributes like krbMaxRenewableAge >>> >>> Objectclasses for reference: >>> >>> objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR >>> Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey >>> $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ >>> krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange >>> $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF >>> ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) >> >> Of these we may want to show krbPrincipalName, krbCanonicalName, >> krbPrincipalAliases by default. > > Added. > >> I am uncertain about krbPrincipalExpiration, krbPasswordExpiration, >> krbLastPwdChange, but they may be needed for clients like SSSD to do >> proper checking and for power users to figure out themselves when they >> need to change passwords or ask for an account validity extension etc.. > > Let's show them then, to make their lives easier. Paranoid admins can always > hide them. > >> We certainly should not expose: >> krbPrincipalKey, krbPwdHistory (though we do not use this IIRC, yet), >> krbExtraData >> >> The rest I lean more on the not showing by default, although they could >> be safely shown to authenticated users if necessary. > > Similarly, generous admins can always give more access. I've not added these. > >>> objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 NAME 'krbTicketPolicyAux' AUXI >>> LIARY MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) ) >> >> I do not think we need to expose these, although exposing them is not >> problematic, you can infer what they are by simply asking for tickets >> anyway. > > Not added. > > > I assume the same will also apply to users and services? > IMO yes. We will see if any issue caused by unreadable attribute pops up. For example, user-status command won't work properly without additional permissions as it reads krbLastSuccessfulAuth and krbLastFailedAuth. But we will get to that part when we get to users. As for this patch, it works OK so it is an ACK from me. Martin From pviktori at redhat.com Mon Apr 14 08:58:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Apr 2014 10:58:29 +0200 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <534BA22A.8080009@redhat.com> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> <1397134344.19767.79.camel@willson.li.ssimo.org> <534696D5.8080000@redhat.com> <5346B8CE.1030602@redhat.com> <53479E58.5090606@redhat.com> <1397219769.19767.95.camel@willson.li.ssimo.org> <5347E5AC.9050106@redhat.com> <534BA22A.8080009@redhat.com> Message-ID: <534BA335.2030300@redhat.com> On 04/14/2014 10:54 AM, Martin Kosek wrote: > On 04/11/2014 02:53 PM, Petr Viktorin wrote: >> On 04/11/2014 02:36 PM, Simo Sorce wrote: >>> On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote: >>>> On 04/10/2014 05:29 PM, Petr Viktorin wrote: >>>>> On 04/10/2014 03:04 PM, Martin Kosek wrote: >>>>>> On 04/10/2014 02:52 PM, Simo Sorce wrote: >>>>>>> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: >>>>>>>> On 04/09/2014 12:25 PM, Martin Kosek wrote: >>>>>>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: >>>>>>>>>> Hello, >>>>>>>>>> This adds read permissions to read hosts. >>>>>>>>>> >>>>>>>>>> Read access is given to all authenticated users. >>>>>>>>>> For reading host membership info, there is a separate permission that >>>>>>>>>> also >>>>>>>>>> defaults to all authenticated users. >>>>>>>>>> >>>>>>>>>> The userPassword attribute is not included for obvious reasons. >>>>>>>>> >>>>>>>>> 1) We decided to show hosts only to authenticated users by default. I >>>>>>>>> am just >>>>>>>>> thinking - should some portion of hosts be readable just like groups and >>>>>>>>> users >>>>>>>>> are? For example at least the host core defined by nsHost objectlass? >>>>>>>>> >>>>>>>>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined >>>>>>>>> objectclass' >>>>>>>>> SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ >>>>>>>>> nsHostLoc >>>>>>>>> ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) >>>>>>>>> >>>>>>>>> Are application supposed to be able to anonymously read that information? >>>>>>>> >>>>>>>> I'm not sure. Simo? >>>>>>> >>>>>>> Good question, probably not by default, we offer DNS and do not >>>>>>> recommend people to rely on exposed host maps. >>>>>> >>>>>> Question is if should have a separate permission like "System: Read Host Core >>>>>> Attributes", "System: Read Host", "System: Read Host Membership" or we are >>>>>> fine >>>>>> with just "System: Read Host", "System: Read Host Membership". >>>>>> >>>>>> If we do not expect people and programs to often read the list of host or the >>>>>> basic host information anonymously, I would stick with the latter. >>>>> >>>>> Let's do that then. It's easy enough to add a custom permission. >>>>> >>>>>>>>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read >>>>>>>>> Host >>>>>>>>> Membership" permission or should it be included in the "Read Hosts" >>>>>>>>> permission? >>>>>>>>> >>>>>>>>> If we want to stick with previous behavior, we would want to have only >>>>>>>>> "memberOf" listed as this is how our original member handling ACI looks >>>>>>>>> like: >>>>>>>>> >>>>>>>>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || >>>>>>>>> memberHost || >>>>>>>>> memberUser")(version 3.0; acl "No anonymous access to member information"; >>>>>>>>> deny >>>>>>>>> (read,search,compare) userdn != "ldap:///all"; >>>>>>>> >>>>>>>> What was the reasoning behind enrolledBy and managedBy? I got it from >>>>>>>> the notes from devconf; I don't think there was much discussion. >>>>>>> >>>>>>> I have no recollection :( >>>>>> >>>>>> There was no discussion about these particular attributes. I added then to >>>>>> Membership permission because they were DN-ish, but when I think more >>>>>> about it, >>>>>> it does not seem as a membership in the sense of the ACI above. I would >>>>>> personally only keep member/memberOf in the Membership attributes. >>>>> >>>>> Moved to Read Host. >>>>> >>>>>>>>> 3) I could not functionally test if e.g. clients and replicas still >>>>>>>>> enroll as >>>>>>>>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and >>>>>>>>> ipa-client-install searches for it. >>>>>>>>> >>>>>>>>> Speaking of which, we will need to have an ACI for reading a portion of >>>>>>>>> krbRealmContainer anonymously to enable IPA client autodiscovery >>>>>>>>> (cn+objectclass should be sufficient). >>>>>>> >>>>>>> Sad we ended up depending on this, I would have preferred to not depend >>>>>>> on keeping this around if we ever want to change something. >>>>>> >>>>>> Yeah... But we should be OK with exposing just the CN which is not really a >>>>>> secret as we know what is the realm name... >>>>>> >>>>>> Martin >>>>>> >>>> >>>> The basis looks good now. However, when I was checking host's objectclass and >>>> attributes we allow, I saw many attributes not listed in our DevConf meeting >>>> minutes, but which are now missing in the entry when I read it as authenticated >>>> used. >>> >>> As an admin, or as a regular user ? >>> >>>> krbPrincipalAux attributes like krbCanonicalName, krbExtraData, >>>> krbLastAdminUnlock, krbLastFailedAuth... >>>> We may want to list them all, except the ones we chose to now show, like >>>> krbPrincipalKey :) I would welcome Simo's recommendation in this place. >>> >>> I do not think we necessarily need to expose most of them to regular >>> users (which include keytab bearing services) by default. >>> >>>> krbTicketPolicyAux attributes like krbMaxRenewableAge >>>> >>>> Objectclasses for reference: >>>> >>>> objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR >>>> Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey >>>> $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ >>>> krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange >>>> $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF >>>> ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) >>> >>> Of these we may want to show krbPrincipalName, krbCanonicalName, >>> krbPrincipalAliases by default. >> >> Added. >> >>> I am uncertain about krbPrincipalExpiration, krbPasswordExpiration, >>> krbLastPwdChange, but they may be needed for clients like SSSD to do >>> proper checking and for power users to figure out themselves when they >>> need to change passwords or ask for an account validity extension etc.. >> >> Let's show them then, to make their lives easier. Paranoid admins can always >> hide them. >> >>> We certainly should not expose: >>> krbPrincipalKey, krbPwdHistory (though we do not use this IIRC, yet), >>> krbExtraData >>> >>> The rest I lean more on the not showing by default, although they could >>> be safely shown to authenticated users if necessary. >> >> Similarly, generous admins can always give more access. I've not added these. >> >>>> objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 NAME 'krbTicketPolicyAux' AUXI >>>> LIARY MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) ) >>> >>> I do not think we need to expose these, although exposing them is not >>> problematic, you can infer what they are by simply asking for tickets >>> anyway. >> >> Not added. >> >> >> I assume the same will also apply to users and services? >> > > IMO yes. We will see if any issue caused by unreadable attribute pops up. For > example, user-status command won't work properly without additional permissions > as it reads krbLastSuccessfulAuth and krbLastFailedAuth. But we will get to > that part when we get to users. > > As for this patch, it works OK so it is an ACK from me. Thanks, pushed to master: c08f8d2f1e61e607a493980880a81120ad01a045 -- Petr? From mkosek at redhat.com Mon Apr 14 10:03:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Apr 2014 12:03:29 +0200 Subject: [Freeipa-devel] [PATCH] 0519 Add managed read permissions to pwpolicy and cosentry In-Reply-To: <1397219941.19767.96.camel@willson.li.ssimo.org> References: <5347DF84.1000509@redhat.com> <1397219941.19767.96.camel@willson.li.ssimo.org> Message-ID: <534BB271.8040102@redhat.com> On 04/11/2014 02:39 PM, Simo Sorce wrote: > On Fri, 2014-04-11 at 14:26 +0200, Petr Viktorin wrote: >> Read access is given as a new privilege, 'Password Policy Readers', and >> also to the existing privilege 'Password Policy Administrator'. >> > > LGTM > Simo. > I tested and it works fine. I hit a crash when manipulating pwpolicy: https://fedorahosted.org/freeipa/ticket/4309 However, it is not related to this patch and is present in current master tree. I.e. not a blocker for this patch. ACK from me too. Martin From pviktori at redhat.com Mon Apr 14 10:06:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Apr 2014 12:06:04 +0200 Subject: [Freeipa-devel] [PATCH] 0519 Add managed read permissions to pwpolicy and cosentry In-Reply-To: <534BB271.8040102@redhat.com> References: <5347DF84.1000509@redhat.com> <1397219941.19767.96.camel@willson.li.ssimo.org> <534BB271.8040102@redhat.com> Message-ID: <534BB30C.3050300@redhat.com> On 04/14/2014 12:03 PM, Martin Kosek wrote: > On 04/11/2014 02:39 PM, Simo Sorce wrote: >> On Fri, 2014-04-11 at 14:26 +0200, Petr Viktorin wrote: >>> Read access is given as a new privilege, 'Password Policy Readers', and >>> also to the existing privilege 'Password Policy Administrator'. >>> >> >> LGTM >> Simo. >> > > I tested and it works fine. I hit a crash when manipulating pwpolicy: > https://fedorahosted.org/freeipa/ticket/4309 > > However, it is not related to this patch and is present in current master tree. > I.e. not a blocker for this patch. > > ACK from me too. > > Martin > Thanks, pushed to master: f10ec17c03dfe6bdf46903e89f68fa588664fdc0 -- Petr? From mkosek at redhat.com Mon Apr 14 10:55:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Apr 2014 12:55:06 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc Message-ID: <534BBE8A.6080101@redhat.com> When heading for a lunch today, I had a discussion with Petr3 about ACIs for cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will simply allow all attributes in cn=etc for authenticated users and will just exclude the blacklisted attributes (for context, see ticket #3566). I personally think it is not the best thing to do as it will just move the problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It would be better to add normal ACIs for cn=etc as well. I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it seems straightforward what ACIs would be needed: ========================================================================== dn: cn=etc,SUFFIX - ADD aci allowing reading nsContainer for anonymous, EXCEPT: - cn=virtual operations,cn=etc,SUFFIX - cn=masters,cn=ipa,cn=etc,SUFFIX - cn=Managed Entries,cn=etc,SUFFIX dn: cn=sysaccounts,cn=etc,SUFFIX - ADD aci allowing reading all attributes but password attributes (people may add unstructured accounts following different objectclasses) dn: cn=ipa,cn=etc,SUFFIX - no ACI needed dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) dn: cn=replicas,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading replicas for authenticated users (masters) dn: cn=dna,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading dnaSharedConfig objects for authenticated dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX - no ACI needed dn: cn=ca_renewal,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading for authenticated users (hosts' certmonger) dn: cn=s4u2proxy,cn=etc,SUFFIX - no ACI needed at this point, KDC access it with DM privileges AFAIK dn: cn=ipaConfig,cn=etc,SUFFIX - ADD aci allowing reading ipaConfigObject attributes for authenticated users. We already plan aci allowing writing them dn: cn=ranges,cn=etc,SUFFIX - ADD aci allowing reading ipaIDrange for authenticated users dn: cn=virtual operations,cn=etc,SUFFIX - ADD aci allowing reading/updating virtual operations, assign to RBAC privileges dn: cn=retrieve certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=request certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=request certificate different host,cn=virtual operations,SUFFIX dn: cn=certificate status,cn=virtual operations,cn=etc,SUFFIX dn: cn=revoke certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=certificate remove hold,cn=virtual operations,cn=etc,SUFFIX - no ACI needed dn: cn=Managed Entries,cn=etc,SUFFIX - no ACI needed, not managed by IPA users dn: cn=automember,cn=etc,SUFFIX - ADD standard automembers ACIs (read, write, delete, ...) dn: cn=CAcert,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading cACertificate for anonymous dn: cn=anonymous-limits,cn=etc,SUFFIX - no ACI needed, not managed by IPA users dn: cn=replication,cn=etc,SUFFIX - ADD aci allowing reading for authenticated users (used in ipa-replica-install) dn: cn=Realm Domains,cn=ipa,cn=etc,SUFFIX - no ACI needed, we already added read aci dn: cn=ad,cn=etc,SUFFIX - ADD aci allowing reading ipaNTDomainAttrs for authenticated users (trust settings) ========================================================================== That should be pretty much all. I know that devil hides in details, but I did not see any blocker to skip the chance to add proper ACIs also for cn=etc as well and thus remove the all allowing ACI at all (I am afraid that we would be stuck with cn=etc all-allowing ACI for years otherwise). Comments welcome. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pviktori at redhat.com Mon Apr 14 11:04:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Apr 2014 13:04:47 +0200 Subject: [Freeipa-devel] [PATCH] 0520 Add managed read permission to service Message-ID: <534BC0CF.9090103@redhat.com> Read access is given to all authenticated users. Exposed attributes are: [top] objectClass [ipaObject] ipaUniqueID [ipaService] managedBy memberOf ipaKrbAuthzData (a.k.a. pac_type) [pkiUser] userCertificate [krbPrincipalAux] krbPrincipalName krbCanonicalName krbPrincipalAliases krbPrincipalExpiration krbPasswordExpiration krbLastPwdChange [krbTicketPolicyAux] - none [ipaKrbPrincipal] krbPrincipalName ipaKrbPrincipalAlias [krbPrincipal] krbPrincipalName krbObjectReferences Kerberos-related attributes were discussed for hosts here: http://www.redhat.com/archives/freeipa-devel/2014-April/msg00242.html -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0520-Add-managed-read-permissions-to-service.patch Type: text/x-patch Size: 1514 bytes Desc: not available URL: From simo at redhat.com Mon Apr 14 13:50:46 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 14 Apr 2014 09:50:46 -0400 Subject: [Freeipa-devel] [PATCH] 0506 Default read ACIs for hosts In-Reply-To: <534BA22A.8080009@redhat.com> References: <533D3364.1010606@redhat.com> <5345200B.1010802@redhat.com> <534686D6.7010403@redhat.com> <1397134344.19767.79.camel@willson.li.ssimo.org> <534696D5.8080000@redhat.com> <5346B8CE.1030602@redhat.com> <53479E58.5090606@redhat.com> <1397219769.19767.95.camel@willson.li.ssimo.org> <5347E5AC.9050106@redhat.com> <534BA22A.8080009@redhat.com> Message-ID: <1397483446.19767.241.camel@willson.li.ssimo.org> On Mon, 2014-04-14 at 10:54 +0200, Martin Kosek wrote: > On 04/11/2014 02:53 PM, Petr Viktorin wrote: > > On 04/11/2014 02:36 PM, Simo Sorce wrote: > >> On Fri, 2014-04-11 at 09:48 +0200, Martin Kosek wrote: > >>> On 04/10/2014 05:29 PM, Petr Viktorin wrote: > >>>> On 04/10/2014 03:04 PM, Martin Kosek wrote: > >>>>> On 04/10/2014 02:52 PM, Simo Sorce wrote: > >>>>>> On Thu, 2014-04-10 at 13:56 +0200, Petr Viktorin wrote: > >>>>>>> On 04/09/2014 12:25 PM, Martin Kosek wrote: > >>>>>>>> On 04/03/2014 12:09 PM, Petr Viktorin wrote: > >>>>>>>>> Hello, > >>>>>>>>> This adds read permissions to read hosts. > >>>>>>>>> > >>>>>>>>> Read access is given to all authenticated users. > >>>>>>>>> For reading host membership info, there is a separate permission that > >>>>>>>>> also > >>>>>>>>> defaults to all authenticated users. > >>>>>>>>> > >>>>>>>>> The userPassword attribute is not included for obvious reasons. > >>>>>>>> > >>>>>>>> 1) We decided to show hosts only to authenticated users by default. I > >>>>>>>> am just > >>>>>>>> thinking - should some portion of hosts be readable just like groups and > >>>>>>>> users > >>>>>>>> are? For example at least the host core defined by nsHost objectlass? > >>>>>>>> > >>>>>>>> objectClasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined > >>>>>>>> objectclass' > >>>>>>>> SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ > >>>>>>>> nsHostLoc > >>>>>>>> ation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' ) > >>>>>>>> > >>>>>>>> Are application supposed to be able to anonymously read that information? > >>>>>>> > >>>>>>> I'm not sure. Simo? > >>>>>> > >>>>>> Good question, probably not by default, we offer DNS and do not > >>>>>> recommend people to rely on exposed host maps. > >>>>> > >>>>> Question is if should have a separate permission like "System: Read Host Core > >>>>> Attributes", "System: Read Host", "System: Read Host Membership" or we are > >>>>> fine > >>>>> with just "System: Read Host", "System: Read Host Membership". > >>>>> > >>>>> If we do not expect people and programs to often read the list of host or the > >>>>> basic host information anonymously, I would stick with the latter. > >>>> > >>>> Let's do that then. It's easy enough to add a custom permission. > >>>> > >>>>>>>> 2) Do we want to count enrolledBy and managedBy attribute to "System: Read > >>>>>>>> Host > >>>>>>>> Membership" permission or should it be included in the "Read Hosts" > >>>>>>>> permission? > >>>>>>>> > >>>>>>>> If we want to stick with previous behavior, we would want to have only > >>>>>>>> "memberOf" listed as this is how our original member handling ACI looks > >>>>>>>> like: > >>>>>>>> > >>>>>>>> install/share/default-aci.ldif:aci: (targetattr = "memberOf || > >>>>>>>> memberHost || > >>>>>>>> memberUser")(version 3.0; acl "No anonymous access to member information"; > >>>>>>>> deny > >>>>>>>> (read,search,compare) userdn != "ldap:///all"; > >>>>>>> > >>>>>>> What was the reasoning behind enrolledBy and managedBy? I got it from > >>>>>>> the notes from devconf; I don't think there was much discussion. > >>>>>> > >>>>>> I have no recollection :( > >>>>> > >>>>> There was no discussion about these particular attributes. I added then to > >>>>> Membership permission because they were DN-ish, but when I think more > >>>>> about it, > >>>>> it does not seem as a membership in the sense of the ACI above. I would > >>>>> personally only keep member/memberOf in the Membership attributes. > >>>> > >>>> Moved to Read Host. > >>>> > >>>>>>>> 3) I could not functionally test if e.g. clients and replicas still > >>>>>>>> enroll as > >>>>>>>> we do not have an ACI for krbtpolicy/krbRealmContainer yet and > >>>>>>>> ipa-client-install searches for it. > >>>>>>>> > >>>>>>>> Speaking of which, we will need to have an ACI for reading a portion of > >>>>>>>> krbRealmContainer anonymously to enable IPA client autodiscovery > >>>>>>>> (cn+objectclass should be sufficient). > >>>>>> > >>>>>> Sad we ended up depending on this, I would have preferred to not depend > >>>>>> on keeping this around if we ever want to change something. > >>>>> > >>>>> Yeah... But we should be OK with exposing just the CN which is not really a > >>>>> secret as we know what is the realm name... > >>>>> > >>>>> Martin > >>>>> > >>> > >>> The basis looks good now. However, when I was checking host's objectclass and > >>> attributes we allow, I saw many attributes not listed in our DevConf meeting > >>> minutes, but which are now missing in the entry when I read it as authenticated > >>> used. > >> > >> As an admin, or as a regular user ? > >> > >>> krbPrincipalAux attributes like krbCanonicalName, krbExtraData, > >>> krbLastAdminUnlock, krbLastFailedAuth... > >>> We may want to list them all, except the ones we chose to now show, like > >>> krbPrincipalKey :) I would welcome Simo's recommendation in this place. > >> > >> I do not think we necessarily need to expose most of them to regular > >> users (which include keytab bearing services) by default. > >> > >>> krbTicketPolicyAux attributes like krbMaxRenewableAge > >>> > >>> Objectclasses for reference: > >>> > >>> objectClasses: ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' AUXILIAR > >>> Y MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey > >>> $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ > >>> krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange > >>> $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginF > >>> ailedCount $ krbExtraData $ krbLastAdminUnlock ) ) > >> > >> Of these we may want to show krbPrincipalName, krbCanonicalName, > >> krbPrincipalAliases by default. > > > > Added. > > > >> I am uncertain about krbPrincipalExpiration, krbPasswordExpiration, > >> krbLastPwdChange, but they may be needed for clients like SSSD to do > >> proper checking and for power users to figure out themselves when they > >> need to change passwords or ask for an account validity extension etc.. > > > > Let's show them then, to make their lives easier. Paranoid admins can always > > hide them. > > > >> We certainly should not expose: > >> krbPrincipalKey, krbPwdHistory (though we do not use this IIRC, yet), > >> krbExtraData > >> > >> The rest I lean more on the not showing by default, although they could > >> be safely shown to authenticated users if necessary. > > > > Similarly, generous admins can always give more access. I've not added these. > > > >>> objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 NAME 'krbTicketPolicyAux' AUXI > >>> LIARY MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) ) > >> > >> I do not think we need to expose these, although exposing them is not > >> problematic, you can infer what they are by simply asking for tickets > >> anyway. > > > > Not added. > > > > > > I assume the same will also apply to users and services? > > > > IMO yes. We will see if any issue caused by unreadable attribute pops up. For > example, user-status command won't work properly without additional permissions > as it reads krbLastSuccessfulAuth and krbLastFailedAuth. But we will get to > that part when we get to users. Admin/Helpdesk people will need access to those attributes indeed. I guess those should be added to permissions to manage users. > As for this patch, it works OK so it is an ACK from me. LGTM. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Apr 14 14:00:37 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 Apr 2014 10:00:37 -0400 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <534BBE8A.6080101@redhat.com> References: <534BBE8A.6080101@redhat.com> Message-ID: <1397484037.19767.243.camel@willson.li.ssimo.org> On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: > When heading for a lunch today, I had a discussion with Petr3 about ACIs for > cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will > simply allow all attributes in cn=etc for authenticated users and will just > exclude the blacklisted attributes (for context, see ticket #3566). > > I personally think it is not the best thing to do as it will just move the > problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It > would be better to add normal ACIs for cn=etc as well. > > I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it > seems straightforward what ACIs would be needed: > > ========================================================================== > dn: cn=etc,SUFFIX > - ADD aci allowing reading nsContainer for anonymous, EXCEPT: > - cn=virtual operations,cn=etc,SUFFIX > - cn=masters,cn=ipa,cn=etc,SUFFIX > - cn=Managed Entries,cn=etc,SUFFIX > > dn: cn=sysaccounts,cn=etc,SUFFIX > - ADD aci allowing reading all attributes but password attributes (people may > add unstructured accounts following different objectclasses) > > dn: cn=ipa,cn=etc,SUFFIX > - no ACI needed > > dn: cn=masters,cn=ipa,cn=etc,SUFFIX > - ADD aci allowing reading hosts (to have it separate from global cn=etc one so > that we can once assign it only to ipamasters hostgroup for example) > > dn: cn=replicas,cn=ipa,cn=etc,SUFFIX > - ADD aci allowing reading replicas for authenticated users (masters) > > dn: cn=dna,cn=ipa,cn=etc,SUFFIX > - ADD aci allowing reading dnaSharedConfig objects for authenticated > > dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX > - no ACI needed > > dn: cn=ca_renewal,cn=ipa,cn=etc,SUFFIX > - ADD aci allowing reading for authenticated users (hosts' certmonger) > > dn: cn=s4u2proxy,cn=etc,SUFFIX > - no ACI needed at this point, KDC access it with DM privileges AFAIK > > dn: cn=ipaConfig,cn=etc,SUFFIX > - ADD aci allowing reading ipaConfigObject attributes for authenticated users. > We already plan aci allowing writing them > > dn: cn=ranges,cn=etc,SUFFIX > - ADD aci allowing reading ipaIDrange for authenticated users > > dn: cn=virtual operations,cn=etc,SUFFIX > - ADD aci allowing reading/updating virtual operations, assign to RBAC privileges > > dn: cn=retrieve certificate,cn=virtual operations,cn=etc,SUFFIX > dn: cn=request certificate,cn=virtual operations,cn=etc,SUFFIX > dn: cn=request certificate different host,cn=virtual operations,SUFFIX > dn: cn=certificate status,cn=virtual operations,cn=etc,SUFFIX > dn: cn=revoke certificate,cn=virtual operations,cn=etc,SUFFIX > dn: cn=certificate remove hold,cn=virtual operations,cn=etc,SUFFIX > - no ACI needed > > dn: cn=Managed Entries,cn=etc,SUFFIX > - no ACI needed, not managed by IPA users > > dn: cn=automember,cn=etc,SUFFIX > - ADD standard automembers ACIs (read, write, delete, ...) > > dn: cn=CAcert,cn=ipa,cn=etc,SUFFIX > - ADD aci allowing reading cACertificate for anonymous > > dn: cn=anonymous-limits,cn=etc,SUFFIX > - no ACI needed, not managed by IPA users > > dn: cn=replication,cn=etc,SUFFIX > - ADD aci allowing reading for authenticated users (used in ipa-replica-install) > > dn: cn=Realm Domains,cn=ipa,cn=etc,SUFFIX > - no ACI needed, we already added read aci > > dn: cn=ad,cn=etc,SUFFIX > - ADD aci allowing reading ipaNTDomainAttrs for authenticated users (trust > settings) > > ========================================================================== > > That should be pretty much all. I know that devil hides in details, but I did > not see any blocker to skip the chance to add proper ACIs also for cn=etc as > well and thus remove the all allowing ACI at all (I am afraid that we would be > stuck with cn=etc all-allowing ACI for years otherwise). > > Comments welcome. Agree with the general plan, let's start with this and add permissions as needed. Simo. From alee at redhat.com Mon Apr 14 14:42:12 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 14 Apr 2014 10:42:12 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <5343FF31.8050206@redhat.com> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> <53439C4D.6060108@redhat.com> <5343FF31.8050206@redhat.com> Message-ID: <1397486532.29593.8.camel@aleeredhat.laptop> Attached a new patch to address some of the concerns below, specifically I created a new base class DogtagInstance, in which much of the common CA/KRA code is placed. I'm sure we could go further in reducing duplication, and I'm open to further suggestions and refinements. I did not tackle the packaging and spec file dependencies, because I'd like some clearer direction on how we want to proceed here. In any case, I think the splitting of the ipa packages into ca and possibly kra packages should be a separate patch. As before, with this patch you can: - install a ca and drm using ipa-server-install - install a ca and drm replica using ipa-replica-prepare ipa-replica-install --setup-ca --setup-drm You need to use a PKI build from the 10.2 (master) branch). One such build is given below: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo Thanks, Ade On Tue, 2014-04-08 at 09:52 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On 04/07/2014 10:40 PM, Rob Crittenden wrote: > >> Ade Lee wrote: > >>> This patch adds the capability of installing a Dogtag DRM > >>> to an IPA instance. With this patch, when ipa-server-install > >>> is run, a Dogtag CA and a Dogtag DRM are created. The DRM > >>> shares the same tomcat instance and DS instance as the Dogtag CA. > >>> Moreover, the same admin user/agent (and agent cert) can be used > >>> for both subsystems. Certmonger is also confgured to monitor the > >>> new subsystem certificates. > >>> > >>> It is also possible to clone the DRM. When the IPA instance is > >>> cloned, if --enable-ca and --enable-drm are specified, the DRM > >>> is cloned as well. > >>> > >>> Installing a DRM requires the user to have a Dogtag CA instance. > >>> We can look into possibly relaxing that requirement in a later patch. > >>> > >>> I am still working on patches for a ipa-drm-install script, which > >>> would be used to add a DRM to an existing master (that includes > >>> a dogtag CA), or an existing clone. > >>> > >>> Please review, > >>> > >>> Thanks, > >>> Ade > >> > >> Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be > >> pushed ASAP. > > > > Oops, looks like a change that should go to IPA 3.3.x. What is the implication? > > > >> freeipa-spec.in needs a dependency on pki-kra. > > > > Let us stop here. Please see a following RFE I filed: > > https://fedorahosted.org/freeipa/ticket/4058 > > > > I would prefer it KRA files and specifics would be in a new subpackage like > > freeipa-server-kra. Otherwise we will need to rework it again when we would be > > splitting CA to freeipa-server-pki in 4.1. > > Yes, that is a question I didn't ask: Is the DRM going to be configured > by default on all new installs? > > > I would prefer to start the right modularization now as I do not think that > > every FreeIPA server needs to run CA/KRA, i.e. it does not need to have the > > bits installed either. > > I think the decision on a separate sub-package will be dependent upon > whether it is default or not, otherwise we can get away with > freeipa-server-ca and just lump everything in there. > > > I am also quite worried about the duplication that the new drminstance.py > > introduces. There is a lot of functions which do more or less the same thing > > and have most of the handling code the same with only a very small and > > predictable pki/kra change. For example __http_proxy function seems to be > > exactly the same. > > > > It would be great to avoid this duplication and rather have some common ground > > utilized by both PKI and KRA. Otherwise it will be very difficult to maintain > > the new code. > > I touched on some of that too, but some of this is just inevitable I > think which is why I didn't pound on it too hard. An abstraction would > be nice, but I'm not sure abstracting for two things, and only in the > installer, is worth the effort. I could be wrong. > > rob > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 73390 bytes Desc: not available URL: From pviktori at redhat.com Mon Apr 14 16:54:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Apr 2014 18:54:20 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name Message-ID: <534C12BC.4040805@redhat.com> Hello, The first patch adds default read permissions to krbtpolicy. Since the plugin manages entries in two trees, there are two permissions. Since two permissions are needed to cover krbtpolicy, it can't be used as a permission's --type. The permissions are added to a new privilege, 'Kerberos Ticket Policy Readers'. The second patch adds an ACI for reading the Kerberos realm name. Since client enrollment won't work without this, I don't see a reason for having it managed by a permission. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0521-Add-managed-read-permissions-to-krbtpolicy.patch Type: text/x-patch Size: 3655 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0522-Allow-anonymous-read-access-to-Kerberos-realm-contai.patch Type: text/x-patch Size: 1224 bytes Desc: not available URL: From ssorce at redhat.com Mon Apr 14 17:18:18 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 Apr 2014 13:18:18 -0400 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534C12BC.4040805@redhat.com> References: <534C12BC.4040805@redhat.com> Message-ID: <1397495898.19767.256.camel@willson.li.ssimo.org> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: > Hello, > > The first patch adds default read permissions to krbtpolicy. Since the > plugin manages entries in two trees, there are two permissions. Since > two permissions are needed to cover krbtpolicy, it can't be used as a > permission's --type. > The permissions are added to a new privilege, 'Kerberos Ticket Policy > Readers'. > > The second patch adds an ACI for reading the Kerberos realm name. Since > client enrollment won't work without this, I don't see a reason for > having it managed by a permission. > LGTM Simo. From pviktori at redhat.com Mon Apr 14 19:41:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Apr 2014 21:41:32 +0200 Subject: [Freeipa-devel] [PATCH] 0523 Fix expected output in permission tests Message-ID: <534C39EC.3060608@redhat.com> It turns out the test failure caused by the realmdomains ACI was not a single occurrence. Another one was caused by Read Group Password Policy. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0523-Fix-expected-output-in-permission-tests.patch Type: text/x-patch Size: 3208 bytes Desc: not available URL: From pviktori at redhat.com Mon Apr 14 20:00:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 14 Apr 2014 22:00:06 +0200 Subject: [Freeipa-devel] [PATCH] 0524 Add managed read permission to config Message-ID: <534C3E46.9@redhat.com> Read access is given to all authenticated users. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0524-Add-managed-read-permission-to-config.patch Type: text/x-patch Size: 1883 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 15 07:38:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Apr 2014 09:38:40 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <1397495898.19767.256.camel@willson.li.ssimo.org> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> Message-ID: <534CE200.9020200@redhat.com> On 04/14/2014 07:18 PM, Simo Sorce wrote: > On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >> Hello, >> >> The first patch adds default read permissions to krbtpolicy. Since the >> plugin manages entries in two trees, there are two permissions. Since >> two permissions are needed to cover krbtpolicy, it can't be used as a >> permission's --type. >> The permissions are added to a new privilege, 'Kerberos Ticket Policy >> Readers'. >> >> The second patch adds an ACI for reading the Kerberos realm name. Since >> client enrollment won't work without this, I don't see a reason for >> having it managed by a permission. >> > > LGTM > > Simo. > 521 breaks a unit test: ====================================================================== FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in check_output assert_deepequal(expected, got, nice) File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal VALUE % (doc, expected, got, stack) AssertionError: assert_deepequal: expected != got. test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree expected = 1 got = 2 path = ('count',) Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we miss permissions for users). Martin From pvoborni at redhat.com Tue Apr 15 07:39:54 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 15 Apr 2014 09:39:54 +0200 Subject: [Freeipa-devel] [PATCH] 569-583 New Login Screen In-Reply-To: <20140411143110.5bb2a674@unused-4-246.brq.redhat.com> References: <5335734D.9030300@redhat.com> <20140411143110.5bb2a674@unused-4-246.brq.redhat.com> Message-ID: <534CE24A.8090706@redhat.com> On 11.4.2014 14:31, Misnyovszki Adam wrote: > On Fri, 28 Mar 2014 14:04:13 +0100 > Petr Vobornik wrote: > >> Attached patches replace IPA.unauthorized dialog with new Login >> Screen. >> >> To make it happen, a support for standalone facets had to be >> developed because current framework was limited by facets dependent >> on entities and a container with menu. This new feature was already >> used for Load facet which is part of this patchset and also will be a >> basis for API browser and OTP sync page. >> >> Patches should fix these tickets: >> https://fedorahosted.org/freeipa/ticket/3903 >> https://fedorahosted.org/freeipa/ticket/4017 >> >> Depends on patches #565-#568. >> >> >> [PATCH] webui: facet container >> ------------------------------ >> A widget which servers as container for facets. FacetContainer is a >> base class. App is specialization. >> >> Doing this abstraction will allow us to implement various facet >> containers. >> >> [PATCH] webui: FormMixin >> ------------------------ >> a mixin used for fields validation. Basically implements a logic which >> is already in details facet and dialog. >> >> Now this logic can be used in any component. >> >> The long term goal is to replace the logic in details facet and dialog >> with this mixin. >> >> [PATCH] webui: ContainerMixin >> ----------------------------- >> A mixin which implements widget storing logic. Similar logic is >> already implemented >> in details facet and dialog. >> >> Long term goal is to replace that with this one. >> >> Separating the logic into mixin makes it usable in other components. >> >> [PATCH] webui: standalone facet >> ------------------------------- >> `facet.Facet` is a new base class for facets. It doesn't have any >> dependencies >> on entities so it's usable for general purpose facets, e.g., future >> API browser, >> load facet or login facet. >> >> [PATCH] webui: activity widget >> ------------------------------ >> A widget for showing ongoing activity. >> >> Displays a text with changing dots. >> >> It listens to `network-activity-start` and `network-activity-end` >> topics. >> >> [PATCH] webui: publish network activity topics >> ---------------------------------------------- >> Network activity is now published through global topics. It allows >> other components like activity_widget to listen to them. >> >> [PATCH] webui: load page >> ------------------------ >> Load page is a simple facet which is displayed up to 'runtime' phase. >> >> On application start it tells the user that there is ongoing activity. >> >> [PATCH] webui: validation summary widget >> ---------------------------------------- >> A widget which aggregates warnings and errors and shows them on one >> place. >> >> [PATCH] webui: login screen widget >> ---------------------------------- >> Reimplementation of unauthorized dialog into separate widget. It uses >> RCUE design. >> >> New features compared to unauthorized dialog: >> >> - reflects auth methods from `auth` module >> - validation summary >> - differentiates Kerberos auth failure with session expiration >> - Caps Lock warning >> - form based method doesn't allow password only submission >> >> https://fedorahosted.org/freeipa/ticket/4017 >> https://fedorahosted.org/freeipa/ticket/3903 >> >> >> [PATCH] webui: login page >> ------------------------- >> A facet with login sreen widget. >> >> [PATCH] webui: authentication module >> ------------------------------------ >> General purpose authentication interface and state. See doc of >> 'freeipa/auth' module. >> >> [PATCH] webui: use asynchronous call for authentication >> >> Change `IPA.login_password` and `IPA.get_credentials` to use async >> AJAX and to return promise instead of blocking the code. >> >> IPA.get_credentials is still partially blocking because of negotiate >> process. >> We can't do anything about that. >> >> It allows activity indicators to do their job. >> >> [PATCH] webui: fix combobox styles to work with selenium testing >> [PATCH] webui-ci: adapt to new login screen >> [PATCH] webui: remove IPA.unauthorized_dialog > > Hi, > - Attached patch fixes weird combobox behaviour - opens automatically > on facet load Thank you. I squashed it into patch 581 since it's a fix for unpushed code. > - When trying to log in with password only(username field is empty), > there is an error message "Authentication with Kerberos failed", > which is not the desired behaviour. It should sign that the username > field is invalid. New, attached version of patch #577 should fix that. It was a typo. > - When trying to log in with kerberos credentials, and the realm of > the krb ticket is not the same as the > realm of freeipa(eg freeipa realm is IPA.TEST.COM, and > the ticket's is TEST.COM), firefox goes into an endless cycle > calling the kerberos auth url. Currently it seems to me as a browser > issue. Anyways, with correct krb ticket, authentication works fine. As investigated with Adam - not a FreeIPA issue. > Although, unit tests ran, integration tests ran as expected, and > browsing through the code manually was ok for me, so if that validation > issue is corrected, than it will be an ACK. > > > Thanks: > Adam > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0577-2-webui-login-screen-widget.patch Type: text/x-patch Size: 130134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0581-1-webui-fix-combobox-styles-to-work-with-selenium-test.patch Type: text/x-patch Size: 2228 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 15 07:43:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Apr 2014 09:43:49 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534CE200.9020200@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> Message-ID: <534CE335.5070804@redhat.com> On 04/15/2014 09:38 AM, Martin Kosek wrote: > On 04/14/2014 07:18 PM, Simo Sorce wrote: >> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>> Hello, >>> >>> The first patch adds default read permissions to krbtpolicy. Since the >>> plugin manages entries in two trees, there are two permissions. Since >>> two permissions are needed to cover krbtpolicy, it can't be used as a >>> permission's --type. >>> The permissions are added to a new privilege, 'Kerberos Ticket Policy >>> Readers'. >>> >>> The second patch adds an ACI for reading the Kerberos realm name. Since >>> client enrollment won't work without this, I don't see a reason for >>> having it managed by a permission. >>> >> >> LGTM >> >> Simo. >> > > 521 breaks a unit test: > > ====================================================================== > FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using > --subtree > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in > > func = lambda: self.check(nice, **test) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in > check > self.check_output(nice, cmd, args, options, expected, extra_check) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in > check_output > assert_deepequal(expected, got, nice) > File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal > assert_deepequal(e_sub, g_sub, doc, stack + (key,)) > File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal > VALUE % (doc, expected, got, stack) > AssertionError: assert_deepequal: expected != got. > test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree > expected = 1 > got = 2 > path = ('count',) > > Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we > miss permissions for users). > > Martin /me hit Send too soon. Although 522 works functionally and client now discovers the IPA server, there is no path from SUFFIX to cn=REALM for anonymous users. I would personally change the ACI to (targetattr = "cn || objectclass")(targetfilter = "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version 3.0;acl "Anonymous read access to Kerberos container";allow (read,compare,search) userdn = "ldap:///anyone";)' and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass). Martin From mkosek at redhat.com Tue Apr 15 07:46:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Apr 2014 09:46:38 +0200 Subject: [Freeipa-devel] [PATCH] 0523 Fix expected output in permission tests In-Reply-To: <534C39EC.3060608@redhat.com> References: <534C39EC.3060608@redhat.com> Message-ID: <534CE3DE.6060302@redhat.com> On 04/14/2014 09:41 PM, Petr Viktorin wrote: > It turns out the test failure caused by the realmdomains ACI was not a single > occurrence. Another one was caused by Read Group Password Policy. > /me sighs. This fixes the tests, ACK. Pushed to master: 3deb76cf17a79a0736aa555f550415e6d9f2ed08 Martin From mkosek at redhat.com Tue Apr 15 07:53:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Apr 2014 09:53:04 +0200 Subject: [Freeipa-devel] [PATCH] 0524 Add managed read permission to config In-Reply-To: <534C3E46.9@redhat.com> References: <534C3E46.9@redhat.com> Message-ID: <534CE560.5010009@redhat.com> On 04/14/2014 10:00 PM, Petr Viktorin wrote: > Read access is given to all authenticated users. > This only works when I added cn and objectclass attributes to the ACI. Is this expected? It would work when we add nsContainer ACI for cn=etc though as it has the nsContainer objectlass. Martin From pvoborni at redhat.com Tue Apr 15 07:54:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 15 Apr 2014 09:54:22 +0200 Subject: [Freeipa-devel] [PATCH] 585 webui: fix OTP Token add regression Message-ID: <534CE5AE.8090804@redhat.com> OTP Token add failed because of invalid function call. qr_widget doesn't contain `on_value_changed` method since it inherits from `IPA.widget` and not from `IPA.input_widget`. Emitting the event was preserved for future possible usage. https://fedorahosted.org/freeipa/ticket/4306 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0585-webui-fix-OTP-Token-add-regression.patch Type: text/x-patch Size: 1175 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 15 08:37:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 15 Apr 2014 10:37:34 +0200 Subject: [Freeipa-devel] [PATCH] 0524 Add managed read permission to config In-Reply-To: <534CE560.5010009@redhat.com> References: <534C3E46.9@redhat.com> <534CE560.5010009@redhat.com> Message-ID: <534CEFCE.9040809@redhat.com> On 04/15/2014 09:53 AM, Martin Kosek wrote: > On 04/14/2014 10:00 PM, Petr Viktorin wrote: >> Read access is given to all authenticated users. >> > > This only works when I added cn and objectclass attributes to the ACI. Is this > expected? > > It would work when we add nsContainer ACI for cn=etc though as it has the > nsContainer objectlass. You're right, cn and objectclass should be granted explicitly. My mistake. Fixed patch attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0524.2-Add-managed-read-permission-to-config.patch Type: text/x-patch Size: 1922 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 15 08:43:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Apr 2014 10:43:44 +0200 Subject: [Freeipa-devel] [PATCH] 0524 Add managed read permission to config In-Reply-To: <534CEFCE.9040809@redhat.com> References: <534C3E46.9@redhat.com> <534CE560.5010009@redhat.com> <534CEFCE.9040809@redhat.com> Message-ID: <534CF140.3010807@redhat.com> On 04/15/2014 10:37 AM, Petr Viktorin wrote: > On 04/15/2014 09:53 AM, Martin Kosek wrote: >> On 04/14/2014 10:00 PM, Petr Viktorin wrote: >>> Read access is given to all authenticated users. >>> >> >> This only works when I added cn and objectclass attributes to the ACI. Is this >> expected? >> >> It would work when we add nsContainer ACI for cn=etc though as it has the >> nsContainer objectlass. > > You're right, cn and objectclass should be granted explicitly. My mistake. > Fixed patch attached. > > That's better - works fine. ACK. Pushed to master: 75eaf0bddfe0ce3eaea86b42a767c16846379b4b Martin From sbose at redhat.com Tue Apr 15 09:13:38 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 15 Apr 2014 11:13:38 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust Message-ID: <20140415091338.GE4165@localhost.localdomain> Hi, I have started to write a design page for 'Migrating existing environments to Trust' http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust It shall cover https://fedorahosted.org/freeipa/ticket/3318 and https://fedorahosted.org/freeipa/ticket/3979 . I came across several questions which need answers so that more details can be added to the design. Besides that comments and suggestions are welcome as well. For your convenience I added the test below as well. bye, Sumit = Overview = This page illustrates how existing solutions which make AD users available to Linux hosts can be migrated to FreeIPA with Trusts. This includes migrations from the FreeIPA WinSync feature or environments where the AD users where correlated to NIS users. The common problem here is that some if not all attributes needed by a POSIX user or group must be overwritten or supplied by the IPA server. The link to the related AD object is preferably the SID but if it is not available on both sides the name of the object must be used. AD will keep the responsibility for authentication and provide the AD group-memberships of the object. = Use Cases = * Migration from the FreeIPA Sync solution to the FreeIPA Trust solution ** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] * Migration/Consolidation of domains currently managed by other solutions, e.g. NIS ** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) = Design = In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. # Instead of just offering a single override option the introduction of views are suggested. A suitable client can ask for a specific view with override options different from the default override view.Questions: #* Will the default view always be applied? I think it makes sense to always apply it to get a consistent default behavior. If there is a reason for a client to get the unmodified data a special view called e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin to be able to send the raw data to the IPA client so that SSSD can use different views on the client which might be needed for docker/container use cases. #* Will views only be applied to users from other domains or to IPA users as well? #* Do we want stackable views? #* Do we want to override everything or shall there be immutable attributes like e.g. the SID or the user name? #* Shall we allow different UIDs/GIDs in different views? #* I think overriding UIDs/GIDs should only be allowed for ipa-ad-trust-posix idranges, mixing override with algorithmic mapping does not make sense imo. # The views will be stored in containers below cn=views,cn=accounts,$SUFFIX with containers for users and groups. The objectclasses will look similar to posixAccount and posixGroup objectclasses but with only optional (MAY) attributes. Questions: #* Do we want to consider to allow to add arbitrary attributes to a view to cover requests like "We have this beautiful application which can get all user data via the SSSD D-BUS responder but our AD admin will not extend the AD LDAP schema to add the required attributes. Can IPA add them for users from trusted domains?" #* It was suggested to use a UUID to reference the original objects. For AD users and groups the SID would be a good choice because it is unique and already contains a reference to the original domain. I wonder if we should add a type prefix like 'SID:' to be able to add other types like 'IPAUUID:domref:ef2b7400-a3c4-11e3-82e7-525400de2951' where domref will be a reference to the other IPA domain. On the other hand a type can be added later and if the type is missing a SID is assumed. On the SSSD side the views can be stored below the corresponding user or group object in the cache and the SYSDB API has to be enhanced to return merged results. The merging only happens in the responders (NSS, D-BUS) before sending data to the clients. To manage the views a new set CLI tools/Web UI pages should be added. Depending if we would like to allow to override IPA users as well or only users from trusted domains the tools might get their own name space, ipa override-*, or can be added below the trust name space, ipa trust-override-*. It has to be noted that changes of a view will only be visible on the client after the related cached object is expired. = Implementation = =Feature Management = == UI == == CLI == = Major configuration options and enablement = Any configuration options? Any commands to enable/disable the feature or turn on/off its parts? = Replication = Any impact on replication? = Updates and Upgrades = Any impact on updates and upgrades? = Dependencies = Any new package and library dependencies. = External Impact = Impact on other development teams and components = Backup and Restore = Any files or configuration that needs to be taken care of in backup or restore procedure. = Test Plan = Test scenarios that will be transformed to test cases for FreeIPA Continuous Integration during implementation or review phase. = RFE Author = [[User:Sbose|Sumit Bose]] From amisnyov at redhat.com Tue Apr 15 10:05:13 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 15 Apr 2014 12:05:13 +0200 Subject: [Freeipa-devel] [PATCH] 569-583 New Login Screen In-Reply-To: <534CE24A.8090706@redhat.com> References: <5335734D.9030300@redhat.com> <20140411143110.5bb2a674@unused-4-246.brq.redhat.com> <534CE24A.8090706@redhat.com> Message-ID: <20140415120513.453fb809@unused-4-246.brq.redhat.com> On Tue, 15 Apr 2014 09:39:54 +0200 Petr Vobornik wrote: > On 11.4.2014 14:31, Misnyovszki Adam wrote: > > On Fri, 28 Mar 2014 14:04:13 +0100 > > Petr Vobornik wrote: > > > >> Attached patches replace IPA.unauthorized dialog with new Login > >> Screen. > >> > >> To make it happen, a support for standalone facets had to be > >> developed because current framework was limited by facets dependent > >> on entities and a container with menu. This new feature was already > >> used for Load facet which is part of this patchset and also will > >> be a basis for API browser and OTP sync page. > >> > >> Patches should fix these tickets: > >> https://fedorahosted.org/freeipa/ticket/3903 > >> https://fedorahosted.org/freeipa/ticket/4017 > >> > >> Depends on patches #565-#568. > >> > >> > >> [PATCH] webui: facet container > >> ------------------------------ > >> A widget which servers as container for facets. FacetContainer is a > >> base class. App is specialization. > >> > >> Doing this abstraction will allow us to implement various facet > >> containers. > >> > >> [PATCH] webui: FormMixin > >> ------------------------ > >> a mixin used for fields validation. Basically implements a logic > >> which is already in details facet and dialog. > >> > >> Now this logic can be used in any component. > >> > >> The long term goal is to replace the logic in details facet and > >> dialog with this mixin. > >> > >> [PATCH] webui: ContainerMixin > >> ----------------------------- > >> A mixin which implements widget storing logic. Similar logic is > >> already implemented > >> in details facet and dialog. > >> > >> Long term goal is to replace that with this one. > >> > >> Separating the logic into mixin makes it usable in other > >> components. > >> > >> [PATCH] webui: standalone facet > >> ------------------------------- > >> `facet.Facet` is a new base class for facets. It doesn't have any > >> dependencies > >> on entities so it's usable for general purpose facets, e.g., future > >> API browser, > >> load facet or login facet. > >> > >> [PATCH] webui: activity widget > >> ------------------------------ > >> A widget for showing ongoing activity. > >> > >> Displays a text with changing dots. > >> > >> It listens to `network-activity-start` and `network-activity-end` > >> topics. > >> > >> [PATCH] webui: publish network activity topics > >> ---------------------------------------------- > >> Network activity is now published through global topics. It allows > >> other components like activity_widget to listen to them. > >> > >> [PATCH] webui: load page > >> ------------------------ > >> Load page is a simple facet which is displayed up to 'runtime' > >> phase. > >> > >> On application start it tells the user that there is ongoing > >> activity. > >> > >> [PATCH] webui: validation summary widget > >> ---------------------------------------- > >> A widget which aggregates warnings and errors and shows them on one > >> place. > >> > >> [PATCH] webui: login screen widget > >> ---------------------------------- > >> Reimplementation of unauthorized dialog into separate widget. It > >> uses RCUE design. > >> > >> New features compared to unauthorized dialog: > >> > >> - reflects auth methods from `auth` module > >> - validation summary > >> - differentiates Kerberos auth failure with session expiration > >> - Caps Lock warning > >> - form based method doesn't allow password only submission > >> > >> https://fedorahosted.org/freeipa/ticket/4017 > >> https://fedorahosted.org/freeipa/ticket/3903 > >> > >> > >> [PATCH] webui: login page > >> ------------------------- > >> A facet with login sreen widget. > >> > >> [PATCH] webui: authentication module > >> ------------------------------------ > >> General purpose authentication interface and state. See doc of > >> 'freeipa/auth' module. > >> > >> [PATCH] webui: use asynchronous call for authentication > >> > >> Change `IPA.login_password` and `IPA.get_credentials` to use async > >> AJAX and to return promise instead of blocking the code. > >> > >> IPA.get_credentials is still partially blocking because of > >> negotiate process. > >> We can't do anything about that. > >> > >> It allows activity indicators to do their job. > >> > >> [PATCH] webui: fix combobox styles to work with selenium testing > >> [PATCH] webui-ci: adapt to new login screen > >> [PATCH] webui: remove IPA.unauthorized_dialog > > > > Hi, > > - Attached patch fixes weird combobox behaviour - opens > > automatically on facet load > > Thank you. I squashed it into patch 581 since it's a fix for unpushed > code. > > > - When trying to log in with password only(username field is > > empty), there is an error message "Authentication with Kerberos > > failed", which is not the desired behaviour. It should sign that > > the username field is invalid. > > New, attached version of patch #577 should fix that. It was a typo. > > > - When trying to log in with kerberos credentials, and the realm > > of the krb ticket is not the same as the > > realm of freeipa(eg freeipa realm is IPA.TEST.COM, and > > the ticket's is TEST.COM), firefox goes into an endless cycle > > calling the kerberos auth url. Currently it seems to me as a > > browser issue. Anyways, with correct krb ticket, authentication > > works fine. > > As investigated with Adam - not a FreeIPA issue. > > > Although, unit tests ran, integration tests ran as expected, and > > browsing through the code manually was ok for me, so if that > > validation issue is corrected, than it will be an ACK. > > > > > > Thanks: > > Adam > > > ACK Thanks: Adam From amisnyov at redhat.com Tue Apr 15 10:41:48 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 15 Apr 2014 12:41:48 +0200 Subject: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix Message-ID: <20140415124148.43f848a1@unused-4-246.brq.redhat.com> Hi, this patch fixes FreeIPA Jenkins CI test freeipa-integration-forced_client_reenrollment-f19, by turning sshfp records into a set, and sorting them before assertion. https://fedorahosted.org/freeipa/ticket/4298 Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0011-CI-test_forced_client_reenrollment-stability-fix.patch Type: text/x-patch Size: 1231 bytes Desc: not available URL: From pvoborni at redhat.com Tue Apr 15 10:47:10 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 15 Apr 2014 12:47:10 +0200 Subject: [Freeipa-devel] [PATCH] 569-583 New Login Screen In-Reply-To: <20140415120513.453fb809@unused-4-246.brq.redhat.com> References: <5335734D.9030300@redhat.com> <20140411143110.5bb2a674@unused-4-246.brq.redhat.com> <534CE24A.8090706@redhat.com> <20140415120513.453fb809@unused-4-246.brq.redhat.com> Message-ID: <534D0E2E.4060602@redhat.com> On 15.4.2014 12:05, Misnyovszki Adam wrote: > On Tue, 15 Apr 2014 09:39:54 +0200 > Petr Vobornik wrote: > >> On 11.4.2014 14:31, Misnyovszki Adam wrote: >>> On Fri, 28 Mar 2014 14:04:13 +0100 >>> Petr Vobornik wrote: >>> >>>> Attached patches replace IPA.unauthorized dialog with new Login >>>> Screen. >>>> >>>> To make it happen, a support for standalone facets had to be >>>> developed because current framework was limited by facets dependent >>>> on entities and a container with menu. This new feature was already >>>> used for Load facet which is part of this patchset and also will >>>> be a basis for API browser and OTP sync page. >>>> >>>> Patches should fix these tickets: >>>> https://fedorahosted.org/freeipa/ticket/3903 >>>> https://fedorahosted.org/freeipa/ticket/4017 >>>> >>>> Depends on patches #565-#568. >>>> >>>> >>>> [PATCH] webui: facet container >>>> ------------------------------ >>>> A widget which servers as container for facets. FacetContainer is a >>>> base class. App is specialization. >>>> >>>> Doing this abstraction will allow us to implement various facet >>>> containers. >>>> >>>> [PATCH] webui: FormMixin >>>> ------------------------ >>>> a mixin used for fields validation. Basically implements a logic >>>> which is already in details facet and dialog. >>>> >>>> Now this logic can be used in any component. >>>> >>>> The long term goal is to replace the logic in details facet and >>>> dialog with this mixin. >>>> >>>> [PATCH] webui: ContainerMixin >>>> ----------------------------- >>>> A mixin which implements widget storing logic. Similar logic is >>>> already implemented >>>> in details facet and dialog. >>>> >>>> Long term goal is to replace that with this one. >>>> >>>> Separating the logic into mixin makes it usable in other >>>> components. >>>> >>>> [PATCH] webui: standalone facet >>>> ------------------------------- >>>> `facet.Facet` is a new base class for facets. It doesn't have any >>>> dependencies >>>> on entities so it's usable for general purpose facets, e.g., future >>>> API browser, >>>> load facet or login facet. >>>> >>>> [PATCH] webui: activity widget >>>> ------------------------------ >>>> A widget for showing ongoing activity. >>>> >>>> Displays a text with changing dots. >>>> >>>> It listens to `network-activity-start` and `network-activity-end` >>>> topics. >>>> >>>> [PATCH] webui: publish network activity topics >>>> ---------------------------------------------- >>>> Network activity is now published through global topics. It allows >>>> other components like activity_widget to listen to them. >>>> >>>> [PATCH] webui: load page >>>> ------------------------ >>>> Load page is a simple facet which is displayed up to 'runtime' >>>> phase. >>>> >>>> On application start it tells the user that there is ongoing >>>> activity. >>>> >>>> [PATCH] webui: validation summary widget >>>> ---------------------------------------- >>>> A widget which aggregates warnings and errors and shows them on one >>>> place. >>>> >>>> [PATCH] webui: login screen widget >>>> ---------------------------------- >>>> Reimplementation of unauthorized dialog into separate widget. It >>>> uses RCUE design. >>>> >>>> New features compared to unauthorized dialog: >>>> >>>> - reflects auth methods from `auth` module >>>> - validation summary >>>> - differentiates Kerberos auth failure with session expiration >>>> - Caps Lock warning >>>> - form based method doesn't allow password only submission >>>> >>>> https://fedorahosted.org/freeipa/ticket/4017 >>>> https://fedorahosted.org/freeipa/ticket/3903 >>>> >>>> >>>> [PATCH] webui: login page >>>> ------------------------- >>>> A facet with login sreen widget. >>>> >>>> [PATCH] webui: authentication module >>>> ------------------------------------ >>>> General purpose authentication interface and state. See doc of >>>> 'freeipa/auth' module. >>>> >>>> [PATCH] webui: use asynchronous call for authentication >>>> >>>> Change `IPA.login_password` and `IPA.get_credentials` to use async >>>> AJAX and to return promise instead of blocking the code. >>>> >>>> IPA.get_credentials is still partially blocking because of >>>> negotiate process. >>>> We can't do anything about that. >>>> >>>> It allows activity indicators to do their job. >>>> >>>> [PATCH] webui: fix combobox styles to work with selenium testing >>>> [PATCH] webui-ci: adapt to new login screen >>>> [PATCH] webui: remove IPA.unauthorized_dialog >>> >>> Hi, >>> - Attached patch fixes weird combobox behaviour - opens >>> automatically on facet load >> >> Thank you. I squashed it into patch 581 since it's a fix for unpushed >> code. >> >>> - When trying to log in with password only(username field is >>> empty), there is an error message "Authentication with Kerberos >>> failed", which is not the desired behaviour. It should sign that >>> the username field is invalid. >> >> New, attached version of patch #577 should fix that. It was a typo. >> >>> - When trying to log in with kerberos credentials, and the realm >>> of the krb ticket is not the same as the >>> realm of freeipa(eg freeipa realm is IPA.TEST.COM, and >>> the ticket's is TEST.COM), firefox goes into an endless cycle >>> calling the kerberos auth url. Currently it seems to me as a >>> browser issue. Anyways, with correct krb ticket, authentication >>> works fine. >> >> As investigated with Adam - not a FreeIPA issue. >> >>> Although, unit tests ran, integration tests ran as expected, and >>> browsing through the code manually was ok for me, so if that >>> validation issue is corrected, than it will be an ACK. >>> >>> >>> Thanks: >>> Adam >>> >> > > ACK > Thanks: > Adam > Pushed to master: * 2680d21402d8ac51146bf03be3c0fd63ab49cada webui: facet container * f39f4aaae2fef6de6a8312dcc652bcaa5766b22b webui: FormMixin * dec7f98aa995b369f022813093ac88d0062e5089 webui: ContainerMixin * 642345fd53faabd9183bef1a7667bdb7956d27f7 webui: standalone facet * 93c4a6388bf05a754403a888e95e4a887180d9b1 webui: activity widget * a1c25122788ec7d9d7953db840ca6067f979432d webui: publish network activity topics * cb486136dbf86d52e75e1684d4876fd46c44aa22 webui: load page * 0c8b04699b35ea48b897bcd3419a94dd90a07c5d webui: validation summary widget * efc9e66f4ddff7c0aaae5d460ab41f6026fbd32d webui: login screen widget * 7c068f036f64b3b5156862fc2fc5855db612ef2e webui: login page * 2ec5d969a27b91b04a2b424d93800e68a77aa6e8 webui: authentication module * 937533c48e27c5a8d4d63978d32990451a10a36a webui: use asynchronous call for authentication * ad48697ff9a7a25f52047e3ddf68a551c89b0758 webui: fix combobox styles to work with selenium testing * 466e32f9ec817f0a8102c5dc7881b42b18267df5 webui-ci: adapt to new login screen * 6b0c6bf34435859a21936ad69d3eb984c27f9d8d webui: remove IPA.unauthorized_dialog -- Petr Vobornik From pviktori at redhat.com Tue Apr 15 10:51:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 15 Apr 2014 12:51:47 +0200 Subject: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix In-Reply-To: <20140415124148.43f848a1@unused-4-246.brq.redhat.com> References: <20140415124148.43f848a1@unused-4-246.brq.redhat.com> Message-ID: <534D0F43.1050408@redhat.com> On 04/15/2014 12:41 PM, Misnyovszki Adam wrote: > Hi, > this patch fixes FreeIPA Jenkins CI test > freeipa-integration-forced_client_reenrollment-f19, by turning sshfp > records into a set, and sorting them before assertion. > > https://fedorahosted.org/freeipa/ticket/4298 > > Greets > Adam The list.sort() method sorts in-place and returns None, so now the test would not really test anything. Use the sorted() function. You might want to log the value before returning it. -- Petr? From pviktori at redhat.com Tue Apr 15 11:13:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 15 Apr 2014 13:13:37 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534CE335.5070804@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> Message-ID: <534D1461.3090800@redhat.com> On 04/15/2014 09:43 AM, Martin Kosek wrote: > On 04/15/2014 09:38 AM, Martin Kosek wrote: >> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>> Hello, >>>> >>>> The first patch adds default read permissions to krbtpolicy. Since the >>>> plugin manages entries in two trees, there are two permissions. Since >>>> two permissions are needed to cover krbtpolicy, it can't be used as a >>>> permission's --type. >>>> The permissions are added to a new privilege, 'Kerberos Ticket Policy >>>> Readers'. >>>> >>>> The second patch adds an ACI for reading the Kerberos realm name. Since >>>> client enrollment won't work without this, I don't see a reason for >>>> having it managed by a permission. >>>> >>> >>> LGTM >>> >>> Simo. >>> >> >> 521 breaks a unit test: >> >> ====================================================================== >> FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using >> --subtree >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest >> self.test(*self.arg) >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in >> >> func = lambda: self.check(nice, **test) >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in >> check >> self.check_output(nice, cmd, args, options, expected, extra_check) >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in >> check_output >> assert_deepequal(expected, got, nice) >> File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal >> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >> File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal >> VALUE % (doc, expected, got, stack) >> AssertionError: assert_deepequal: expected != got. >> test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree >> expected = 1 >> got = 2 >> path = ('count',) Thanks for the catch, tests updated. >> Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we >> miss permissions for users). Right; I don't think this permission by itself should allow access to users. Correct me if that's wrong. I created a users permission for testing: ipa permission-add 'allow reading user objectclass' --type user --right={read,search,compare} --attrs objectclass --bind all > /me hit Send too soon. > > Although 522 works functionally and client now discovers the IPA server, there > is no path from SUFFIX to cn=REALM for anonymous users. > > I would personally change the ACI to > > (targetattr = "cn || objectclass")(targetfilter = > "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version 3.0;acl > "Anonymous read access to Kerberos container";allow (read,compare,search) > userdn = "ldap:///anyone";)' > > and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass). Right, that's necessary for UIs to list the container. Simo, are you okay with this? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0521.2-Add-managed-read-permissions-to-krbtpolicy.patch Type: text/x-patch Size: 6986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0522.2-Allow-anonymous-read-access-to-Kerberos-containers.patch Type: text/x-patch Size: 1291 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 15 12:33:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 15 Apr 2014 14:33:15 +0200 Subject: [Freeipa-devel] [PATCH] 0525 Add managed read permissions to automember Message-ID: <534D270B.8070307@redhat.com> Read access to both rules and definitions is given to a new privilege, 'Automember Readers', as well as the existing 'Automember Task Administrator'. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0525-Add-managed-read-permissions-to-automember.patch Type: text/x-patch Size: 3212 bytes Desc: not available URL: From ssorce at redhat.com Tue Apr 15 13:16:13 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 15 Apr 2014 09:16:13 -0400 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534D1461.3090800@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> Message-ID: <1397567773.19767.287.camel@willson.li.ssimo.org> On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: > On 04/15/2014 09:43 AM, Martin Kosek wrote: > > On 04/15/2014 09:38 AM, Martin Kosek wrote: > >> On 04/14/2014 07:18 PM, Simo Sorce wrote: > >>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: > >>>> Hello, > >>>> > >>>> The first patch adds default read permissions to krbtpolicy. Since the > >>>> plugin manages entries in two trees, there are two permissions. Since > >>>> two permissions are needed to cover krbtpolicy, it can't be used as a > >>>> permission's --type. > >>>> The permissions are added to a new privilege, 'Kerberos Ticket Policy > >>>> Readers'. > >>>> > >>>> The second patch adds an ACI for reading the Kerberos realm name. Since > >>>> client enrollment won't work without this, I don't see a reason for > >>>> having it managed by a permission. > >>>> > >>> > >>> LGTM > >>> > >>> Simo. > >>> > >> > >> 521 breaks a unit test: > >> > >> ====================================================================== > >> FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using > >> --subtree > >> ---------------------------------------------------------------------- > >> Traceback (most recent call last): > >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > >> self.test(*self.arg) > >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in > >> > >> func = lambda: self.check(nice, **test) > >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in > >> check > >> self.check_output(nice, cmd, args, options, expected, extra_check) > >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in > >> check_output > >> assert_deepequal(expected, got, nice) > >> File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal > >> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) > >> File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal > >> VALUE % (doc, expected, got, stack) > >> AssertionError: assert_deepequal: expected != got. > >> test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree > >> expected = 1 > >> got = 2 > >> path = ('count',) > > Thanks for the catch, tests updated. > > >> Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we > >> miss permissions for users). > > Right; I don't think this permission by itself should allow access to > users. Correct me if that's wrong. > > I created a users permission for testing: > ipa permission-add 'allow reading user objectclass' --type user > --right={read,search,compare} --attrs objectclass --bind all > > > /me hit Send too soon. > > > > Although 522 works functionally and client now discovers the IPA server, there > > is no path from SUFFIX to cn=REALM for anonymous users. > > > > I would personally change the ACI to > > > > (targetattr = "cn || objectclass")(targetfilter = > > "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version 3.0;acl > > "Anonymous read access to Kerberos container";allow (read,compare,search) > > userdn = "ldap:///anyone";)' > > > > and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass). > > Right, that's necessary for UIs to list the container. > Simo, are you okay with this? It is no secret that an IPA server has a container named after the domain. And the REALM name is available unauthenticated from DNS, so knowledge of it's existence is given. Therefore I see no problem if anonymous can see the container exists, as long as no contents (beyond what we already determined need to be) are revealed I see no problem. Simo. From amisnyov at redhat.com Tue Apr 15 13:21:47 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 15 Apr 2014 15:21:47 +0200 Subject: [Freeipa-devel] [PATCH] 585 webui: fix OTP Token add regression In-Reply-To: <534CE5AE.8090804@redhat.com> References: <534CE5AE.8090804@redhat.com> Message-ID: <20140415152147.4b269658@unused-4-246.brq.redhat.com> On Tue, 15 Apr 2014 09:54:22 +0200 Petr Vobornik wrote: > OTP Token add failed because of invalid function call. qr_widget > doesn't contain `on_value_changed` method since it inherits from > `IPA.widget` and not from `IPA.input_widget`. > > Emitting the event was preserved for future possible usage. > > https://fedorahosted.org/freeipa/ticket/4306 ACK Greets Adam From mkosek at redhat.com Tue Apr 15 14:48:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Apr 2014 16:48:27 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <1397567773.19767.287.camel@willson.li.ssimo.org> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> Message-ID: <534D46BB.707@redhat.com> On 04/15/2014 03:16 PM, Simo Sorce wrote: > On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: >> On 04/15/2014 09:43 AM, Martin Kosek wrote: >>> On 04/15/2014 09:38 AM, Martin Kosek wrote: >>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>>>> Hello, >>>>>> >>>>>> The first patch adds default read permissions to krbtpolicy. Since the >>>>>> plugin manages entries in two trees, there are two permissions. Since >>>>>> two permissions are needed to cover krbtpolicy, it can't be used as a >>>>>> permission's --type. >>>>>> The permissions are added to a new privilege, 'Kerberos Ticket Policy >>>>>> Readers'. >>>>>> >>>>>> The second patch adds an ACI for reading the Kerberos realm name. Since >>>>>> client enrollment won't work without this, I don't see a reason for >>>>>> having it managed by a permission. >>>>>> >>>>> >>>>> LGTM >>>>> >>>>> Simo. >>>>> >>>> >>>> 521 breaks a unit test: >>>> >>>> ====================================================================== >>>> FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using >>>> --subtree >>>> ---------------------------------------------------------------------- >>>> Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest >>>> self.test(*self.arg) >>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in >>>> >>>> func = lambda: self.check(nice, **test) >>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in >>>> check >>>> self.check_output(nice, cmd, args, options, expected, extra_check) >>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in >>>> check_output >>>> assert_deepequal(expected, got, nice) >>>> File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal >>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >>>> File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal >>>> VALUE % (doc, expected, got, stack) >>>> AssertionError: assert_deepequal: expected != got. >>>> test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree >>>> expected = 1 >>>> got = 2 >>>> path = ('count',) >> >> Thanks for the catch, tests updated. >> >>>> Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we >>>> miss permissions for users). >> >> Right; I don't think this permission by itself should allow access to >> users. Correct me if that's wrong. >> >> I created a users permission for testing: >> ipa permission-add 'allow reading user objectclass' --type user >> --right={read,search,compare} --attrs objectclass --bind all >> >>> /me hit Send too soon. >>> >>> Although 522 works functionally and client now discovers the IPA server, there >>> is no path from SUFFIX to cn=REALM for anonymous users. >>> >>> I would personally change the ACI to >>> >>> (targetattr = "cn || objectclass")(targetfilter = >>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version 3.0;acl >>> "Anonymous read access to Kerberos container";allow (read,compare,search) >>> userdn = "ldap:///anyone";)' >>> >>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass). >> >> Right, that's necessary for UIs to list the container. >> Simo, are you okay with this? > > It is no secret that an IPA server has a container named after the > domain. And the REALM name is available unauthenticated from DNS, so > knowledge of it's existence is given. > Therefore I see no problem if anonymous can see the container exists, as > long as no contents (beyond what we already determined need to be) are > revealed I see no problem. > > Simo. > > Patches work fine. The only problem I see that we now expose group password policies # ldapsearch -h `hostname` -x -b 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn ... # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test cn: MKOSEK-FEDORA20.TEST # global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc =test cn: global_policy # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test dn: cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test cn: ipausers ... It seems suboptimal as we now moved access to group password policy to special permission and we probably do not want to leak a list of defined group policies. Question is how to prevent it as the group password policies have nsContainer OC. I see 2 options: 1) Update pwpolicy plugin to avoid using nsContainer for group password policy (I do not think it is needed, krbPwdPolicy contains cn attribute 2) Update our container allowing ACI to not display it. Option 1) would be nice, but I am afraid it would break search in older versions which expects the nsContainer OC to be there. As for option 2) I am not sure how best to do it. It would be best to exclude both cn=etc and cn=kerberos subtrees, but I could not figure out an ACI syntax to do it. Both (target != "ldap:///some=dn")(target != "ldap:///other=dn") and (target != "ldap:///some=dn" && target != "ldap:///other=dn") are not correct. CCing Ludwig to advise. Alternative is to exclude the the password policies by targetfilter, but I think excluding whole tree is better. Martin From pviktori at redhat.com Tue Apr 15 14:55:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 15 Apr 2014 16:55:14 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user Message-ID: <534D4852.2000405@redhat.com> Hello, At Devconf, we decided what most of the default read permissions should look like, but we did not get to user. Here is a draft of 4 read permissions. Please comment. Basic info (anonymous): [top] objectclass [person] cn, sn, description [organizationalPerson] title [inetOrgPerson] uid displayName, givenName, initials manager [inetUser] memberOf [ipaObject] ipaUniqueID [ipaSshUser] ipaSshPubKey [ipaUserAuthTypeClass] ipaUserAuthType [posixAccount] gecos, gidNumber, homeDirectory, loginShell, uidNumber Details (all authenticated): [person] seeAlso, telephoneNumber [organizationalPerson] fax, l, ou, st, postalCode, street destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName, postalAddress, postOfficeBox, preferredDeliveryMethod, registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address [inetOrgPerson] carLicense, departmentNumber, employeeNumber, employeeType, preferredLanguage, mail, mobile, pager audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, labeledURI, o, photo, roomNumber, secretary, userCertificate, userPKCS12, userSMIMECertificate, x500UniqueIdentifier [inetUser] inetUserHttpURL, inetUserStatus [ipaUser] userClass Kerberos/login-related (all authenticated): [krbPrincipalAux] krbPrincipalName, krbCanonicalName, krbPrincipalAliases, krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange [+] nsAccountLock Kerberos-related (user admins only): [krbPrincipalAux] krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange No read permission: [person] userPassword [krbPrincipalAux] krbPrincipalKey, krbExtraData, krbPwdHistory krbLastAdminUnlock, krbLoginFailedCount, krbPrincipalType, krbPwdPolicyReference, krbTicketPolicyReference, krbUPEnabled [krbTicketPolicyAux] krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags [mepOriginEntry] mepManagedEntry -- Petr? From ssorce at redhat.com Tue Apr 15 15:08:27 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 15 Apr 2014 11:08:27 -0400 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534D46BB.707@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> <534D46BB.707@redhat.com> Message-ID: <1397574507.19767.317.camel@willson.li.ssimo.org> On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote: > On 04/15/2014 03:16 PM, Simo Sorce wrote: > > On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: > >> On 04/15/2014 09:43 AM, Martin Kosek wrote: > >>> On 04/15/2014 09:38 AM, Martin Kosek wrote: > >>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: > >>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: > >>>>>> Hello, > >>>>>> > >>>>>> The first patch adds default read permissions to krbtpolicy. Since the > >>>>>> plugin manages entries in two trees, there are two permissions. Since > >>>>>> two permissions are needed to cover krbtpolicy, it can't be used as a > >>>>>> permission's --type. > >>>>>> The permissions are added to a new privilege, 'Kerberos Ticket Policy > >>>>>> Readers'. > >>>>>> > >>>>>> The second patch adds an ACI for reading the Kerberos realm name. Since > >>>>>> client enrollment won't work without this, I don't see a reason for > >>>>>> having it managed by a permission. > >>>>>> > >>>>> > >>>>> LGTM > >>>>> > >>>>> Simo. > >>>>> > >>>> > >>>> 521 breaks a unit test: > >>>> > >>>> ====================================================================== > >>>> FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using > >>>> --subtree > >>>> ---------------------------------------------------------------------- > >>>> Traceback (most recent call last): > >>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > >>>> self.test(*self.arg) > >>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in > >>>> > >>>> func = lambda: self.check(nice, **test) > >>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in > >>>> check > >>>> self.check_output(nice, cmd, args, options, expected, extra_check) > >>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in > >>>> check_output > >>>> assert_deepequal(expected, got, nice) > >>>> File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal > >>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) > >>>> File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal > >>>> VALUE % (doc, expected, got, stack) > >>>> AssertionError: assert_deepequal: expected != got. > >>>> test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree > >>>> expected = 1 > >>>> got = 2 > >>>> path = ('count',) > >> > >> Thanks for the catch, tests updated. > >> > >>>> Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we > >>>> miss permissions for users). > >> > >> Right; I don't think this permission by itself should allow access to > >> users. Correct me if that's wrong. > >> > >> I created a users permission for testing: > >> ipa permission-add 'allow reading user objectclass' --type user > >> --right={read,search,compare} --attrs objectclass --bind all > >> > >>> /me hit Send too soon. > >>> > >>> Although 522 works functionally and client now discovers the IPA server, there > >>> is no path from SUFFIX to cn=REALM for anonymous users. > >>> > >>> I would personally change the ACI to > >>> > >>> (targetattr = "cn || objectclass")(targetfilter = > >>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version 3.0;acl > >>> "Anonymous read access to Kerberos container";allow (read,compare,search) > >>> userdn = "ldap:///anyone";)' > >>> > >>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass). > >> > >> Right, that's necessary for UIs to list the container. > >> Simo, are you okay with this? > > > > It is no secret that an IPA server has a container named after the > > domain. And the REALM name is available unauthenticated from DNS, so > > knowledge of it's existence is given. > > Therefore I see no problem if anonymous can see the container exists, as > > long as no contents (beyond what we already determined need to be) are > > revealed I see no problem. > > > > Simo. > > > > > > Patches work fine. The only problem I see that we now expose group password > policies > > # ldapsearch -h `hostname` -x -b > 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn > ... > # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test > dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test > cn: MKOSEK-FEDORA20.TEST > > # global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test > dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc > =test > cn: global_policy > > # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test > dn: cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test > cn: ipausers > ... > > It seems suboptimal as we now moved access to group password policy to special > permission and we probably do not want to leak a list of defined group policies. > > Question is how to prevent it as the group password policies have nsContainer > OC. I see 2 options: > > 1) Update pwpolicy plugin to avoid using nsContainer for group password policy > (I do not think it is needed, krbPwdPolicy contains cn attribute > > 2) Update our container allowing ACI to not display it. > > Option 1) would be nice, but I am afraid it would break search in older > versions which expects the nsContainer OC to be there. > > As for option 2) I am not sure how best to do it. It would be best to exclude > both cn=etc and cn=kerberos subtrees, but I could not figure out an ACI syntax > to do it. > > Both > (target != "ldap:///some=dn")(target != "ldap:///other=dn") > and > (target != "ldap:///some=dn" && target != "ldap:///other=dn") > are not correct. CCing Ludwig to advise. > > Alternative is to exclude the the password policies by targetfilter, but I > think excluding whole tree is better. > > Martin It's like an LDAP filter but no quite so maybe: (&(target != "ldap:///some=dn")(target != "ldap:///other=dn")) ? HTH, Simo. From mkosek at redhat.com Tue Apr 15 15:10:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Apr 2014 17:10:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <1397574507.19767.317.camel@willson.li.ssimo.org> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> <534D46BB.707@redhat.com> <1397574507.19767.317.camel@willson.li.ssimo.org> Message-ID: <534D4C02.5090708@redhat.com> On 04/15/2014 05:08 PM, Simo Sorce wrote: > On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote: >> On 04/15/2014 03:16 PM, Simo Sorce wrote: >>> On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: >>>> On 04/15/2014 09:43 AM, Martin Kosek wrote: >>>>> On 04/15/2014 09:38 AM, Martin Kosek wrote: >>>>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>>>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> The first patch adds default read permissions to krbtpolicy. Since the >>>>>>>> plugin manages entries in two trees, there are two permissions. Since >>>>>>>> two permissions are needed to cover krbtpolicy, it can't be used as a >>>>>>>> permission's --type. >>>>>>>> The permissions are added to a new privilege, 'Kerberos Ticket Policy >>>>>>>> Readers'. >>>>>>>> >>>>>>>> The second patch adds an ACI for reading the Kerberos realm name. Since >>>>>>>> client enrollment won't work without this, I don't see a reason for >>>>>>>> having it managed by a permission. >>>>>>>> >>>>>>> >>>>>>> LGTM >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> 521 breaks a unit test: >>>>>> >>>>>> ====================================================================== >>>>>> FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using >>>>>> --subtree >>>>>> ---------------------------------------------------------------------- >>>>>> Traceback (most recent call last): >>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest >>>>>> self.test(*self.arg) >>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in >>>>>> >>>>>> func = lambda: self.check(nice, **test) >>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in >>>>>> check >>>>>> self.check_output(nice, cmd, args, options, expected, extra_check) >>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in >>>>>> check_output >>>>>> assert_deepequal(expected, got, nice) >>>>>> File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal >>>>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >>>>>> File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal >>>>>> VALUE % (doc, expected, got, stack) >>>>>> AssertionError: assert_deepequal: expected != got. >>>>>> test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree >>>>>> expected = 1 >>>>>> got = 2 >>>>>> path = ('count',) >>>> >>>> Thanks for the catch, tests updated. >>>> >>>>>> Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we >>>>>> miss permissions for users). >>>> >>>> Right; I don't think this permission by itself should allow access to >>>> users. Correct me if that's wrong. >>>> >>>> I created a users permission for testing: >>>> ipa permission-add 'allow reading user objectclass' --type user >>>> --right={read,search,compare} --attrs objectclass --bind all >>>> >>>>> /me hit Send too soon. >>>>> >>>>> Although 522 works functionally and client now discovers the IPA server, there >>>>> is no path from SUFFIX to cn=REALM for anonymous users. >>>>> >>>>> I would personally change the ACI to >>>>> >>>>> (targetattr = "cn || objectclass")(targetfilter = >>>>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version 3.0;acl >>>>> "Anonymous read access to Kerberos container";allow (read,compare,search) >>>>> userdn = "ldap:///anyone";)' >>>>> >>>>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass). >>>> >>>> Right, that's necessary for UIs to list the container. >>>> Simo, are you okay with this? >>> >>> It is no secret that an IPA server has a container named after the >>> domain. And the REALM name is available unauthenticated from DNS, so >>> knowledge of it's existence is given. >>> Therefore I see no problem if anonymous can see the container exists, as >>> long as no contents (beyond what we already determined need to be) are >>> revealed I see no problem. >>> >>> Simo. >>> >>> >> >> Patches work fine. The only problem I see that we now expose group password >> policies >> >> # ldapsearch -h `hostname` -x -b >> 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn >> ... >> # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >> cn: MKOSEK-FEDORA20.TEST >> >> # global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >> dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc >> =test >> cn: global_policy >> >> # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >> dn: cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >> cn: ipausers >> ... >> >> It seems suboptimal as we now moved access to group password policy to special >> permission and we probably do not want to leak a list of defined group policies. >> >> Question is how to prevent it as the group password policies have nsContainer >> OC. I see 2 options: >> >> 1) Update pwpolicy plugin to avoid using nsContainer for group password policy >> (I do not think it is needed, krbPwdPolicy contains cn attribute >> >> 2) Update our container allowing ACI to not display it. >> >> Option 1) would be nice, but I am afraid it would break search in older >> versions which expects the nsContainer OC to be there. >> >> As for option 2) I am not sure how best to do it. It would be best to exclude >> both cn=etc and cn=kerberos subtrees, but I could not figure out an ACI syntax >> to do it. >> >> Both >> (target != "ldap:///some=dn")(target != "ldap:///other=dn") >> and >> (target != "ldap:///some=dn" && target != "ldap:///other=dn") >> are not correct. CCing Ludwig to advise. >> >> Alternative is to exclude the the password policies by targetfilter, but I >> think excluding whole tree is better. >> >> Martin > > It's like an LDAP filter but no quite so maybe: > (&(target != "ldap:///some=dn")(target != "ldap:///other=dn")) ? > > HTH, > Simo. > Try again... [15/Apr/2014:17:15:01 +0200] NSACLPlugin - ACL Syntax Error(-5):(targetfilter=\22(objectclass=nsContainer)\22)(&(target != \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22)(target != \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22))(targetattr=\22objectclass || cn\22)(version 3.0; acl \22Anonymous read access to containers\22; allow(read, search, compare) userdn = \22ldap:///anyone\22;) Martin From amisnyov at redhat.com Tue Apr 15 15:36:47 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 15 Apr 2014 17:36:47 +0200 Subject: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix In-Reply-To: <534D0F43.1050408@redhat.com> References: <20140415124148.43f848a1@unused-4-246.brq.redhat.com> <534D0F43.1050408@redhat.com> Message-ID: <20140415173647.56826042@unused-4-246.brq.redhat.com> On Tue, 15 Apr 2014 12:51:47 +0200 Petr Viktorin wrote: > On 04/15/2014 12:41 PM, Misnyovszki Adam wrote: > > Hi, > > this patch fixes FreeIPA Jenkins CI test > > freeipa-integration-forced_client_reenrollment-f19, by turning sshfp > > records into a set, and sorting them before assertion. > > > > https://fedorahosted.org/freeipa/ticket/4298 > > > > Greets > > Adam > > The list.sort() method sorts in-place and returns None, so now the > test would not really test anything. Use the sorted() function. > > You might want to log the value before returning it. > My mistake, see the attached, corrected patch. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0011-2-CI-test_forced_client_reenrollment-stability-fix.patch Type: text/x-patch Size: 1253 bytes Desc: not available URL: From rcritten at redhat.com Tue Apr 15 15:41:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Apr 2014 11:41:24 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <1397486532.29593.8.camel@aleeredhat.laptop> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> <53439C4D.6060108@redhat.com> <5343FF31.8050206@redhat.com> <1397486532.29593.8.camel@aleeredhat.laptop> Message-ID: <534D5324.4060802@redhat.com> Ade Lee wrote: > Attached a new patch to address some of the concerns below, specifically > I created a new base class DogtagInstance, in which much of the common > CA/KRA code is placed. I'm sure we could go further in reducing > duplication, and I'm open to further suggestions and refinements. > > I did not tackle the packaging and spec file dependencies, because I'd > like some clearer direction on how we want to proceed here. In any > case, I think the splitting of the ipa packages into ca and possibly kra > packages should be a separate patch. > > As before, with this patch you can: > - install a ca and drm using ipa-server-install > - install a ca and drm replica using > ipa-replica-prepare > ipa-replica-install --setup-ca --setup-drm > > You need to use a PKI build from the 10.2 (master) branch). One such > build is given below: > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo The terms KRA and DRM tend to be used interchangeably. Should we pick one? Need to bump the version number in install/conf/ipa-pki-proxy.conf so that upgrades get the new LocationMatch. ipa-replica-install still uses the if/then to set the value of enable_drm when it can be reduced like you did in ipa-server-install. In ipa-server-install you have an extra comment, probably left for yourself: # code to create drm here In dogtaginstance.py there are a few direct references to DRM in comments and output. cainstance.py doesn't need to override is_installed.py I also don't think you need the explicit definitions for enable, start_instance, etc. Those should be inherited from the DogtagInstance class, in both cainstance.py and drminstance.py. I think spawn_instance should take an option to add things to nolog in case there are server-independent things we don't want to log. I don't want to pile too much on, but it seems to me that if we are going to copy in default.conf then we can do away with realm_info completely and just use default.conf. Both would need to be supported for a while though. Martin, what do you think? I still have quite a bit of functional testing to go. I've only installed a fresh standalone master. Still need to do upgrade and replication testing. rob From lkrispen at redhat.com Tue Apr 15 15:45:50 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 15 Apr 2014 17:45:50 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534D4C02.5090708@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> <534D46BB.707@redhat.com> <1397574507.19767.317.camel@willson.li.ssimo.org> <534D4C02.5090708@redhat.com> Message-ID: <534D542E.4050701@redhat.com> On 04/15/2014 05:10 PM, Martin Kosek wrote: > On 04/15/2014 05:08 PM, Simo Sorce wrote: >> On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote: >>> On 04/15/2014 03:16 PM, Simo Sorce wrote: >>>> On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: >>>>> On 04/15/2014 09:43 AM, Martin Kosek wrote: >>>>>> On 04/15/2014 09:38 AM, Martin Kosek wrote: >>>>>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>>>>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> The first patch adds default read permissions to krbtpolicy. Since the >>>>>>>>> plugin manages entries in two trees, there are two permissions. Since >>>>>>>>> two permissions are needed to cover krbtpolicy, it can't be used as a >>>>>>>>> permission's --type. >>>>>>>>> The permissions are added to a new privilege, 'Kerberos Ticket Policy >>>>>>>>> Readers'. >>>>>>>>> >>>>>>>>> The second patch adds an ACI for reading the Kerberos realm name. Since >>>>>>>>> client enrollment won't work without this, I don't see a reason for >>>>>>>>> having it managed by a permission. >>>>>>>>> >>>>>>>> LGTM >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> 521 breaks a unit test: >>>>>>> >>>>>>> ====================================================================== >>>>>>> FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' using >>>>>>> --subtree >>>>>>> ---------------------------------------------------------------------- >>>>>>> Traceback (most recent call last): >>>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest >>>>>>> self.test(*self.arg) >>>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in >>>>>>> >>>>>>> func = lambda: self.check(nice, **test) >>>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in >>>>>>> check >>>>>>> self.check_output(nice, cmd, args, options, expected, extra_check) >>>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in >>>>>>> check_output >>>>>>> assert_deepequal(expected, got, nice) >>>>>>> File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal >>>>>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >>>>>>> File "/root/freeipa-master/ipatests/util.py", line 352, in assert_deepequal >>>>>>> VALUE % (doc, expected, got, stack) >>>>>>> AssertionError: assert_deepequal: expected != got. >>>>>>> test_permission[37]: permission_find: Search for u'Testperm_RN' using --subtree >>>>>>> expected = 1 >>>>>>> got = 2 >>>>>>> path = ('count',) >>>>> Thanks for the catch, tests updated. >>>>> >>>>>>> Otherwise it works fine (krbtpolicy-show for user cannot be tested yet as we >>>>>>> miss permissions for users). >>>>> Right; I don't think this permission by itself should allow access to >>>>> users. Correct me if that's wrong. >>>>> >>>>> I created a users permission for testing: >>>>> ipa permission-add 'allow reading user objectclass' --type user >>>>> --right={read,search,compare} --attrs objectclass --bind all >>>>> >>>>>> /me hit Send too soon. >>>>>> >>>>>> Although 522 works functionally and client now discovers the IPA server, there >>>>>> is no path from SUFFIX to cn=REALM for anonymous users. >>>>>> >>>>>> I would personally change the ACI to >>>>>> >>>>>> (targetattr = "cn || objectclass")(targetfilter = >>>>>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version 3.0;acl >>>>>> "Anonymous read access to Kerberos container";allow (read,compare,search) >>>>>> userdn = "ldap:///anyone";)' >>>>>> >>>>>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass). >>>>> Right, that's necessary for UIs to list the container. >>>>> Simo, are you okay with this? >>>> It is no secret that an IPA server has a container named after the >>>> domain. And the REALM name is available unauthenticated from DNS, so >>>> knowledge of it's existence is given. >>>> Therefore I see no problem if anonymous can see the container exists, as >>>> long as no contents (beyond what we already determined need to be) are >>>> revealed I see no problem. >>>> >>>> Simo. >>>> >>>> >>> Patches work fine. The only problem I see that we now expose group password >>> policies >>> >>> # ldapsearch -h `hostname` -x -b >>> 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn >>> ... >>> # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>> cn: MKOSEK-FEDORA20.TEST >>> >>> # global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>> dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc >>> =test >>> cn: global_policy >>> >>> # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>> dn: cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>> cn: ipausers >>> ... >>> >>> It seems suboptimal as we now moved access to group password policy to special >>> permission and we probably do not want to leak a list of defined group policies. >>> >>> Question is how to prevent it as the group password policies have nsContainer >>> OC. I see 2 options: >>> >>> 1) Update pwpolicy plugin to avoid using nsContainer for group password policy >>> (I do not think it is needed, krbPwdPolicy contains cn attribute >>> >>> 2) Update our container allowing ACI to not display it. >>> >>> Option 1) would be nice, but I am afraid it would break search in older >>> versions which expects the nsContainer OC to be there. >>> >>> As for option 2) I am not sure how best to do it. It would be best to exclude >>> both cn=etc and cn=kerberos subtrees, but I could not figure out an ACI syntax >>> to do it. >>> >>> Both >>> (target != "ldap:///some=dn")(target != "ldap:///other=dn") >>> and >>> (target != "ldap:///some=dn" && target != "ldap:///other=dn") >>> are not correct. CCing Ludwig to advise. >>> >>> Alternative is to exclude the the password policies by targetfilter, but I >>> think excluding whole tree is better. >>> >>> Martin >> It's like an LDAP filter but no quite so maybe: >> (&(target != "ldap:///some=dn")(target != "ldap:///other=dn")) ? >> >> HTH, >> Simo. >> > Try again... > > [15/Apr/2014:17:15:01 +0200] NSACLPlugin - ACL Syntax > Error(-5):(targetfilter=\22(objectclass=nsContainer)\22)(&(target != > \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22)(target != > \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22))(targetattr=\22objectclass || > cn\22)(version 3.0; acl \22Anonymous read access to containers\22; allow(read, > search, compare) userdn = \22ldap:///anyone\22;) > > Martin (target!="ldap:///some=dn || ldap:///other=dn") is accepted, but in a quick test also didn't work as expected. Need to investigate a bit more From lkrispen at redhat.com Tue Apr 15 16:10:51 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 15 Apr 2014 18:10:51 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534D542E.4050701@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> <534D46BB.707@redhat.com> <1397574507.19767.317.camel@willson.li.ssimo.org> <534D4C02.5090708@redhat.com> <534D542E.4050701@redhat.com> Message-ID: <534D5A0B.8060602@redhat.com> On 04/15/2014 05:45 PM, Ludwig Krispenz wrote: > > On 04/15/2014 05:10 PM, Martin Kosek wrote: >> On 04/15/2014 05:08 PM, Simo Sorce wrote: >>> On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote: >>>> On 04/15/2014 03:16 PM, Simo Sorce wrote: >>>>> On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: >>>>>> On 04/15/2014 09:43 AM, Martin Kosek wrote: >>>>>>> On 04/15/2014 09:38 AM, Martin Kosek wrote: >>>>>>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>>>>>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> The first patch adds default read permissions to krbtpolicy. >>>>>>>>>> Since the >>>>>>>>>> plugin manages entries in two trees, there are two >>>>>>>>>> permissions. Since >>>>>>>>>> two permissions are needed to cover krbtpolicy, it can't be >>>>>>>>>> used as a >>>>>>>>>> permission's --type. >>>>>>>>>> The permissions are added to a new privilege, 'Kerberos >>>>>>>>>> Ticket Policy >>>>>>>>>> Readers'. >>>>>>>>>> >>>>>>>>>> The second patch adds an ACI for reading the Kerberos realm >>>>>>>>>> name. Since >>>>>>>>>> client enrollment won't work without this, I don't see a >>>>>>>>>> reason for >>>>>>>>>> having it managed by a permission. >>>>>>>>>> >>>>>>>>> LGTM >>>>>>>>> >>>>>>>>> Simo. >>>>>>>>> >>>>>>>> 521 breaks a unit test: >>>>>>>> >>>>>>>> ====================================================================== >>>>>>>> >>>>>>>> FAIL: test_permission[37]: permission_find: Search for >>>>>>>> u'Testperm_RN' using >>>>>>>> --subtree >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> Traceback (most recent call last): >>>>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line >>>>>>>> 197, in runTest >>>>>>>> self.test(*self.arg) >>>>>>>> File >>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>> line 301, in >>>>>>>> >>>>>>>> func = lambda: self.check(nice, **test) >>>>>>>> File >>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>> line 319, in >>>>>>>> check >>>>>>>> self.check_output(nice, cmd, args, options, expected, >>>>>>>> extra_check) >>>>>>>> File >>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>> line 359, in >>>>>>>> check_output >>>>>>>> assert_deepequal(expected, got, nice) >>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 344, in >>>>>>>> assert_deepequal >>>>>>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 352, in >>>>>>>> assert_deepequal >>>>>>>> VALUE % (doc, expected, got, stack) >>>>>>>> AssertionError: assert_deepequal: expected != got. >>>>>>>> test_permission[37]: permission_find: Search for >>>>>>>> u'Testperm_RN' using --subtree >>>>>>>> expected = 1 >>>>>>>> got = 2 >>>>>>>> path = ('count',) >>>>>> Thanks for the catch, tests updated. >>>>>> >>>>>>>> Otherwise it works fine (krbtpolicy-show for user cannot be >>>>>>>> tested yet as we >>>>>>>> miss permissions for users). >>>>>> Right; I don't think this permission by itself should allow >>>>>> access to >>>>>> users. Correct me if that's wrong. >>>>>> >>>>>> I created a users permission for testing: >>>>>> ipa permission-add 'allow reading user objectclass' --type user >>>>>> --right={read,search,compare} --attrs objectclass --bind all >>>>>> >>>>>>> /me hit Send too soon. >>>>>>> >>>>>>> Although 522 works functionally and client now discovers the IPA >>>>>>> server, there >>>>>>> is no path from SUFFIX to cn=REALM for anonymous users. >>>>>>> >>>>>>> I would personally change the ACI to >>>>>>> >>>>>>> (targetattr = "cn || objectclass")(targetfilter = >>>>>>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version >>>>>>> 3.0;acl >>>>>>> "Anonymous read access to Kerberos container";allow >>>>>>> (read,compare,search) >>>>>>> userdn = "ldap:///anyone";)' >>>>>>> >>>>>>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer >>>>>>> objectclass). >>>>>> Right, that's necessary for UIs to list the container. >>>>>> Simo, are you okay with this? >>>>> It is no secret that an IPA server has a container named after the >>>>> domain. And the REALM name is available unauthenticated from DNS, so >>>>> knowledge of it's existence is given. >>>>> Therefore I see no problem if anonymous can see the container >>>>> exists, as >>>>> long as no contents (beyond what we already determined need to be) >>>>> are >>>>> revealed I see no problem. >>>>> >>>>> Simo. >>>>> >>>>> >>>> Patches work fine. The only problem I see that we now expose group >>>> password >>>> policies >>>> >>>> # ldapsearch -h `hostname` -x -b >>>> 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn >>>> ... >>>> # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>> cn: MKOSEK-FEDORA20.TEST >>>> >>>> # global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>> dn: >>>> cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc >>>> =test >>>> cn: global_policy >>>> >>>> # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>> dn: >>>> cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>> cn: ipausers >>>> ... >>>> >>>> It seems suboptimal as we now moved access to group password policy >>>> to special >>>> permission and we probably do not want to leak a list of defined >>>> group policies. >>>> >>>> Question is how to prevent it as the group password policies have >>>> nsContainer >>>> OC. I see 2 options: >>>> >>>> 1) Update pwpolicy plugin to avoid using nsContainer for group >>>> password policy >>>> (I do not think it is needed, krbPwdPolicy contains cn attribute >>>> >>>> 2) Update our container allowing ACI to not display it. >>>> >>>> Option 1) would be nice, but I am afraid it would break search in >>>> older >>>> versions which expects the nsContainer OC to be there. >>>> >>>> As for option 2) I am not sure how best to do it. It would be best >>>> to exclude >>>> both cn=etc and cn=kerberos subtrees, but I could not figure out an >>>> ACI syntax >>>> to do it. >>>> >>>> Both >>>> (target != "ldap:///some=dn")(target != "ldap:///other=dn") >>>> and >>>> (target != "ldap:///some=dn" && target != "ldap:///other=dn") >>>> are not correct. CCing Ludwig to advise. >>>> >>>> Alternative is to exclude the the password policies by >>>> targetfilter, but I >>>> think excluding whole tree is better. >>>> >>>> Martin >>> It's like an LDAP filter but no quite so maybe: >>> (&(target != "ldap:///some=dn")(target != "ldap:///other=dn")) ? >>> >>> HTH, >>> Simo. >>> >> Try again... >> >> [15/Apr/2014:17:15:01 +0200] NSACLPlugin - ACL Syntax >> Error(-5):(targetfilter=\22(objectclass=nsContainer)\22)(&(target != >> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22)(target != >> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22))(targetattr=\22objectclass >> || >> cn\22)(version 3.0; acl \22Anonymous read access to containers\22; >> allow(read, >> search, compare) userdn = \22ldap:///anyone\22;) >> >> Martin > (target!="ldap:///some=dn || ldap:///other=dn") is accepted, but in a > quick test also didn't work as expected. Need to investigate a bit more looks like we do not handle multiple targets at all. Although in the bind rules logical operations of binddns and bindgroups are handled, so that would be an enhancement :-( so I think you either have to move to denies for the two subtrees and a general allow for the parent tree, which is not nice or use targetfilter if possible. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pspacek at redhat.com Tue Apr 15 16:48:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 15 Apr 2014 18:48:21 +0200 Subject: [Freeipa-devel] [PATCH 0236] Fix crash in create_zone() Message-ID: <534D62D5.4010306@redhat.com> Hello, Fix crash in create_zone(). dns_zone_getmgr(zone) call in cleanup section was called even if zone was NULL. This patch should go to master, v4 and v3 branches where applicable. You probably need to use debugger to reproduce this crash. I have encountered it during work on new DNSSEC code ... -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0236-Fix-crash-in-create_zone.patch Type: text/x-patch Size: 1050 bytes Desc: not available URL: From alee at redhat.com Tue Apr 15 18:54:40 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 15 Apr 2014 14:54:40 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <534D5324.4060802@redhat.com> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> <53439C4D.6060108@redhat.com> <5343FF31.8050206@redhat.com> <1397486532.29593.8.camel@aleeredhat.laptop> <534D5324.4060802@redhat.com> Message-ID: <1397588080.31462.4.camel@aleeredhat.laptop> Attached is a patch that adds the script ipa-drm-install. This script will be used to install a drm in any ipa server that contains a Dogtag CA. Right now, it works for a master. I will add logic in a subsequent patch to allow the installation on a replica using the same script. This patch is to applied on top of the previous one. So, patch 2 and then patch 3. I will create a patch to address the issues mentioned below, as well as some other formatting issues reported by pycharm. Thanks, Ade On Tue, 2014-04-15 at 11:41 -0400, Rob Crittenden wrote: > Ade Lee wrote: > > Attached a new patch to address some of the concerns below, specifically > > I created a new base class DogtagInstance, in which much of the common > > CA/KRA code is placed. I'm sure we could go further in reducing > > duplication, and I'm open to further suggestions and refinements. > > > > I did not tackle the packaging and spec file dependencies, because I'd > > like some clearer direction on how we want to proceed here. In any > > case, I think the splitting of the ipa packages into ca and possibly kra > > packages should be a separate patch. > > > > As before, with this patch you can: > > - install a ca and drm using ipa-server-install > > - install a ca and drm replica using > > ipa-replica-prepare > > ipa-replica-install --setup-ca --setup-drm > > > > You need to use a PKI build from the 10.2 (master) branch). One such > > build is given below: > > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo > > The terms KRA and DRM tend to be used interchangeably. Should we pick one? > > Need to bump the version number in install/conf/ipa-pki-proxy.conf so > that upgrades get the new LocationMatch. > > ipa-replica-install still uses the if/then to set the value of > enable_drm when it can be reduced like you did in ipa-server-install. > > In ipa-server-install you have an extra comment, probably left for > yourself: # code to create drm here > > In dogtaginstance.py there are a few direct references to DRM in > comments and output. > > cainstance.py doesn't need to override is_installed.py > > I also don't think you need the explicit definitions for enable, > start_instance, etc. Those should be inherited from the DogtagInstance > class, in both cainstance.py and drminstance.py. > > I think spawn_instance should take an option to add things to nolog in > case there are server-independent things we don't want to log. > > I don't want to pile too much on, but it seems to me that if we are > going to copy in default.conf then we can do away with realm_info > completely and just use default.conf. Both would need to be supported > for a while though. Martin, what do you think? > > I still have quite a bit of functional testing to go. I've only > installed a fresh standalone master. Still need to do upgrade and > replication testing. > > rob > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Added-ipa-drm-install.patch Type: text/x-patch Size: 22704 bytes Desc: not available URL: From redhatrises at gmail.com Wed Apr 16 03:01:04 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 15 Apr 2014 21:01:04 -0600 Subject: [Freeipa-devel] [PATCH][DOC] Update Solaris Documentation, add proxy agent, and profile Message-ID: Hello, The following patches update the Solaris documentation and add a proxy agent/profile for Solaris. - Solaris documentation update https://fedorahosted.org/freeipa/ticket/3731 - Patch adds default Proxy Agent and default_secure profile through 20-nss_ldap.update when ipa-server-install is run. https://fedorahosted.org/freeipa/ticket/2561 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0014-DOC-Update-Solaris-client-documentation.patch Type: text/x-patch Size: 29263 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0015-Add-Solaris-proxy-agent-and-profile-during-install.patch Type: text/x-patch Size: 2166 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 16 05:48:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 07:48:48 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534D5A0B.8060602@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> <534D46BB.707@redhat.com> <1397574507.19767.317.camel@willson.li.ssimo.org> <534D4C02.5090708@redhat.com> <534D542E.4050701@redhat.com> <534D5A0B.8060602@redhat.com> Message-ID: <534E19C0.4050008@redhat.com> On 04/15/2014 06:10 PM, Ludwig Krispenz wrote: > > On 04/15/2014 05:45 PM, Ludwig Krispenz wrote: >> >> On 04/15/2014 05:10 PM, Martin Kosek wrote: >>> On 04/15/2014 05:08 PM, Simo Sorce wrote: >>>> On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote: >>>>> On 04/15/2014 03:16 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: >>>>>>> On 04/15/2014 09:43 AM, Martin Kosek wrote: >>>>>>>> On 04/15/2014 09:38 AM, Martin Kosek wrote: >>>>>>>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>>>>>>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> The first patch adds default read permissions to krbtpolicy. Since the >>>>>>>>>>> plugin manages entries in two trees, there are two permissions. Since >>>>>>>>>>> two permissions are needed to cover krbtpolicy, it can't be used as a >>>>>>>>>>> permission's --type. >>>>>>>>>>> The permissions are added to a new privilege, 'Kerberos Ticket Policy >>>>>>>>>>> Readers'. >>>>>>>>>>> >>>>>>>>>>> The second patch adds an ACI for reading the Kerberos realm name. Since >>>>>>>>>>> client enrollment won't work without this, I don't see a reason for >>>>>>>>>>> having it managed by a permission. >>>>>>>>>>> >>>>>>>>>> LGTM >>>>>>>>>> >>>>>>>>>> Simo. >>>>>>>>>> >>>>>>>>> 521 breaks a unit test: >>>>>>>>> >>>>>>>>> ====================================================================== >>>>>>>>> FAIL: test_permission[37]: permission_find: Search for u'Testperm_RN' >>>>>>>>> using >>>>>>>>> --subtree >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> Traceback (most recent call last): >>>>>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>>>>>>> runTest >>>>>>>>> self.test(*self.arg) >>>>>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>> line 301, in >>>>>>>>> >>>>>>>>> func = lambda: self.check(nice, **test) >>>>>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>> line 319, in >>>>>>>>> check >>>>>>>>> self.check_output(nice, cmd, args, options, expected, extra_check) >>>>>>>>> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>> line 359, in >>>>>>>>> check_output >>>>>>>>> assert_deepequal(expected, got, nice) >>>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 344, in >>>>>>>>> assert_deepequal >>>>>>>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >>>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 352, in >>>>>>>>> assert_deepequal >>>>>>>>> VALUE % (doc, expected, got, stack) >>>>>>>>> AssertionError: assert_deepequal: expected != got. >>>>>>>>> test_permission[37]: permission_find: Search for u'Testperm_RN' >>>>>>>>> using --subtree >>>>>>>>> expected = 1 >>>>>>>>> got = 2 >>>>>>>>> path = ('count',) >>>>>>> Thanks for the catch, tests updated. >>>>>>> >>>>>>>>> Otherwise it works fine (krbtpolicy-show for user cannot be tested yet >>>>>>>>> as we >>>>>>>>> miss permissions for users). >>>>>>> Right; I don't think this permission by itself should allow access to >>>>>>> users. Correct me if that's wrong. >>>>>>> >>>>>>> I created a users permission for testing: >>>>>>> ipa permission-add 'allow reading user objectclass' --type user >>>>>>> --right={read,search,compare} --attrs objectclass --bind all >>>>>>> >>>>>>>> /me hit Send too soon. >>>>>>>> >>>>>>>> Although 522 works functionally and client now discovers the IPA >>>>>>>> server, there >>>>>>>> is no path from SUFFIX to cn=REALM for anonymous users. >>>>>>>> >>>>>>>> I would personally change the ACI to >>>>>>>> >>>>>>>> (targetattr = "cn || objectclass")(targetfilter = >>>>>>>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version >>>>>>>> 3.0;acl >>>>>>>> "Anonymous read access to Kerberos container";allow (read,compare,search) >>>>>>>> userdn = "ldap:///anyone";)' >>>>>>>> >>>>>>>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer objectclass). >>>>>>> Right, that's necessary for UIs to list the container. >>>>>>> Simo, are you okay with this? >>>>>> It is no secret that an IPA server has a container named after the >>>>>> domain. And the REALM name is available unauthenticated from DNS, so >>>>>> knowledge of it's existence is given. >>>>>> Therefore I see no problem if anonymous can see the container exists, as >>>>>> long as no contents (beyond what we already determined need to be) are >>>>>> revealed I see no problem. >>>>>> >>>>>> Simo. >>>>>> >>>>>> >>>>> Patches work fine. The only problem I see that we now expose group password >>>>> policies >>>>> >>>>> # ldapsearch -h `hostname` -x -b >>>>> 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn >>>>> ... >>>>> # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>>> cn: MKOSEK-FEDORA20.TEST >>>>> >>>>> # global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>> dn: >>>>> cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc >>>>> =test >>>>> cn: global_policy >>>>> >>>>> # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>> dn: >>>>> cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>>> cn: ipausers >>>>> ... >>>>> >>>>> It seems suboptimal as we now moved access to group password policy to >>>>> special >>>>> permission and we probably do not want to leak a list of defined group >>>>> policies. >>>>> >>>>> Question is how to prevent it as the group password policies have nsContainer >>>>> OC. I see 2 options: >>>>> >>>>> 1) Update pwpolicy plugin to avoid using nsContainer for group password >>>>> policy >>>>> (I do not think it is needed, krbPwdPolicy contains cn attribute >>>>> >>>>> 2) Update our container allowing ACI to not display it. >>>>> >>>>> Option 1) would be nice, but I am afraid it would break search in older >>>>> versions which expects the nsContainer OC to be there. >>>>> >>>>> As for option 2) I am not sure how best to do it. It would be best to exclude >>>>> both cn=etc and cn=kerberos subtrees, but I could not figure out an ACI >>>>> syntax >>>>> to do it. >>>>> >>>>> Both >>>>> (target != "ldap:///some=dn")(target != "ldap:///other=dn") >>>>> and >>>>> (target != "ldap:///some=dn" && target != "ldap:///other=dn") >>>>> are not correct. CCing Ludwig to advise. >>>>> >>>>> Alternative is to exclude the the password policies by targetfilter, but I >>>>> think excluding whole tree is better. >>>>> >>>>> Martin >>>> It's like an LDAP filter but no quite so maybe: >>>> (&(target != "ldap:///some=dn")(target != "ldap:///other=dn")) ? >>>> >>>> HTH, >>>> Simo. >>>> >>> Try again... >>> >>> [15/Apr/2014:17:15:01 +0200] NSACLPlugin - ACL Syntax >>> Error(-5):(targetfilter=\22(objectclass=nsContainer)\22)(&(target != >>> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22)(target != >>> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22))(targetattr=\22objectclass || >>> cn\22)(version 3.0; acl \22Anonymous read access to containers\22; allow(read, >>> search, compare) userdn = \22ldap:///anyone\22;) >>> >>> Martin >> (target!="ldap:///some=dn || ldap:///other=dn") is accepted, but in a quick >> test also didn't work as expected. Need to investigate a bit more > looks like we do not handle multiple targets at all. Although in the bind rules > logical operations of binddns and bindgroups are handled, so that would be an > enhancement :-( > > so I think you either have to move to denies for the two subtrees and a general > allow for the parent tree, which is not nice or use targetfilter if possible. Ok, thanks for investigation. Petr, it seems we will simply need to update the container ACI and exclude krbPwdPolicy objectclass in the target filter. Martin From mkosek at redhat.com Wed Apr 16 05:59:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 07:59:39 +0200 Subject: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix In-Reply-To: <20140415173647.56826042@unused-4-246.brq.redhat.com> References: <20140415124148.43f848a1@unused-4-246.brq.redhat.com> <534D0F43.1050408@redhat.com> <20140415173647.56826042@unused-4-246.brq.redhat.com> Message-ID: <534E1C4B.1090100@redhat.com> On 04/15/2014 05:36 PM, Misnyovszki Adam wrote: > On Tue, 15 Apr 2014 12:51:47 +0200 > Petr Viktorin wrote: > >> On 04/15/2014 12:41 PM, Misnyovszki Adam wrote: >>> Hi, >>> this patch fixes FreeIPA Jenkins CI test >>> freeipa-integration-forced_client_reenrollment-f19, by turning sshfp >>> records into a set, and sorting them before assertion. >>> >>> https://fedorahosted.org/freeipa/ticket/4298 >>> >>> Greets >>> Adam >> >> The list.sort() method sorts in-place and returns None, so now the >> test would not really test anything. Use the sorted() function. >> >> You might want to log the value before returning it. >> > > My mistake, see the attached, corrected patch. > Thanks > Adam Adam, Petr - why can't we use a set as I already proposed in the ticket description? >>> set(['i', 'p', 'a']) == set(['a', 'p', 'i']) True Martin From mkosek at redhat.com Wed Apr 16 07:31:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 09:31:48 +0200 Subject: [Freeipa-devel] kadmin is unresponsive in FreeIPA installation Message-ID: <534E31E4.3090009@redhat.com> Did anyone hit https://bugzilla.redhat.com/show_bug.cgi?id=1088163 or is it something specific to my environment? Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From justin.brown at fandingo.org Wed Apr 16 07:56:08 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Wed, 16 Apr 2014 02:56:08 -0500 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <5345EC92.3010008@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> <534442FA.1060709@redhat.com> <5345EC92.3010008@redhat.com> Message-ID: Dmitri, Thanks for the feedback. I've had a chance to revise the proposal and incorporated your feedback. The first thing to note is that while this implementation is focused on FirewallD support I want to leave open the possibility of supporting other firewalls should anyone else be interested writing the patches. To that end, the module name and command option says "firewall" not FirewallD. Therefore, I've moved the proposal page to http://www.freeipa.org/page/V4/Firewall_Configuration. I've addressed most of your questions, but here's a brief overview: A, B, C, and D: Corrected E: There's a "DBus Method Overview" section now. F: I added a statement about error handling. It's hard to go into too much detail about how the various failures will be handled on the wiki. Error handling is very important to me, so don't worry that I'm overlooking it. G: It's really easy to handle existing configurations with FirewallD. (It's actually what makes this possible in comparison to iptables-save scripts.) There will be log messages to notify the user that some services were already allowed to caution that they should not be removed. H and I: There's a "restore" sub-section in the wiki. This will be easy to handle since the zone uses easily parsable XML. J: Yes. When ipa-server-install invokes the firewall module, it passes through a list of which services should be enabled. K: This will be easy for the firewall configuration module. Just invoke it with the new services. Is there an upgrade script currently, and if so, where is it? I'll add in the proper section there for the firewall. L: This is interesting, and I have a couple of questions on how this should work. 1) Is there an actual use-case when a tool actually would want to check status of a port without correcting it? It seems to me that any sort of is_port_open() call that returned False would be immediately followed by open_port(). If that's the case, then why not just roll them into one operation? There won't be any firewall reload if no modifications take place, so there's no cost to combining them. We could also find a middle ground where there's only one method with a default parameter open_port(..., auto_add=True). 2) Will these tools be executed as root? To query NM and FirewallD, I have to connect to the system bus, which by default, won't allow access from other users without additional authorization. If non-privileged users need to query the firewall configuration, I'll need to look at the DBus policy more closely. 3) Could you point me at a similar tool that has this check and modify behavior? Thanks, Justin On Wed, Apr 9, 2014 at 7:57 PM, Dmitri Pal wrote: > On 04/08/2014 02:42 PM, Rob Crittenden wrote: >> >> Justin Brown wrote: >>> >>> Dmitri, >>> >>> I'd be more than happy to, but I'm having trouble figuring out where >>> it should go. Could you send me a link to a similar design page? >>> >> >> I'd put it under here: http://www.freeipa.org/page/V4_Proposals >> >> There is a template at http://www.freeipa.org/page/Feature_template >> >> So maybe something like http://www.freeipa.org/page/V4/Firewalld > > > > Rob has beaten me to it, sorry. > I reviewed the page. > Pretty informative, thank you. > > Couple comments: > a) No replication impact. > b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 > --forwarder=192.168.0.3 > I think you want to add the --firewall at the end > c) Please be consistent in one place you use freeipa-.. in other just ipa-.. > but this is minor > d) No commands or config options. > e) It would be really nice to have a bit more information about what kind of > methods and calls you plan to use to interact with NetworkManager and > FirewallD. If you can spell out something like: > Logic: > Call NM and get blah using method X > For each port in the list > call FirewallD method Y > f) What would be error handling if something goes wrong? Would it abort or > create a special message? > g) How should it behave if some ports are already open? Will it print a > message or do it silently? > h) There is actually impact on restore, restore might also now check that > ports are configured in the same way they have been. > i) We should probably also record in the rollback log the ports that have > been opened and close them back if we have to roll back installation or > uninstall server. > j) We should differentiate whether the CA is being installed and open CA > ports only if the CA component is there. > k) We are planning to add other components like DRM and TPS We need to > figure out if we would have to do something on the upgades when we add those > services to add additional ports. > l) I suspect that there be cases where different tools and scripts in IPA > would need to check and open ports. This means that we should probably > create a reusble library that would provide check and update methods. > > > This is so far what came to mind. > Thanks for doing it! > Really appreciated. > > > Dmitri > >> >> rob >> >>> Thanks, >>> Justin >>> >>> On Mon, Apr 7, 2014 at 6:51 PM, Dmitri Pal wrote: >>>> >>>> On 04/07/2014 09:00 AM, Rob Crittenden wrote: >>>>> >>>>> >>>>> Simo Sorce wrote: >>>>>> >>>>>> >>>>>> On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote: >>>>>>> >>>>>>> >>>>>>> On 4.4.2014 09:17, Martin Kosek wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 04/04/2014 09:04 AM, Justin Brown wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I would actually do it the opposite way and open the ports after >>>>>>>>>> the >>>>>>>>>> FreeIPA server is fully configured. After all, I do not think we >>>>>>>>>> want to >>>>>>>>>> open the ports when the server is just half-configured and for >>>>>>>>>> example some >>>>>>>>>> ACIs are missing. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> My thinking was that nothing would be listening on these ports if >>>>>>>>> the >>>>>>>>> install doesn't succeed, but there's really necessity to modify the >>>>>>>>> firewall configuration early. (All of the internal install >>>>>>>>> communication will be over a local interface (to netfilter) and >>>>>>>>> unblock anyways. I don't have any problem in delaying firewall >>>>>>>>> configuration to the end of install. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> If ipa-server-install does succeed without configuring the >>>>>>>> firewalld, >>>>>>>> then we >>>>>>>> will indeed have no other option than to do it early. >>>>>>>> >>>>>>>> I am thinking that we may want to put all the firewalld >>>>>>>> configuration >>>>>>>> in >>>>>>>> ipaserver/install/firewalldinstance.py, >>>>>>>> and then make the firewalld configuration the actual step of the >>>>>>>> installation. >>>>>>>> Something like: >>>>>>>> >>>>>>>> ... >>>>>>>> Configuring Firewall (firewalld) >>>>>>>> [1/2]: looking up the right zone >>>>>>>> [2/2]: allowing ports >>>>>>>> Done configuring Firewall (firewalld). >>>>>>>> ... >>>>>>>> >>>>>>>> The Service class derived object can be really simple, we would just >>>>>>>> reuse the >>>>>>>> functionality it already has + let us properly hook into it in >>>>>>>> ipa-{server,replica}-install and the uninstallation. >>>>>>>> >>>>>>>> It would also make it easier to split this functionality to >>>>>>>> freeipa-server-firewalld if we chose to in a future. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In general I agree with the idea, thank you Justin for working on >>>>>>> that! >>>>>>> >>>>>>> I would like to emphasis the necessity to work without NetworkManager >>>>>>> and >>>>>>> FirewallD. New dependencies make Debian folks unhappy ... >>>>>>> >>>>>>> On the other hand, it is perfectly fine to skip firewall >>>>>>> configuration >>>>>>> if >>>>>>> NM/FirewallD/DBus is not available. >>>>>>> >>>>>>> Have a nice day! >>>>>> >>>>>> >>>>>> >>>>>> Should be easy, probe for the dbus firewalld service and just skip >>>>>> (not >>>>>> error out) if it is not there. >>>>>> Set a variable in that case that will cause the installer to throw the >>>>>> classic banner we have now which warns you about what ports need to be >>>>>> opened at the end of the install. >>>>> >>>>> >>>>> >>>>> Probably just need to spit out a large, preferably flashing warning >>>>> that >>>>> the firewall has not been automatically configured. Perhaps even >>>>> multiple >>>>> times: one in-line and one at the install summary at the end. >>>>> >>>>> rob >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> >>>> >>>> Thanks for looking into this! >>>> >>>> Would it be possible to summarize this thread in a design page on the >>>> wiki? >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From justin.brown at fandingo.org Wed Apr 16 07:59:09 2014 From: justin.brown at fandingo.org (Justin Brown) Date: Wed, 16 Apr 2014 02:59:09 -0500 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <53463ED1.4000206@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> <534442FA.1060709@redhat.com> <5345EC92.3010008@redhat.com> <53463ED1.4000206@redhat.com> Message-ID: Martin, I think that making the firewall configuration automatic is the best solution. I've updated http://www.freeipa.org/page/V4/Firewall_Configuration for automatic configuration unless --no-firewall is passed. You guys know the user-base better than I do, but I would imagine that users would benefit by making a FreeIPA installation work properly with as few arguments as possible. Thanks, Justin On Thu, Apr 10, 2014 at 1:48 AM, Martin Kosek wrote: > On 04/10/2014 02:57 AM, Dmitri Pal wrote: >> On 04/08/2014 02:42 PM, Rob Crittenden wrote: >>> Justin Brown wrote: > ... >> b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 >> --forwarder=192.168.0.3 > > Let's talk about CLI. Shouldn't we add just one option - "--no-firewall"? I > would assume that we want to open the firewall ports by default *if* the > firewalld is running. If firewalld is not running, ipa-server-install would > detect it via DBUS and just simply print warning and would not configure > anything and could just maybe spit out iptables configuration as Justin > mentioned (optional). > > Martin From mkosek at redhat.com Wed Apr 16 08:02:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 10:02:41 +0200 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... Message-ID: <534E3921.4000006@redhat.com> I was looking into ticket https://fedorahosted.org/freeipa/ticket/4054 and experimenting with ACIs allowing privileged users to manage only their own LDAP objects. As already proposed in the Bugzilla, I had success with following ACIs: ~~~~~~~~~~~~~~~~ # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetattr = "userclass")(targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own hosts";allow (write) userattr = "creatorsName#USERDN";) modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test add: aci aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own hosts";allow (delete) userattr = "creatorsName#USERDN";) modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" ~~~~~~~~~~~~~~~~ When I then added a user fbar with permission "Add hosts", I was able to do exactly what proposed in the ticket: $ ipa host-add test.example.com --force ----------------------------- Added host "test.example.com" ----------------------------- Host name: test.example.com Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST Password: False Keytab: False Managed by: test.example.com $ ipa host-mod test.example.com --class foo -------------------------------- Modified host "test.example.com" -------------------------------- Host name: test.example.com Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST Class: foo Password: False Keytab: False Managed by: test.example.com $ ipa host-mod admin.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del admin.example.com ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. $ ipa host-del test.example.com ------------------------------- Deleted host "test.example.com" ------------------------------- I think this could be pretty powerful also with other LDAP objects. Question is what can be done to allow that to our users. I do not think we should add these ACIs by default as not everybody would like them. But if we enhance our permission API to allow the userattr bind rule, admins could add these ACIs at their wish. IMO the API is not that difficult, something like this could work: $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname --bind-attr-type=USERDN --bind-attr could be more or less free form text to allow "creatorsname" or "parent[0].creatorsname" --bind-attr-type would be enum of values USERDN/GROUPDN This should cover most of the basic use cases. Thoughts? -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From abokovoy at redhat.com Wed Apr 16 08:09:39 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Apr 2014 11:09:39 +0300 Subject: [Freeipa-devel] kadmin is unresponsive in FreeIPA installation In-Reply-To: <534E31E4.3090009@redhat.com> References: <534E31E4.3090009@redhat.com> Message-ID: <20140416080939.GH20958@redhat.com> On Wed, 16 Apr 2014, Martin Kosek wrote: >Did anyone hit https://bugzilla.redhat.com/show_bug.cgi?id=1088163 or >is it something specific to my environment? I've seen this before several times but couldn't reproduce at all. Latest change to ipa_kdb_passwords.c where the code that does handle the password change was done over a year ago (Jan 2013). Perhaps you can use gdb and break in ipadb_change_pwd()? -- / Alexander Bokovoy From pviktori at redhat.com Wed Apr 16 08:20:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 10:20:47 +0200 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <534E3921.4000006@redhat.com> References: <534E3921.4000006@redhat.com> Message-ID: <534E3D5F.7000803@redhat.com> On 04/16/2014 10:02 AM, Martin Kosek wrote: > I was looking into ticket > https://fedorahosted.org/freeipa/ticket/4054 > and experimenting with ACIs allowing privileged users to manage only > their own LDAP objects. > > As already proposed in the Bugzilla, I had success with following ACIs: > > ~~~~~~~~~~~~~~~~ > # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > add: aci > aci: (targetattr = "userclass")(targetfilter = > "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own > hosts";allow (write) userattr = "creatorsName#USERDN";) > > modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > > # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > add: aci > aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl > "permission:Modify own hosts";allow (delete) userattr = > "creatorsName#USERDN";) > > modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > ~~~~~~~~~~~~~~~~ > > When I then added a user fbar with permission "Add hosts", I was able to > do exactly what proposed in the ticket: > > > $ ipa host-add test.example.com --force > ----------------------------- > Added host "test.example.com" > ----------------------------- > Host name: test.example.com > Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > Password: False > Keytab: False > Managed by: test.example.com > > $ ipa host-mod test.example.com --class foo > -------------------------------- > Modified host "test.example.com" > -------------------------------- > Host name: test.example.com > Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > Class: foo > Password: False > Keytab: False > Managed by: test.example.com > > $ ipa host-mod admin.example.com --class foo > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > 'userClass' attribute of entry > 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > > > $ ipa host-del admin.example.com > ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to > delete the entry > 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > > > $ ipa host-del test.example.com > ------------------------------- > Deleted host "test.example.com" > ------------------------------- > > I think this could be pretty powerful also with other LDAP objects. > Question is what can be done to allow that to our users. > > I do not think we should add these ACIs by default as not everybody > would like them. But if we enhance our permission API to allow the > userattr bind rule, admins could add these ACIs at their wish. > > IMO the API is not that difficult, something like this could work: > > $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname > --bind-attr-type=USERDN > > --bind-attr could be more or less free form text to allow "creatorsname" > or "parent[0].creatorsname" > --bind-attr-type would be enum of values USERDN/GROUPDN > > This should cover most of the basic use cases. > > Thoughts? > Makes sense. I'd do it around the time we move self-service to permissions. Simo, can you reserve two more OIDs for the attributes? -- Petr? From jcholast at redhat.com Wed Apr 16 08:35:27 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 16 Apr 2014 10:35:27 +0200 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <534E3D5F.7000803@redhat.com> References: <534E3921.4000006@redhat.com> <534E3D5F.7000803@redhat.com> Message-ID: <534E40CF.5020701@redhat.com> On 16.4.2014 10:20, Petr Viktorin wrote: > On 04/16/2014 10:02 AM, Martin Kosek wrote: >> I was looking into ticket >> https://fedorahosted.org/freeipa/ticket/4054 >> and experimenting with ACIs allowing privileged users to manage only >> their own LDAP objects. >> >> As already proposed in the Bugzilla, I had success with following ACIs: >> >> ~~~~~~~~~~~~~~~~ >> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >> add: aci >> aci: (targetattr = "userclass")(targetfilter = >> "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own >> hosts";allow (write) userattr = "creatorsName#USERDN";) >> >> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >> >> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >> add: aci >> aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl >> "permission:Modify own hosts";allow (delete) userattr = >> "creatorsName#USERDN";) >> >> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >> ~~~~~~~~~~~~~~~~ >> >> When I then added a user fbar with permission "Add hosts", I was able to >> do exactly what proposed in the ticket: >> >> >> $ ipa host-add test.example.com --force >> ----------------------------- >> Added host "test.example.com" >> ----------------------------- >> Host name: test.example.com >> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >> Password: False >> Keytab: False >> Managed by: test.example.com >> >> $ ipa host-mod test.example.com --class foo >> -------------------------------- >> Modified host "test.example.com" >> -------------------------------- >> Host name: test.example.com >> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >> Class: foo >> Password: False >> Keytab: False >> Managed by: test.example.com >> >> $ ipa host-mod admin.example.com --class foo >> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the >> 'userClass' attribute of entry >> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >> >> >> >> $ ipa host-del admin.example.com >> ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to >> delete the entry >> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >> >> >> >> $ ipa host-del test.example.com >> ------------------------------- >> Deleted host "test.example.com" >> ------------------------------- >> >> I think this could be pretty powerful also with other LDAP objects. >> Question is what can be done to allow that to our users. >> >> I do not think we should add these ACIs by default as not everybody >> would like them. But if we enhance our permission API to allow the >> userattr bind rule, admins could add these ACIs at their wish. >> >> IMO the API is not that difficult, something like this could work: >> >> $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname >> --bind-attr-type=USERDN >> >> --bind-attr could be more or less free form text to allow "creatorsname" >> or "parent[0].creatorsname" >> --bind-attr-type would be enum of values USERDN/GROUPDN >> >> This should cover most of the basic use cases. >> >> Thoughts? >> > > Makes sense. I'd do it around the time we move self-service to permissions. > > Simo, can you reserve two more OIDs for the attributes? > > I don't think we need creatorsName, we already have managedBy. Or am I missing something? Honza -- Jan Cholasta From jcholast at redhat.com Wed Apr 16 08:35:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 16 Apr 2014 10:35:33 +0200 Subject: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions In-Reply-To: <5347D28A.2020300@redhat.com> References: <5347D28A.2020300@redhat.com> Message-ID: <534E40D5.10502@redhat.com> On 11.4.2014 13:31, Petr Viktorin wrote: > One of the default_attributes of permission is memberofindirect, a > virtual attribute manufactured by ldap2, which is set when a permission > is part of a role. > When update_entry is called on an entry with memberofindirect, ipaldap > tries to add the attribute to LDAP and fails with an objectclass violation. > > Do not ask for memberindirect when retrieving the entry. > > > > CCing Honza since he designs ipaldap. Virtual attributes are often > helpful, and in any case IPA uses them a lot and having to filter them > out every time is error-prone. > Maybe we should add support for them directly in ipaldap -- e.g. an > attribute set by `entry.virtual[attr_name] = [x]` would be visible in > entry[attr_name] but would not be synced back to LDAP? > I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff in the future. Your suggestion works in sort of opposite direction, so I can't say I like it. Currently we use LDAPEntry in frontend code directly, but I think that's wrong. There should be a frontend-specific class for this (make ipalib.frontend.Object instantiable?) and LDAPEntry should be used (almost) only in backend code. Honza -- Jan Cholasta From jcholast at redhat.com Wed Apr 16 09:04:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 16 Apr 2014 11:04:37 +0200 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <5346F9B0.8060600@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> Message-ID: <534E47A5.9030607@redhat.com> On 10.4.2014 22:06, Rob Crittenden wrote: > Some in-line, a whole ton of data appended to end. > > Jan Cholasta wrote: >> On 7.4.2014 20:09, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> >>>> 242 >>>> >>>> I wonder if it would be clearer to use variables instead of a raw list >>>> in the return value for these handlers: (result, message) = >>>> handler(...) >>>> rather than examining result[0], etc. That may be beyond the scope of >>>> this patch though. >> >> Yes. It would be nice if certmonger included a Python module for helper >> scripts... > > Yes, but what I mean is the internal handling returns tuples of data > with unique variable names, then plucks them out positionally. len(result) depends on result[0], so you can't do "result, message = handler(...)", because it would blow up when len(result) != 2. >>>> >>>> 243 >>>> >>>> You are going to end up with a lot of acis with the same comment value. >>>> Perhaps add the host in there as well. >>>> >>>> These are not removed when a master is deleted. >> >> I merely did the same thing as the "Add CA Certificates for renewals" >> and "Modify CA Certificates for renewals" ACIs. >> >> I agree it's suboptimal, but IMO it should be fixed in the scope of >> (the "ipa masters >> hostgroup" part). > > There is a replica_cleanup() method in replication.py. I don't know why > this couldn't be added there. OK, added, see patch 263. But we should do the hostgroup thing anyway, this solution sucks. >>>> >>>> 247 >>>> >>>> We've been burned by hardcoded timeouts in the past. Should this be >>>> configurable? This module doesn't currently do any logging but it might >>>> be worth spitting out a "waiting" message, at least for debugging. >> >> Added a timeout argument. > > Did you forget to send this one, I didn't see an update to 247. Are you sure you have 247.1 (now 247.2)? I can see at that I have sent the correct version of the patches. >>>> >>>> 251 >>>> >>>> The tool should provide some feedback while it's running. For the >>>> impatient (me) it takes a really long time and it's hard to know >>>> what is >>>> going on, something in between nothing and full debug output. >> >> Added some messages about what's going on. > > I dpn't see an update to 251 either. Please make sure you have 251.1 (now 251.2). > >>>> >>>> The man page needs some more work too. I think some more explanation is >>>> needed and an example would probably be really helpful as well. I think >>>> particularly an example for external certs and a description of what >>>> you >>>> mean by Self-signed CA (I assume you mean IPA-provided). I don't think >>>> it really matters how many steps there are unless you are going to >>>> provide progress output. >> >> Reworded the man page a little bit. >> >>>> >>>> Got a backtrace when running as non-root: >>>> >>>> $ ipa-cacert-manage -v renew >>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 168, in >>>> execute >>>> self.validate_options() >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>>> >>>> >>>> >>>> line 62, in validate_options >>>> super(CACertManage, self).validate_options(needs_root=True) >>>> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >>>> 189, in validate_options >>>> raise ScriptError('Must be root to run %s' % self.command_name, 1) >>>> >>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >>>> ipa-cacert-manage command failed, exception: ScriptError: Must be root >>>> to run ipa-cacert-manage >>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be >>>> root to run ipa-cacert-manage >> >> That's correct, you can run it only as root, because you can't resubmit >> certmonger requests as a regular user. > > Yes but one shouldn't get a traceback! You get the traceback only in verbose mode. I did not invent this, it's how ipapython.admintool does things. >>> >>> After moving time forward on the replica these certificates are in >>> CA_WORKING: >>> >>> ipaCert >>> auditSigningCert cert-pki-ca >>> ocspSigningCert cert-pki-ca >>> subsystemCert cert-pki-ca >>> >>> cn=ca_renewal is completely empty on the replica. On the master it only >>> has the subsystemCert. I'm guessing this is at least partly due to my >>> switching time one system at a time rather than (somewhat) >>> simultaneously, but it still would have blown up with 3 missing certs. >> >> Can you post the related log messages from /var/log/messages from the >> master somewhere? >> >> There's not much I can do about broken replication. I think you hit >> . >> >>> >>> rob >> >> Thanks for the review. >> >> Updated and rebased patches attached. >> > > Patch 262 has lots of lint errors because you're adding arguments to > functions that don't currently define one, is_renewal_master() for example. They are defined in patch 246.1 (now 246.2). > > I think the ipa-cacert-manage man page is missing one really important > piece: why would you ever need to run this? And when? Added a paragraph about this. > > The renewal was failing on the replica due to SELinux failures: > > # ausearch -m AVC -ts recent > ---- > time->Mon Mar 21 11:00:05 2016 > type=SYSCALL msg=audit(1458572405.859:828): arch=c000003e syscall=59 > success=no exit=-13 a0=c687c0 a1=c688c0 a2=c66e40 a3=7ffff0a46120 > items=0 ppid=4172 pid=4173 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="sh" > exe="/usr/bin/bash" subj=system_u:system_r:certmonger_t:s0 key=(null) > type=AVC msg=audit(1458572405.859:828): avc: denied { execute } for > pid=4173 comm="sh" name="ldconfig" dev="dm-1" ino=134149 > scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file All of the ldconfig-related denials do not seem to affect anything. > ---- > time->Mon Mar 21 11:00:06 2016 > type=SYSCALL msg=audit(1458572406.334:834): arch=c000003e syscall=2 > success=no exit=-13 a0=315f900 a1=0 a2=1b6 a3=7fffbfef2060 items=0 > ppid=3672 pid=4168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" > exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) > type=AVC msg=audit(1458572406.334:834): avc: denied { read } for > pid=4168 comm="dogtag-ipa-ca-r" name="sysupgrade.state" dev="dm-1" > ino=276510 scontext=system_u:system_r:certmonger_t:s0 > tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file > ---- > time->Mon Mar 21 11:00:07 2016 > type=SYSCALL msg=audit(1458572407.378:835): arch=c000003e syscall=2 > success=no exit=-13 a0=2c98030 a1=0 a2=1b6 a3=7fffbfef2450 items=0 > ppid=3672 pid=4168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" > exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) > type=AVC msg=audit(1458572407.378:835): avc: denied { read } for > pid=4168 comm="dogtag-ipa-ca-r" name="sysrestore.state" dev="dm-1" > ino=273976 scontext=system_u:system_r:certmonger_t:s0 I haven't seen these two on my system, probably unrelated. > tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file > ---- > time->Mon Mar 21 11:00:07 2016 > type=SYSCALL msg=audit(1458572407.385:836): arch=c000003e syscall=42 > success=no exit=-13 a0=4 a1=7fffbfef24f0 a2=6e a3=7fffbfef24f2 items=0 > ppid=3672 pid=4168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="dogtag-ipa-ca-r" > exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) > type=AVC msg=audit(1458572407.385:836): avc: denied { write } for > pid=4168 comm="dogtag-ipa-ca-r" name="slapd-GREYOAK-COM.socket" > dev="tmpfs" ino=53896 scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file Weird, I haven't seen this before. > > Mar 21 11:07:00 sif.greyoak.com dogtag-ipa-ca-renew-agent-submit[4337]: > Traceback (most recent call last): > File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line > 299, in > sys.exit(main()) > File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line > 288, in main > if ca.is_renewal_master(): > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 1548, in is_renewal_master > self.ldap_connect() > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 118, in ldap_connect > conn.do_external_bind(pw_name) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1727, > in do_external_bind > self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1713, > in __bind_with_wait > self.__wait_for_connection(timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1699, > in __wait_for_connection > wait_for_open_socket(lurl.hostport, timeout) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1173, > in wait_for_open_socket > raise e > error: [Errno 13] Permission denied > Mar 21 11:07:00 sif.greyoak.com certmonger[3672]: 2016-03-21 11:07:00 > [3672] Internal error > > I updated selinux-policy but I'm not seeing the certs added consistently > to ca_renewal so there is nothing to do, so it sits in CA_WORKING. I > verified it isn't a replication issue, the replication is working fine, > the certs just weren't pushed. Fixed renewal scripts not to use ldapi, see patch 264. Also fixed certificate retrieval from LDAP to check if the certificate was actually renewed, see patch 265. > > Here is what syslog on the initial master has to say about it. The > reason strange part is the references to dogtag-ipa-renew-agent: That's normal, dogtag-ipa-ca-renew-agent forwards "real" certificate requests to dogtag-ipa-renew-agent (hence the similar name). Updated and rebased, as well as new (263-265) patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.2-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.2-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 2920 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.2-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1130 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.2-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2304 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.2-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.2-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.2-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.2-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 6022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.2-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 2036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.2-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 2917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.2-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 16832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.2-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.2-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.1-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2654 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 11904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 1874 bytes Desc: not available URL: From pviktori at redhat.com Wed Apr 16 10:07:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 12:07:06 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534E19C0.4050008@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> <534D46BB.707@redhat.com> <1397574507.19767.317.camel@willson.li.ssimo.org> <534D4C02.5090708@redhat.com> <534D542E.4050701@redhat.com> <534D5A0B.8060602@redhat.com> <534E19C0.4050008@redhat.com> Message-ID: <534E564A.4040704@redhat.com> On 04/16/2014 07:48 AM, Martin Kosek wrote: > On 04/15/2014 06:10 PM, Ludwig Krispenz wrote: >> >> On 04/15/2014 05:45 PM, Ludwig Krispenz wrote: >>> >>> On 04/15/2014 05:10 PM, Martin Kosek wrote: >>>> On 04/15/2014 05:08 PM, Simo Sorce wrote: >>>>> On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote: >>>>>> On 04/15/2014 03:16 PM, Simo Sorce wrote: >>>>>>> On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: >>>>>>>> On 04/15/2014 09:43 AM, Martin Kosek wrote: >>>>>>>>> On 04/15/2014 09:38 AM, Martin Kosek wrote: >>>>>>>>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>>>>>>>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> The first patch adds default read permissions to krbtpolicy. >>>>>>>>>>>> Since the >>>>>>>>>>>> plugin manages entries in two trees, there are two >>>>>>>>>>>> permissions. Since >>>>>>>>>>>> two permissions are needed to cover krbtpolicy, it can't be >>>>>>>>>>>> used as a >>>>>>>>>>>> permission's --type. >>>>>>>>>>>> The permissions are added to a new privilege, 'Kerberos >>>>>>>>>>>> Ticket Policy >>>>>>>>>>>> Readers'. >>>>>>>>>>>> >>>>>>>>>>>> The second patch adds an ACI for reading the Kerberos realm >>>>>>>>>>>> name. Since >>>>>>>>>>>> client enrollment won't work without this, I don't see a >>>>>>>>>>>> reason for >>>>>>>>>>>> having it managed by a permission. >>>>>>>>>>>> >>>>>>>>>>> LGTM >>>>>>>>>>> >>>>>>>>>>> Simo. >>>>>>>>>>> >>>>>>>>>> 521 breaks a unit test: >>>>>>>>>> >>>>>>>>>> ====================================================================== >>>>>>>>>> >>>>>>>>>> FAIL: test_permission[37]: permission_find: Search for >>>>>>>>>> u'Testperm_RN' >>>>>>>>>> using >>>>>>>>>> --subtree >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> Traceback (most recent call last): >>>>>>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line >>>>>>>>>> 197, in >>>>>>>>>> runTest >>>>>>>>>> self.test(*self.arg) >>>>>>>>>> File >>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>> line 301, in >>>>>>>>>> >>>>>>>>>> func = lambda: self.check(nice, **test) >>>>>>>>>> File >>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>> line 319, in >>>>>>>>>> check >>>>>>>>>> self.check_output(nice, cmd, args, options, expected, >>>>>>>>>> extra_check) >>>>>>>>>> File >>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>> line 359, in >>>>>>>>>> check_output >>>>>>>>>> assert_deepequal(expected, got, nice) >>>>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 344, in >>>>>>>>>> assert_deepequal >>>>>>>>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >>>>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 352, in >>>>>>>>>> assert_deepequal >>>>>>>>>> VALUE % (doc, expected, got, stack) >>>>>>>>>> AssertionError: assert_deepequal: expected != got. >>>>>>>>>> test_permission[37]: permission_find: Search for >>>>>>>>>> u'Testperm_RN' >>>>>>>>>> using --subtree >>>>>>>>>> expected = 1 >>>>>>>>>> got = 2 >>>>>>>>>> path = ('count',) >>>>>>>> Thanks for the catch, tests updated. >>>>>>>> >>>>>>>>>> Otherwise it works fine (krbtpolicy-show for user cannot be >>>>>>>>>> tested yet >>>>>>>>>> as we >>>>>>>>>> miss permissions for users). >>>>>>>> Right; I don't think this permission by itself should allow >>>>>>>> access to >>>>>>>> users. Correct me if that's wrong. >>>>>>>> >>>>>>>> I created a users permission for testing: >>>>>>>> ipa permission-add 'allow reading user objectclass' --type >>>>>>>> user >>>>>>>> --right={read,search,compare} --attrs objectclass --bind all >>>>>>>> >>>>>>>>> /me hit Send too soon. >>>>>>>>> >>>>>>>>> Although 522 works functionally and client now discovers the IPA >>>>>>>>> server, there >>>>>>>>> is no path from SUFFIX to cn=REALM for anonymous users. >>>>>>>>> >>>>>>>>> I would personally change the ACI to >>>>>>>>> >>>>>>>>> (targetattr = "cn || objectclass")(targetfilter = >>>>>>>>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version >>>>>>>>> >>>>>>>>> 3.0;acl >>>>>>>>> "Anonymous read access to Kerberos container";allow >>>>>>>>> (read,compare,search) >>>>>>>>> userdn = "ldap:///anyone";)' >>>>>>>>> >>>>>>>>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer >>>>>>>>> objectclass). >>>>>>>> Right, that's necessary for UIs to list the container. >>>>>>>> Simo, are you okay with this? >>>>>>> It is no secret that an IPA server has a container named after the >>>>>>> domain. And the REALM name is available unauthenticated from DNS, so >>>>>>> knowledge of it's existence is given. >>>>>>> Therefore I see no problem if anonymous can see the container >>>>>>> exists, as >>>>>>> long as no contents (beyond what we already determined need to >>>>>>> be) are >>>>>>> revealed I see no problem. >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>>> >>>>>> Patches work fine. The only problem I see that we now expose group >>>>>> password >>>>>> policies >>>>>> >>>>>> # ldapsearch -h `hostname` -x -b >>>>>> 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn >>>>>> ... >>>>>> # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>>> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>>>> cn: MKOSEK-FEDORA20.TEST >>>>>> >>>>>> # global_policy, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>>> dn: >>>>>> cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc >>>>>> >>>>>> =test >>>>>> cn: global_policy >>>>>> >>>>>> # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>>> dn: >>>>>> cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>>>> >>>>>> cn: ipausers >>>>>> ... >>>>>> >>>>>> It seems suboptimal as we now moved access to group password >>>>>> policy to >>>>>> special >>>>>> permission and we probably do not want to leak a list of defined >>>>>> group >>>>>> policies. >>>>>> >>>>>> Question is how to prevent it as the group password policies have >>>>>> nsContainer >>>>>> OC. I see 2 options: >>>>>> >>>>>> 1) Update pwpolicy plugin to avoid using nsContainer for group >>>>>> password >>>>>> policy >>>>>> (I do not think it is needed, krbPwdPolicy contains cn attribute >>>>>> >>>>>> 2) Update our container allowing ACI to not display it. >>>>>> >>>>>> Option 1) would be nice, but I am afraid it would break search in >>>>>> older >>>>>> versions which expects the nsContainer OC to be there. >>>>>> >>>>>> As for option 2) I am not sure how best to do it. It would be best >>>>>> to exclude >>>>>> both cn=etc and cn=kerberos subtrees, but I could not figure out >>>>>> an ACI >>>>>> syntax >>>>>> to do it. >>>>>> >>>>>> Both >>>>>> (target != "ldap:///some=dn")(target != "ldap:///other=dn") >>>>>> and >>>>>> (target != "ldap:///some=dn" && target != "ldap:///other=dn") >>>>>> are not correct. CCing Ludwig to advise. >>>>>> >>>>>> Alternative is to exclude the the password policies by >>>>>> targetfilter, but I >>>>>> think excluding whole tree is better. >>>>>> >>>>>> Martin >>>>> It's like an LDAP filter but no quite so maybe: >>>>> (&(target != "ldap:///some=dn")(target != "ldap:///other=dn")) ? >>>>> >>>>> HTH, >>>>> Simo. >>>>> >>>> Try again... >>>> >>>> [15/Apr/2014:17:15:01 +0200] NSACLPlugin - ACL Syntax >>>> Error(-5):(targetfilter=\22(objectclass=nsContainer)\22)(&(target != >>>> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22)(target != >>>> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22))(targetattr=\22objectclass >>>> || >>>> cn\22)(version 3.0; acl \22Anonymous read access to containers\22; >>>> allow(read, >>>> search, compare) userdn = \22ldap:///anyone\22;) >>>> >>>> Martin >>> (target!="ldap:///some=dn || ldap:///other=dn") is accepted, but in a >>> quick >>> test also didn't work as expected. Need to investigate a bit more >> looks like we do not handle multiple targets at all. Although in the >> bind rules >> logical operations of binddns and bindgroups are handled, so that >> would be an >> enhancement :-( >> >> so I think you either have to move to denies for the two subtrees and >> a general >> allow for the parent tree, which is not nice or use targetfilter if >> possible. > > Ok, thanks for investigation. Petr, it seems we will simply need to > update the container ACI and exclude krbPwdPolicy objectclass in the > target filter. > > Martin Patch here. It doesn't handle updating from unreleased code, so if you're upgrading from recent master, remove the previous "Anonymous read access to containers" ACI. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0523-Disallow-anonymous-read-access-to-Kerberos-password-.patch Type: text/x-patch Size: 1334 bytes Desc: not available URL: From pviktori at redhat.com Wed Apr 16 10:29:38 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 12:29:38 +0200 Subject: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions In-Reply-To: <534E40D5.10502@redhat.com> References: <5347D28A.2020300@redhat.com> <534E40D5.10502@redhat.com> Message-ID: <534E5B92.7050105@redhat.com> On 04/16/2014 10:35 AM, Jan Cholasta wrote: > On 11.4.2014 13:31, Petr Viktorin wrote: >> One of the default_attributes of permission is memberofindirect, a >> virtual attribute manufactured by ldap2, which is set when a permission >> is part of a role. >> When update_entry is called on an entry with memberofindirect, ipaldap >> tries to add the attribute to LDAP and fails with an objectclass >> violation. >> >> Do not ask for memberindirect when retrieving the entry. >> >> >> >> CCing Honza since he designs ipaldap. Virtual attributes are often >> helpful, and in any case IPA uses them a lot and having to filter them >> out every time is error-prone. >> Maybe we should add support for them directly in ipaldap -- e.g. an >> attribute set by `entry.virtual[attr_name] = [x]` would be visible in >> entry[attr_name] but would not be synced back to LDAP? >> > > I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff > in the future. Your suggestion works in sort of opposite direction, so I > can't say I like it. > > Currently we use LDAPEntry in frontend code directly, but I think that's > wrong. There should be a frontend-specific class for this (make > ipalib.frontend.Object instantiable?) and LDAPEntry should be used > (almost) only in backend code. Right, that's the way to go long-term. Virtual attributes could be a stop-gap solution before we get there, since to remove this from ldap2 we'd need to change all the plugins that use it. Thinking about it more, it probably would be too much work for a workaround. -- Petr? From pviktori at redhat.com Wed Apr 16 10:34:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 12:34:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534E564A.4040704@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> <534D46BB.707@redhat.com> <1397574507.19767.317.camel@willson.li.ssimo.org> <534D4C02.5090708@redhat.com> <534D542E.4050701@redhat.com> <534D5A0B.8060602@redhat.com> <534E19C0.4050008@redhat.com> <534E564A.4040704@redhat.com> Message-ID: <534E5CA5.9090404@redhat.com> On 04/16/2014 12:07 PM, Petr Viktorin wrote: > On 04/16/2014 07:48 AM, Martin Kosek wrote: >> On 04/15/2014 06:10 PM, Ludwig Krispenz wrote: >>> >>> On 04/15/2014 05:45 PM, Ludwig Krispenz wrote: >>>> >>>> On 04/15/2014 05:10 PM, Martin Kosek wrote: >>>>> On 04/15/2014 05:08 PM, Simo Sorce wrote: >>>>>> On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote: >>>>>>> On 04/15/2014 03:16 PM, Simo Sorce wrote: >>>>>>>> On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: >>>>>>>>> On 04/15/2014 09:43 AM, Martin Kosek wrote: >>>>>>>>>> On 04/15/2014 09:38 AM, Martin Kosek wrote: >>>>>>>>>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>>>>>>>>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> The first patch adds default read permissions to krbtpolicy. >>>>>>>>>>>>> Since the >>>>>>>>>>>>> plugin manages entries in two trees, there are two >>>>>>>>>>>>> permissions. Since >>>>>>>>>>>>> two permissions are needed to cover krbtpolicy, it can't be >>>>>>>>>>>>> used as a >>>>>>>>>>>>> permission's --type. >>>>>>>>>>>>> The permissions are added to a new privilege, 'Kerberos >>>>>>>>>>>>> Ticket Policy >>>>>>>>>>>>> Readers'. >>>>>>>>>>>>> >>>>>>>>>>>>> The second patch adds an ACI for reading the Kerberos realm >>>>>>>>>>>>> name. Since >>>>>>>>>>>>> client enrollment won't work without this, I don't see a >>>>>>>>>>>>> reason for >>>>>>>>>>>>> having it managed by a permission. >>>>>>>>>>>>> >>>>>>>>>>>> LGTM >>>>>>>>>>>> >>>>>>>>>>>> Simo. >>>>>>>>>>>> >>>>>>>>>>> 521 breaks a unit test: >>>>>>>>>>> >>>>>>>>>>> ====================================================================== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> FAIL: test_permission[37]: permission_find: Search for >>>>>>>>>>> u'Testperm_RN' >>>>>>>>>>> using >>>>>>>>>>> --subtree >>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line >>>>>>>>>>> 197, in >>>>>>>>>>> runTest >>>>>>>>>>> self.test(*self.arg) >>>>>>>>>>> File >>>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>>> line 301, in >>>>>>>>>>> >>>>>>>>>>> func = lambda: self.check(nice, **test) >>>>>>>>>>> File >>>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>>> line 319, in >>>>>>>>>>> check >>>>>>>>>>> self.check_output(nice, cmd, args, options, expected, >>>>>>>>>>> extra_check) >>>>>>>>>>> File >>>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>>> line 359, in >>>>>>>>>>> check_output >>>>>>>>>>> assert_deepequal(expected, got, nice) >>>>>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 344, in >>>>>>>>>>> assert_deepequal >>>>>>>>>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >>>>>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 352, in >>>>>>>>>>> assert_deepequal >>>>>>>>>>> VALUE % (doc, expected, got, stack) >>>>>>>>>>> AssertionError: assert_deepequal: expected != got. >>>>>>>>>>> test_permission[37]: permission_find: Search for >>>>>>>>>>> u'Testperm_RN' >>>>>>>>>>> using --subtree >>>>>>>>>>> expected = 1 >>>>>>>>>>> got = 2 >>>>>>>>>>> path = ('count',) >>>>>>>>> Thanks for the catch, tests updated. >>>>>>>>> >>>>>>>>>>> Otherwise it works fine (krbtpolicy-show for user cannot be >>>>>>>>>>> tested yet >>>>>>>>>>> as we >>>>>>>>>>> miss permissions for users). >>>>>>>>> Right; I don't think this permission by itself should allow >>>>>>>>> access to >>>>>>>>> users. Correct me if that's wrong. >>>>>>>>> >>>>>>>>> I created a users permission for testing: >>>>>>>>> ipa permission-add 'allow reading user objectclass' --type >>>>>>>>> user >>>>>>>>> --right={read,search,compare} --attrs objectclass --bind all >>>>>>>>> >>>>>>>>>> /me hit Send too soon. >>>>>>>>>> >>>>>>>>>> Although 522 works functionally and client now discovers the IPA >>>>>>>>>> server, there >>>>>>>>>> is no path from SUFFIX to cn=REALM for anonymous users. >>>>>>>>>> >>>>>>>>>> I would personally change the ACI to >>>>>>>>>> >>>>>>>>>> (targetattr = "cn || objectclass")(targetfilter = >>>>>>>>>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3.0;acl >>>>>>>>>> "Anonymous read access to Kerberos container";allow >>>>>>>>>> (read,compare,search) >>>>>>>>>> userdn = "ldap:///anyone";)' >>>>>>>>>> >>>>>>>>>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer >>>>>>>>>> objectclass). >>>>>>>>> Right, that's necessary for UIs to list the container. >>>>>>>>> Simo, are you okay with this? >>>>>>>> It is no secret that an IPA server has a container named after the >>>>>>>> domain. And the REALM name is available unauthenticated from >>>>>>>> DNS, so >>>>>>>> knowledge of it's existence is given. >>>>>>>> Therefore I see no problem if anonymous can see the container >>>>>>>> exists, as >>>>>>>> long as no contents (beyond what we already determined need to >>>>>>>> be) are >>>>>>>> revealed I see no problem. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>>> >>>>>>> Patches work fine. The only problem I see that we now expose group >>>>>>> password >>>>>>> policies >>>>>>> >>>>>>> # ldapsearch -h `hostname` -x -b >>>>>>> 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn >>>>>>> ... >>>>>>> # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>>>> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>>>>> cn: MKOSEK-FEDORA20.TEST >>>>>>> >>>>>>> # global_policy, MKOSEK-FEDORA20.TEST, kerberos, >>>>>>> mkosek-fedora20.test >>>>>>> dn: >>>>>>> cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc >>>>>>> >>>>>>> >>>>>>> =test >>>>>>> cn: global_policy >>>>>>> >>>>>>> # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>>>> dn: >>>>>>> cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>>>>> >>>>>>> >>>>>>> cn: ipausers >>>>>>> ... >>>>>>> >>>>>>> It seems suboptimal as we now moved access to group password >>>>>>> policy to >>>>>>> special >>>>>>> permission and we probably do not want to leak a list of defined >>>>>>> group >>>>>>> policies. >>>>>>> >>>>>>> Question is how to prevent it as the group password policies have >>>>>>> nsContainer >>>>>>> OC. I see 2 options: >>>>>>> >>>>>>> 1) Update pwpolicy plugin to avoid using nsContainer for group >>>>>>> password >>>>>>> policy >>>>>>> (I do not think it is needed, krbPwdPolicy contains cn attribute >>>>>>> >>>>>>> 2) Update our container allowing ACI to not display it. >>>>>>> >>>>>>> Option 1) would be nice, but I am afraid it would break search in >>>>>>> older >>>>>>> versions which expects the nsContainer OC to be there. >>>>>>> >>>>>>> As for option 2) I am not sure how best to do it. It would be best >>>>>>> to exclude >>>>>>> both cn=etc and cn=kerberos subtrees, but I could not figure out >>>>>>> an ACI >>>>>>> syntax >>>>>>> to do it. >>>>>>> >>>>>>> Both >>>>>>> (target != "ldap:///some=dn")(target != "ldap:///other=dn") >>>>>>> and >>>>>>> (target != "ldap:///some=dn" && target != "ldap:///other=dn") >>>>>>> are not correct. CCing Ludwig to advise. >>>>>>> >>>>>>> Alternative is to exclude the the password policies by >>>>>>> targetfilter, but I >>>>>>> think excluding whole tree is better. >>>>>>> >>>>>>> Martin >>>>>> It's like an LDAP filter but no quite so maybe: >>>>>> (&(target != "ldap:///some=dn")(target != "ldap:///other=dn")) ? >>>>>> >>>>>> HTH, >>>>>> Simo. >>>>>> >>>>> Try again... >>>>> >>>>> [15/Apr/2014:17:15:01 +0200] NSACLPlugin - ACL Syntax >>>>> Error(-5):(targetfilter=\22(objectclass=nsContainer)\22)(&(target != >>>>> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22)(target != >>>>> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22))(targetattr=\22objectclass >>>>> >>>>> || >>>>> cn\22)(version 3.0; acl \22Anonymous read access to containers\22; >>>>> allow(read, >>>>> search, compare) userdn = \22ldap:///anyone\22;) >>>>> >>>>> Martin >>>> (target!="ldap:///some=dn || ldap:///other=dn") is accepted, but in a >>>> quick >>>> test also didn't work as expected. Need to investigate a bit more >>> looks like we do not handle multiple targets at all. Although in the >>> bind rules >>> logical operations of binddns and bindgroups are handled, so that >>> would be an >>> enhancement :-( >>> >>> so I think you either have to move to denies for the two subtrees and >>> a general >>> allow for the parent tree, which is not nice or use targetfilter if >>> possible. >> >> Ok, thanks for investigation. Petr, it seems we will simply need to >> update the container ACI and exclude krbPwdPolicy objectclass in the >> target filter. >> >> Martin > > Patch here. > It doesn't handle updating from unreleased code, so if you're upgrading > from recent master, remove the previous "Anonymous read access to > containers" ACI. Actually, we might want to delay pushing this patch; It'll need some more modifications to allow containers in cn=etc. -- Petr? From mkosek at redhat.com Wed Apr 16 10:47:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 12:47:04 +0200 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> <534442FA.1060709@redhat.com> <5345EC92.3010008@redhat.com> <53463ED1.4000206@redhat.com> Message-ID: <534E5FA8.9090301@redhat.com> On 04/16/2014 09:59 AM, Justin Brown wrote: > Martin, > > I think that making the firewall configuration automatic is the best > solution. I've updated > http://www.freeipa.org/page/V4/Firewall_Configuration for automatic > configuration unless --no-firewall is passed. > > You guys know the user-base better than I do, but I would imagine that > users would benefit by making a FreeIPA installation work properly > with as few arguments as possible. > > Thanks, > Justin > > On Thu, Apr 10, 2014 at 1:48 AM, Martin Kosek wrote: >> On 04/10/2014 02:57 AM, Dmitri Pal wrote: >>> On 04/08/2014 02:42 PM, Rob Crittenden wrote: >>>> Justin Brown wrote: >> ... >>> b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 >>> --forwarder=192.168.0.3 >> >> Let's talk about CLI. Shouldn't we add just one option - "--no-firewall"? I >> would assume that we want to open the firewall ports by default *if* the >> firewalld is running. If firewalld is not running, ipa-server-install would >> detect it via DBUS and just simply print warning and would not configure >> anything and could just maybe spit out iptables configuration as Justin >> mentioned (optional). >> >> Martin Right. The default installation option should fit the most users. Which automatic configuration of firewall (when it is present) is the one. Thanks, Martin From pviktori at redhat.com Wed Apr 16 10:50:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 12:50:45 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <1397484037.19767.243.camel@willson.li.ssimo.org> References: <534BBE8A.6080101@redhat.com> <1397484037.19767.243.camel@willson.li.ssimo.org> Message-ID: <534E6085.3000002@redhat.com> On 04/14/2014 04:00 PM, Simo Sorce wrote: > On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: >> When heading for a lunch today, I had a discussion with Petr3 about ACIs for >> cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will >> simply allow all attributes in cn=etc for authenticated users and will just >> exclude the blacklisted attributes (for context, see ticket #3566). >> >> I personally think it is not the best thing to do as it will just move the >> problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It >> would be better to add normal ACIs for cn=etc as well. >> >> I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it >> seems straightforward what ACIs would be needed: >> >> ========================================================================== >> dn: cn=etc,SUFFIX >> - ADD aci allowing reading nsContainer for anonymous, EXCEPT: We can combine this with the general nsContainer read ACI. The problem is that we can only have one target-based exclusion rule. >> - cn=virtual operations,cn=etc,SUFFIX Could we use a special objectClass rather than nsContainer for these? >> - cn=masters,cn=ipa,cn=etc,SUFFIX This is the one I'd exclude with the target rule. >> - cn=Managed Entries,cn=etc,SUFFIX Why exclude this one? Aren't the containers the same in all IPA installs? >> dn: cn=sysaccounts,cn=etc,SUFFIX >> - ADD aci allowing reading all attributes but password attributes (people may >> add unstructured accounts following different objectclasses) I'd rather list the attributes and let people add custom attributes themselves. >> dn: cn=ipa,cn=etc,SUFFIX >> - no ACI needed >> >> dn: cn=masters,cn=ipa,cn=etc,SUFFIX >> - ADD aci allowing reading hosts (to have it separate from global cn=etc one so >> that we can once assign it only to ipamasters hostgroup for example) >> >> dn: cn=replicas,cn=ipa,cn=etc,SUFFIX >> - ADD aci allowing reading replicas for authenticated users (masters) >> >> dn: cn=dna,cn=ipa,cn=etc,SUFFIX >> - ADD aci allowing reading dnaSharedConfig objects for authenticated >> >> dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX >> - no ACI needed >> >> dn: cn=ca_renewal,cn=ipa,cn=etc,SUFFIX >> - ADD aci allowing reading for authenticated users (hosts' certmonger) >> >> dn: cn=s4u2proxy,cn=etc,SUFFIX >> - no ACI needed at this point, KDC access it with DM privileges AFAIK >> >> dn: cn=ipaConfig,cn=etc,SUFFIX >> - ADD aci allowing reading ipaConfigObject attributes for authenticated users. >> We already plan aci allowing writing them >> >> dn: cn=ranges,cn=etc,SUFFIX >> - ADD aci allowing reading ipaIDrange for authenticated users >> >> dn: cn=virtual operations,cn=etc,SUFFIX >> - ADD aci allowing reading/updating virtual operations, assign to RBAC privileges >> >> dn: cn=retrieve certificate,cn=virtual operations,cn=etc,SUFFIX >> dn: cn=request certificate,cn=virtual operations,cn=etc,SUFFIX >> dn: cn=request certificate different host,cn=virtual operations,SUFFIX >> dn: cn=certificate status,cn=virtual operations,cn=etc,SUFFIX >> dn: cn=revoke certificate,cn=virtual operations,cn=etc,SUFFIX >> dn: cn=certificate remove hold,cn=virtual operations,cn=etc,SUFFIX >> - no ACI needed >> >> dn: cn=Managed Entries,cn=etc,SUFFIX >> - no ACI needed, not managed by IPA users >> >> dn: cn=automember,cn=etc,SUFFIX >> - ADD standard automembers ACIs (read, write, delete, ...) >> >> dn: cn=CAcert,cn=ipa,cn=etc,SUFFIX >> - ADD aci allowing reading cACertificate for anonymous >> >> dn: cn=anonymous-limits,cn=etc,SUFFIX >> - no ACI needed, not managed by IPA users >> >> dn: cn=replication,cn=etc,SUFFIX >> - ADD aci allowing reading for authenticated users (used in ipa-replica-install) >> >> dn: cn=Realm Domains,cn=ipa,cn=etc,SUFFIX >> - no ACI needed, we already added read aci >> >> dn: cn=ad,cn=etc,SUFFIX >> - ADD aci allowing reading ipaNTDomainAttrs for authenticated users (trust >> settings) >> >> ========================================================================== >> >> That should be pretty much all. I know that devil hides in details, but I did >> not see any blocker to skip the chance to add proper ACIs also for cn=etc as >> well and thus remove the all allowing ACI at all (I am afraid that we would be >> stuck with cn=etc all-allowing ACI for years otherwise). >> >> Comments welcome. > > Agree with the general plan, let's start with this and add permissions > as needed. > > Simo. > > > -- Petr? From pviktori at redhat.com Wed Apr 16 11:02:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 13:02:11 +0200 Subject: [Freeipa-devel] [PATCH] 0527 Add managed read permission to idrange Message-ID: <534E6333.3090705@redhat.com> Read access is given to all authenticated users. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0527-Add-managed-read-permission-to-idrange.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 16 11:12:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 13:12:14 +0200 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <534E40CF.5020701@redhat.com> References: <534E3921.4000006@redhat.com> <534E3D5F.7000803@redhat.com> <534E40CF.5020701@redhat.com> Message-ID: <534E658E.7020004@redhat.com> On 04/16/2014 10:35 AM, Jan Cholasta wrote: > On 16.4.2014 10:20, Petr Viktorin wrote: >> On 04/16/2014 10:02 AM, Martin Kosek wrote: >>> I was looking into ticket >>> https://fedorahosted.org/freeipa/ticket/4054 >>> and experimenting with ACIs allowing privileged users to manage only >>> their own LDAP objects. >>> >>> As already proposed in the Bugzilla, I had success with following ACIs: >>> >>> ~~~~~~~~~~~~~~~~ >>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>> add: aci >>> aci: (targetattr = "userclass")(targetfilter = >>> "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own >>> hosts";allow (write) userattr = "creatorsName#USERDN";) >>> >>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>> >>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>> add: aci >>> aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl >>> "permission:Modify own hosts";allow (delete) userattr = >>> "creatorsName#USERDN";) >>> >>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>> ~~~~~~~~~~~~~~~~ >>> >>> When I then added a user fbar with permission "Add hosts", I was able to >>> do exactly what proposed in the ticket: >>> >>> >>> $ ipa host-add test.example.com --force >>> ----------------------------- >>> Added host "test.example.com" >>> ----------------------------- >>> Host name: test.example.com >>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >>> Password: False >>> Keytab: False >>> Managed by: test.example.com >>> >>> $ ipa host-mod test.example.com --class foo >>> -------------------------------- >>> Modified host "test.example.com" >>> -------------------------------- >>> Host name: test.example.com >>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >>> Class: foo >>> Password: False >>> Keytab: False >>> Managed by: test.example.com >>> >>> $ ipa host-mod admin.example.com --class foo >>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the >>> 'userClass' attribute of entry >>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>> >>> >>> >>> $ ipa host-del admin.example.com >>> ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to >>> delete the entry >>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>> >>> >>> >>> $ ipa host-del test.example.com >>> ------------------------------- >>> Deleted host "test.example.com" >>> ------------------------------- >>> >>> I think this could be pretty powerful also with other LDAP objects. >>> Question is what can be done to allow that to our users. >>> >>> I do not think we should add these ACIs by default as not everybody >>> would like them. But if we enhance our permission API to allow the >>> userattr bind rule, admins could add these ACIs at their wish. >>> >>> IMO the API is not that difficult, something like this could work: >>> >>> $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname >>> --bind-attr-type=USERDN >>> >>> --bind-attr could be more or less free form text to allow "creatorsname" >>> or "parent[0].creatorsname" >>> --bind-attr-type would be enum of values USERDN/GROUPDN >>> >>> This should cover most of the basic use cases. >>> >>> Thoughts? >>> >> >> Makes sense. I'd do it around the time we move self-service to permissions. >> >> Simo, can you reserve two more OIDs for the attributes? >> >> > > I don't think we need creatorsName, we already have managedBy. Or am I missing > something? > > Honza Currently, managedBy is our own attribute where we can put DNs of other host entries that can manage/edit the host. So you are right, you could partially solve this use case with managedBy. User adding a new host would, however, need to pre-fill managedBy with own DN so that it is acknowledged as host "manager". On the other side, creatorsName is an LDAP operational attribute filled automatically. So IMO it would fit the use case described in the ticket better. But as you see, there are different approaches to do that, which confirms my intent to only provide API for creating this type of permissions and let user create it himself. Martin From pspacek at redhat.com Wed Apr 16 11:13:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Apr 2014 13:13:18 +0200 Subject: [Freeipa-devel] [PATCH][DOC] Update Solaris Documentation, add proxy agent, and profile In-Reply-To: References: Message-ID: <534E65CE.8070504@redhat.com> On 16.4.2014 05:01, Gabe Alford wrote: > The following patches update the Solaris documentation and add a proxy > agent/profile for Solaris. > > - Solaris documentation update > https://fedorahosted.org/freeipa/ticket/3731 > > - Patch adds default Proxy Agent and default_secure profile through > 20-nss_ldap.update when ipa-server-install is run. > https://fedorahosted.org/freeipa/ticket/2561 Thank you Gabe! I think this chapter deserves review from a Solaris expert. Core IPA team doesn't have one so we need to find some victim ... :-) Sigbjorn, would you mind reviewing this patch set? Instructions how to build docs are here: http://www.freeipa.org/page/Contribute/Documentation Thank you very much! -- Petr^2 Spacek From mkosek at redhat.com Wed Apr 16 11:31:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 13:31:31 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <534E6085.3000002@redhat.com> References: <534BBE8A.6080101@redhat.com> <1397484037.19767.243.camel@willson.li.ssimo.org> <534E6085.3000002@redhat.com> Message-ID: <534E6A13.1070203@redhat.com> On 04/16/2014 12:50 PM, Petr Viktorin wrote: > On 04/14/2014 04:00 PM, Simo Sorce wrote: >> On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: >>> When heading for a lunch today, I had a discussion with Petr3 about ACIs for >>> cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will >>> simply allow all attributes in cn=etc for authenticated users and will just >>> exclude the blacklisted attributes (for context, see ticket #3566). >>> >>> I personally think it is not the best thing to do as it will just move the >>> problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It >>> would be better to add normal ACIs for cn=etc as well. >>> >>> I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it >>> seems straightforward what ACIs would be needed: >>> >>> ========================================================================== >>> dn: cn=etc,SUFFIX >>> - ADD aci allowing reading nsContainer for anonymous, EXCEPT: > > We can combine this with the general nsContainer read ACI. The problem is that > we can only have one target-based exclusion rule. Right. > >>> - cn=virtual operations,cn=etc,SUFFIX > > Could we use a special objectClass rather than nsContainer for these? We would need to invent one, like ipaVirtualOperation with one MUST attribute "cn" and then apply it to all virtual operations and replace nsContainer. It should not be a problem though as we do not provide API to handle the virtual operations. There are very static. Simo, Rob, would you be OK with changing virtual operation objectclass to our own one to have a better control over it? > >>> - cn=masters,cn=ipa,cn=etc,SUFFIX > > This is the one I'd exclude with the target rule. Ok. > >>> - cn=Managed Entries,cn=etc,SUFFIX > > Why exclude this one? Aren't the containers the same in all IPA installs? Hm, exclusion of this one is probably not needed. User would really only see the containers for Definitions and Templates, not the real configuration (NGP/UGP). >>> dn: cn=sysaccounts,cn=etc,SUFFIX >>> - ADD aci allowing reading all attributes but password attributes (people may >>> add unstructured accounts following different objectclasses) > > I'd rather list the attributes and let people add custom attributes themselves. Makes sense. Right now, we have 2 types of objects here: 1) system users: simpleSecurityObject objectclass 2) system groups: groupofnames objectclass We can make 2 ACIs, allowing those: - allow reading "uid, objectclass" of "simplesecurityobject" to authenticated users - allow reading "cn, member, objectclass" of "groupofnames" to authenticated users Martin From abokovoy at redhat.com Wed Apr 16 11:35:47 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Apr 2014 14:35:47 +0300 Subject: [Freeipa-devel] [PATCH][DOC] Fix NFS configuration documentation Message-ID: <20140416113547.GI20958@redhat.com> Hi, Attached patch attempts to improve NFS configuration section. Please review, if it is OK, I'll prepare patch to update the other parts as we have quite a duplication across the guide. https://fedorahosted.org/freeipa/ticket/4310 -- / Alexander Bokovoy -------------- next part -------------- >From 825d9b89dc127154c87333dd9f3bc7238fa56b07 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 16 Apr 2014 14:27:58 +0300 Subject: [PATCH] NFS: update instructions to use safe method to transfer the keytab --- src/user_guide/en-US/InstallingClients.xml | 56 ++++++++++++++++++------------ 1 file changed, 34 insertions(+), 22 deletions(-) diff --git a/src/user_guide/en-US/InstallingClients.xml b/src/user_guide/en-US/InstallingClients.xml index 1665a6c..f4795c3 100644 --- a/src/user_guide/en-US/InstallingClients.xml +++ b/src/user_guide/en-US/InstallingClients.xml @@ -413,6 +413,8 @@ $ getent group admins RPCSVCGSSDARGS="-vvv" + Kerberos authentication requires that both client and server participating in an exchange have own Kerberos principals. NFS servers are configured by default to use a Kerberos principal named nfs/server's host name. NFS client software constructs NFS server's Kerberos principal by prepending nfs/ to the server's hostname. The client's Kerberos principal is not that important; as long as KDC permits issuing a ticket towards nfs/server.example.com, the client's Kerberos principal can be used to perform the authentication. For example, an NFS client can connect using host/client.example.com principal or as a specific user. + When NFS server machine nfs.example.com is enrolled to &IPAA; domain as &IPAA; client, a service named nfs/nfs.example.com has to be created by &IPAA; administrator and the service key has to be extracted and stored on the NFS server. @@ -424,22 +426,44 @@ RPCSVCGSSDARGS="-vvv" On &IPAA; server, add an NFS service principal for the NFS client. -[root at server ~]# ipa service-add nfs/ipaclient.example.com at EXAMPLE +[root at server ~]# ipa service-add nfs/nfs.example.com at EXAMPLE NOTE - This must be run from a machine with the ipa-admintools package installed so that the ipa command is available. + This command must be run on a machine with the ipa-admintools package installed so that the ipa command is available. - + - On the &IPA; server, obtain a keytab for the NFS service principal. + Next we need to obtain a keytab for the NFS service principal. The keytab contains long term Kerberos key which uniquely authenticates nfs/nfs.example.com to the KDC. This key must be protected or otherwise anyone who has access to the key may impersonate the NFS server. Ideally, NFS server is &IPAA; client, thus it should already have ipa-getkeytab installed. - - -[root at server ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/ipaclient.example.com at EXAMPLE -k /tmp/krb5.keytab - + + + + If NFS server has ipa-getkeytab installed, it is safer to fetch the key directly from the NFS server. Given that &IPA;-enrolled machine owns all services associated with it, host/nfs.example.com principal may retrieve the NFS service keytab directly on the NFS server: + [root at nfs ~]# kinit -k host/`hostname` +[root at nfs ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/`hostname`@EXAMPLE -k /etc/krb5.keytab +[root at nfs ~]# kdestroy + + ipa-getkeytab utility makes sure to not overwrite other Kerberos keys in the keytab. + + + + + If ipa-getkeytab is not available on the NFS server, the keys can be fetched up on the &IPA; server and copied over to the NFS server: + [root at server ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/nfs.example.com at EXAMPLE -k /tmp/krb5.keytab +[root at server ~]# chmod 0600 /tmp/krb5.keytab +[root at server ~]# scp -p /tmp/krb5.keytab root at nfs.example.com:/tmp/krb5.keytab + ... switch over to the NFS server +[root at nfs ~]# ( echo rkt /tmp/krb5.keytab ; echo wkt /etc/krb5.keytab ) | ktutil +[root at nfs ~]# rm -f /tmp/krb5.keytab + + + It is recommended to use ktutil utility to transfer Kerberos keys between keytabs to avoid overwriting keys that are already placed in the keytab by other applications. For example, all &IPA; clients have their host/client.example.com keys stored in /etc/krb5.keytab file. Simple overwrite of the file will render SSH authentication to the client impossible as SSH server will not be able to authenticate to the KDC using host/client.example.com key. The same can be said about users and groups as SSSD on &IPA; clients is configured to authenticate with the help of the host key. + + + NOTE @@ -454,18 +478,6 @@ RPCSVCGSSDARGS="-vvv" - Copy the keytab from the &IPA; server to the NFS server. For example, if the &IPA; and NFS servers are on different machines: -[root at server ~]# scp /tmp/krb5.keytab root at nfs.example.com:/etc/krb5.keytab - - - - - Copy the keytab from the &IPA; server to the &IPA; client. For example: -[root at server ~]# scp /tmp/krb5.keytab root at client.example.com:/etc/krb5.keytab - - - - Configure the /etc/exports file on the NFS server. /ipashare gss/krb5p(rw,no_root_squash,subtree_check,fsid=0) @@ -476,7 +488,7 @@ RPCSVCGSSDARGS="-vvv" - Always specify the share as nfs_server:/ /mountpoint. + Always specify the share as nfs.example.com:/share /mountpoint, using fully-qualified domain name of the NFS server. @@ -486,7 +498,7 @@ RPCSVCGSSDARGS="-vvv" -[root at ipaclient ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ /mnt/ipashare +[root at ipaclient ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ipashare /mnt/ipashare -- 1.9.0 From abokovoy at redhat.com Wed Apr 16 11:43:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Apr 2014 14:43:40 +0300 Subject: [Freeipa-devel] [PATCH][DOC] Fix NFS configuration documentation In-Reply-To: <20140416113547.GI20958@redhat.com> References: <20140416113547.GI20958@redhat.com> Message-ID: <20140416114340.GK20958@redhat.com> On Wed, 16 Apr 2014, Alexander Bokovoy wrote: > Hi, > > Attached patch attempts to improve NFS configuration section. > Please review, if it is OK, I'll prepare patch to update the other parts > as we have quite a duplication across the guide. > > https://fedorahosted.org/freeipa/ticket/4310 To ease the review, I've made compiled version available at http://abbra.fedorapeople.org/.todo/freeipa-docs/#set_up_nfs_with_kerberos Section 3.4.1 is the part about NFS setup. -- / Alexander Bokovoy From mkosek at redhat.com Wed Apr 16 11:57:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 13:57:52 +0200 Subject: [Freeipa-devel] kadmin is unresponsive in FreeIPA installation In-Reply-To: <20140416080939.GH20958@redhat.com> References: <534E31E4.3090009@redhat.com> <20140416080939.GH20958@redhat.com> Message-ID: <534E7040.6050703@redhat.com> On 04/16/2014 10:09 AM, Alexander Bokovoy wrote: > On Wed, 16 Apr 2014, Martin Kosek wrote: >> Did anyone hit https://bugzilla.redhat.com/show_bug.cgi?id=1088163 or is it >> something specific to my environment? > I've seen this before several times but couldn't reproduce at all. > Latest change to ipa_kdb_passwords.c where the code that does handle the > password change was done over a year ago (Jan 2013). > > Perhaps you can use gdb and break in ipadb_change_pwd()? In the end I strace'd the kadmin and found out this is related to entropy (again) - kadmind was not really started even though it claimed to be and it was blocked reading /dev/random. I added details to the Bugzilla. Martin From pviktori at redhat.com Wed Apr 16 12:14:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 14:14:57 +0200 Subject: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount Message-ID: <534E7441.6020205@redhat.com> A single permission granting anonymous read access covers automountlocation, automountmap, and automountkey. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0528-Add-managed-read-permissions-to-automount.patch Type: text/x-patch Size: 1561 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 16 12:39:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 14:39:43 +0200 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> <534442FA.1060709@redhat.com> <5345EC92.3010008@redhat.com> Message-ID: <534E7A0F.3020200@redhat.com> On 04/16/2014 09:56 AM, Justin Brown wrote: ... > L: This is interesting, and I have a couple of questions on how this > should work. > > 1) Is there an actual use-case when a tool actually would want to > check status of a port without correcting it? It seems to me that any > sort of is_port_open() call that returned False would be immediately > followed by open_port(). If that's the case, then why not just roll > them into one operation? There won't be any firewall reload if no > modifications take place, so there's no cost to combining them. We > could also find a middle ground where there's only one method with a > default parameter open_port(..., auto_add=True). I can imagine situations when we would want to see if a port is open in a firewall and then ask user if he wants to automatically open it. In such cases, 2 separate calls would be indeed helpful. > 2) Will these tools be executed as root? To query NM and FirewallD, I > have to connect to the system bus, which by default, won't allow > access from other users without additional authorization. If > non-privileged users need to query the firewall configuration, I'll > need to look at the DBus policy more closely. In situations when we are about to manipulate ports, I think it is safe to assume we are operating under root account. I think you can have this assumption in your current code and do not deal with additional authorization at this point. We can think about this case when we need it. > > 3) Could you point me at a similar tool that has this check and modify > behavior? There are many situations in FreeIPA interactive wizards where we have a pattern do_action = check_something() if do_action: do_something() For example, ipa-adtrust-install is checking if there are any users without SID assigned and if there are, it offers to run a task to add them. Martin From ssorce at redhat.com Wed Apr 16 12:42:18 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 08:42:18 -0400 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <534E3921.4000006@redhat.com> References: <534E3921.4000006@redhat.com> Message-ID: <1397652138.19767.375.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 10:02 +0200, Martin Kosek wrote: > I was looking into ticket > https://fedorahosted.org/freeipa/ticket/4054 > and experimenting with ACIs allowing privileged users to manage only their own > LDAP objects. > > As already proposed in the Bugzilla, I had success with following ACIs: > > ~~~~~~~~~~~~~~~~ > # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > add: aci > aci: (targetattr = "userclass")(targetfilter = "(objectclass=ipahost)")(version > 3.0;acl "permission:Modify own hosts";allow (write) userattr = > "creatorsName#USERDN";) > > modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > > # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > add: aci > aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl > "permission:Modify own hosts";allow (delete) userattr = "creatorsName#USERDN";) > > modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > ~~~~~~~~~~~~~~~~ > > When I then added a user fbar with permission "Add hosts", I was able to do > exactly what proposed in the ticket: > > > $ ipa host-add test.example.com --force > ----------------------------- > Added host "test.example.com" > ----------------------------- > Host name: test.example.com > Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > Password: False > Keytab: False > Managed by: test.example.com > > $ ipa host-mod test.example.com --class foo > -------------------------------- > Modified host "test.example.com" > -------------------------------- > Host name: test.example.com > Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > Class: foo > Password: False > Keytab: False > Managed by: test.example.com > > $ ipa host-mod admin.example.com --class foo > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > 'userClass' attribute of entry > 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > > $ ipa host-del admin.example.com > ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to delete the > entry 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > > $ ipa host-del test.example.com > ------------------------------- > Deleted host "test.example.com" > ------------------------------- > > I think this could be pretty powerful also with other LDAP objects. Question is > what can be done to allow that to our users. > > I do not think we should add these ACIs by default as not everybody would like > them. But if we enhance our permission API to allow the userattr bind rule, > admins could add these ACIs at their wish. > > IMO the API is not that difficult, something like this could work: > > $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname > --bind-attr-type=USERDN > > --bind-attr could be more or less free form text to allow "creatorsname" or > "parent[0].creatorsname" > --bind-attr-type would be enum of values USERDN/GROUPDN > > This should cover most of the basic use cases. > > Thoughts? Creatorsname is inflexible as you cannot change it, we should probably have a way to add a role/group attribute at add time that would bind the object to specific roles/groups of users, but beyond this details it looks pretty powerful. One issue is how you still limit access to some attributes that you may not want to allow the creator to set or change, for example ipaUniqueId or similar things, that should always be under control of the system. Simo. From ssorce at redhat.com Wed Apr 16 12:45:33 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 08:45:33 -0400 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <534E3D5F.7000803@redhat.com> References: <534E3921.4000006@redhat.com> <534E3D5F.7000803@redhat.com> Message-ID: <1397652333.19767.377.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: > On 04/16/2014 10:02 AM, Martin Kosek wrote: > > I was looking into ticket > > https://fedorahosted.org/freeipa/ticket/4054 > > and experimenting with ACIs allowing privileged users to manage only > > their own LDAP objects. > > > > As already proposed in the Bugzilla, I had success with following ACIs: > > > > ~~~~~~~~~~~~~~~~ > > # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > > dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > > add: aci > > aci: (targetattr = "userclass")(targetfilter = > > "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own > > hosts";allow (write) userattr = "creatorsName#USERDN";) > > > > modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > > > > # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > > dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > > add: aci > > aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl > > "permission:Modify own hosts";allow (delete) userattr = > > "creatorsName#USERDN";) > > > > modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > > ~~~~~~~~~~~~~~~~ > > > > When I then added a user fbar with permission "Add hosts", I was able to > > do exactly what proposed in the ticket: > > > > > > $ ipa host-add test.example.com --force > > ----------------------------- > > Added host "test.example.com" > > ----------------------------- > > Host name: test.example.com > > Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > > Password: False > > Keytab: False > > Managed by: test.example.com > > > > $ ipa host-mod test.example.com --class foo > > -------------------------------- > > Modified host "test.example.com" > > -------------------------------- > > Host name: test.example.com > > Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > > Class: foo > > Password: False > > Keytab: False > > Managed by: test.example.com > > > > $ ipa host-mod admin.example.com --class foo > > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > > 'userClass' attribute of entry > > 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > > > > > > $ ipa host-del admin.example.com > > ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to > > delete the entry > > 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > > > > > > $ ipa host-del test.example.com > > ------------------------------- > > Deleted host "test.example.com" > > ------------------------------- > > > > I think this could be pretty powerful also with other LDAP objects. > > Question is what can be done to allow that to our users. > > > > I do not think we should add these ACIs by default as not everybody > > would like them. But if we enhance our permission API to allow the > > userattr bind rule, admins could add these ACIs at their wish. > > > > IMO the API is not that difficult, something like this could work: > > > > $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname > > --bind-attr-type=USERDN > > > > --bind-attr could be more or less free form text to allow "creatorsname" > > or "parent[0].creatorsname" > > --bind-attr-type would be enum of values USERDN/GROUPDN > > > > This should cover most of the basic use cases. > > > > Thoughts? > > > > Makes sense. I'd do it around the time we move self-service to permissions. > > Simo, can you reserve two more OIDs for the attributes? What attributes ? userclass ? Can't we simply use a group/role ? From ssorce at redhat.com Wed Apr 16 12:47:36 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 08:47:36 -0400 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <534E658E.7020004@redhat.com> References: <534E3921.4000006@redhat.com> <534E3D5F.7000803@redhat.com> <534E40CF.5020701@redhat.com> <534E658E.7020004@redhat.com> Message-ID: <1397652456.19767.378.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 13:12 +0200, Martin Kosek wrote: > On 04/16/2014 10:35 AM, Jan Cholasta wrote: > > On 16.4.2014 10:20, Petr Viktorin wrote: > >> On 04/16/2014 10:02 AM, Martin Kosek wrote: > >>> I was looking into ticket > >>> https://fedorahosted.org/freeipa/ticket/4054 > >>> and experimenting with ACIs allowing privileged users to manage only > >>> their own LDAP objects. > >>> > >>> As already proposed in the Bugzilla, I had success with following ACIs: > >>> > >>> ~~~~~~~~~~~~~~~~ > >>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > >>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > >>> add: aci > >>> aci: (targetattr = "userclass")(targetfilter = > >>> "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own > >>> hosts";allow (write) userattr = "creatorsName#USERDN";) > >>> > >>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > >>> > >>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > >>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > >>> add: aci > >>> aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl > >>> "permission:Modify own hosts";allow (delete) userattr = > >>> "creatorsName#USERDN";) > >>> > >>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > >>> ~~~~~~~~~~~~~~~~ > >>> > >>> When I then added a user fbar with permission "Add hosts", I was able to > >>> do exactly what proposed in the ticket: > >>> > >>> > >>> $ ipa host-add test.example.com --force > >>> ----------------------------- > >>> Added host "test.example.com" > >>> ----------------------------- > >>> Host name: test.example.com > >>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > >>> Password: False > >>> Keytab: False > >>> Managed by: test.example.com > >>> > >>> $ ipa host-mod test.example.com --class foo > >>> -------------------------------- > >>> Modified host "test.example.com" > >>> -------------------------------- > >>> Host name: test.example.com > >>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > >>> Class: foo > >>> Password: False > >>> Keytab: False > >>> Managed by: test.example.com > >>> > >>> $ ipa host-mod admin.example.com --class foo > >>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > >>> 'userClass' attribute of entry > >>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > >>> > >>> > >>> > >>> $ ipa host-del admin.example.com > >>> ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to > >>> delete the entry > >>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > >>> > >>> > >>> > >>> $ ipa host-del test.example.com > >>> ------------------------------- > >>> Deleted host "test.example.com" > >>> ------------------------------- > >>> > >>> I think this could be pretty powerful also with other LDAP objects. > >>> Question is what can be done to allow that to our users. > >>> > >>> I do not think we should add these ACIs by default as not everybody > >>> would like them. But if we enhance our permission API to allow the > >>> userattr bind rule, admins could add these ACIs at their wish. > >>> > >>> IMO the API is not that difficult, something like this could work: > >>> > >>> $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname > >>> --bind-attr-type=USERDN > >>> > >>> --bind-attr could be more or less free form text to allow "creatorsname" > >>> or "parent[0].creatorsname" > >>> --bind-attr-type would be enum of values USERDN/GROUPDN > >>> > >>> This should cover most of the basic use cases. > >>> > >>> Thoughts? > >>> > >> > >> Makes sense. I'd do it around the time we move self-service to permissions. > >> > >> Simo, can you reserve two more OIDs for the attributes? > >> > >> > > > > I don't think we need creatorsName, we already have managedBy. Or am I missing > > something? > > > > Honza > > Currently, managedBy is our own attribute where we can put DNs of other host > entries that can manage/edit the host. So you are right, you could partially > solve this use case with managedBy. > > User adding a new host would, however, need to pre-fill managedBy with own DN > so that it is acknowledged as host "manager". On the other side, creatorsName > is an LDAP operational attribute filled automatically. So IMO it would fit the > use case described in the ticket better. > > But as you see, there are different approaches to do that, which confirms my > intent to only provide API for creating this type of permissions and let user > create it himself. Agreed. Simo. From pviktori at redhat.com Wed Apr 16 12:49:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 14:49:26 +0200 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <1397652333.19767.377.camel@willson.li.ssimo.org> References: <534E3921.4000006@redhat.com> <534E3D5F.7000803@redhat.com> <1397652333.19767.377.camel@willson.li.ssimo.org> Message-ID: <534E7C56.8000708@redhat.com> On 04/16/2014 02:45 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: >> On 04/16/2014 10:02 AM, Martin Kosek wrote: >>> I was looking into ticket >>> https://fedorahosted.org/freeipa/ticket/4054 >>> and experimenting with ACIs allowing privileged users to manage only >>> their own LDAP objects. >>> >>> As already proposed in the Bugzilla, I had success with following ACIs: >>> >>> ~~~~~~~~~~~~~~~~ >>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>> add: aci >>> aci: (targetattr = "userclass")(targetfilter = >>> "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own >>> hosts";allow (write) userattr = "creatorsName#USERDN";) >>> >>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>> >>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>> add: aci >>> aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl >>> "permission:Modify own hosts";allow (delete) userattr = >>> "creatorsName#USERDN";) >>> >>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>> ~~~~~~~~~~~~~~~~ >>> >>> When I then added a user fbar with permission "Add hosts", I was able to >>> do exactly what proposed in the ticket: >>> >>> >>> $ ipa host-add test.example.com --force >>> ----------------------------- >>> Added host "test.example.com" >>> ----------------------------- >>> Host name: test.example.com >>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >>> Password: False >>> Keytab: False >>> Managed by: test.example.com >>> >>> $ ipa host-mod test.example.com --class foo >>> -------------------------------- >>> Modified host "test.example.com" >>> -------------------------------- >>> Host name: test.example.com >>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >>> Class: foo >>> Password: False >>> Keytab: False >>> Managed by: test.example.com >>> >>> $ ipa host-mod admin.example.com --class foo >>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the >>> 'userClass' attribute of entry >>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>> >>> >>> $ ipa host-del admin.example.com >>> ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to >>> delete the entry >>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>> >>> >>> $ ipa host-del test.example.com >>> ------------------------------- >>> Deleted host "test.example.com" >>> ------------------------------- >>> >>> I think this could be pretty powerful also with other LDAP objects. >>> Question is what can be done to allow that to our users. >>> >>> I do not think we should add these ACIs by default as not everybody >>> would like them. But if we enhance our permission API to allow the >>> userattr bind rule, admins could add these ACIs at their wish. >>> >>> IMO the API is not that difficult, something like this could work: >>> >>> $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname >>> --bind-attr-type=USERDN >>> >>> --bind-attr could be more or less free form text to allow "creatorsname" >>> or "parent[0].creatorsname" >>> --bind-attr-type would be enum of values USERDN/GROUPDN >>> >>> This should cover most of the basic use cases. >>> >>> Thoughts? >>> >> >> Makes sense. I'd do it around the time we move self-service to permissions. >> >> Simo, can you reserve two more OIDs for the attributes? > > What attributes ? userclass ? Can't we simply use a group/role ? The --bind-attr and --bind-attr-type values will need to be stored in the permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType. -- Petr? From pviktori at redhat.com Wed Apr 16 12:55:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 14:55:43 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts Message-ID: <534E7DCF.9080205@redhat.com> Similarly to automount, a single permission is added for reading all the trust objects. Read access is given to all authenticated users. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0529-Add-managed-read-permissions-to-trust.patch Type: text/x-patch Size: 2130 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 16 12:55:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 14:55:44 +0200 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <534E7C56.8000708@redhat.com> References: <534E3921.4000006@redhat.com> <534E3D5F.7000803@redhat.com> <1397652333.19767.377.camel@willson.li.ssimo.org> <534E7C56.8000708@redhat.com> Message-ID: <534E7DD0.90804@redhat.com> On 04/16/2014 02:49 PM, Petr Viktorin wrote: > On 04/16/2014 02:45 PM, Simo Sorce wrote: >> On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: >>> On 04/16/2014 10:02 AM, Martin Kosek wrote: >>>> I was looking into ticket >>>> https://fedorahosted.org/freeipa/ticket/4054 >>>> and experimenting with ACIs allowing privileged users to manage only >>>> their own LDAP objects. >>>> >>>> As already proposed in the Bugzilla, I had success with following ACIs: >>>> >>>> ~~~~~~~~~~~~~~~~ >>>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>>> add: aci >>>> aci: (targetattr = "userclass")(targetfilter = >>>> "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own >>>> hosts";allow (write) userattr = "creatorsName#USERDN";) >>>> >>>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>>> >>>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>>> add: aci >>>> aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl >>>> "permission:Modify own hosts";allow (delete) userattr = >>>> "creatorsName#USERDN";) >>>> >>>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>>> ~~~~~~~~~~~~~~~~ >>>> >>>> When I then added a user fbar with permission "Add hosts", I was able to >>>> do exactly what proposed in the ticket: >>>> >>>> >>>> $ ipa host-add test.example.com --force >>>> ----------------------------- >>>> Added host "test.example.com" >>>> ----------------------------- >>>> Host name: test.example.com >>>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >>>> Password: False >>>> Keytab: False >>>> Managed by: test.example.com >>>> >>>> $ ipa host-mod test.example.com --class foo >>>> -------------------------------- >>>> Modified host "test.example.com" >>>> -------------------------------- >>>> Host name: test.example.com >>>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST >>>> Class: foo >>>> Password: False >>>> Keytab: False >>>> Managed by: test.example.com >>>> >>>> $ ipa host-mod admin.example.com --class foo >>>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the >>>> 'userClass' attribute of entry >>>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>>> >>>> >>>> $ ipa host-del admin.example.com >>>> ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to >>>> delete the entry >>>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>>> >>>> >>>> $ ipa host-del test.example.com >>>> ------------------------------- >>>> Deleted host "test.example.com" >>>> ------------------------------- >>>> >>>> I think this could be pretty powerful also with other LDAP objects. >>>> Question is what can be done to allow that to our users. >>>> >>>> I do not think we should add these ACIs by default as not everybody >>>> would like them. But if we enhance our permission API to allow the >>>> userattr bind rule, admins could add these ACIs at their wish. >>>> >>>> IMO the API is not that difficult, something like this could work: >>>> >>>> $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname >>>> --bind-attr-type=USERDN >>>> >>>> --bind-attr could be more or less free form text to allow "creatorsname" >>>> or "parent[0].creatorsname" >>>> --bind-attr-type would be enum of values USERDN/GROUPDN >>>> >>>> This should cover most of the basic use cases. >>>> >>>> Thoughts? >>>> >>> >>> Makes sense. I'd do it around the time we move self-service to permissions. >>> >>> Simo, can you reserve two more OIDs for the attributes? >> >> What attributes ? userclass ? Can't we simply use a group/role ? > > The --bind-attr and --bind-attr-type values will need to be stored in the > permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType. I would personally wait with reserving OID until we create a design of this feature as there are several approaches. We could for example need one more attribute, ipaPermBindAttrDepth we would use for control of the ACI effective depth (mutli valued, values 0-4). Martin From ssorce at redhat.com Wed Apr 16 12:55:45 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 08:55:45 -0400 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <534E6A13.1070203@redhat.com> References: <534BBE8A.6080101@redhat.com> <1397484037.19767.243.camel@willson.li.ssimo.org> <534E6085.3000002@redhat.com> <534E6A13.1070203@redhat.com> Message-ID: <1397652945.19767.384.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 13:31 +0200, Martin Kosek wrote: > On 04/16/2014 12:50 PM, Petr Viktorin wrote: > > On 04/14/2014 04:00 PM, Simo Sorce wrote: > >> On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: > >>> When heading for a lunch today, I had a discussion with Petr3 about ACIs for > >>> cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will > >>> simply allow all attributes in cn=etc for authenticated users and will just > >>> exclude the blacklisted attributes (for context, see ticket #3566). > >>> > >>> I personally think it is not the best thing to do as it will just move the > >>> problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It > >>> would be better to add normal ACIs for cn=etc as well. > >>> > >>> I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it > >>> seems straightforward what ACIs would be needed: > >>> > >>> ========================================================================== > >>> dn: cn=etc,SUFFIX > >>> - ADD aci allowing reading nsContainer for anonymous, EXCEPT: > > > > We can combine this with the general nsContainer read ACI. The problem is that > > we can only have one target-based exclusion rule. > > Right. > > > > >>> - cn=virtual operations,cn=etc,SUFFIX > > > > Could we use a special objectClass rather than nsContainer for these? > > We would need to invent one, like ipaVirtualOperation with one MUST attribute > "cn" and then apply it to all virtual operations and replace nsContainer. It > should not be a problem though as we do not provide API to handle the virtual > operations. There are very static. > > Simo, Rob, would you be OK with changing virtual operation objectclass to our > own one to have a better control over it? No, in general I am not ok to change objects that already exist in IPA as it make upgrades with new and old replicas break the old replicas. Also we can add new auxiliray classes but removing structural classes is not possible, you would have to delete and recreate the object, and that would be racy too. > > > >>> - cn=masters,cn=ipa,cn=etc,SUFFIX > > > > This is the one I'd exclude with the target rule. > > Ok. > > > > >>> - cn=Managed Entries,cn=etc,SUFFIX > > > > Why exclude this one? Aren't the containers the same in all IPA installs? > > Hm, exclusion of this one is probably not needed. User would really only see > the containers for Definitions and Templates, not the real configuration (NGP/UGP). > > >>> dn: cn=sysaccounts,cn=etc,SUFFIX > >>> - ADD aci allowing reading all attributes but password attributes (people may > >>> add unstructured accounts following different objectclasses) > > > > I'd rather list the attributes and let people add custom attributes themselves. > > Makes sense. Right now, we have 2 types of objects here: > > 1) system users: simpleSecurityObject objectclass > 2) system groups: groupofnames objectclass > > We can make 2 ACIs, allowing those: > > - allow reading "uid, objectclass" of "simplesecurityobject" to authenticated users > - allow reading "cn, member, objectclass" of "groupofnames" to authenticated users Yeah we do not need fancy stuff, and we are planning (since forever ?) to give a command to create these entities, so eventually the format will be clear. Simo. From pviktori at redhat.com Wed Apr 16 13:00:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Apr 2014 15:00:27 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <1397652945.19767.384.camel@willson.li.ssimo.org> References: <534BBE8A.6080101@redhat.com> <1397484037.19767.243.camel@willson.li.ssimo.org> <534E6085.3000002@redhat.com> <534E6A13.1070203@redhat.com> <1397652945.19767.384.camel@willson.li.ssimo.org> Message-ID: <534E7EEB.5080903@redhat.com> On 04/16/2014 02:55 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 13:31 +0200, Martin Kosek wrote: >> On 04/16/2014 12:50 PM, Petr Viktorin wrote: >>> On 04/14/2014 04:00 PM, Simo Sorce wrote: >>>> On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: >>>>> When heading for a lunch today, I had a discussion with Petr3 about ACIs for >>>>> cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will >>>>> simply allow all attributes in cn=etc for authenticated users and will just >>>>> exclude the blacklisted attributes (for context, see ticket #3566). >>>>> >>>>> I personally think it is not the best thing to do as it will just move the >>>>> problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It >>>>> would be better to add normal ACIs for cn=etc as well. >>>>> >>>>> I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it >>>>> seems straightforward what ACIs would be needed: >>>>> >>>>> ========================================================================== >>>>> dn: cn=etc,SUFFIX >>>>> - ADD aci allowing reading nsContainer for anonymous, EXCEPT: >>> >>> We can combine this with the general nsContainer read ACI. The problem is that >>> we can only have one target-based exclusion rule. >> >> Right. >> >>> >>>>> - cn=virtual operations,cn=etc,SUFFIX >>> >>> Could we use a special objectClass rather than nsContainer for these? >> >> We would need to invent one, like ipaVirtualOperation with one MUST attribute >> "cn" and then apply it to all virtual operations and replace nsContainer. It >> should not be a problem though as we do not provide API to handle the virtual >> operations. There are very static. >> >> Simo, Rob, would you be OK with changing virtual operation objectclass to our >> own one to have a better control over it? > > No, in general I am not ok to change objects that already exist in IPA > as it make upgrades with new and old replicas break the old replicas. > > Also we can add new auxiliray classes but removing structural classes is > not possible, you would have to delete and recreate the object, and that > would be racy too. I see. How about adding a new objectClass in addition to nsContainer, and using a negative targetfilter? >>>>> - cn=masters,cn=ipa,cn=etc,SUFFIX >>> >>> This is the one I'd exclude with the target rule. >> >> Ok. >> >>> >>>>> - cn=Managed Entries,cn=etc,SUFFIX >>> >>> Why exclude this one? Aren't the containers the same in all IPA installs? >> >> Hm, exclusion of this one is probably not needed. User would really only see >> the containers for Definitions and Templates, not the real configuration (NGP/UGP). >> >>>>> dn: cn=sysaccounts,cn=etc,SUFFIX >>>>> - ADD aci allowing reading all attributes but password attributes (people may >>>>> add unstructured accounts following different objectclasses) >>> >>> I'd rather list the attributes and let people add custom attributes themselves. >> >> Makes sense. Right now, we have 2 types of objects here: >> >> 1) system users: simpleSecurityObject objectclass >> 2) system groups: groupofnames objectclass >> >> We can make 2 ACIs, allowing those: >> >> - allow reading "uid, objectclass" of "simplesecurityobject" to authenticated users >> - allow reading "cn, member, objectclass" of "groupofnames" to authenticated users > > Yeah we do not need fancy stuff, and we are planning (since forever ?) > to give a command to create these entities, so eventually the format > will be clear. > > Simo. > -- Petr? From ssorce at redhat.com Wed Apr 16 13:01:15 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 09:01:15 -0400 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <534E7DCF.9080205@redhat.com> References: <534E7DCF.9080205@redhat.com> Message-ID: <1397653275.19767.386.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 14:55 +0200, Petr Viktorin wrote: > Similarly to automount, a single permission is added for reading all > the > trust objects. > Read access is given to all authenticated users. NACK!! See inline > From a499784cbea2f1282a07629a94e67e14c14a35d0 Mon Sep 17 00:00:00 2001 > From: Petr Viktorin > Date: Wed, 26 Mar 2014 17:11:23 +0100 > Subject: [PATCH] Add managed read permissions to trust > > A single permission is added to cover trust, trustconfig, and > trustdomain. > > Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 > --- > ipalib/plugins/trust.py | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py > index > f57cf7d891928903fdbee67697b96db4ad2679b7..df69bb82d9c545839f2962d6a1a961f89e6691d3 100644 > --- a/ipalib/plugins/trust.py > +++ b/ipalib/plugins/trust.py > @@ -312,6 +312,29 @@ class trust(LDAPObject): > search_display_attributes = ['cn', 'ipantflatname', > 'ipanttrusteddomainsid', > 'ipanttrusttype', > 'ipantsidblacklistincoming', > 'ipantsidblacklistoutgoing' ] > + managed_permissions = { > + 'System: Read Trusts': { > + # Single read permission for all trust-related entries > + 'non_object': True, > + 'ipapermlocation': DN(container_dn, api.env.basedn), > + 'replaces_global_anonymous_aci': True, > + 'ipapermbindruletype': 'all', > + 'ipapermright': {'read', 'search', 'compare'}, > + 'ipapermdefaultattr': { > + 'cn', 'objectclass', > + # ipaNTTrustedDomain: > + 'ipanttrusttype', 'ipanttrustattributes', > + 'ipanttrustdirection', 'ipanttrustpartner', > 'ipantflatname', > + 'ipanttrustauthoutgoing', 'ipanttrustauthincoming', These 2 attributes here ^^^^ They contain trust credentials, certainly must not be readbale by any authenticated user except the trust agents. > + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', > + 'ipanttrustposixoffset', > 'ipantsupportedencryptiontypes', > + 'ipantsidblacklistincoming', > 'ipantsidblacklistoutgoing', > + # ipaNTDomainAttrs: > + 'ipantsecurityidentifier', 'ipantflatname', > 'ipantdomainguid', > + 'ipantfallbackprimarygroup', > + }, > + }, > + } > > label = _('Trusts') > label_singular = _('Trust') In general I am not sure all authenticated users need access to all this info. Alexander ? Simo. From ssorce at redhat.com Wed Apr 16 13:04:43 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 09:04:43 -0400 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <534E7EEB.5080903@redhat.com> References: <534BBE8A.6080101@redhat.com> <1397484037.19767.243.camel@willson.li.ssimo.org> <534E6085.3000002@redhat.com> <534E6A13.1070203@redhat.com> <1397652945.19767.384.camel@willson.li.ssimo.org> <534E7EEB.5080903@redhat.com> Message-ID: <1397653483.19767.389.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 15:00 +0200, Petr Viktorin wrote: > >> Simo, Rob, would you be OK with changing virtual operation > objectclass to our > >> own one to have a better control over it? > > > > No, in general I am not ok to change objects that already exist in > IPA > > as it make upgrades with new and old replicas break the old > replicas. > > > > Also we can add new auxiliray classes but removing structural > classes is > > not possible, you would have to delete and recreate the object, and > that > > would be racy too. > > I see. > How about adding a new objectClass in addition to nsContainer, and > using > a negative targetfilter? > I have no objection to that, but should be last resort if we have no other way IMO, and valid only for objects that are not normally created on a daily basis, as old replicas creating new objects would not know to add the new objectclass. In this case it seem like we should be ok as we do not commonly create these objects, so the chances an old replica creates them are negligible. Simo. From amisnyov at redhat.com Wed Apr 16 13:05:43 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 16 Apr 2014 15:05:43 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 13 - Log pretty-printed request and response Message-ID: <20140416150543.0434eb32@unused-4-246.brq.redhat.com> Hi, this patch enables logging json dumps of request and response, using the --log-payload switch in ipa cli. RFC tag is to ensure that I handled the --log-payload switch correctly in ipa cli. Be careful, it only logs, so --log-payload without -v switch doesn't make the dump visible in command line, -v does! https://fedorahosted.org/freeipa/ticket/4233 Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0013-Log-pretty-printed-request-and-response.patch Type: text/x-patch Size: 4519 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 16 13:08:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 15:08:28 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <534D4852.2000405@redhat.com> References: <534D4852.2000405@redhat.com> Message-ID: <534E80CC.8060901@redhat.com> On 04/15/2014 04:55 PM, Petr Viktorin wrote: > Hello, > At Devconf, we decided what most of the default read permissions should look > like, but we did not get to user. > Here is a draft of 4 read permissions. Please comment. > > > Basic info (anonymous): > [top] > objectclass > [person] > cn, sn, description > [organizationalPerson] > title > [inetOrgPerson] > uid > displayName, givenName, initials > manager > [inetUser] > memberOf <== We originally specifically hidden memberOf attribute from anonymous users. I think we should continue hiding it. > [ipaObject] > ipaUniqueID > [ipaSshUser] > ipaSshPubKey > [ipaUserAuthTypeClass] > ipaUserAuthType > [posixAccount] > gecos, gidNumber, homeDirectory, loginShell, uidNumber > > > Details (all authenticated): > [person] > seeAlso, telephoneNumber > [organizationalPerson] > fax, l, ou, st, postalCode, street > destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName, > postalAddress, postOfficeBox, preferredDeliveryMethod, > registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address > [inetOrgPerson] > carLicense, departmentNumber, employeeNumber, employeeType, > preferredLanguage, mail, mobile, pager > audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, > labeledURI, o, photo, roomNumber, secretary, userCertificate, > userPKCS12, userSMIMECertificate, x500UniqueIdentifier > [inetUser] > inetUserHttpURL, inetUserStatus > [ipaUser] > userClass I would personally not divide the attributes as basic and detailed. IMO it is our artificial distinction and may vary between deployments. Why would we for example show inetUserHttpURL to authenticated only and ipaSshPublicKey to everyone? My proposal would be to have a permission "Read User Information" for all attributes above. > Kerberos/login-related (all authenticated): > [krbPrincipalAux] > krbPrincipalName, krbCanonicalName, krbPrincipalAliases, > krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange > [+] > nsAccountLock Ok. So permission "Read User Kerberos Attributes"? > > > Kerberos-related (user admins only): > [krbPrincipalAux] > krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange So permission "Read User Kerberos Login Attributes"? I think this group should also have: krbLastAdminUnlock krbLoginFailedCount > No read permission: > [person] > userPassword ok > [krbPrincipalAux] > krbPrincipalKey, krbExtraData, krbPwdHistory ok > krbLastAdminUnlock, Move this one. > krbLoginFailedCount Move this one. > krbPrincipalType Simo? I know we do not user this attribute, but wouldn't it fit in "Read User Kerberos Attributes" permission? > krbPwdPolicyReference This could contain DN to user's password policy attribute. IMO somebody should have a right to read it. Simo, should all authenticated users be able to read it? > krbTicketPolicyReference, krbUPEnabled I would treat those the same as krbPwdPolicyReference. > [krbTicketPolicyAux] > krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags Ok. This will be readable by people with "System: Read User Kerberos Ticket Policy" permission. > [mepOriginEntry] > mepManagedEntry This is used to bind user to it's private group. We use it for example in group-detach command to distinguish between managed and non-managed groups. We may want to show it to all authenticated users. Martin From abokovoy at redhat.com Wed Apr 16 13:15:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Apr 2014 16:15:29 +0300 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <1397653275.19767.386.camel@willson.li.ssimo.org> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> Message-ID: <20140416131529.GL20958@redhat.com> On Wed, 16 Apr 2014, Simo Sorce wrote: >> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', >> + 'ipanttrustposixoffset', >> 'ipantsupportedencryptiontypes', >> + 'ipantsidblacklistincoming', >> 'ipantsidblacklistoutgoing', >> + # ipaNTDomainAttrs: >> + 'ipantsecurityidentifier', 'ipantflatname', >> 'ipantdomainguid', >> + 'ipantfallbackprimarygroup', >> + }, >> + }, >> + } >> >> label = _('Trusts') >> label_singular = _('Trust') > >In general I am not sure all authenticated users need access to all this >info. Alexander ? SSSD needs to read some of this information for subdomains support. That would be at least host/*@REALM who needs to access it. -- / Alexander Bokovoy From simo at redhat.com Wed Apr 16 13:41:32 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 09:41:32 -0400 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <534E80CC.8060901@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> Message-ID: <1397655692.19767.394.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: > On 04/15/2014 04:55 PM, Petr Viktorin wrote: > > Hello, > > At Devconf, we decided what most of the default read permissions should look > > like, but we did not get to user. > > Here is a draft of 4 read permissions. Please comment. > > > > > > Basic info (anonymous): > > [top] > > objectclass > > [person] > > cn, sn, description > > [organizationalPerson] > > title > > [inetOrgPerson] > > uid > > displayName, givenName, initials > > manager > > [inetUser] > > memberOf > > <== We originally specifically hidden memberOf attribute from anonymous users. > I think we should continue hiding it. > > > [ipaObject] > > ipaUniqueID > > [ipaSshUser] > > ipaSshPubKey > > [ipaUserAuthTypeClass] > > ipaUserAuthType > > [posixAccount] > > gecos, gidNumber, homeDirectory, loginShell, uidNumber > > > > > > Details (all authenticated): > > [person] > > seeAlso, telephoneNumber > > [organizationalPerson] > > fax, l, ou, st, postalCode, street > > destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName, > > postalAddress, postOfficeBox, preferredDeliveryMethod, > > registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address > > [inetOrgPerson] > > carLicense, departmentNumber, employeeNumber, employeeType, > > preferredLanguage, mail, mobile, pager > > audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, > > labeledURI, o, photo, roomNumber, secretary, userCertificate, > > userPKCS12, userSMIMECertificate, x500UniqueIdentifier > > [inetUser] > > inetUserHttpURL, inetUserStatus > > [ipaUser] > > userClass > > I would personally not divide the attributes as basic and detailed. IMO it is > our artificial distinction and may vary between deployments. Why would we for > example show inetUserHttpURL to authenticated only and ipaSshPublicKey to everyone? > > My proposal would be to have a permission "Read User Information" for all > attributes above. > > > > Kerberos/login-related (all authenticated): > > [krbPrincipalAux] > > krbPrincipalName, krbCanonicalName, krbPrincipalAliases, > > krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange > > [+] > > nsAccountLock > > Ok. So permission "Read User Kerberos Attributes"? > > > > > > > Kerberos-related (user admins only): > > [krbPrincipalAux] > > krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange > > So permission "Read User Kerberos Login Attributes"? > > I think this group should also have: > > krbLastAdminUnlock > krbLoginFailedCount +1 > > No read permission: > > [person] > > userPassword > > ok > > > [krbPrincipalAux] > > krbPrincipalKey, krbExtraData, krbPwdHistory > > ok > > > krbLastAdminUnlock, > > Move this one. > > > krbLoginFailedCount > > Move this one. > > > krbPrincipalType > > Simo? I know we do not user this attribute, but wouldn't it fit in "Read User > Kerberos Attributes" permission? Yes, we do not use it yet, but we may want to in the future. > > krbPwdPolicyReference > > This could contain DN to user's password policy attribute. IMO somebody should > have a right to read it. Simo, should all authenticated users be able to read it? Probably not. In another thread we are trying hard to conceal password policy objects, showing this to everybody would thwart that effort as you'd be able to find out the objects by querying all the ones that reference them. Admin and Help Desk people would need access to it though as they need to be able to inspect and change this attribute. > > krbTicketPolicyReference, krbUPEnabled > > I would treat those the same as krbPwdPolicyReference. Yeah, makes sense. > > [krbTicketPolicyAux] > > krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags > > Ok. This will be readable by people with "System: Read User Kerberos Ticket > Policy" permission. > > > [mepOriginEntry] > > mepManagedEntry > > This is used to bind user to it's private group. We use it for example in > group-detach command to distinguish between managed and non-managed groups. > > We may want to show it to all authenticated users. Do we need to ? It is only interesting for internal/administrative operations. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Apr 16 13:42:03 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 09:42:03 -0400 Subject: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups... In-Reply-To: <534E7DD0.90804@redhat.com> References: <534E3921.4000006@redhat.com> <534E3D5F.7000803@redhat.com> <1397652333.19767.377.camel@willson.li.ssimo.org> <534E7C56.8000708@redhat.com> <534E7DD0.90804@redhat.com> Message-ID: <1397655723.19767.395.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 14:55 +0200, Martin Kosek wrote: > On 04/16/2014 02:49 PM, Petr Viktorin wrote: > > On 04/16/2014 02:45 PM, Simo Sorce wrote: > >> On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: > >>> On 04/16/2014 10:02 AM, Martin Kosek wrote: > >>>> I was looking into ticket > >>>> https://fedorahosted.org/freeipa/ticket/4054 > >>>> and experimenting with ACIs allowing privileged users to manage only > >>>> their own LDAP objects. > >>>> > >>>> As already proposed in the Bugzilla, I had success with following ACIs: > >>>> > >>>> ~~~~~~~~~~~~~~~~ > >>>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > >>>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > >>>> add: aci > >>>> aci: (targetattr = "userclass")(targetfilter = > >>>> "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own > >>>> hosts";allow (write) userattr = "creatorsName#USERDN";) > >>>> > >>>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > >>>> > >>>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 > >>>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test > >>>> add: aci > >>>> aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl > >>>> "permission:Modify own hosts";allow (delete) userattr = > >>>> "creatorsName#USERDN";) > >>>> > >>>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" > >>>> ~~~~~~~~~~~~~~~~ > >>>> > >>>> When I then added a user fbar with permission "Add hosts", I was able to > >>>> do exactly what proposed in the ticket: > >>>> > >>>> > >>>> $ ipa host-add test.example.com --force > >>>> ----------------------------- > >>>> Added host "test.example.com" > >>>> ----------------------------- > >>>> Host name: test.example.com > >>>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > >>>> Password: False > >>>> Keytab: False > >>>> Managed by: test.example.com > >>>> > >>>> $ ipa host-mod test.example.com --class foo > >>>> -------------------------------- > >>>> Modified host "test.example.com" > >>>> -------------------------------- > >>>> Host name: test.example.com > >>>> Principal name: host/test.example.com at MKOSEK-FEDORA20.TEST > >>>> Class: foo > >>>> Password: False > >>>> Keytab: False > >>>> Managed by: test.example.com > >>>> > >>>> $ ipa host-mod admin.example.com --class foo > >>>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > >>>> 'userClass' attribute of entry > >>>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > >>>> > >>>> > >>>> $ ipa host-del admin.example.com > >>>> ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to > >>>> delete the entry > >>>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. > >>>> > >>>> > >>>> $ ipa host-del test.example.com > >>>> ------------------------------- > >>>> Deleted host "test.example.com" > >>>> ------------------------------- > >>>> > >>>> I think this could be pretty powerful also with other LDAP objects. > >>>> Question is what can be done to allow that to our users. > >>>> > >>>> I do not think we should add these ACIs by default as not everybody > >>>> would like them. But if we enhance our permission API to allow the > >>>> userattr bind rule, admins could add these ACIs at their wish. > >>>> > >>>> IMO the API is not that difficult, something like this could work: > >>>> > >>>> $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname > >>>> --bind-attr-type=USERDN > >>>> > >>>> --bind-attr could be more or less free form text to allow "creatorsname" > >>>> or "parent[0].creatorsname" > >>>> --bind-attr-type would be enum of values USERDN/GROUPDN > >>>> > >>>> This should cover most of the basic use cases. > >>>> > >>>> Thoughts? > >>>> > >>> > >>> Makes sense. I'd do it around the time we move self-service to permissions. > >>> > >>> Simo, can you reserve two more OIDs for the attributes? > >> > >> What attributes ? userclass ? Can't we simply use a group/role ? > > > > The --bind-attr and --bind-attr-type values will need to be stored in the > > permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType. > > I would personally wait with reserving OID until we create a design of this > feature as there are several approaches. We could for example need one more > attribute, ipaPermBindAttrDepth we would use for control of the ACI effective > depth (mutli valued, values 0-4). Agreed, there is no hurry until we have a design page. simo. From ssorce at redhat.com Wed Apr 16 13:42:36 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 09:42:36 -0400 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140416131529.GL20958@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> Message-ID: <1397655756.19767.396.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote: > On Wed, 16 Apr 2014, Simo Sorce wrote: > >> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', > >> + 'ipanttrustposixoffset', > >> 'ipantsupportedencryptiontypes', > >> + 'ipantsidblacklistincoming', > >> 'ipantsidblacklistoutgoing', > >> + # ipaNTDomainAttrs: > >> + 'ipantsecurityidentifier', 'ipantflatname', > >> 'ipantdomainguid', > >> + 'ipantfallbackprimarygroup', > >> + }, > >> + }, > >> + } > >> > >> label = _('Trusts') > >> label_singular = _('Trust') > > > >In general I am not sure all authenticated users need access to all this > >info. Alexander ? > SSSD needs to read some of this information for subdomains support. > That would be at least host/*@REALM who needs to access it. Can you please list exactly which ones are needed ? Simo. From simo at redhat.com Wed Apr 16 13:46:18 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 09:46:18 -0400 Subject: [Freeipa-devel] kadmin is unresponsive in FreeIPA installation In-Reply-To: <534E31E4.3090009@redhat.com> References: <534E31E4.3090009@redhat.com> Message-ID: <1397655978.19767.398.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 09:31 +0200, Martin Kosek wrote: > Did anyone hit https://bugzilla.redhat.com/show_bug.cgi?id=1088163 or is it > something specific to my environment? a lot of people is starting to use libvirtd switches to make entropy available to their VMs or using other in VM entropy generating engines, but I've hit entropy starvatoin myself during installs, so this is "normal" if you have VMs w/o entropy engines activated. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Apr 16 13:47:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 15:47:01 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <1397655692.19767.394.camel@willson.li.ssimo.org> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> Message-ID: <534E89D5.1060900@redhat.com> On 04/16/2014 03:41 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: >> On 04/15/2014 04:55 PM, Petr Viktorin wrote: ... >>> [mepOriginEntry] >>> mepManagedEntry >> >> This is used to bind user to it's private group. We use it for example in >> group-detach command to distinguish between managed and non-managed groups. >> >> We may want to show it to all authenticated users. > > Do we need to ? > It is only interesting for internal/administrative operations. After reading the code closely, I see we mostly decide whether an object is managed or not by present of the mepManagedEntry _objetclass_. Reading attribute may not be required if we do not want to display it. We just need to allow it for people operating group-detach command is it writes to it. Martin From simo at redhat.com Wed Apr 16 13:47:16 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 09:47:16 -0400 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> <534442FA.1060709@redhat.com> <5345EC92.3010008@redhat.com> <53463ED1.4000206@redhat.com> Message-ID: <1397656036.19767.399.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 02:59 -0500, Justin Brown wrote: > Martin, > > I think that making the firewall configuration automatic is the best > solution. I've updated > http://www.freeipa.org/page/V4/Firewall_Configuration for automatic > configuration unless --no-firewall is passed. > > You guys know the user-base better than I do, but I would imagine that > users would benefit by making a FreeIPA installation work properly > with as few arguments as possible. +1 Simo. > Thanks, > Justin > > On Thu, Apr 10, 2014 at 1:48 AM, Martin Kosek wrote: > > On 04/10/2014 02:57 AM, Dmitri Pal wrote: > >> On 04/08/2014 02:42 PM, Rob Crittenden wrote: > >>> Justin Brown wrote: > > ... > >> b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2 > >> --forwarder=192.168.0.3 > > > > Let's talk about CLI. Shouldn't we add just one option - "--no-firewall"? I > > would assume that we want to open the firewall ports by default *if* the > > firewalld is running. If firewalld is not running, ipa-server-install would > > detect it via DBUS and just simply print warning and would not configure > > anything and could just maybe spit out iptables configuration as Justin > > mentioned (optional). > > > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Apr 16 13:52:36 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 09:52:36 -0400 Subject: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions In-Reply-To: <534E40D5.10502@redhat.com> References: <5347D28A.2020300@redhat.com> <534E40D5.10502@redhat.com> Message-ID: <1397656356.19767.400.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 10:35 +0200, Jan Cholasta wrote: > On 11.4.2014 13:31, Petr Viktorin wrote: > > One of the default_attributes of permission is memberofindirect, a > > virtual attribute manufactured by ldap2, which is set when a permission > > is part of a role. > > When update_entry is called on an entry with memberofindirect, ipaldap > > tries to add the attribute to LDAP and fails with an objectclass violation. > > > > Do not ask for memberindirect when retrieving the entry. > > > > > > > > CCing Honza since he designs ipaldap. Virtual attributes are often > > helpful, and in any case IPA uses them a lot and having to filter them > > out every time is error-prone. > > Maybe we should add support for them directly in ipaldap -- e.g. an > > attribute set by `entry.virtual[attr_name] = [x]` would be visible in > > entry[attr_name] but would not be synced back to LDAP? > > > > I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff > in the future. Your suggestion works in sort of opposite direction, so I > can't say I like it. > > Currently we use LDAPEntry in frontend code directly, but I think that's > wrong. There should be a frontend-specific class for this (make > ipalib.frontend.Object instantiable?) and LDAPEntry should be used > (almost) only in backend code. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Apr 16 13:58:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 15:58:21 +0200 Subject: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions In-Reply-To: <1397656356.19767.400.camel@willson.li.ssimo.org> References: <5347D28A.2020300@redhat.com> <534E40D5.10502@redhat.com> <1397656356.19767.400.camel@willson.li.ssimo.org> Message-ID: <534E8C7D.5020004@redhat.com> On 04/16/2014 03:52 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 10:35 +0200, Jan Cholasta wrote: >> On 11.4.2014 13:31, Petr Viktorin wrote: >>> One of the default_attributes of permission is memberofindirect, a >>> virtual attribute manufactured by ldap2, which is set when a permission >>> is part of a role. >>> When update_entry is called on an entry with memberofindirect, ipaldap >>> tries to add the attribute to LDAP and fails with an objectclass violation. >>> >>> Do not ask for memberindirect when retrieving the entry. >>> >>> >>> >>> CCing Honza since he designs ipaldap. Virtual attributes are often >>> helpful, and in any case IPA uses them a lot and having to filter them >>> out every time is error-prone. >>> Maybe we should add support for them directly in ipaldap -- e.g. an >>> attribute set by `entry.virtual[attr_name] = [x]` would be visible in >>> entry[attr_name] but would not be synced back to LDAP? >>> >> >> I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff >> in the future. Your suggestion works in sort of opposite direction, so I >> can't say I like it. >> >> Currently we use LDAPEntry in frontend code directly, but I think that's >> wrong. There should be a frontend-specific class for this (make >> ipalib.frontend.Object instantiable?) and LDAPEntry should be used >> (almost) only in backend code. > > +1 > > Simo. We are then stuck with Petr's original patch 518 - ACK from me. Martin From abokovoy at redhat.com Wed Apr 16 13:59:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Apr 2014 16:59:55 +0300 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <1397655756.19767.396.camel@willson.li.ssimo.org> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> Message-ID: <20140416135954.GM20958@redhat.com> On Wed, 16 Apr 2014, Simo Sorce wrote: >On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote: >> On Wed, 16 Apr 2014, Simo Sorce wrote: >> >> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', >> >> + 'ipanttrustposixoffset', >> >> 'ipantsupportedencryptiontypes', >> >> + 'ipantsidblacklistincoming', >> >> 'ipantsidblacklistoutgoing', >> >> + # ipaNTDomainAttrs: >> >> + 'ipantsecurityidentifier', 'ipantflatname', >> >> 'ipantdomainguid', >> >> + 'ipantfallbackprimarygroup', >> >> + }, >> >> + }, >> >> + } >> >> >> >> label = _('Trusts') >> >> label_singular = _('Trust') >> > >> >In general I am not sure all authenticated users need access to all this >> >info. Alexander ? >> SSSD needs to read some of this information for subdomains support. >> That would be at least host/*@REALM who needs to access it. > >Can you please list exactly which ones are needed ? SSSD subdomains support needs: - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs - ipaNTFlatName - ipaNTSecurityIdentifier - ipaNTTrustedDomainSID - cn - objectclass ipaIDRange - cn - ipaBaseID - ipaIDRangeSize - ipaBaseRID - ipaSecondaryBaseRID > >Simo. > > > -- / Alexander Bokovoy From pspacek at redhat.com Wed Apr 16 14:01:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Apr 2014 16:01:52 +0200 Subject: [Freeipa-devel] [PATCH 0237] Handle paths without trailing / in fs_dirs_create() Message-ID: <534E8D50.3090204@redhat.com> Hello, Handle paths without trailing / in fs_dirs_create(). This patch should go to all branches with fs_dirs_create() function. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0237-Handle-paths-without-trailing-in-fs_dirs_create.patch Type: text/x-patch Size: 752 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 16 14:02:41 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Apr 2014 16:02:41 +0200 Subject: [Freeipa-devel] [PATCH 0238] Update .gitignore to skip Eclipse and Autotools file Message-ID: <534E8D81.4050802@redhat.com> Hello, Update .gitignore to skip Eclipse and Autotools files. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0238-Update-.gitignore-to-skip-Eclipse-and-Autotools-file.patch Type: text/x-patch Size: 755 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 16 14:19:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 16:19:03 +0200 Subject: [Freeipa-devel] [PATCHES] 0521-0522 - Add managed read permissions to krbtpolicy & Allow anonymous read access to Kerberos realm container name In-Reply-To: <534E5CA5.9090404@redhat.com> References: <534C12BC.4040805@redhat.com> <1397495898.19767.256.camel@willson.li.ssimo.org> <534CE200.9020200@redhat.com> <534CE335.5070804@redhat.com> <534D1461.3090800@redhat.com> <1397567773.19767.287.camel@willson.li.ssimo.org> <534D46BB.707@redhat.com> <1397574507.19767.317.camel@willson.li.ssimo.org> <534D4C02.5090708@redhat.com> <534D542E.4050701@redhat.com> <534D5A0B.8060602@redhat.com> <534E19C0.4050008@redhat.com> <534E564A.4040704@redhat.com> <534E5CA5.9090404@redhat.com> Message-ID: <534E9157.3010409@redhat.com> On 04/16/2014 12:34 PM, Petr Viktorin wrote: > On 04/16/2014 12:07 PM, Petr Viktorin wrote: >> On 04/16/2014 07:48 AM, Martin Kosek wrote: >>> On 04/15/2014 06:10 PM, Ludwig Krispenz wrote: >>>> >>>> On 04/15/2014 05:45 PM, Ludwig Krispenz wrote: >>>>> >>>>> On 04/15/2014 05:10 PM, Martin Kosek wrote: >>>>>> On 04/15/2014 05:08 PM, Simo Sorce wrote: >>>>>>> On Tue, 2014-04-15 at 16:48 +0200, Martin Kosek wrote: >>>>>>>> On 04/15/2014 03:16 PM, Simo Sorce wrote: >>>>>>>>> On Tue, 2014-04-15 at 13:13 +0200, Petr Viktorin wrote: >>>>>>>>>> On 04/15/2014 09:43 AM, Martin Kosek wrote: >>>>>>>>>>> On 04/15/2014 09:38 AM, Martin Kosek wrote: >>>>>>>>>>>> On 04/14/2014 07:18 PM, Simo Sorce wrote: >>>>>>>>>>>>> On Mon, 2014-04-14 at 18:54 +0200, Petr Viktorin wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The first patch adds default read permissions to krbtpolicy. >>>>>>>>>>>>>> Since the >>>>>>>>>>>>>> plugin manages entries in two trees, there are two >>>>>>>>>>>>>> permissions. Since >>>>>>>>>>>>>> two permissions are needed to cover krbtpolicy, it can't be >>>>>>>>>>>>>> used as a >>>>>>>>>>>>>> permission's --type. >>>>>>>>>>>>>> The permissions are added to a new privilege, 'Kerberos >>>>>>>>>>>>>> Ticket Policy >>>>>>>>>>>>>> Readers'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The second patch adds an ACI for reading the Kerberos realm >>>>>>>>>>>>>> name. Since >>>>>>>>>>>>>> client enrollment won't work without this, I don't see a >>>>>>>>>>>>>> reason for >>>>>>>>>>>>>> having it managed by a permission. >>>>>>>>>>>>>> >>>>>>>>>>>>> LGTM >>>>>>>>>>>>> >>>>>>>>>>>>> Simo. >>>>>>>>>>>>> >>>>>>>>>>>> 521 breaks a unit test: >>>>>>>>>>>> >>>>>>>>>>>> ====================================================================== >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> FAIL: test_permission[37]: permission_find: Search for >>>>>>>>>>>> u'Testperm_RN' >>>>>>>>>>>> using >>>>>>>>>>>> --subtree >>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line >>>>>>>>>>>> 197, in >>>>>>>>>>>> runTest >>>>>>>>>>>> self.test(*self.arg) >>>>>>>>>>>> File >>>>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>>>> line 301, in >>>>>>>>>>>> >>>>>>>>>>>> func = lambda: self.check(nice, **test) >>>>>>>>>>>> File >>>>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>>>> line 319, in >>>>>>>>>>>> check >>>>>>>>>>>> self.check_output(nice, cmd, args, options, expected, >>>>>>>>>>>> extra_check) >>>>>>>>>>>> File >>>>>>>>>>>> "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", >>>>>>>>>>>> line 359, in >>>>>>>>>>>> check_output >>>>>>>>>>>> assert_deepequal(expected, got, nice) >>>>>>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 344, in >>>>>>>>>>>> assert_deepequal >>>>>>>>>>>> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >>>>>>>>>>>> File "/root/freeipa-master/ipatests/util.py", line 352, in >>>>>>>>>>>> assert_deepequal >>>>>>>>>>>> VALUE % (doc, expected, got, stack) >>>>>>>>>>>> AssertionError: assert_deepequal: expected != got. >>>>>>>>>>>> test_permission[37]: permission_find: Search for >>>>>>>>>>>> u'Testperm_RN' >>>>>>>>>>>> using --subtree >>>>>>>>>>>> expected = 1 >>>>>>>>>>>> got = 2 >>>>>>>>>>>> path = ('count',) >>>>>>>>>> Thanks for the catch, tests updated. >>>>>>>>>> >>>>>>>>>>>> Otherwise it works fine (krbtpolicy-show for user cannot be >>>>>>>>>>>> tested yet >>>>>>>>>>>> as we >>>>>>>>>>>> miss permissions for users). >>>>>>>>>> Right; I don't think this permission by itself should allow >>>>>>>>>> access to >>>>>>>>>> users. Correct me if that's wrong. >>>>>>>>>> >>>>>>>>>> I created a users permission for testing: >>>>>>>>>> ipa permission-add 'allow reading user objectclass' --type >>>>>>>>>> user >>>>>>>>>> --right={read,search,compare} --attrs objectclass --bind all >>>>>>>>>> >>>>>>>>>>> /me hit Send too soon. >>>>>>>>>>> >>>>>>>>>>> Although 522 works functionally and client now discovers the IPA >>>>>>>>>>> server, there >>>>>>>>>>> is no path from SUFFIX to cn=REALM for anonymous users. >>>>>>>>>>> >>>>>>>>>>> I would personally change the ACI to >>>>>>>>>>> >>>>>>>>>>> (targetattr = "cn || objectclass")(targetfilter = >>>>>>>>>>> "(|(objectclass=krbrealmcontainer)(objectclass=krbcontainer))")(version >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3.0;acl >>>>>>>>>>> "Anonymous read access to Kerberos container";allow >>>>>>>>>>> (read,compare,search) >>>>>>>>>>> userdn = "ldap:///anyone";)' >>>>>>>>>>> >>>>>>>>>>> and put it to cn=kerberos,$SUFFIX (which is of krbcontainer >>>>>>>>>>> objectclass). >>>>>>>>>> Right, that's necessary for UIs to list the container. >>>>>>>>>> Simo, are you okay with this? >>>>>>>>> It is no secret that an IPA server has a container named after the >>>>>>>>> domain. And the REALM name is available unauthenticated from >>>>>>>>> DNS, so >>>>>>>>> knowledge of it's existence is given. >>>>>>>>> Therefore I see no problem if anonymous can see the container >>>>>>>>> exists, as >>>>>>>>> long as no contents (beyond what we already determined need to >>>>>>>>> be) are >>>>>>>>> revealed I see no problem. >>>>>>>>> >>>>>>>>> Simo. >>>>>>>>> >>>>>>>>> >>>>>>>> Patches work fine. The only problem I see that we now expose group >>>>>>>> password >>>>>>>> policies >>>>>>>> >>>>>>>> # ldapsearch -h `hostname` -x -b >>>>>>>> 'cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test' cn >>>>>>>> ... >>>>>>>> # MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>>>>> dn: cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>>>>>> cn: MKOSEK-FEDORA20.TEST >>>>>>>> >>>>>>>> # global_policy, MKOSEK-FEDORA20.TEST, kerberos, >>>>>>>> mkosek-fedora20.test >>>>>>>> dn: >>>>>>>> cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc >>>>>>>> >>>>>>>> >>>>>>>> =test >>>>>>>> cn: global_policy >>>>>>>> >>>>>>>> # ipausers, MKOSEK-FEDORA20.TEST, kerberos, mkosek-fedora20.test >>>>>>>> dn: >>>>>>>> cn=ipausers,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test >>>>>>>> >>>>>>>> >>>>>>>> cn: ipausers >>>>>>>> ... >>>>>>>> >>>>>>>> It seems suboptimal as we now moved access to group password >>>>>>>> policy to >>>>>>>> special >>>>>>>> permission and we probably do not want to leak a list of defined >>>>>>>> group >>>>>>>> policies. >>>>>>>> >>>>>>>> Question is how to prevent it as the group password policies have >>>>>>>> nsContainer >>>>>>>> OC. I see 2 options: >>>>>>>> >>>>>>>> 1) Update pwpolicy plugin to avoid using nsContainer for group >>>>>>>> password >>>>>>>> policy >>>>>>>> (I do not think it is needed, krbPwdPolicy contains cn attribute >>>>>>>> >>>>>>>> 2) Update our container allowing ACI to not display it. >>>>>>>> >>>>>>>> Option 1) would be nice, but I am afraid it would break search in >>>>>>>> older >>>>>>>> versions which expects the nsContainer OC to be there. >>>>>>>> >>>>>>>> As for option 2) I am not sure how best to do it. It would be best >>>>>>>> to exclude >>>>>>>> both cn=etc and cn=kerberos subtrees, but I could not figure out >>>>>>>> an ACI >>>>>>>> syntax >>>>>>>> to do it. >>>>>>>> >>>>>>>> Both >>>>>>>> (target != "ldap:///some=dn")(target != "ldap:///other=dn") >>>>>>>> and >>>>>>>> (target != "ldap:///some=dn" && target != "ldap:///other=dn") >>>>>>>> are not correct. CCing Ludwig to advise. >>>>>>>> >>>>>>>> Alternative is to exclude the the password policies by >>>>>>>> targetfilter, but I >>>>>>>> think excluding whole tree is better. >>>>>>>> >>>>>>>> Martin >>>>>>> It's like an LDAP filter but no quite so maybe: >>>>>>> (&(target != "ldap:///some=dn")(target != "ldap:///other=dn")) ? >>>>>>> >>>>>>> HTH, >>>>>>> Simo. >>>>>>> >>>>>> Try again... >>>>>> >>>>>> [15/Apr/2014:17:15:01 +0200] NSACLPlugin - ACL Syntax >>>>>> Error(-5):(targetfilter=\22(objectclass=nsContainer)\22)(&(target != >>>>>> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22)(target != >>>>>> \22ldap:///cn=etc,dc=mkosek-fedora20,dc=test\22))(targetattr=\22objectclass >>>>>> >>>>>> || >>>>>> cn\22)(version 3.0; acl \22Anonymous read access to containers\22; >>>>>> allow(read, >>>>>> search, compare) userdn = \22ldap:///anyone\22;) >>>>>> >>>>>> Martin >>>>> (target!="ldap:///some=dn || ldap:///other=dn") is accepted, but in a >>>>> quick >>>>> test also didn't work as expected. Need to investigate a bit more >>>> looks like we do not handle multiple targets at all. Although in the >>>> bind rules >>>> logical operations of binddns and bindgroups are handled, so that >>>> would be an >>>> enhancement :-( >>>> >>>> so I think you either have to move to denies for the two subtrees and >>>> a general >>>> allow for the parent tree, which is not nice or use targetfilter if >>>> possible. >>> >>> Ok, thanks for investigation. Petr, it seems we will simply need to >>> update the container ACI and exclude krbPwdPolicy objectclass in the >>> target filter. >>> >>> Martin >> >> Patch here. >> It doesn't handle updating from unreleased code, so if you're upgrading >> from recent master, remove the previous "Anonymous read access to >> containers" ACI. > > > Actually, we might want to delay pushing this patch; It'll need some more > modifications to allow containers in cn=etc. Ok. Given you plan to address the krbPwdPolicy separately, I see no problem with accepting patches 521.2 and 522.2. ACK, pushed both to master. Martin From amisnyov at redhat.com Wed Apr 16 14:21:52 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 16 Apr 2014 16:21:52 +0200 Subject: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix In-Reply-To: <534E1C4B.1090100@redhat.com> References: <20140415124148.43f848a1@unused-4-246.brq.redhat.com> <534D0F43.1050408@redhat.com> <20140415173647.56826042@unused-4-246.brq.redhat.com> <534E1C4B.1090100@redhat.com> Message-ID: <20140416162152.3379f4fc@unused-4-246.brq.redhat.com> On Wed, 16 Apr 2014 07:59:39 +0200 Martin Kosek wrote: > On 04/15/2014 05:36 PM, Misnyovszki Adam wrote: > > On Tue, 15 Apr 2014 12:51:47 +0200 > > Petr Viktorin wrote: > > > >> On 04/15/2014 12:41 PM, Misnyovszki Adam wrote: > >>> Hi, > >>> this patch fixes FreeIPA Jenkins CI test > >>> freeipa-integration-forced_client_reenrollment-f19, by turning > >>> sshfp records into a set, and sorting them before assertion. > >>> > >>> https://fedorahosted.org/freeipa/ticket/4298 > >>> > >>> Greets > >>> Adam > >> > >> The list.sort() method sorts in-place and returns None, so now the > >> test would not really test anything. Use the sorted() function. > >> > >> You might want to log the value before returning it. > >> > > > > My mistake, see the attached, corrected patch. > > Thanks > > Adam > > Adam, Petr - why can't we use a set as I already proposed in the > ticket description? > > >>> set(['i', 'p', 'a']) == set(['a', 'p', 'i']) > True > > Martin Hi, see the attached patch. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0011-3-CI-test_forced_client_reenrollment-stability-fix.patch Type: text/x-patch Size: 1250 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 16 14:35:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 16:35:09 +0200 Subject: [Freeipa-devel] [PATCH] 0525 Add managed read permissions to automember In-Reply-To: <534D270B.8070307@redhat.com> References: <534D270B.8070307@redhat.com> Message-ID: <534E951D.9090405@redhat.com> On 04/15/2014 02:33 PM, Petr Viktorin wrote: > Read access to both rules and definitions is given to a new privilege, > 'Automember Readers', as well as the existing 'Automember Task Administrator'. This needs a mild rebase in 40-delegation.update. When I resolved the conflict patch worked fine, no problem found. ACK when you fix the conflict. Martin From mkosek at redhat.com Wed Apr 16 14:38:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 16:38:29 +0200 Subject: [Freeipa-devel] [PATCH] 0527 Add managed read permission to idrange In-Reply-To: <534E6333.3090705@redhat.com> References: <534E6333.3090705@redhat.com> Message-ID: <534E95E5.3010906@redhat.com> On 04/16/2014 01:02 PM, Petr Viktorin wrote: > Read access is given to all authenticated users. Works fine, no problem found - ACK. Pushed to master: bb4e47d9ea249d7f3ead460284dd67312cc82bd5 Martin From mkosek at redhat.com Wed Apr 16 14:50:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 16:50:37 +0200 Subject: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount In-Reply-To: <534E7441.6020205@redhat.com> References: <534E7441.6020205@redhat.com> Message-ID: <534E98BD.2080400@redhat.com> On 04/16/2014 02:14 PM, Petr Viktorin wrote: > A single permission granting anonymous read access covers automountlocation, > automountmap, and automountkey. > This works fine, I am just wondering about the ACI: 1) Simo, are you OK with one ACI covering all automount objects? I personally am, I cannot imagine a situation when somebody allows automount maps but not the automount keys. But on the other hand, we also have separate permissions for sudo commands, sudo command groups, sudo rules... 2) Should we limit the ACI by an objectclass filter? I.e. (|(objectclass=automountmap)(objectclass=automount))? Martin From mkosek at redhat.com Wed Apr 16 14:55:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 16:55:30 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140416135954.GM20958@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> Message-ID: <534E99E2.5020701@redhat.com> On 04/16/2014 03:59 PM, Alexander Bokovoy wrote: > On Wed, 16 Apr 2014, Simo Sorce wrote: >> On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote: >>> On Wed, 16 Apr 2014, Simo Sorce wrote: >>> >> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', >>> >> + 'ipanttrustposixoffset', >>> >> 'ipantsupportedencryptiontypes', >>> >> + 'ipantsidblacklistincoming', >>> >> 'ipantsidblacklistoutgoing', >>> >> + # ipaNTDomainAttrs: >>> >> + 'ipantsecurityidentifier', 'ipantflatname', >>> >> 'ipantdomainguid', >>> >> + 'ipantfallbackprimarygroup', >>> >> + }, >>> >> + }, >>> >> + } >>> >> >>> >> label = _('Trusts') >>> >> label_singular = _('Trust') >>> > >>> >In general I am not sure all authenticated users need access to all this >>> >info. Alexander ? >>> SSSD needs to read some of this information for subdomains support. >>> That would be at least host/*@REALM who needs to access it. >> >> Can you please list exactly which ones are needed ? > SSSD subdomains support needs: > - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs > - ipaNTFlatName > - ipaNTSecurityIdentifier > - ipaNTTrustedDomainSID > - cn Question is - is there any added value in hiding part of the trust information from authenticated users? I.e. attributes like ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this attribute anyway?), SID blacklists... If yes, we would need to split this permission in 2 and have one for authenticated users and one for "Trust Adminitrators" and "Trust Readers". Martin From abokovoy at redhat.com Wed Apr 16 15:10:19 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Apr 2014 18:10:19 +0300 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <534E99E2.5020701@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> Message-ID: <20140416151019.GN20958@redhat.com> On Wed, 16 Apr 2014, Martin Kosek wrote: >On 04/16/2014 03:59 PM, Alexander Bokovoy wrote: >> On Wed, 16 Apr 2014, Simo Sorce wrote: >>> On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote: >>>> On Wed, 16 Apr 2014, Simo Sorce wrote: >>>> >> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', >>>> >> + 'ipanttrustposixoffset', >>>> >> 'ipantsupportedencryptiontypes', >>>> >> + 'ipantsidblacklistincoming', >>>> >> 'ipantsidblacklistoutgoing', >>>> >> + # ipaNTDomainAttrs: >>>> >> + 'ipantsecurityidentifier', 'ipantflatname', >>>> >> 'ipantdomainguid', >>>> >> + 'ipantfallbackprimarygroup', >>>> >> + }, >>>> >> + }, >>>> >> + } >>>> >> >>>> >> label = _('Trusts') >>>> >> label_singular = _('Trust') >>>> > >>>> >In general I am not sure all authenticated users need access to all this >>>> >info. Alexander ? >>>> SSSD needs to read some of this information for subdomains support. >>>> That would be at least host/*@REALM who needs to access it. >>> >>> Can you please list exactly which ones are needed ? >> SSSD subdomains support needs: >> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >> - ipaNTFlatName >> - ipaNTSecurityIdentifier >> - ipaNTTrustedDomainSID >> - cn > >Question is - is there any added value in hiding part of the >trust information from authenticated users? I.e. attributes like >ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >attribute anyway?), SID blacklists... Yes. Some of those attributes are needed as internal detail of ipasam -- part of how Samba stores this information taken from specific DCE RPC structures. >If yes, we would need to split this permission in 2 and have one for >authenticated users and one for "Trust Adminitrators" and "Trust Readers". Yes. Authenticated users shouldn't get any access to those details: ipantsupportedencryptiontypes ipanttrustattributes ipanttrustauthincoming ipanttrustauthoutgoing -- / Alexander Bokovoy From mkosek at redhat.com Wed Apr 16 15:16:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 17:16:38 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140416151019.GN20958@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> Message-ID: <534E9ED6.2080502@redhat.com> On 04/16/2014 05:10 PM, Alexander Bokovoy wrote: > On Wed, 16 Apr 2014, Martin Kosek wrote: >> On 04/16/2014 03:59 PM, Alexander Bokovoy wrote: >>> On Wed, 16 Apr 2014, Simo Sorce wrote: >>>> On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote: >>>>> On Wed, 16 Apr 2014, Simo Sorce wrote: >>>>> >> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', >>>>> >> + 'ipanttrustposixoffset', >>>>> >> 'ipantsupportedencryptiontypes', >>>>> >> + 'ipantsidblacklistincoming', >>>>> >> 'ipantsidblacklistoutgoing', >>>>> >> + # ipaNTDomainAttrs: >>>>> >> + 'ipantsecurityidentifier', 'ipantflatname', >>>>> >> 'ipantdomainguid', >>>>> >> + 'ipantfallbackprimarygroup', >>>>> >> + }, >>>>> >> + }, >>>>> >> + } >>>>> >> >>>>> >> label = _('Trusts') >>>>> >> label_singular = _('Trust') >>>>> > >>>>> >In general I am not sure all authenticated users need access to all this >>>>> >info. Alexander ? >>>>> SSSD needs to read some of this information for subdomains support. >>>>> That would be at least host/*@REALM who needs to access it. >>>> >>>> Can you please list exactly which ones are needed ? >>> SSSD subdomains support needs: >>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>> - ipaNTFlatName >>> - ipaNTSecurityIdentifier >>> - ipaNTTrustedDomainSID >>> - cn >> >> Question is - is there any added value in hiding part of the >> trust information from authenticated users? I.e. attributes like >> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >> attribute anyway?), SID blacklists... > Yes. Some of those attributes are needed as internal detail of ipasam -- > part of how Samba stores this information taken from specific DCE RPC > structures. > >> If yes, we would need to split this permission in 2 and have one for >> authenticated users and one for "Trust Adminitrators" and "Trust Readers". > Yes. Authenticated users shouldn't get any access to those details: > ipantsupportedencryptiontypes > ipanttrustattributes > ipanttrustauthincoming > ipanttrustauthoutgoing > > Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group should then have this permission assigned so that samba can operate the attributes. Martin From abokovoy at redhat.com Wed Apr 16 15:22:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Apr 2014 18:22:55 +0300 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <534E9ED6.2080502@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> Message-ID: <20140416152255.GO20958@redhat.com> On Wed, 16 Apr 2014, Martin Kosek wrote: >On 04/16/2014 05:10 PM, Alexander Bokovoy wrote: >> On Wed, 16 Apr 2014, Martin Kosek wrote: >>> On 04/16/2014 03:59 PM, Alexander Bokovoy wrote: >>>> On Wed, 16 Apr 2014, Simo Sorce wrote: >>>>> On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote: >>>>>> On Wed, 16 Apr 2014, Simo Sorce wrote: >>>>>> >> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', >>>>>> >> + 'ipanttrustposixoffset', >>>>>> >> 'ipantsupportedencryptiontypes', >>>>>> >> + 'ipantsidblacklistincoming', >>>>>> >> 'ipantsidblacklistoutgoing', >>>>>> >> + # ipaNTDomainAttrs: >>>>>> >> + 'ipantsecurityidentifier', 'ipantflatname', >>>>>> >> 'ipantdomainguid', >>>>>> >> + 'ipantfallbackprimarygroup', >>>>>> >> + }, >>>>>> >> + }, >>>>>> >> + } >>>>>> >> >>>>>> >> label = _('Trusts') >>>>>> >> label_singular = _('Trust') >>>>>> > >>>>>> >In general I am not sure all authenticated users need access to all this >>>>>> >info. Alexander ? >>>>>> SSSD needs to read some of this information for subdomains support. >>>>>> That would be at least host/*@REALM who needs to access it. >>>>> >>>>> Can you please list exactly which ones are needed ? >>>> SSSD subdomains support needs: >>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>> - ipaNTFlatName >>>> - ipaNTSecurityIdentifier >>>> - ipaNTTrustedDomainSID >>>> - cn >>> >>> Question is - is there any added value in hiding part of the >>> trust information from authenticated users? I.e. attributes like >>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>> attribute anyway?), SID blacklists... >> Yes. Some of those attributes are needed as internal detail of ipasam -- >> part of how Samba stores this information taken from specific DCE RPC >> structures. >> >>> If yes, we would need to split this permission in 2 and have one for >>> authenticated users and one for "Trust Adminitrators" and "Trust Readers". >> Yes. Authenticated users shouldn't get any access to those details: >> ipantsupportedencryptiontypes >> ipanttrustattributes >> ipanttrustauthincoming >> ipanttrustauthoutgoing >> >> > >Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group should >then have this permission assigned so that samba can operate the attributes. 'adtrust agents' and 'trust administrators' should have read, modify, delete, and search on cn=trusts. -- / Alexander Bokovoy From mkosek at redhat.com Wed Apr 16 15:29:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Apr 2014 17:29:36 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140416152255.GO20958@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> Message-ID: <534EA1E0.6080801@redhat.com> On 04/16/2014 05:22 PM, Alexander Bokovoy wrote: > On Wed, 16 Apr 2014, Martin Kosek wrote: >> On 04/16/2014 05:10 PM, Alexander Bokovoy wrote: >>> On Wed, 16 Apr 2014, Martin Kosek wrote: >>>> On 04/16/2014 03:59 PM, Alexander Bokovoy wrote: >>>>> On Wed, 16 Apr 2014, Simo Sorce wrote: >>>>>> On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote: >>>>>>> On Wed, 16 Apr 2014, Simo Sorce wrote: >>>>>>> >> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', >>>>>>> >> + 'ipanttrustposixoffset', >>>>>>> >> 'ipantsupportedencryptiontypes', >>>>>>> >> + 'ipantsidblacklistincoming', >>>>>>> >> 'ipantsidblacklistoutgoing', >>>>>>> >> + # ipaNTDomainAttrs: >>>>>>> >> + 'ipantsecurityidentifier', 'ipantflatname', >>>>>>> >> 'ipantdomainguid', >>>>>>> >> + 'ipantfallbackprimarygroup', >>>>>>> >> + }, >>>>>>> >> + }, >>>>>>> >> + } >>>>>>> >> >>>>>>> >> label = _('Trusts') >>>>>>> >> label_singular = _('Trust') >>>>>>> > >>>>>>> >In general I am not sure all authenticated users need access to all this >>>>>>> >info. Alexander ? >>>>>>> SSSD needs to read some of this information for subdomains support. >>>>>>> That would be at least host/*@REALM who needs to access it. >>>>>> >>>>>> Can you please list exactly which ones are needed ? >>>>> SSSD subdomains support needs: >>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>> - ipaNTFlatName >>>>> - ipaNTSecurityIdentifier >>>>> - ipaNTTrustedDomainSID >>>>> - cn >>>> >>>> Question is - is there any added value in hiding part of the >>>> trust information from authenticated users? I.e. attributes like >>>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>>> attribute anyway?), SID blacklists... >>> Yes. Some of those attributes are needed as internal detail of ipasam -- >>> part of how Samba stores this information taken from specific DCE RPC >>> structures. >>> >>>> If yes, we would need to split this permission in 2 and have one for >>>> authenticated users and one for "Trust Adminitrators" and "Trust Readers". >>> Yes. Authenticated users shouldn't get any access to those details: >>> ipantsupportedencryptiontypes >>> ipanttrustattributes >>> ipanttrustauthincoming >>> ipanttrustauthoutgoing >>> >>> >> >> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group should >> then have this permission assigned so that samba can operate the attributes. > 'adtrust agents' and 'trust administrators' should have read, modify, > delete, and search on cn=trusts. > Right. We will probably want to turn most of ACIs in install/updates/60-trusts.update in managed permissions (i.e. defined in trust.py) and make "adtrust agents" and "trust admins" it's members. It'd make the ACIs more maintainable and install/updates/60-trusts.update would get much shorter. Martin From abokovoy at redhat.com Wed Apr 16 15:34:14 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Apr 2014 18:34:14 +0300 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <534EA1E0.6080801@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> Message-ID: <20140416153414.GP20958@redhat.com> On Wed, 16 Apr 2014, Martin Kosek wrote: >>>>>>>> >In general I am not sure all authenticated users need access to all this >>>>>>>> >info. Alexander ? >>>>>>>> SSSD needs to read some of this information for subdomains support. >>>>>>>> That would be at least host/*@REALM who needs to access it. >>>>>>> >>>>>>> Can you please list exactly which ones are needed ? >>>>>> SSSD subdomains support needs: >>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>>> - ipaNTFlatName >>>>>> - ipaNTSecurityIdentifier >>>>>> - ipaNTTrustedDomainSID >>>>>> - cn >>>>> >>>>> Question is - is there any added value in hiding part of the >>>>> trust information from authenticated users? I.e. attributes like >>>>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>>>> attribute anyway?), SID blacklists... >>>> Yes. Some of those attributes are needed as internal detail of ipasam -- >>>> part of how Samba stores this information taken from specific DCE RPC >>>> structures. >>>> >>>>> If yes, we would need to split this permission in 2 and have one for >>>>> authenticated users and one for "Trust Adminitrators" and "Trust Readers". >>>> Yes. Authenticated users shouldn't get any access to those details: >>>> ipantsupportedencryptiontypes >>>> ipanttrustattributes >>>> ipanttrustauthincoming >>>> ipanttrustauthoutgoing >>>> >>>> >>> >>> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group should >>> then have this permission assigned so that samba can operate the attributes. >> 'adtrust agents' and 'trust administrators' should have read, modify, >> delete, and search on cn=trusts. >> > >Right. We will probably want to turn most of ACIs in >install/updates/60-trusts.update in managed permissions (i.e. defined in >trust.py) and make "adtrust agents" and "trust admins" it's members. I agree. -- / Alexander Bokovoy From rcritten at redhat.com Wed Apr 16 15:42:00 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Apr 2014 11:42:00 -0400 Subject: [Freeipa-devel] [PATCH][RFC] 13 - Log pretty-printed request and response In-Reply-To: <20140416150543.0434eb32@unused-4-246.brq.redhat.com> References: <20140416150543.0434eb32@unused-4-246.brq.redhat.com> Message-ID: <534EA4C8.4060308@redhat.com> Misnyovszki Adam wrote: > Hi, > this patch enables logging json dumps of request and response, using > the --log-payload switch in ipa cli. RFC tag is to ensure that I > handled the --log-payload switch correctly in ipa cli. Be careful, it > only logs, so --log-payload without -v switch doesn't make the dump > visible in command line, -v does! > > https://fedorahosted.org/freeipa/ticket/4233 Not a NACK but using -vvv makes this a much simpler operation as you can then just compare verbose >= 3. This seems like a lot of work just to pretty-print some output. rob From ssorce at redhat.com Wed Apr 16 15:56:32 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 11:56:32 -0400 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140416153414.GP20958@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> <20140416153414.GP20958@redhat.com> Message-ID: <1397663792.19767.401.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: > On Wed, 16 Apr 2014, Martin Kosek wrote: > >>>>>>>> >In general I am not sure all authenticated users need access to all this > >>>>>>>> >info. Alexander ? > >>>>>>>> SSSD needs to read some of this information for subdomains support. > >>>>>>>> That would be at least host/*@REALM who needs to access it. > >>>>>>> > >>>>>>> Can you please list exactly which ones are needed ? > >>>>>> SSSD subdomains support needs: > >>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs > >>>>>> - ipaNTFlatName > >>>>>> - ipaNTSecurityIdentifier > >>>>>> - ipaNTTrustedDomainSID > >>>>>> - cn > >>>>> > >>>>> Question is - is there any added value in hiding part of the > >>>>> trust information from authenticated users? I.e. attributes like > >>>>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this > >>>>> attribute anyway?), SID blacklists... > >>>> Yes. Some of those attributes are needed as internal detail of ipasam -- > >>>> part of how Samba stores this information taken from specific DCE RPC > >>>> structures. > >>>> > >>>>> If yes, we would need to split this permission in 2 and have one for > >>>>> authenticated users and one for "Trust Adminitrators" and "Trust Readers". > >>>> Yes. Authenticated users shouldn't get any access to those details: > >>>> ipantsupportedencryptiontypes > >>>> ipanttrustattributes > >>>> ipanttrustauthincoming > >>>> ipanttrustauthoutgoing > >>>> > >>>> > >>> > >>> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group should > >>> then have this permission assigned so that samba can operate the attributes. > >> 'adtrust agents' and 'trust administrators' should have read, modify, > >> delete, and search on cn=trusts. > >> > > > >Right. We will probably want to turn most of ACIs in > >install/updates/60-trusts.update in managed permissions (i.e. defined in > >trust.py) and make "adtrust agents" and "trust admins" it's members. > I agree. > +1 Simo. From rcritten at redhat.com Wed Apr 16 15:59:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Apr 2014 11:59:46 -0400 Subject: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount In-Reply-To: <534E98BD.2080400@redhat.com> References: <534E7441.6020205@redhat.com> <534E98BD.2080400@redhat.com> Message-ID: <534EA8F2.1090708@redhat.com> Martin Kosek wrote: > On 04/16/2014 02:14 PM, Petr Viktorin wrote: >> A single permission granting anonymous read access covers automountlocation, >> automountmap, and automountkey. >> > > This works fine, I am just wondering about the ACI: > > 1) Simo, are you OK with one ACI covering all automount objects? I personally > am, I cannot imagine a situation when somebody allows automount maps but not > the automount keys. But on the other hand, we also have separate permissions > for sudo commands, sudo command groups, sudo rules... With sudo you may want a different set of users deciding WHAT can be executed from WHO can execute it. I don't think automount needs that level of specificity. > > 2) Should we limit the ACI by an objectclass filter? I.e. > (|(objectclass=automountmap)(objectclass=automount))? I think these are the only things living in that container so it may be overkill. I'm not against adding it if someone feels more strongly about it. rob From ssorce at redhat.com Wed Apr 16 16:15:53 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Apr 2014 12:15:53 -0400 Subject: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount In-Reply-To: <534EA8F2.1090708@redhat.com> References: <534E7441.6020205@redhat.com> <534E98BD.2080400@redhat.com> <534EA8F2.1090708@redhat.com> Message-ID: <1397664953.19767.411.camel@willson.li.ssimo.org> On Wed, 2014-04-16 at 11:59 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On 04/16/2014 02:14 PM, Petr Viktorin wrote: > >> A single permission granting anonymous read access covers automountlocation, > >> automountmap, and automountkey. > >> > > > > This works fine, I am just wondering about the ACI: > > > > 1) Simo, are you OK with one ACI covering all automount objects? I personally > > am, I cannot imagine a situation when somebody allows automount maps but not > > the automount keys. But on the other hand, we also have separate permissions > > for sudo commands, sudo command groups, sudo rules... > > With sudo you may want a different set of users deciding WHAT can be > executed from WHO can execute it. I don't think automount needs that > level of specificity. > > > > > 2) Should we limit the ACI by an objectclass filter? I.e. > > (|(objectclass=automountmap)(objectclass=automount))? > > I think these are the only things living in that container so it may be > overkill. I'm not against adding it if someone feels more strongly about it. I think Rob summarized my own thought, and I think he has more authority than I have as he's been working on automount stuff more than I have. Simo. From sbose at redhat.com Wed Apr 16 16:56:25 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Apr 2014 18:56:25 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140416135954.GM20958@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> Message-ID: <20140416165625.GI4165@localhost.localdomain> On Wed, Apr 16, 2014 at 04:59:55PM +0300, Alexander Bokovoy wrote: > On Wed, 16 Apr 2014, Simo Sorce wrote: > >On Wed, 2014-04-16 at 16:15 +0300, Alexander Bokovoy wrote: > >>On Wed, 16 Apr 2014, Simo Sorce wrote: > >>>> + 'ipanttrusteddomainsid', 'ipanttrustforesttrustinfo', > >>>> + 'ipanttrustposixoffset', > >>>> 'ipantsupportedencryptiontypes', > >>>> + 'ipantsidblacklistincoming', > >>>> 'ipantsidblacklistoutgoing', > >>>> + # ipaNTDomainAttrs: > >>>> + 'ipantsecurityidentifier', 'ipantflatname', > >>>> 'ipantdomainguid', > >>>> + 'ipantfallbackprimarygroup', > >>>> + }, > >>>> + }, > >>>> + } > >>>> > >>>> label = _('Trusts') > >>>> label_singular = _('Trust') > >>> > >>>In general I am not sure all authenticated users need access to all this > >>>info. Alexander ? > >>SSSD needs to read some of this information for subdomains support. > >>That would be at least host/*@REALM who needs to access it. > > > >Can you please list exactly which ones are needed ? > SSSD subdomains support needs: > - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs > - ipaNTFlatName > - ipaNTSecurityIdentifier > - ipaNTTrustedDomainSID > - cn > > - objectclass ipaIDRange > - cn > - ipaBaseID > - ipaIDRangeSize > - ipaBaseRID > - ipaSecondaryBaseRID iparangetype and ipanttrusteddomainsid are needed as well. bye, Sumit > > > > > > > >Simo. > > > > > > > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From dpal at redhat.com Thu Apr 17 00:33:02 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 16 Apr 2014 20:33:02 -0400 Subject: [Freeipa-devel] Ipa-server-install Firewall Support In-Reply-To: <534E7A0F.3020200@redhat.com> References: <533E509A.4000004@redhat.com> <533E5C8A.20306@redhat.com> <533E6665.6000402@redhat.com> <1396617621.18479.64.camel@willson.li.ssimo.org> <5342A18B.7070701@redhat.com> <534339FD.3090901@redhat.com> <534442FA.1060709@redhat.com> <5345EC92.3010008@redhat.com> <534E7A0F.3020200@redhat.com> Message-ID: <534F213E.30503@redhat.com> On 04/16/2014 08:39 AM, Martin Kosek wrote: > On 04/16/2014 09:56 AM, Justin Brown wrote: > ... >> L: This is interesting, and I have a couple of questions on how this >> should work. >> >> 1) Is there an actual use-case when a tool actually would want to >> check status of a port without correcting it? It seems to me that any >> sort of is_port_open() call that returned False would be immediately >> followed by open_port(). If that's the case, then why not just roll >> them into one operation? There won't be any firewall reload if no >> modifications take place, so there's no cost to combining them. We >> could also find a middle ground where there's only one method with a >> default parameter open_port(..., auto_add=True). > I can imagine situations when we would want to see if a port is open in a > firewall and then ask user if he wants to automatically open it. In such cases, > 2 separate calls would be indeed helpful. > >> 2) Will these tools be executed as root? To query NM and FirewallD, I >> have to connect to the system bus, which by default, won't allow >> access from other users without additional authorization. If >> non-privileged users need to query the firewall configuration, I'll >> need to look at the DBus policy more closely. > In situations when we are about to manipulate ports, I think it is safe to > assume we are operating under root account. I think you can have this > assumption in your current code and do not deal with additional authorization > at this point. > > We can think about this case when we need it. > >> 3) Could you point me at a similar tool that has this check and modify >> behavior? > There are many situations in FreeIPA interactive wizards where we have a pattern > > do_action = check_something() > > if do_action: > do_something() > > For example, ipa-adtrust-install is checking if there are any users without SID > assigned and if there are, it offers to run a task to add them. > > Martin +1 on all -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Apr 17 01:02:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 16 Apr 2014 21:02:00 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140415091338.GE4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> Message-ID: <534F2808.5010708@redhat.com> On 04/15/2014 05:13 AM, Sumit Bose wrote: > Hi, > > I have started to write a design page for 'Migrating existing > environments to Trust' > http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > https://fedorahosted.org/freeipa/ticket/3979 . > > I came across several questions which need answers so that more details > can be added to the design. Besides that comments and suggestions are > welcome as well. > > For your convenience I added the test below as well. > > bye, > Sumit > > = Overview = > > This page illustrates how existing solutions which make AD users > available to Linux hosts can be migrated to FreeIPA with Trusts. This > includes migrations from the FreeIPA WinSync feature or environments > where the AD users where correlated to NIS users. > > The common problem here is that some if not all attributes needed by a > POSIX user or group must be overwritten or supplied by the IPA server. > The link to the related AD object is preferably the SID but if it is not > available on both sides the name of the object must be used. AD will > keep the responsibility for authentication and provide the AD > group-memberships of the object. > > = Use Cases = > * Migration from the FreeIPA Sync solution to the FreeIPA Trust solution > ** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] > * Migration/Consolidation of domains currently managed by other solutions, e.g. NIS > ** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) As I mentioned in the ticket not only that. Based on conversations with different potential consumers of the trust functionality the ability to use existing POSIX attributes and manage them in IPA while user accounts come from AD is a crucial next step. > > = Design = > In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. > # Instead of just offering a single override option the introduction of > views are suggested. A suitable client can ask for a specific view > with override options different from the default override > view. Yes. > Questions: > #* Will the default view always be applied? I think it makes sense to > always apply it to get a consistent default behavior. If there is a > reason for a client to get the unmodified data a special view called > e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin > to be able to send the raw data to the IPA client so that SSSD can use > different views on the client which might be needed for docker/container > use cases. Sounds reasonable to have the default view and apply it always. If the view does not contain posix attributes for the specific user we should use dynamic mapping based on SIDs. > #* Will views only be applied to users from other domains or to IPA > users as well? Design goal will be to allow them to be applied to all users. Implementation goal will be to apply them to external users first. Or I should say we need to figure out the procedure: 1) Pre migration: AD with no POSIX, LDAP/NIS with POSIX for some/same users. 2) Past migration: AD with no POSIX, no duplicate accounts in IdM, POSIX attributes for AD users are migrated into a view. How we do it is the question but we need to have a path. May be it would require some kind of tool: ipa create-view --check This will go through all users in IPA and check them against available trusted domains and would report which users will be removed becuase they are found in a specific domain. ipa create-view --create --except= This will actually do the work but if there are special users that need to be processed in some special way admin might temporarily put them into a specific group and then exclude this group or groups from cleanup. Just a thought... > #* Do we want stackable views? We want client oriented views. I.e. views should be attached to host groups. For the legacy clients there should be a way to expose a view as a separate base=DN so that one set of legacy clients can be pointed to one DN and another to another. If the host based views and DN based views do not have data for a specific user the data should be fetched from a global default view. I think we can use CoS for that in conjunction with the compat plugin but I would leave this to experts to decide. Bottom line: one global fallback view and then specific views for host groups and for legacy clients. I know I might be asking a lot ;-) > #* Do we want to override everything or shall there be immutable > attributes like e.g. the SID or the user name? I do not know why would overwrite the SID but I think that overwriting the user name would give us an interesting aliasing capability as a feature as a side effect. > #* Shall we allow different UIDs/GIDs in different views? Yes. > #* I think overriding UIDs/GIDs should only be allowed for > ipa-ad-trust-posix idranges, mixing override with algorithmic mapping > does not make sense imo. I think it does at least for the migration time. But it might not be achievable. The idea is that you really should be required to manage UID/GID for the users manually via views if it is an old user. If it is a new user that never was on the Linux side before the algorithmic mapping might be preferred. But I also think that this should be controlled by a policy and admin would have to decide whether the IPA should generate UIDs or he would prefer to set the manually explicitly. > # The views will be stored in containers below > cn=views,cn=accounts,$SUFFIX with containers for users and groups. The > objectclasses will look similar to posixAccount and posixGroup > objectclasses but with only optional (MAY) attributes. Questions: > #* Do we want to consider to allow to add arbitrary attributes to a view > to cover requests like "We have this beautiful application which can get > all user data via the SSSD D-BUS responder but our AD admin will not > extend the AD LDAP schema to add the required attributes. Can IPA add > them for users from trusted domains?" Yes but probably not as phase 1. So it is a separate enhancement. > #* It was suggested to use a UUID to reference the original objects. For > AD users and groups the SID would be a good choice because it is unique > and already contains a reference to the original domain. I wonder if we > should add a type prefix like 'SID:' to be able to add other types like > 'IPAUUID:domref:ef2b7400-a3c4-11e3-82e7-525400de2951' where domref will > be a reference to the other IPA domain. On the other hand a type can be > added later and if the type is missing a SID is assumed. > > On the SSSD side the views can be stored below the corresponding user or > group object in the cache and the SYSDB API has to be enhanced to return > merged results. The merging only happens in the responders (NSS, D-BUS) > before sending data to the clients. Why SSSD should know about different views? It should know raw and not raw but it always sees one merged view from the server. What am I missing? > > To manage the views a new set CLI tools/Web UI pages should be added. > Depending if we would like to allow to override IPA users as well or > only users from trusted domains the tools might get their own name > space, ipa override-*, or can be added below the trust name space, ipa > trust-override-*. It has to be noted that changes of a view will only > be visible on the client after the related cached object is expired. OK. > > = Implementation = See comments above. I hope they give enough hints for implementation. At least for the first pass. > =Feature Management = > == UI == > == CLI == > > = Major configuration options and enablement = > Any configuration options? Any commands to enable/disable the feature or > turn on/off its parts? > > = Replication = > Any impact on replication? > > = Updates and Upgrades = > Any impact on updates and upgrades? > > = Dependencies = > Any new package and library dependencies. > > = External Impact = > Impact on other development teams and components > > = Backup and Restore = > Any files or configuration that needs to be taken care of in backup or > restore procedure. > > = Test Plan = > Test scenarios that will be transformed to test cases for FreeIPA > Continuous Integration during implementation or review phase. > > = RFE Author = > [[User:Sbose|Sumit Bose]] > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Thu Apr 17 05:51:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Apr 2014 07:51:50 +0200 Subject: [Freeipa-devel] [PATCH] 0528 Add managed read permission to automount In-Reply-To: <1397664953.19767.411.camel@willson.li.ssimo.org> References: <534E7441.6020205@redhat.com> <534E98BD.2080400@redhat.com> <534EA8F2.1090708@redhat.com> <1397664953.19767.411.camel@willson.li.ssimo.org> Message-ID: <534F6BF6.5050302@redhat.com> On 04/16/2014 06:15 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 11:59 -0400, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 04/16/2014 02:14 PM, Petr Viktorin wrote: >>>> A single permission granting anonymous read access covers automountlocation, >>>> automountmap, and automountkey. >>>> >>> >>> This works fine, I am just wondering about the ACI: >>> >>> 1) Simo, are you OK with one ACI covering all automount objects? I personally >>> am, I cannot imagine a situation when somebody allows automount maps but not >>> the automount keys. But on the other hand, we also have separate permissions >>> for sudo commands, sudo command groups, sudo rules... >> >> With sudo you may want a different set of users deciding WHAT can be >> executed from WHO can execute it. I don't think automount needs that >> level of specificity. >> >>> >>> 2) Should we limit the ACI by an objectclass filter? I.e. >>> (|(objectclass=automountmap)(objectclass=automount))? >> >> I think these are the only things living in that container so it may be >> overkill. I'm not against adding it if someone feels more strongly about it. > > > I think Rob summarized my own thought, and I think he has more authority > than I have as he's been working on automount stuff more than I have. > > Simo. Thanks for discussion. In that case, the ACI is good as is. ACK. Pushed to master: adde918f38a7df8f72e5293d1d0c5a5637b7e5a8 Martin From mkosek at redhat.com Thu Apr 17 06:26:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Apr 2014 08:26:53 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140416165625.GI4165@localhost.localdomain> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <20140416165625.GI4165@localhost.localdomain> Message-ID: <534F742D.7000101@redhat.com> On 04/16/2014 06:56 PM, Sumit Bose wrote: > On Wed, Apr 16, 2014 at 04:59:55PM +0300, Alexander Bokovoy wrote: >> On Wed, 16 Apr 2014, Simo Sorce wrote: ... >>> Can you please list exactly which ones are needed ? ... >> - objectclass ipaIDRange >> - cn >> - ipaBaseID >> - ipaIDRangeSize >> - ipaBaseRID >> - ipaSecondaryBaseRID > > iparangetype and ipanttrusteddomainsid are needed as well. > > bye, > Sumit > Thanks. But in case of ID Ranges we are safe as we exposed all ID range attributes to all authenticated users (hosts). Trust objects are different, we plan to have at least 2 permissions so that only needed attributes are exposed. Martin From pviktori at redhat.com Thu Apr 17 08:05:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 10:05:00 +0200 Subject: [Freeipa-devel] [PATCH] Do not ask for memberindirect when updating managed permissions In-Reply-To: <534E8C7D.5020004@redhat.com> References: <5347D28A.2020300@redhat.com> <534E40D5.10502@redhat.com> <1397656356.19767.400.camel@willson.li.ssimo.org> <534E8C7D.5020004@redhat.com> Message-ID: <534F8B2C.5010300@redhat.com> On 04/16/2014 03:58 PM, Martin Kosek wrote: > On 04/16/2014 03:52 PM, Simo Sorce wrote: >> On Wed, 2014-04-16 at 10:35 +0200, Jan Cholasta wrote: >>> On 11.4.2014 13:31, Petr Viktorin wrote: >>>> One of the default_attributes of permission is memberofindirect, a >>>> virtual attribute manufactured by ldap2, which is set when a permission >>>> is part of a role. >>>> When update_entry is called on an entry with memberofindirect, ipaldap >>>> tries to add the attribute to LDAP and fails with an objectclass violation. >>>> >>>> Do not ask for memberindirect when retrieving the entry. >>>> >>>> >>>> >>>> CCing Honza since he designs ipaldap. Virtual attributes are often >>>> helpful, and in any case IPA uses them a lot and having to filter them >>>> out every time is error-prone. >>>> Maybe we should add support for them directly in ipaldap -- e.g. an >>>> attribute set by `entry.virtual[attr_name] = [x]` would be visible in >>>> entry[attr_name] but would not be synced back to LDAP? >>>> >>> >>> I would prefer if we stopped abusing LDAPEntry to handle non-LDAP stuff >>> in the future. Your suggestion works in sort of opposite direction, so I >>> can't say I like it. >>> >>> Currently we use LDAPEntry in frontend code directly, but I think that's >>> wrong. There should be a frontend-specific class for this (make >>> ipalib.frontend.Object instantiable?) and LDAPEntry should be used >>> (almost) only in backend code. >> >> +1 >> >> Simo. > > We are then stuck with Petr's original patch 518 - ACK from me. > > Martin > Thanks, pushed to master: 81b0e7466d739a61b16c0e79c660a9f85d073c8c -- Petr? From sbose at redhat.com Thu Apr 17 09:15:39 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 17 Apr 2014 11:15:39 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <534F2808.5010708@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> Message-ID: <20140417091539.GJ4165@localhost.localdomain> On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: > On 04/15/2014 05:13 AM, Sumit Bose wrote: > >Hi, > > > >I have started to write a design page for 'Migrating existing > >environments to Trust' > >http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust > >It shall cover https://fedorahosted.org/freeipa/ticket/3318 and > >https://fedorahosted.org/freeipa/ticket/3979 . > > > >I came across several questions which need answers so that more details > >can be added to the design. Besides that comments and suggestions are > >welcome as well. > > > >For your convenience I added the test below as well. > > > >bye, > >Sumit > > > >= Overview = > > > >This page illustrates how existing solutions which make AD users > >available to Linux hosts can be migrated to FreeIPA with Trusts. This > >includes migrations from the FreeIPA WinSync feature or environments > >where the AD users where correlated to NIS users. > > > >The common problem here is that some if not all attributes needed by a > >POSIX user or group must be overwritten or supplied by the IPA server. > >The link to the related AD object is preferably the SID but if it is not > >available on both sides the name of the object must be used. AD will > >keep the responsibility for authentication and provide the AD > >group-memberships of the object. > > > >= Use Cases = > >* Migration from the FreeIPA Sync solution to the FreeIPA Trust solution > >** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] > >* Migration/Consolidation of domains currently managed by other solutions, e.g. NIS > >** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) > > As I mentioned in the ticket not only that. Based on conversations > with different potential consumers of the trust functionality the > ability to use existing POSIX attributes and manage them in IPA > while user accounts come from AD is a crucial next step. Thank you for your feedback, it was very helpful but I'm afraid it might also caused some new questions. > > > > >= Design = > >In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. > ># Instead of just offering a single override option the introduction of > > views are suggested. A suitable client can ask for a specific view > > with override options different from the default override > > view. > > Yes. > > >Questions: > >#* Will the default view always be applied? I think it makes sense to > > always apply it to get a consistent default behavior. If there is a > > reason for a client to get the unmodified data a special view called > > e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin > > to be able to send the raw data to the IPA client so that SSSD can use > > different views on the client which might be needed for docker/container > > use cases. > > Sounds reasonable to have the default view and apply it always. If > the view does not contain posix attributes for the specific user we > should use dynamic mapping based on SIDs. Quite some time ago we have decided to not mix algorithmic mapping and manually managed POSIX IDs. E.g. think about the case where a view with POSIX ID was added for an existing user which already has an algorithmic ID assigned on some clients. I think the admin has to decide what he wants. Below you mentioned a migration use case where old users should keep their IDs but new users will get algorithmically generated ones. I think this is bad practice and technically is it next to impossible without additional admin effort to decide if a given AD user is an old or a new user. The admin either has to add special flags/attributes to the old AD user objects or we have to keep an immutable list of old users in IPA. Please note that this has to be done for groups as well. Imo it would be easier and safer for the admin to either do a full migration to algorithmically mapped IDs or manage all POSIX IDs manually on the IPA side. Additionally I think that in your use case there might be even the need to manually manage POSIX IDs even for new user. E.g. in the case where a larger amount of new users is added to AD which where managed by a completely independent system before. > > >#* Will views only be applied to users from other domains or to IPA > > users as well? > Design goal will be to allow them to be applied to all users. Why, what is the use case to override attribute of IPA users which cannot be solved by adding other attributes with the needed values to the IPA user object directly? > Implementation goal will be to apply them to external users first. > Or I should say we need to figure out the procedure: > 1) Pre migration: AD with no POSIX, LDAP/NIS with POSIX for some/same users. > 2) Past migration: AD with no POSIX, no duplicate accounts in IdM, > POSIX attributes for AD users are migrated into a view. > > How we do it is the question but we need to have a path. May be it > would require some kind of tool: > ipa create-view --check > > This will go through all users in IPA and check them against > available trusted domains and would report which users will be > removed becuase they are found in a specific domain. I think it should only report conflicts. The admin should decide how to solve the conflict. > ipa create-view --create --except= > > This will actually do the work but if there are special users that > need to be processed in some special way admin might temporarily put > them into a specific group and then exclude this group or groups > from cleanup. > > Just a thought... > > >#* Do we want stackable views? > > We want client oriented views. I.e. views should be attached to host groups. > For the legacy clients there should be a way to expose a view as a > separate base=DN so that one set of legacy clients can be pointed to > one DN and another to another. I'm not sure if this will stretch the compat tree too much, I let Alexander and Nalin decided. > > If the host based views and DN based views do not have data for a > specific user the data should be fetched from a global default view. > I think we can use CoS for that in conjunction with the compat > plugin but I would leave this to experts to decide. > > Bottom line: one global fallback view and then specific views for > host groups and for legacy clients. > I know I might be asking a lot ;-) How shall this 'global default view' work? E.g. if there is an AD user without a POSIX ID in AD and algorithmic mapping is not enabled for this user. If there is no override object for this user in the current view or if the override object does not contains a POSIX ID attribute where should the ID come from? Please note that it is a valid use-case that a user does not has a POSIX ID e.g. web applications. I think it is not necessary to forcefully try to assign some POSIX ID to a user. If the admin decides that the user does not need one, why shall we try to create one? > > > >#* Do we want to override everything or shall there be immutable > > attributes like e.g. the SID or the user name? > > I do not know why would overwrite the SID but I think that > overwriting the user name would give us an interesting aliasing > capability as a feature as a side effect. But is there a use case for such a feature which is not solved better by creating a new user with the given name? Please note the side effects, e.g. with respect to the home-directory path. Typically the user name is part of the of path. What if the original object has a home-directory path shall we override it implicitly as well or keep it and who shall decided? Or what about Kerberos principals, who shall user 'abc' know that his name was overridden and his Kerberos principal is 'xyz at AD.REALM'? > > >#* Shall we allow different UIDs/GIDs in different views? > > Yes. I hope the admin knows what he does in this case. I think it's similar like with the user name, is there really a user-case for this with cannot be solved better by creating a new user with the given UID? Think about what happens if a host is moved to a new host group e.g. to change the HBAC rules but by chance has now a different view with different UIDs? >From the OS point of view a user with a different UID is a different user, from the peoples point of view a user with a different name is a different user. I think what we achieve with allowing different values for user names and/or UIDs is to allow different users share the same password, Kerberos credentials etc and I'm not sure we really want this. > > >#* I think overriding UIDs/GIDs should only be allowed for > > ipa-ad-trust-posix idranges, mixing override with algorithmic mapping > > does not make sense imo. > > I think it does at least for the migration time. But it might not be > achievable. > The idea is that you really should be required to manage UID/GID for > the users manually via views if it is an old user. > If it is a new user that never was on the Linux side before the > algorithmic mapping might be preferred. see above > But I also think that this should be controlled by a policy and > admin would have to decide whether the IPA should generate UIDs or > he would prefer to set the manually explicitly. yes, this can already be controlled by the idrange type. But you have to choose either algorithmic or manual mapping you cannot have both in a given domain. What you can do is to create a domain in the AD forest for the old users and one for the new users. Now you can use manual mapping for the old-users-domain and algorithmic mapping for the new-users-domain. > > ># The views will be stored in containers below > > cn=views,cn=accounts,$SUFFIX with containers for users and groups. The > > objectclasses will look similar to posixAccount and posixGroup > > objectclasses but with only optional (MAY) attributes. Questions: > >#* Do we want to consider to allow to add arbitrary attributes to a view > > to cover requests like "We have this beautiful application which can get > > all user data via the SSSD D-BUS responder but our AD admin will not > > extend the AD LDAP schema to add the required attributes. Can IPA add > > them for users from trusted domains?" > Yes but probably not as phase 1. So it is a separate enhancement. > > >#* It was suggested to use a UUID to reference the original objects. For > > AD users and groups the SID would be a good choice because it is unique > > and already contains a reference to the original domain. I wonder if we > > should add a type prefix like 'SID:' to be able to add other types like > > 'IPAUUID:domref:ef2b7400-a3c4-11e3-82e7-525400de2951' where domref will > > be a reference to the other IPA domain. On the other hand a type can be > > added later and if the type is missing a SID is assumed. > > > >On the SSSD side the views can be stored below the corresponding user or > >group object in the cache and the SYSDB API has to be enhanced to return > >merged results. The merging only happens in the responders (NSS, D-BUS) > >before sending data to the clients. > > Why SSSD should know about different views? > It should know raw and not raw but it always sees one merged view > from the server. > What am I missing? You miss the docker/container use case where a central SSSD instance is used by instances with different host names which might belong to different host groups and hence require different views. So SSSD does not only need to know all views but the host groups (we already have them for HBAC) and their corresponding views as well. Although this use case is work-in-progress I think we should include it from the start because the extra work to read all views quite small and might be a larger effort when added later. bye, Sumit > > > >To manage the views a new set CLI tools/Web UI pages should be added. > >Depending if we would like to allow to override IPA users as well or > >only users from trusted domains the tools might get their own name > >space, ipa override-*, or can be added below the trust name space, ipa > >trust-override-*. It has to be noted that changes of a view will only > >be visible on the client after the related cached object is expired. > > OK. > > > > >= Implementation = > See comments above. I hope they give enough hints for > implementation. At least for the first pass. > > >=Feature Management = > >== UI == > >== CLI == > > > >= Major configuration options and enablement = > >Any configuration options? Any commands to enable/disable the feature or > >turn on/off its parts? > > > >= Replication = > >Any impact on replication? > > > >= Updates and Upgrades = > >Any impact on updates and upgrades? > > > >= Dependencies = > >Any new package and library dependencies. > > > >= External Impact = > >Impact on other development teams and components > > > >= Backup and Restore = > >Any files or configuration that needs to be taken care of in backup or > >restore procedure. > > > >= Test Plan = > >Test scenarios that will be transformed to test cases for FreeIPA > >Continuous Integration during implementation or review phase. > > > >= RFE Author = > >[[User:Sbose|Sumit Bose]] > > > >_______________________________________________ > >Freeipa-devel mailing list > >Freeipa-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/freeipa-devel > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Thu Apr 17 10:03:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 12:03:32 +0200 Subject: [Freeipa-devel] [PATCH] 0525 Add managed read permissions to automember In-Reply-To: <534E951D.9090405@redhat.com> References: <534D270B.8070307@redhat.com> <534E951D.9090405@redhat.com> Message-ID: <534FA6F4.9070402@redhat.com> On 04/16/2014 04:35 PM, Martin Kosek wrote: > On 04/15/2014 02:33 PM, Petr Viktorin wrote: >> Read access to both rules and definitions is given to a new privilege, >> 'Automember Readers', as well as the existing 'Automember Task Administrator'. > > This needs a mild rebase in 40-delegation.update. When I resolved the conflict > patch worked fine, no problem found. > > ACK when you fix the conflict. Rebased to current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0525.2-Add-managed-read-permissions-to-automember.patch Type: text/x-patch Size: 3251 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 17 10:21:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 12:21:06 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <1397653483.19767.389.camel@willson.li.ssimo.org> References: <534BBE8A.6080101@redhat.com> <1397484037.19767.243.camel@willson.li.ssimo.org> <534E6085.3000002@redhat.com> <534E6A13.1070203@redhat.com> <1397652945.19767.384.camel@willson.li.ssimo.org> <534E7EEB.5080903@redhat.com> <1397653483.19767.389.camel@willson.li.ssimo.org> Message-ID: <534FAB12.2020808@redhat.com> On 04/16/2014 03:04 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 15:00 +0200, Petr Viktorin wrote: >>>> Simo, Rob, would you be OK with changing virtual operation >> objectclass to our >>>> own one to have a better control over it? >>> >>> No, in general I am not ok to change objects that already exist in >> IPA >>> as it make upgrades with new and old replicas break the old >> replicas. >>> >>> Also we can add new auxiliray classes but removing structural >> classes is >>> not possible, you would have to delete and recreate the object, and >> that >>> would be racy too. >> >> I see. >> How about adding a new objectClass in addition to nsContainer, and >> using >> a negative targetfilter? >> > I have no objection to that, but should be last resort if we have no > other way IMO, and valid only for objects that are not normally created > on a daily basis, as old replicas creating new objects would not know to > add the new objectclass. > In this case it seem like we should be ok as we do not commonly create > these objects, so the chances an old replica creates them are > negligible. > > Simo. > Alright. I've reserved 2.16.840.1.113730.3.8.12.23 for a new ipaVirtualOperation objectclass. Let me know if I should use a different one. -- Petr? From tbabej at redhat.com Thu Apr 17 10:22:32 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Apr 2014 12:22:32 +0200 Subject: [Freeipa-devel] Ipatests fixes In-Reply-To: <53452FF5.1080601@redhat.com> References: <53451BE3.2070406@redhat.com> <53452FF5.1080601@redhat.com> Message-ID: <534FAB68.70401@redhat.com> On 04/09/2014 01:33 PM, Petr Viktorin wrote: > On 04/09/2014 12:07 PM, Tomas Babej wrote: >> Hi, >> >> the following batch deals with the following: >> >> * cleans up apache's semaphores prior to installing IPA (CA install can >> get stuck when IPA is reinstalled many times) > > What happens if Apache is running for some reason? Should we also stop > it before deleting the semaphores? Agreed, if for any reason apache is running, we should stop it beforehand. Fixed. > >> * allows to pass extra arguments to install_client task > > Please avoid mutable argument defaults; use `extra_args=()` and then > `list(extra_args)` Fixed. > >> * uses trailing dot in the hostname as fqdn which should not be >> overridden by domain name > > ACK. > >> * fixes incorrect assert for UIDs/GIDs in legacy client tests > > ACK, this fixes a lot of failures (though not all of them yet). > Updated patches attached. -- 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-0168-2-ipatests-Fix-apache-semaphores-prior-to-installing-I.patch Type: text/x-patch Size: 1848 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0169-2-ipatests-tasks-Accept-extra-arguments-when-installin.patch Type: text/x-patch Size: 1303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0170-ipatests-Allow-using-FQDN-with-trailing-dot-as-final.patch Type: text/x-patch Size: 1548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0171-ipatests-Fix-incorrect-UID-GID-reference-for-subdoma.patch Type: text/x-patch Size: 2294 bytes Desc: not available URL: From abokovoy at redhat.com Thu Apr 17 10:25:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Apr 2014 13:25:08 +0300 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140417091539.GJ4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> Message-ID: <20140417102508.GR20958@redhat.com> On Thu, 17 Apr 2014, Sumit Bose wrote: >On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: >> On 04/15/2014 05:13 AM, Sumit Bose wrote: >> >Hi, >> > >> >I have started to write a design page for 'Migrating existing >> >environments to Trust' >> >http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust >> >It shall cover https://fedorahosted.org/freeipa/ticket/3318 and >> >https://fedorahosted.org/freeipa/ticket/3979 . >> > >> >I came across several questions which need answers so that more details >> >can be added to the design. Besides that comments and suggestions are >> >welcome as well. >> > >> >For your convenience I added the test below as well. >> > >> >bye, >> >Sumit >> > >> >= Overview = >> > >> >This page illustrates how existing solutions which make AD users >> >available to Linux hosts can be migrated to FreeIPA with Trusts. This >> >includes migrations from the FreeIPA WinSync feature or environments >> >where the AD users where correlated to NIS users. >> > >> >The common problem here is that some if not all attributes needed by a >> >POSIX user or group must be overwritten or supplied by the IPA server. >> >The link to the related AD object is preferably the SID but if it is not >> >available on both sides the name of the object must be used. AD will >> >keep the responsibility for authentication and provide the AD >> >group-memberships of the object. >> > >> >= Use Cases = >> >* Migration from the FreeIPA Sync solution to the FreeIPA Trust solution >> >** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] >> >* Migration/Consolidation of domains currently managed by other solutions, e.g. NIS >> >** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) >> >> As I mentioned in the ticket not only that. Based on conversations >> with different potential consumers of the trust functionality the >> ability to use existing POSIX attributes and manage them in IPA >> while user accounts come from AD is a crucial next step. > >Thank you for your feedback, it was very helpful but I'm afraid it might >also caused some new questions. > >> >> > >> >= Design = >> >In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. >> ># Instead of just offering a single override option the introduction of >> > views are suggested. A suitable client can ask for a specific view >> > with override options different from the default override >> > view. >> >> Yes. >> >> >Questions: >> >#* Will the default view always be applied? I think it makes sense to >> > always apply it to get a consistent default behavior. If there is a >> > reason for a client to get the unmodified data a special view called >> > e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin >> > to be able to send the raw data to the IPA client so that SSSD can use >> > different views on the client which might be needed for docker/container >> > use cases. >> >> Sounds reasonable to have the default view and apply it always. If >> the view does not contain posix attributes for the specific user we >> should use dynamic mapping based on SIDs. > >Quite some time ago we have decided to not mix algorithmic mapping and >manually managed POSIX IDs. E.g. think about the case where a view with >POSIX ID was added for an existing user which already has an algorithmic >ID assigned on some clients. > >I think the admin has to decide what he wants. Below you mentioned a >migration use case where old users should keep their IDs but new users >will get algorithmically generated ones. I think this is bad practice >and technically is it next to impossible without additional admin >effort to decide if a given AD user is an old or a new user. The admin >either has to add special flags/attributes to the old AD user objects or >we have to keep an immutable list of old users in IPA. Please note that >this has to be done for groups as well. Imo it would be >easier and safer for the admin to either do a full migration to >algorithmically mapped IDs or manage all POSIX IDs manually on the IPA >side. > >Additionally I think that in your use case there might be even the need >to manually manage POSIX IDs even for new user. E.g. in the case where a >larger amount of new users is added to AD which where managed by a >completely independent system before. For this case admins could force manual POSIX mapping even if there are no POSIX attributes in AD, then use views to supply proper IDs to those users that require them. >> >> >#* Will views only be applied to users from other domains or to IPA >> > users as well? >> Design goal will be to allow them to be applied to all users. > >Why, what is the use case to override attribute of IPA users which >cannot be solved by adding other attributes with the needed values to >the IPA user object directly? I agree, why should we introduce a new level of shadowing for IPA users given that the only tool that would accept these views would be a new SSSD version. I could understand that shadowing to IPA users on selected old clients or machines not under IPA control (NFS filers, for example) but there are no means to force them to use views we are designing here. >> Implementation goal will be to apply them to external users first. >> Or I should say we need to figure out the procedure: >> 1) Pre migration: AD with no POSIX, LDAP/NIS with POSIX for some/same users. >> 2) Past migration: AD with no POSIX, no duplicate accounts in IdM, >> POSIX attributes for AD users are migrated into a view. >> >> How we do it is the question but we need to have a path. May be it >> would require some kind of tool: >> ipa create-view --check >> >> This will go through all users in IPA and check them against >> available trusted domains and would report which users will be >> removed becuase they are found in a specific domain. > >I think it should only report conflicts. The admin should decide how to >solve the conflict. Agreed. >> ipa create-view --create --except= >> >> This will actually do the work but if there are special users that >> need to be processed in some special way admin might temporarily put >> them into a specific group and then exclude this group or groups >> from cleanup. >> >> Just a thought... >> >> >#* Do we want stackable views? >> >> We want client oriented views. I.e. views should be attached to host groups. >> For the legacy clients there should be a way to expose a view as a >> separate base=DN so that one set of legacy clients can be pointed to >> one DN and another to another. > >I'm not sure if this will stretch the compat tree too much, I let >Alexander and Nalin decided. Technically it is possible but configurable manually and not replicable as configuration is in cn=config. >> >> If the host based views and DN based views do not have data for a >> specific user the data should be fetched from a global default view. >> I think we can use CoS for that in conjunction with the compat >> plugin but I would leave this to experts to decide. >> >> Bottom line: one global fallback view and then specific views for >> host groups and for legacy clients. >> I know I might be asking a lot ;-) > >How shall this 'global default view' work? E.g. if there is an AD user >without a POSIX ID in AD and algorithmic mapping is not enabled for this >user. If there is no override object for this user in the current view >or if the override object does not contains a POSIX ID attribute where >should the ID come from? It is unclear to me as well. I could understand if there would have been a way to override certain properties based on a regular expression or a membership but this is pushing too far the whole idea and basically locking down further migrations. >> >#* Shall we allow different UIDs/GIDs in different views? >> >> Yes. > >I hope the admin knows what he does in this case. I think it's similar >like with the user name, is there really a user-case for this with >cannot be solved better by creating a new user with the given UID? Think >about what happens if a host is moved to a new host group e.g. to change >the HBAC rules but by chance has now a different view with different >UIDs? Again, question is what purpose would such view serve? Given that only new SSSD version can resolve these views properly and a likely reason for deviating would be to present such a user somewhere on a legacy system, I see certain conflict of use case wishes. -- / Alexander Bokovoy From mkosek at redhat.com Thu Apr 17 10:42:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Apr 2014 12:42:37 +0200 Subject: [Freeipa-devel] [PATCH] 0525 Add managed read permissions to automember In-Reply-To: <534FA6F4.9070402@redhat.com> References: <534D270B.8070307@redhat.com> <534E951D.9090405@redhat.com> <534FA6F4.9070402@redhat.com> Message-ID: <534FB01D.9030808@redhat.com> On 04/17/2014 12:03 PM, Petr Viktorin wrote: > On 04/16/2014 04:35 PM, Martin Kosek wrote: >> On 04/15/2014 02:33 PM, Petr Viktorin wrote: >>> Read access to both rules and definitions is given to a new privilege, >>> 'Automember Readers', as well as the existing 'Automember Task Administrator'. >> >> This needs a mild rebase in 40-delegation.update. When I resolved the conflict >> patch worked fine, no problem found. >> >> ACK when you fix the conflict. > > Rebased to current master. This is ok, ACK. Pushed to master: 1e46c0a36159c990e083f771de2c0a18ecdbc42e Martin From pviktori at redhat.com Thu Apr 17 11:45:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 13:45:06 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <1397655692.19767.394.camel@willson.li.ssimo.org> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> Message-ID: <534FBEC2.1040809@redhat.com> On 04/16/2014 03:41 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: >> On 04/15/2014 04:55 PM, Petr Viktorin wrote: >>> Hello, >>> At Devconf, we decided what most of the default read permissions should look >>> like, but we did not get to user. >>> Here is a draft of 4 read permissions. Please comment. >>> >>> >>> Basic info (anonymous): >>> [top] >>> objectclass >>> [person] >>> cn, sn, description >>> [organizationalPerson] >>> title >>> [inetOrgPerson] >>> uid >>> displayName, givenName, initials >>> manager >>> [inetUser] >>> memberOf >> >> <== We originally specifically hidden memberOf attribute from anonymous users. >> I think we should continue hiding it. OK >>> [ipaObject] >>> ipaUniqueID >>> [ipaSshUser] >>> ipaSshPubKey >>> [ipaUserAuthTypeClass] >>> ipaUserAuthType >>> [posixAccount] >>> gecos, gidNumber, homeDirectory, loginShell, uidNumber >>> >>> >>> Details (all authenticated): >>> [person] >>> seeAlso, telephoneNumber >>> [organizationalPerson] >>> fax, l, ou, st, postalCode, street >>> destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName, >>> postalAddress, postOfficeBox, preferredDeliveryMethod, >>> registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address >>> [inetOrgPerson] >>> carLicense, departmentNumber, employeeNumber, employeeType, >>> preferredLanguage, mail, mobile, pager >>> audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, >>> labeledURI, o, photo, roomNumber, secretary, userCertificate, >>> userPKCS12, userSMIMECertificate, x500UniqueIdentifier >>> [inetUser] >>> inetUserHttpURL, inetUserStatus >>> [ipaUser] >>> userClass >> >> I would personally not divide the attributes as basic and detailed. IMO it is >> our artificial distinction and may vary between deployments. Why would we for >> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to everyone? I thought it would be helpful to have a distinction between what needs anonymous read, and what's optional. I can move individual attributes, of course. >> My proposal would be to have a permission "Read User Information" for all >> attributes above. This way a paranoid admin would need to go through the attributes one by one to decide what needs to stay anonymous and what doesn't. Having two permissions makes this easier to tune. But of course I can merge them. >>> Kerberos/login-related (all authenticated): >>> [krbPrincipalAux] >>> krbPrincipalName, krbCanonicalName, krbPrincipalAliases, >>> krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange >>> [+] >>> nsAccountLock >> >> Ok. So permission "Read User Kerberos Attributes"? OK >>> Kerberos-related (user admins only): >>> [krbPrincipalAux] >>> krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange >> >> So permission "Read User Kerberos Login Attributes"? OK >> I think this group should also have: >> >> krbLastAdminUnlock >> krbLoginFailedCount > > +1 > >>> No read permission: >>> [person] >>> userPassword >> >> ok >> >>> [krbPrincipalAux] >>> krbPrincipalKey, krbExtraData, krbPwdHistory >> >> ok >> >>> krbLastAdminUnlock, >> >> Move this one. >> >>> krbLoginFailedCount >> >> Move this one. >> >>> krbPrincipalType >> >> Simo? I know we do not user this attribute, but wouldn't it fit in "Read User >> Kerberos Attributes" permission? > > Yes, we do not use it yet, but we may want to in the future. > >>> krbPwdPolicyReference >> >> This could contain DN to user's password policy attribute. IMO somebody should >> have a right to read it. Simo, should all authenticated users be able to read it? > > Probably not. In another thread we are trying hard to conceal password > policy objects, showing this to everybody would thwart that effort as > you'd be able to find out the objects by querying all the ones that > reference them. Admin and Help Desk people would need access to it > though as they need to be able to inspect and change this attribute. > >>> krbTicketPolicyReference, krbUPEnabled >> >> I would treat those the same as krbPwdPolicyReference. > > Yeah, makes sense. > >>> [krbTicketPolicyAux] >>> krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags >> >> Ok. This will be readable by people with "System: Read User Kerberos Ticket >> Policy" permission. >> >>> [mepOriginEntry] >>> mepManagedEntry >> >> This is used to bind user to it's private group. We use it for example in >> group-detach command to distinguish between managed and non-managed groups. >> >> We may want to show it to all authenticated users. > > Do we need to ? > It is only interesting for internal/administrative operations. > > Simo. > -- Petr? From tbabej at redhat.com Thu Apr 17 12:25:03 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Apr 2014 14:25:03 +0200 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements Message-ID: <534FC81F.60507@redhat.com> Hi, This set of patches deals with bugs and extensions of ipa_range_check plugin. See commit messages for details. Parts of: https://fedorahosted.org/freeipa/ticket/4137 -- 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-0172-ipa_range_check-Use-special-attributes-to-determine-.patch Type: text/x-patch Size: 4637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0173-ipa_range_check-Connect-the-new-node-of-the-linked-l.patch Type: text/x-patch Size: 1057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0174-ipa_range_check-Make-a-new-copy-of-forest_root_id-at.patch Type: text/x-patch Size: 1379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0175-ipa_range_check-Do-not-fail-when-no-trusted-domain-i.patch Type: text/x-patch Size: 1898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0176-ipa_range_check-Fix-typo-when-comparing-strings-usin.patch Type: text/x-patch Size: 1714 bytes Desc: not available URL: From tbabej at redhat.com Thu Apr 17 12:33:09 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 17 Apr 2014 14:33:09 +0200 Subject: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks In-Reply-To: <533A7CB6.9010400@redhat.com> References: <533A7CB6.9010400@redhat.com> Message-ID: <534FCA05.9030900@redhat.com> ACK for 256 - 259. On 04/01/2014 10:45 AM, Jan Cholasta wrote: > Hi, > > while working with Martin Ba?ti on issues in his dns plugin patches we > ran into several limitations in the framework. The attached patches > remove these limitations. > > Also, Tom?? Babej pointed out that when using --raw, all the attribute > names should use letter casing as returned by python-ldap. Patch 259 > implements that. > > See commit messages for details. > > Honza > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From abokovoy at redhat.com Thu Apr 17 12:44:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Apr 2014 15:44:21 +0300 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements In-Reply-To: <534FC81F.60507@redhat.com> References: <534FC81F.60507@redhat.com> Message-ID: <20140417124421.GS20958@redhat.com> On Thu, 17 Apr 2014, Tomas Babej wrote: >>From 43cd26a0a42c3b18e4dbb5c6ed0f20ee1562b98a Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 16 Apr 2014 17:15:55 +0200 >Subject: [PATCH] ipa_range_check: Use special attributes to determine presence > of RID bases > >The slapi_entry_attr_get_ulong which is used to get value of the RID base >attributes returns 0 in case the attribute is not set at all. We need >to distinguish this situation from the situation where RID base attributes >are present, but deliberately set to 0. > >Otherwise this can cause false negative results of checks in the range_check >plugin. > >Part of: https://fedorahosted.org/freeipa/ticket/4137 >--- > .../ipa-range-check/ipa_range_check.c | 40 +++++++++++++++++----- > 1 file changed, 31 insertions(+), 9 deletions(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >index da5169e6e9bf74d5fbbf3aea40ee3e1a2c8f6016..68948f599aa4e6d21b071424ab27e3c62c0afefe 100644 >--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >@@ -88,6 +88,8 @@ struct range_info { > uint32_t id_range_size; > uint32_t base_rid; > uint32_t secondary_base_rid; >+ bool base_rid_set; >+ bool secondary_base_rid_set; > }; > > static void free_range_info(struct range_info *range) { >@@ -281,6 +283,7 @@ static int slapi_entry_to_range_info(struct domain_info *domain_info_head, > int ret; > unsigned long ul_val; > struct range_info *range = NULL; >+ Slapi_Attr *attr; > > range = calloc(1, sizeof(struct range_info)); > if (range == NULL) { >@@ -326,6 +329,20 @@ static int slapi_entry_to_range_info(struct domain_info *domain_info_head, > } > range->secondary_base_rid = ul_val; > >+ if (slapi_entry_attr_find(entry, IPA_BASE_RID, &attr) == -1) { >+ range->base_rid_set = false; >+ } >+ else { >+ range->base_rid_set = true; >+ } You replace this by range->base_rid_set = (slapi_entry_attr_find(entry, IPA_BASE_RID, &attr) == -1); >+ >+ if (slapi_entry_attr_find(entry, IPA_SECONDARY_BASE_RID, &attr) == -1) { >+ range->secondary_base_rid_set = false; >+ } >+ else { >+ range->secondary_base_rid_set = true; >+ } >+ Same here. > *_range = range; > ret = 0; > >@@ -398,12 +415,14 @@ static int check_ranges(struct range_info *r1, struct range_info *r2) > > /* For ipa-local or ipa-ad-trust range types primary RID ranges should > * not overlap */ >+ > if (strcasecmp(r1->id_range_type, AD_TRUST_RANGE_TYPE) == 0 || > strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0) { > >- /* Check if rid range overlaps with existing rid range */ >- if (intervals_overlap(r1->base_rid, r2->base_rid, >- r1->id_range_size, r2->id_range_size)) >+ /* Check if primary rid range overlaps with existing primary rid range */ >+ if ((r1->base_rid_set && r2->base_rid_set) && >+ intervals_overlap(r1->base_rid, r2->base_rid, >+ r1->id_range_size, r2->id_range_size)) > return 2; > } > >@@ -412,18 +431,21 @@ static int check_ranges(struct range_info *r1, struct range_info *r2) > > /* Check if secondary RID range overlaps with existing secondary or > * primary RID range. */ >- if (intervals_overlap(r1->secondary_base_rid, >- r2->secondary_base_rid, r1->id_range_size, r2->id_range_size)) >+ if ((r1->secondary_base_rid_set && r2->secondary_base_rid_set) && >+ intervals_overlap(r1->secondary_base_rid, r2->secondary_base_rid, >+ r1->id_range_size, r2->id_range_size)) > return 3; > > /* Check if RID range overlaps with existing secondary RID range */ >- if (intervals_overlap(r1->base_rid, r2->secondary_base_rid, >- r1->id_range_size, r2->id_range_size)) >+ if ((r1->base_rid_set && r2->secondary_base_rid_set) && >+ intervals_overlap(r1->base_rid, r2->secondary_base_rid, >+ r1->id_range_size, r2->id_range_size)) > return 4; > > /* Check if secondary RID range overlaps with existing RID range */ >- if (intervals_overlap(r1->secondary_base_rid, r2->base_rid, >- r1->id_range_size, r2->id_range_size)) >+ if ((r1->secondary_base_rid_set && r2->base_rid_set) && >+ intervals_overlap(r1->secondary_base_rid, r2->base_rid, >+ r1->id_range_size, r2->id_range_size)) > return 5; > } > } I know that is was in your original code, but can we get numbers replaced by an enum? I'd prefer to see symbolic names used instead of numbers. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Apr 17 12:44:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Apr 2014 15:44:57 +0300 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements In-Reply-To: <534FC81F.60507@redhat.com> References: <534FC81F.60507@redhat.com> Message-ID: <20140417124457.GT20958@redhat.com> On Thu, 17 Apr 2014, Tomas Babej wrote: >>From d714f77f1f162d1c7daeecf7a340f95ed3368f2d Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 16 Apr 2014 17:20:55 +0200 >Subject: [PATCH] ipa_range_check: Connect the new node of the linked list > >Part of: https://fedorahosted.org/freeipa/ticket/4137 >--- > daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >index 68948f599aa4e6d21b071424ab27e3c62c0afefe..20961d8810448a46514ab82c8cdc318e014db4fc 100644 >--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >@@ -131,6 +131,7 @@ static int map_domain_to_root(struct domain_info **head, > new_head->forest_root_id = slapi_entry_attr_get_charptr(root_domain, > IPA_DOMAIN_ID); > new_head->next = *head; >+ *head = new_head; > > return 0; > } ACK -- / Alexander Bokovoy From abokovoy at redhat.com Thu Apr 17 12:45:52 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Apr 2014 15:45:52 +0300 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements In-Reply-To: <534FC81F.60507@redhat.com> References: <534FC81F.60507@redhat.com> Message-ID: <20140417124552.GU20958@redhat.com> On Thu, 17 Apr 2014, Tomas Babej wrote: >>From 632c0ed1fca2cb48b981f6daac55badd59c9c263 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 16 Apr 2014 17:22:46 +0200 >Subject: [PATCH] ipa_range_check: Make a new copy of forest_root_id attribute > for range_info struct > >Not making a new copy of this attribute creates multiple frees caused by multiple >pointers to the same forest_root_id from all the range_info structs for all the >domains belonging to given forest. > >Part of: https://fedorahosted.org/freeipa/ticket/4137 >--- > daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >index 20961d8810448a46514ab82c8cdc318e014db4fc..e2affbd47dc54fb6180cffe842dc2395cf482f52 100644 >--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >@@ -147,7 +147,7 @@ static char* get_forest_root_id(struct domain_info *head, char* domain_id) { > if (domain_id != NULL) { > while(head) { > if (strcasecmp(head->domain_id, domain_id) == 0) { >- return head->forest_root_id; >+ return slapi_ch_strdup(head->forest_root_id); > } > head = head->next; > } ACK -- / Alexander Bokovoy From abokovoy at redhat.com Thu Apr 17 12:47:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Apr 2014 15:47:59 +0300 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements In-Reply-To: <534FC81F.60507@redhat.com> References: <534FC81F.60507@redhat.com> Message-ID: <20140417124759.GV20958@redhat.com> On Thu, 17 Apr 2014, Tomas Babej wrote: >>From ed60bd0e865aad85eb1ffa02d8aea7f76220c65c Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 16 Apr 2014 17:26:07 +0200 >Subject: [PATCH] ipa_range_check: Do not fail when no trusted domain is > available > >When building the domain to forest root map, we need to take the case >of IPA server having no trusted domains configured at all. Do not abort >the checks, but return an empty map instead. > >Part of: https://fedorahosted.org/freeipa/ticket/4137 >--- > daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >index e2affbd47dc54fb6180cffe842dc2395cf482f52..b05b121f0e9cbc6fb6422b4d50f96cb7e86cda07 100644 >--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >@@ -173,6 +173,8 @@ static int build_domain_to_forest_root_map(struct domain_info **head, > int search_result; > int ret = 0; > >+ LOG("Building forest root map \n"); >+ > /* Set the base DN for the search to cn=ad, cn=trusts, $SUFFIX */ > ret = asprintf(&base, "cn=ad,cn=trusts,%s", ctx->base_dn); > if (ret == -1) { >@@ -211,8 +213,14 @@ static int build_domain_to_forest_root_map(struct domain_info **head, > > ret = slapi_pblock_get(trusted_domain_search_pb, SLAPI_PLUGIN_INTOP_RESULT, &search_result); > if (ret != 0 || search_result != LDAP_SUCCESS) { >- LOG_FATAL("Internal search failed.\n"); >- ret = LDAP_OPERATIONS_ERROR; >+ >+ /* If the search for the trusted domains fails, >+ * AD Trust support on IPA server is not available */ >+ >+ LOG("No trusts support on IPA server.\n"); Please expand the message here, may be something like LOG("Empty forest root map as trusts are not enabled on this IPA server\n"); >+ ret = 0; >+ *head = NULL; >+ > goto done; > } Otherwise ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Apr 17 12:49:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Apr 2014 15:49:12 +0300 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements In-Reply-To: <534FC81F.60507@redhat.com> References: <534FC81F.60507@redhat.com> Message-ID: <20140417124912.GW20958@redhat.com> On Thu, 17 Apr 2014, Tomas Babej wrote: >>From 96f27c06f062dcfaa40405c50ad087d6013dc62c Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 16 Apr 2014 17:28:34 +0200 >Subject: [PATCH] ipa_range_check: Fix typo when comparing strings using > strcasecmp > >Part of: https://fedorahosted.org/freeipa/ticket/4137 >--- > daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >index b05b121f0e9cbc6fb6422b4d50f96cb7e86cda07..794e7f3c81c283897059da28b52d7be93e8eb15b 100644 >--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >@@ -397,10 +397,10 @@ static int check_ranges(struct range_info *r1, struct range_info *r2) > > /* Check if base range overlaps with existing base range. > * Exception: ipa-ad-trust-posix ranges from the same forest */ >- if (!(strcasecmp(r1->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >- strcasecmp(r2->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >- r1->forest_root_id != NULL && r2->forest_root_id !=NULL && >- strcasecmp(r1->forest_root_id, r2->forest_root_id) == 0)) { >+ if (!((strcasecmp(r1->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) == 0) && >+ (strcasecmp(r2->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) == 0) && >+ (r1->forest_root_id != NULL && r2->forest_root_id != NULL) && >+ (strcasecmp(r1->forest_root_id, r2->forest_root_id) == 0))) { > > if (intervals_overlap(r1->base_id, r2->base_id, > r1->id_range_size, r2->id_range_size)){ ACK. -- / Alexander Bokovoy From mbasti at redhat.com Thu Apr 17 12:51:46 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 17 Apr 2014 14:51:46 +0200 Subject: [Freeipa-devel] Forward zone V4/Design draft Message-ID: <1397739106.2280.4.camel@unused-4-145.brq.redhat.com> Hello, I created draft to split forward and master zone. http://www.freeipa.org/page/V4/Forward_zones#Questions There is question: should it be implemented as new command set, or as --type={master|forward} parameter only. For details see link above in section Questions. Martin^2 Basti From amisnyov at redhat.com Thu Apr 17 12:57:28 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 17 Apr 2014 14:57:28 +0200 Subject: [Freeipa-devel] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install Message-ID: <20140417145728.7fafe198@unused-4-246.brq.redhat.com> Hi, this patch modifies ipa-server-install to warn the user, if there is a lack of entropy, also runs generate-rndc-key.sh before named restart, to ensure, that it can start before systemd timeouts. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0012-Call-generate-rndc-key.sh-during-ipa-server-install.patch Type: text/x-patch Size: 2621 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 17 13:22:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Apr 2014 15:22:08 +0200 Subject: [Freeipa-devel] Forward zone V4/Design draft In-Reply-To: <1397739106.2280.4.camel@unused-4-145.brq.redhat.com> References: <1397739106.2280.4.camel@unused-4-145.brq.redhat.com> Message-ID: <534FD580.7090406@redhat.com> On 04/17/2014 02:51 PM, Martin Basti wrote: > Hello, > > I created draft to split forward and master zone. > http://www.freeipa.org/page/V4/Forward_zones#Questions > > There is question: should it be implemented as new command set, or as > --type={master|forward} parameter only. For details see link above in > section Questions. > > > Martin^2 Basti When I was discussing this with Martin, using a separate command seemed like the best idea to me. Trying to cram both zones to one command would just introduce all sort of hacks and workarounds in the framework. Both DNS zones have different main objectclass, different set of required and optional attributes and IMO cramming them all to one command would just make it confusing (and the API as well). If you look for example at how AD organizes DNS zones, it also does not cram all the zones to one view, but have 2 "folders" for Forward Lookup zones and for Conditional Forwarded zones. Feedback welcome. Martin From mkosek at redhat.com Thu Apr 17 13:48:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Apr 2014 15:48:09 +0200 Subject: [Freeipa-devel] Managed permission versioning Message-ID: <534FDB99.3070507@redhat.com> I would like to discuss more on the managed read permissions upgrades [1]. Right now, we simply merge an old permission with the new one, making sure that we only add new attributes instead of just replacing them, to prevent a managed permission to be spoiled by a lower FreeIPA server version which runs an updates. I was thinking about it some more and seems to me we could run in problems when we for example find out that some permission is too relaxed and we want to remove some default attribute. Or when we want to update the permission filter. Or when object has anonymous and authenticated permission and we want to move attribute from anonymous to authenticated permission. Changes like this can happen, especially in the first release and we do not have means to address them. What about simply versioning the permissions as we do with our configs? I.e. 1) Introduce new MUST numeric attribute ipaPermVersion 2) Add 'version' field to managed permissions: managed_permissions = { 'System: Read Roles': { 'version': 1, 'replaces_global_anonymous_aci': True, 'ipapermbindruletype': 'permission', 'ipapermright': {'read', 'search', 'compare'}, 'ipapermdefaultattr': { 'businesscategory', 'cn', 'description', 'member', 'memberof', 'o', 'objectclass', 'ou', 'owner', 'seealso', }, 'default_privileges': {'RBAC Readers'}, }, } 3) Modify updater to only update the permission if it's version is higher than the one in LDAP. In that case, it should simply replace the managed permission attributes with the new one, no merging (except the attributes that we allow users to change). When we want to change the permission, we simply do the changes, bump the version and we are done and we do not need to fear some older FreeIPA will overwrite it. That of course assumes that the versioning would be available from FreeIPA 4.0. Makes sense? [1] http://www.freeipa.org/page/V3/Managed_Read_permissions -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mbasti at redhat.com Thu Apr 17 13:57:48 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 17 Apr 2014 15:57:48 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0011, 0048-0051 Chapter 10 DNS In-Reply-To: <1381842993.6890.1.camel@unused-4-145.brq.redhat.com> References: <1381842993.6890.1.camel@unused-4-145.brq.redhat.com> Message-ID: <1397743068.2280.8.camel@unused-4-145.brq.redhat.com> Hello, I split original patch into smaller pieces, please take a look DNS chapter really doesn't look good, due to missing spaces and indentation. Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-doc-mbasti-0011-2-Chapter-10-dns-modified-images.patch Type: text/x-patch Size: 639592 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-doc-mbasti-0048-Chapter-10-DNS-Fix-spaces-indentation.patch Type: text/x-patch Size: 66257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-doc-mbasti-0049-Chapter-10-DNS-modified-disabling-enabling-zones-sec.patch Type: text/x-patch Size: 157113 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-doc-mbasti-0050-Chapter-10-DNS-modified-addresses-in-examples.patch Type: text/x-patch Size: 7148 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-doc-mbasti-0051-Chapter-10-DNS-fixed-descriptions-of-params.patch Type: text/x-patch Size: 4083 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 17 14:10:58 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Apr 2014 10:10:58 -0400 Subject: [Freeipa-devel] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install In-Reply-To: <20140417145728.7fafe198@unused-4-246.brq.redhat.com> References: <20140417145728.7fafe198@unused-4-246.brq.redhat.com> Message-ID: <534FE0F2.6070603@redhat.com> Misnyovszki Adam wrote: > Hi, > this patch modifies ipa-server-install to warn the user, if there is > a lack of entropy, also runs generate-rndc-key.sh before named restart, > to ensure, that it can start before systemd timeouts. I think the exception should be logged in check_entropy() in case this every does fail (the file name changes, the format changes, etc). There should be a try/except around the run() call. I noticed that /etc/rndc.key isn't removed on uninstall, which I guess means the same key will be re-used. Should we be removing that? rob From mkosek at redhat.com Thu Apr 17 14:21:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Apr 2014 16:21:19 +0200 Subject: [Freeipa-devel] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install In-Reply-To: <534FE0F2.6070603@redhat.com> References: <20140417145728.7fafe198@unused-4-246.brq.redhat.com> <534FE0F2.6070603@redhat.com> Message-ID: <534FE35F.3070607@redhat.com> On 04/17/2014 04:10 PM, Rob Crittenden wrote: > Misnyovszki Adam wrote: >> Hi, >> this patch modifies ipa-server-install to warn the user, if there is >> a lack of entropy, also runs generate-rndc-key.sh before named restart, >> to ensure, that it can start before systemd timeouts. > > I think the exception should be logged in check_entropy() in case this every > does fail (the file name changes, the format changes, etc). > > There should be a try/except around the run() call. > > I noticed that /etc/rndc.key isn't removed on uninstall, which I guess means > the same key will be re-used. Should we be removing that? > > rob Also, bare exceptions are bad! + except: + service.print_msg("Could not determine entropy, possible long delays") Next, you do all the checks in ipa-server-install, while they should be in service files, like krbinstance.py so that it is also checked in other installers, like ipa-replica-install. Same for DNS, it should be a separate step in bindinstance.py so that when the installation is hanging, you can see [X/Y] Generating rndc key file and know that it is hanging on that part. I would not misuse "service.print_msg" for regular messages, I would only do the service.print_msg("WARNING: Your system is running out of entropy, expect long delays!") others can be either turn into separate installation step or debug log message. Martin From pviktori at redhat.com Thu Apr 17 14:31:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 16:31:50 +0200 Subject: [Freeipa-devel] Ipatests fixes In-Reply-To: <534FAB68.70401@redhat.com> References: <53451BE3.2070406@redhat.com> <53452FF5.1080601@redhat.com> <534FAB68.70401@redhat.com> Message-ID: <534FE5D6.2050909@redhat.com> On 04/17/2014 12:22 PM, Tomas Babej wrote: > On 04/09/2014 01:33 PM, Petr Viktorin wrote: >> On 04/09/2014 12:07 PM, Tomas Babej wrote: >>> Hi, >>> >>> the following batch deals with the following: >>> >>> * cleans up apache's semaphores prior to installing IPA (CA install can >>> get stuck when IPA is reinstalled many times) >> >> What happens if Apache is running for some reason? Should we also stop >> it before deleting the semaphores? > > Agreed, if for any reason apache is running, we should stop it > beforehand. Fixed. > >> >>> * allows to pass extra arguments to install_client task >> >> Please avoid mutable argument defaults; use `extra_args=()` and then >> `list(extra_args)` > > Fixed. > >> >>> * uses trailing dot in the hostname as fqdn which should not be >>> overridden by domain name >> >> ACK. >> >>> * fixes incorrect assert for UIDs/GIDs in legacy client tests >> >> ACK, this fixes a lot of failures (though not all of them yet). >> > > Updated patches attached. > ACK, pushed to: master: f74ab3cba2b02e4726519e602f7de4fc86fca2d1 ipa-3-3: be8f4768877168720d051ba94c3e908af67f1306 -- Petr? From pviktori at redhat.com Thu Apr 17 14:32:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 16:32:46 +0200 Subject: [Freeipa-devel] [PATCH] 11 - CI - test_forced_client_reenrollment stability fix In-Reply-To: <20140416162152.3379f4fc@unused-4-246.brq.redhat.com> References: <20140415124148.43f848a1@unused-4-246.brq.redhat.com> <534D0F43.1050408@redhat.com> <20140415173647.56826042@unused-4-246.brq.redhat.com> <534E1C4B.1090100@redhat.com> <20140416162152.3379f4fc@unused-4-246.brq.redhat.com> Message-ID: <534FE60E.6080208@redhat.com> On 04/16/2014 04:21 PM, Misnyovszki Adam wrote: > On Wed, 16 Apr 2014 07:59:39 +0200 > Martin Kosek wrote: > >> On 04/15/2014 05:36 PM, Misnyovszki Adam wrote: >>> On Tue, 15 Apr 2014 12:51:47 +0200 >>> Petr Viktorin wrote: >>> >>>> On 04/15/2014 12:41 PM, Misnyovszki Adam wrote: >>>>> Hi, >>>>> this patch fixes FreeIPA Jenkins CI test >>>>> freeipa-integration-forced_client_reenrollment-f19, by turning >>>>> sshfp records into a set, and sorting them before assertion. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4298 >>>>> >>>>> Greets >>>>> Adam >>>> >>>> The list.sort() method sorts in-place and returns None, so now the >>>> test would not really test anything. Use the sorted() function. >>>> >>>> You might want to log the value before returning it. >>>> >>> >>> My mistake, see the attached, corrected patch. >>> Thanks >>> Adam >> >> Adam, Petr - why can't we use a set as I already proposed in the >> ticket description? >> >> >>> set(['i', 'p', 'a']) == set(['a', 'p', 'i']) >> True >> >> Martin > > Hi, > see the attached patch. > Thanks > Adam > ACK, pushed to: master: f85fe1e8513327396ef2f9732810abdffc88abba ipa-3-3: 1d16370dc536434e63097115150afab26febd5b4 -- Petr? From pviktori at redhat.com Thu Apr 17 14:34:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 16:34:26 +0200 Subject: [Freeipa-devel] [PATCH] 585 webui: fix OTP Token add regression In-Reply-To: <20140415152147.4b269658@unused-4-246.brq.redhat.com> References: <534CE5AE.8090804@redhat.com> <20140415152147.4b269658@unused-4-246.brq.redhat.com> Message-ID: <534FE672.5040502@redhat.com> On 04/15/2014 03:21 PM, Misnyovszki Adam wrote: > On Tue, 15 Apr 2014 09:54:22 +0200 > Petr Vobornik wrote: > >> OTP Token add failed because of invalid function call. qr_widget >> doesn't contain `on_value_changed` method since it inherits from >> `IPA.widget` and not from `IPA.input_widget`. >> >> Emitting the event was preserved for future possible usage. >> >> https://fedorahosted.org/freeipa/ticket/4306 > > ACK > Greets > Adam Pushed to master: c644b47492e22370bc71f57e5ac46b50f9b4e247 -- Petr? From pviktori at redhat.com Thu Apr 17 14:58:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 16:58:30 +0200 Subject: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks In-Reply-To: <534FCA05.9030900@redhat.com> References: <533A7CB6.9010400@redhat.com> <534FCA05.9030900@redhat.com> Message-ID: <534FEC16.1040306@redhat.com> On 04/17/2014 02:33 PM, Tomas Babej wrote: > ACK for 256 - 259. > > On 04/01/2014 10:45 AM, Jan Cholasta wrote: >> Hi, >> >> while working with Martin Ba?ti on issues in his dns plugin patches we >> ran into several limitations in the framework. The attached patches >> remove these limitations. >> >> Also, Tom?? Babej pointed out that when using --raw, all the attribute >> names should use letter casing as returned by python-ldap. Patch 259 >> implements that. >> >> See commit messages for details. Sorry for the delay. There are some conflicts with master, could you please rebase? -- Petr? From sbose at redhat.com Thu Apr 17 15:20:33 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 17 Apr 2014 17:20:33 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140417102508.GR20958@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <20140417102508.GR20958@redhat.com> Message-ID: <20140417152033.GN4165@localhost.localdomain> On Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote: > On Thu, 17 Apr 2014, Sumit Bose wrote: > >On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: > >>On 04/15/2014 05:13 AM, Sumit Bose wrote: > >>>Hi, > >>> > > > >>>#* Shall we allow different UIDs/GIDs in different views? > >> > >>Yes. > > > >I hope the admin knows what he does in this case. I think it's similar > >like with the user name, is there really a user-case for this with > >cannot be solved better by creating a new user with the given UID? Think > >about what happens if a host is moved to a new host group e.g. to change > >the HBAC rules but by chance has now a different view with different > >UIDs? > Again, question is what purpose would such view serve? Given that only > new SSSD version can resolve these views properly and a likely reason > for deviating would be to present such a user somewhere on a legacy > system, I see certain conflict of use case wishes. It just came to my mind that it is even more complicated. Although the use case is to provide UIDs and GIDs if they are not set in AD we have to handle the case where they are set in AD. What if there are now two different override views for this AD user one with one without a override UID . In the case where a override UID is given imo the override UID should be used. But I wonder what would be the right way if e.g. there is only a shell attribute in the override view for the user? Shall we assume that the user will have the UID set in AD and have different UIDs in different views again or none at all, because there is none given in the view? I think the best way to solve this is to say that in all views the UID will be the same. If the override UID is set the AD user will get this UID. If the override UID is not set then it depends on the AD settings. If a UID is set in AD the user will get this one from AD if not he will have none at all, which is fine for the web apps use-case. If we can agree on this we should consider to modify the suggested LDAP schema so that it is possible to e.g. have different shells and home directories in different views but always the same UID/GID settings. bye, Sumit From abokovoy at redhat.com Thu Apr 17 15:39:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Apr 2014 18:39:12 +0300 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140417152033.GN4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <20140417102508.GR20958@redhat.com> <20140417152033.GN4165@localhost.localdomain> Message-ID: <20140417153912.GX20958@redhat.com> On Thu, 17 Apr 2014, Sumit Bose wrote: >On Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote: >> On Thu, 17 Apr 2014, Sumit Bose wrote: >> >On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: >> >>On 04/15/2014 05:13 AM, Sumit Bose wrote: >> >>>Hi, >> >>> >> >> >> >>>#* Shall we allow different UIDs/GIDs in different views? >> >> >> >>Yes. >> > >> >I hope the admin knows what he does in this case. I think it's similar >> >like with the user name, is there really a user-case for this with >> >cannot be solved better by creating a new user with the given UID? Think >> >about what happens if a host is moved to a new host group e.g. to change >> >the HBAC rules but by chance has now a different view with different >> >UIDs? >> Again, question is what purpose would such view serve? Given that only >> new SSSD version can resolve these views properly and a likely reason >> for deviating would be to present such a user somewhere on a legacy >> system, I see certain conflict of use case wishes. > >It just came to my mind that it is even more complicated. Although the >use case is to provide UIDs and GIDs if they are not set in AD we have >to handle the case where they are set in AD. What if there are now two >different override views for this AD user one with one without a >override UID . In the case where a override UID is given imo the >override UID should be used. But I wonder what would be the right way if >e.g. there is only a shell attribute in the override view for the user? >Shall we assume that the user will have the UID set in AD and have >different UIDs in different views again or none at all, because there is >none given in the view? > >I think the best way to solve this is to say that in all views the UID >will be the same. If the override UID is set the AD user will get this >UID. If the override UID is not set then it depends on the AD settings. >If a UID is set in AD the user will get this one from AD if not he will >have none at all, which is fine for the web apps use-case. Exactly. >If we can agree on this we should consider to modify the suggested LDAP >schema so that it is possible to e.g. have different shells and home >directories in different views but always the same UID/GID settings. +1 -- / Alexander Bokovoy From simo at redhat.com Thu Apr 17 15:50:57 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 17 Apr 2014 11:50:57 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140417152033.GN4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <20140417102508.GR20958@redhat.com> <20140417152033.GN4165@localhost.localdomain> Message-ID: <1397749857.2628.34.camel@willson.li.ssimo.org> On Thu, 2014-04-17 at 17:20 +0200, Sumit Bose wrote: > On Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote: > > On Thu, 17 Apr 2014, Sumit Bose wrote: > > >On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: > > >>On 04/15/2014 05:13 AM, Sumit Bose wrote: > > >>>Hi, > > >>> > > > > > > >>>#* Shall we allow different UIDs/GIDs in different views? > > >> > > >>Yes. > > > > > >I hope the admin knows what he does in this case. I think it's similar > > >like with the user name, is there really a user-case for this with > > >cannot be solved better by creating a new user with the given UID? Think > > >about what happens if a host is moved to a new host group e.g. to change > > >the HBAC rules but by chance has now a different view with different > > >UIDs? Clearly this and administration mistake, and not something we should try to address. Use different groups for HBAC and UID views, period. > > Again, question is what purpose would such view serve? Given that only > > new SSSD version can resolve these views properly and a likely reason > > for deviating would be to present such a user somewhere on a legacy > > system, I see certain conflict of use case wishes. We cannot do anything for legacy clients, short of presenting multiple "views" in LDAP, but *how* do you know which view to show a client ? > It just came to my mind that it is even more complicated. Although the > use case is to provide UIDs and GIDs if they are not set in AD we have > to handle the case where they are set in AD. What if there are now two > different override views for this AD user one with one without a > override UID . If you centralize them, each view needs its own cache, that is quite non-negotiable. > In the case where a override UID is given imo the > override UID should be used. clearly > But I wonder what would be the right way if > e.g. there is only a shell attribute in the override view for the user? The process is simple. for any one client only one view exist. A view is taking the original user, and then overlaying on top only the attributes explicitly set for that user on the specific view. So any attribute that is not overridden is maintained. > Shall we assume that the user will have the UID set in AD and have > different UIDs in different views again or none at all, because there is > none given in the view? Yes, you shall assume that. > I think the best way to solve this is to say that in all views the UID > will be the same. Absolutely not, it would completely defeat the point of having views. > If the override UID is set the AD user will get this > UID. If the override UID is not set then it depends on the AD settings. This is correct. > If a UID is set in AD the user will get this one from AD if not he will > have none at all, which is fine for the web apps use-case. If there is none and SSSD does automatic mapping, then that's what SSSD will set. > If we can agree on this we should consider to modify the suggested LDAP > schema so that it is possible to e.g. have different shells and home > directories in different views but always the same UID/GID settings. No, I do not agree at all, the most important feature of views is not changing home directories, but being able to maintain a different uid because all the local files (which spread on some shared storage) for a group of servers have historically a different uid for the user than the rest of the infrastructure (NIS domains consolidation case). Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Apr 17 17:11:07 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Apr 2014 19:11:07 +0200 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name Message-ID: <53500B2B.9090700@redhat.com> Hello, While working on the trust permissions I found a typo in the 'ipanttrustauthoutgoing' attribute in default_attributes. Here is a fix. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0530-trust-plugin-Fix-typo-in-attribute-name.patch Type: text/x-patch Size: 1164 bytes Desc: not available URL: From pspacek at redhat.com Thu Apr 17 18:00:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 17 Apr 2014 20:00:18 +0200 Subject: [Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry() Message-ID: <535016B2.2010809@redhat.com> Hello, This patch set attempts to move ldap_parse_master_zoneentry() a little bit closer to sane code. It is preparation for https://fedorahosted.org/bind-dyndb-ldap/ticket/56 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0239-Refactor-empty-zone-handling.patch Type: text/x-patch Size: 4686 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0240-Rename-variables-in-ldap_parse_master_zoneentry-and-.patch Type: text/x-patch Size: 7847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0241-Add-support-for-key-directory-to-configure_paths.patch Type: text/x-patch Size: 2161 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0242-Refactor-master-zone-configuration.patch Type: text/x-patch Size: 6463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0243-Refactor-zone-apex-synchronization-and-serial-mainte.patch Type: text/x-patch Size: 12036 bytes Desc: not available URL: From simo at redhat.com Thu Apr 17 18:50:29 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 17 Apr 2014 14:50:29 -0400 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <534FDB99.3070507@redhat.com> References: <534FDB99.3070507@redhat.com> Message-ID: <1397760629.2628.97.camel@willson.li.ssimo.org> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: > I would like to discuss more on the managed read permissions upgrades [1]. > Right now, we simply merge an old permission with the new one, making sure that > we only add new attributes instead of just replacing them, to prevent a managed > permission to be spoiled by a lower FreeIPA server version which runs an updates. > > I was thinking about it some more and seems to me we could run in problems when > we for example find out that some permission is too relaxed and we want to > remove some default attribute. Or when we want to update the permission filter. > Or when object has anonymous and authenticated permission and we want to move > attribute from anonymous to authenticated permission. > > Changes like this can happen, especially in the first release and we do not > have means to address them. What about simply versioning the permissions as we > do with our configs? I.e. > > 1) Introduce new MUST numeric attribute ipaPermVersion > 2) Add 'version' field to managed permissions: > > managed_permissions = { > 'System: Read Roles': { > 'version': 1, > 'replaces_global_anonymous_aci': True, > 'ipapermbindruletype': 'permission', > 'ipapermright': {'read', 'search', 'compare'}, > 'ipapermdefaultattr': { > 'businesscategory', 'cn', 'description', 'member', 'memberof', > 'o', 'objectclass', 'ou', 'owner', 'seealso', > }, > 'default_privileges': {'RBAC Readers'}, > }, > } > 3) Modify updater to only update the permission if it's version is higher than > the one in LDAP. In that case, it should simply replace the managed permission > attributes with the new one, no merging (except the attributes that we allow > users to change). > > When we want to change the permission, we simply do the changes, bump the > version and we are done and we do not need to fear some older FreeIPA will > overwrite it. That of course assumes that the versioning would be available > from FreeIPA 4.0. > > Makes sense? > > [1] http://www.freeipa.org/page/V3/Managed_Read_permissions Uhmm, yes, and no, let me explain. What you say *does* make sense, but you are being too focused :-) The upgrade issue is not limited to permissions, but affects everything. I think that what we need is to add a "ipa schema version" attribute somewhere in cn=etc, and then always check this number in the updater script. if this number is higher than what we know we immediately stop and do not perform updates that affect anything but our own server data. This will protect the whole tree from unintentional changes caused by an older replica. Makes sense ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Apr 17 19:00:19 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Apr 2014 15:00:19 -0400 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <1397760629.2628.97.camel@willson.li.ssimo.org> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> Message-ID: <535024C3.80202@redhat.com> Simo Sorce wrote: > On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: >> I would like to discuss more on the managed read permissions upgrades [1]. >> Right now, we simply merge an old permission with the new one, making sure that >> we only add new attributes instead of just replacing them, to prevent a managed >> permission to be spoiled by a lower FreeIPA server version which runs an updates. >> >> I was thinking about it some more and seems to me we could run in problems when >> we for example find out that some permission is too relaxed and we want to >> remove some default attribute. Or when we want to update the permission filter. >> Or when object has anonymous and authenticated permission and we want to move >> attribute from anonymous to authenticated permission. >> >> Changes like this can happen, especially in the first release and we do not >> have means to address them. What about simply versioning the permissions as we >> do with our configs? I.e. >> >> 1) Introduce new MUST numeric attribute ipaPermVersion >> 2) Add 'version' field to managed permissions: >> >> managed_permissions = { >> 'System: Read Roles': { >> 'version': 1, >> 'replaces_global_anonymous_aci': True, >> 'ipapermbindruletype': 'permission', >> 'ipapermright': {'read', 'search', 'compare'}, >> 'ipapermdefaultattr': { >> 'businesscategory', 'cn', 'description', 'member', 'memberof', >> 'o', 'objectclass', 'ou', 'owner', 'seealso', >> }, >> 'default_privileges': {'RBAC Readers'}, >> }, >> } >> 3) Modify updater to only update the permission if it's version is higher than >> the one in LDAP. In that case, it should simply replace the managed permission >> attributes with the new one, no merging (except the attributes that we allow >> users to change). >> >> When we want to change the permission, we simply do the changes, bump the >> version and we are done and we do not need to fear some older FreeIPA will >> overwrite it. That of course assumes that the versioning would be available >> from FreeIPA 4.0. >> >> Makes sense? >> >> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions > > > Uhmm, yes, and no, let me explain. > > What you say *does* make sense, but you are being too focused :-) > The upgrade issue is not limited to permissions, but affects everything. > > I think that what we need is to add a "ipa schema version" attribute > somewhere in cn=etc, and then always check this number in the updater > script. if this number is higher than what we know we immediately stop > and do not perform updates that affect anything but our own server data. > > This will protect the whole tree from unintentional changes caused by an > older replica. > > Makes sense ? This could lead to new features not working. Those features would rely on containers, ACIs, etc to exist but they wouldn't if the updates aren't run. rob From mkosek at redhat.com Thu Apr 17 18:30:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Apr 2014 20:30:24 +0200 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <53500B2B.9090700@redhat.com> References: <53500B2B.9090700@redhat.com> Message-ID: <53501DC0.8060001@redhat.com> On 04/17/2014 07:11 PM, Petr Viktorin wrote: > Hello, > While working on the trust permissions I found a typo in the > 'ipanttrustauthoutgoing' attribute in default_attributes. Here is a fix. > I think the right question to ask - do we want to have ipanttrustauth{incoming,outgoing} in default attributes? I do not think so. It is supposed to hold a secret for the trust, I do not think you want it displayed on your terminal by default - even if you have a right to display it. Martin From simo at redhat.com Thu Apr 17 19:41:39 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 17 Apr 2014 15:41:39 -0400 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <535024C3.80202@redhat.com> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> Message-ID: <1397763699.2628.124.camel@willson.li.ssimo.org> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: > >> I would like to discuss more on the managed read permissions upgrades [1]. > >> Right now, we simply merge an old permission with the new one, making sure that > >> we only add new attributes instead of just replacing them, to prevent a managed > >> permission to be spoiled by a lower FreeIPA server version which runs an updates. > >> > >> I was thinking about it some more and seems to me we could run in problems when > >> we for example find out that some permission is too relaxed and we want to > >> remove some default attribute. Or when we want to update the permission filter. > >> Or when object has anonymous and authenticated permission and we want to move > >> attribute from anonymous to authenticated permission. > >> > >> Changes like this can happen, especially in the first release and we do not > >> have means to address them. What about simply versioning the permissions as we > >> do with our configs? I.e. > >> > >> 1) Introduce new MUST numeric attribute ipaPermVersion > >> 2) Add 'version' field to managed permissions: > >> > >> managed_permissions = { > >> 'System: Read Roles': { > >> 'version': 1, > >> 'replaces_global_anonymous_aci': True, > >> 'ipapermbindruletype': 'permission', > >> 'ipapermright': {'read', 'search', 'compare'}, > >> 'ipapermdefaultattr': { > >> 'businesscategory', 'cn', 'description', 'member', 'memberof', > >> 'o', 'objectclass', 'ou', 'owner', 'seealso', > >> }, > >> 'default_privileges': {'RBAC Readers'}, > >> }, > >> } > >> 3) Modify updater to only update the permission if it's version is higher than > >> the one in LDAP. In that case, it should simply replace the managed permission > >> attributes with the new one, no merging (except the attributes that we allow > >> users to change). > >> > >> When we want to change the permission, we simply do the changes, bump the > >> version and we are done and we do not need to fear some older FreeIPA will > >> overwrite it. That of course assumes that the versioning would be available > >> from FreeIPA 4.0. > >> > >> Makes sense? > >> > >> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions > > > > > > Uhmm, yes, and no, let me explain. > > > > What you say *does* make sense, but you are being too focused :-) > > The upgrade issue is not limited to permissions, but affects everything. > > > > I think that what we need is to add a "ipa schema version" attribute > > somewhere in cn=etc, and then always check this number in the updater > > script. if this number is higher than what we know we immediately stop > > and do not perform updates that affect anything but our own server data. > > > > This will protect the whole tree from unintentional changes caused by an > > older replica. > > > > Makes sense ? > > This could lead to new features not working. Those features would rely > on containers, ACIs, etc to exist but they wouldn't if the updates > aren't run. Sorry I don't get this, if they are new features, then the version will be "older" and the update *will* run and at the end raise the version. We just prevent old updates from running and current updates from running multiple times, for the shared tree. Do we depend on having updates run multiple times for the data in the shared tree ? Note that I am not saying that all updates should stop, any update for cn=config would still need to be run on each server (although setting a version there too would probably be beneficial). Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Apr 17 20:03:18 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 17 Apr 2014 16:03:18 -0400 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <53501DC0.8060001@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> Message-ID: <1397764998.2628.125.camel@willson.li.ssimo.org> On Thu, 2014-04-17 at 20:30 +0200, Martin Kosek wrote: > On 04/17/2014 07:11 PM, Petr Viktorin wrote: > > Hello, > > While working on the trust permissions I found a typo in the > > 'ipanttrustauthoutgoing' attribute in default_attributes. Here is a fix. > > > > I think the right question to ask - do we want to have > ipanttrustauth{incoming,outgoing} in default attributes? > > I do not think so. It is supposed to hold a secret for the trust, I do not > think you want it displayed on your terminal by default - even if you have a > right to display it. Yep, should not be returned by default to any command line utility. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Thu Apr 17 20:12:04 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Apr 2014 23:12:04 +0300 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <1397764998.2628.125.camel@willson.li.ssimo.org> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> Message-ID: <20140417201204.GY20958@redhat.com> On Thu, 17 Apr 2014, Simo Sorce wrote: >On Thu, 2014-04-17 at 20:30 +0200, Martin Kosek wrote: >> On 04/17/2014 07:11 PM, Petr Viktorin wrote: >> > Hello, >> > While working on the trust permissions I found a typo in the >> > 'ipanttrustauthoutgoing' attribute in default_attributes. Here is a fix. >> > >> >> I think the right question to ask - do we want to have >> ipanttrustauth{incoming,outgoing} in default attributes? >> >> I do not think so. It is supposed to hold a secret for the trust, I do not >> think you want it displayed on your terminal by default - even if you have a >> right to display it. > >Yep, should not be returned by default to any command line utility. Agreed. I wanted to remove it too the other day but forgot to file a ticket. -- / Alexander Bokovoy From dpal at redhat.com Thu Apr 17 22:03:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 17 Apr 2014 18:03:48 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <1397749857.2628.34.camel@willson.li.ssimo.org> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <20140417102508.GR20958@redhat.com> <20140417152033.GN4165@localhost.localdomain> <1397749857.2628.34.camel@willson.li.ssimo.org> Message-ID: <53504FC4.2050200@redhat.com> On 04/17/2014 11:50 AM, Simo Sorce wrote: > On Thu, 2014-04-17 at 17:20 +0200, Sumit Bose wrote: >> On Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote: >>> On Thu, 17 Apr 2014, Sumit Bose wrote: >>>> On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: >>>>> On 04/15/2014 05:13 AM, Sumit Bose wrote: >>>>>> Hi, >>>>>> >>> >>>>>> #* Shall we allow different UIDs/GIDs in different views? >>>>> Yes. >>>> I hope the admin knows what he does in this case. I think it's similar >>>> like with the user name, is there really a user-case for this with >>>> cannot be solved better by creating a new user with the given UID? Think >>>> about what happens if a host is moved to a new host group e.g. to change >>>> the HBAC rules but by chance has now a different view with different >>>> UIDs? > Clearly this and administration mistake, and not something we should try > to address. > > Use different groups for HBAC and UID views, period. > >>> Again, question is what purpose would such view serve? Given that only >>> new SSSD version can resolve these views properly and a likely reason >>> for deviating would be to present such a user somewhere on a legacy >>> system, I see certain conflict of use case wishes. > We cannot do anything for legacy clients, short of presenting multiple > "views" in LDAP, but *how* do you know which view to show a client ? > >> It just came to my mind that it is even more complicated. Although the >> use case is to provide UIDs and GIDs if they are not set in AD we have >> to handle the case where they are set in AD. What if there are now two >> different override views for this AD user one with one without a >> override UID . > If you centralize them, each view needs its own cache, that is quite > non-negotiable. > >> In the case where a override UID is given imo the >> override UID should be used. > clearly > >> But I wonder what would be the right way if >> e.g. there is only a shell attribute in the override view for the user? > The process is simple. > for any one client only one view exist. A view is taking the original > user, and then overlaying on top only the attributes explicitly set for > that user on the specific view. So any attribute that is not overridden > is maintained. > >> Shall we assume that the user will have the UID set in AD and have >> different UIDs in different views again or none at all, because there is >> none given in the view? > Yes, you shall assume that. > >> I think the best way to solve this is to say that in all views the UID >> will be the same. > Absolutely not, it would completely defeat the point of having views. > >> If the override UID is set the AD user will get this >> UID. If the override UID is not set then it depends on the AD settings. > This is correct. > >> If a UID is set in AD the user will get this one from AD if not he will >> have none at all, which is fine for the web apps use-case. > If there is none and SSSD does automatic mapping, then that's what SSSD > will set. > >> If we can agree on this we should consider to modify the suggested LDAP >> schema so that it is possible to e.g. have different shells and home >> directories in different views but always the same UID/GID settings. > No, I do not agree at all, the most important feature of views is not > changing home directories, but being able to maintain a different uid > because all the local files (which spread on some shared storage) for a > group of servers have historically a different uid for the user than the > rest of the infrastructure (NIS domains consolidation case). > > > Simo. > Yes, this is the main use case we are trying to solve: having different UID/GID exposed to different groups of hosts. It should work for simple ldap clients too. This is similar to Zones in some third party solutions. This is actually most asked feature based on the conversations I had this week. I will comment on the rest questions later. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Thu Apr 17 22:25:42 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Apr 2014 18:25:42 -0400 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <1397763699.2628.124.camel@willson.li.ssimo.org> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> Message-ID: <535054E6.4020904@redhat.com> Simo Sorce wrote: > On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: >>>> I would like to discuss more on the managed read permissions upgrades [1]. >>>> Right now, we simply merge an old permission with the new one, making sure that >>>> we only add new attributes instead of just replacing them, to prevent a managed >>>> permission to be spoiled by a lower FreeIPA server version which runs an updates. >>>> >>>> I was thinking about it some more and seems to me we could run in problems when >>>> we for example find out that some permission is too relaxed and we want to >>>> remove some default attribute. Or when we want to update the permission filter. >>>> Or when object has anonymous and authenticated permission and we want to move >>>> attribute from anonymous to authenticated permission. >>>> >>>> Changes like this can happen, especially in the first release and we do not >>>> have means to address them. What about simply versioning the permissions as we >>>> do with our configs? I.e. >>>> >>>> 1) Introduce new MUST numeric attribute ipaPermVersion >>>> 2) Add 'version' field to managed permissions: >>>> >>>> managed_permissions = { >>>> 'System: Read Roles': { >>>> 'version': 1, >>>> 'replaces_global_anonymous_aci': True, >>>> 'ipapermbindruletype': 'permission', >>>> 'ipapermright': {'read', 'search', 'compare'}, >>>> 'ipapermdefaultattr': { >>>> 'businesscategory', 'cn', 'description', 'member', 'memberof', >>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', >>>> }, >>>> 'default_privileges': {'RBAC Readers'}, >>>> }, >>>> } >>>> 3) Modify updater to only update the permission if it's version is higher than >>>> the one in LDAP. In that case, it should simply replace the managed permission >>>> attributes with the new one, no merging (except the attributes that we allow >>>> users to change). >>>> >>>> When we want to change the permission, we simply do the changes, bump the >>>> version and we are done and we do not need to fear some older FreeIPA will >>>> overwrite it. That of course assumes that the versioning would be available >>>> from FreeIPA 4.0. >>>> >>>> Makes sense? >>>> >>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions >>> >>> >>> Uhmm, yes, and no, let me explain. >>> >>> What you say *does* make sense, but you are being too focused :-) >>> The upgrade issue is not limited to permissions, but affects everything. >>> >>> I think that what we need is to add a "ipa schema version" attribute >>> somewhere in cn=etc, and then always check this number in the updater >>> script. if this number is higher than what we know we immediately stop >>> and do not perform updates that affect anything but our own server data. >>> >>> This will protect the whole tree from unintentional changes caused by an >>> older replica. >>> >>> Makes sense ? >> >> This could lead to new features not working. Those features would rely >> on containers, ACIs, etc to exist but they wouldn't if the updates >> aren't run. > > Sorry I don't get this, if they are new features, then the version will > be "older" and the update *will* run and at the end raise the version. > > We just prevent old updates from running and current updates from > running multiple times, for the shared tree. > > Do we depend on having updates run multiple times for the data in the > shared tree ? > > Note that I am not saying that all updates should stop, any update for > cn=config would still need to be run on each server (although setting a > version there too would probably be beneficial). Ok, so the update runs, adds data, which gets replicated out to potentially old servers, and we're at the place you said we wouldn't be. Updates are all loaded and sorted so that all changes to a given DN should be applied at once, so it isn't like applying a old update and a new update are two separate operations. In fact, it would likely be a no-op in the case that they have already been applied. Do you have any examples to clarify your concerns? I'm not following you. rob From simo at redhat.com Thu Apr 17 22:37:53 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 17 Apr 2014 18:37:53 -0400 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <535054E6.4020904@redhat.com> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> <535054E6.4020904@redhat.com> Message-ID: <1397774273.2628.137.camel@willson.li.ssimo.org> On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: > >>>> I would like to discuss more on the managed read permissions upgrades [1]. > >>>> Right now, we simply merge an old permission with the new one, making sure that > >>>> we only add new attributes instead of just replacing them, to prevent a managed > >>>> permission to be spoiled by a lower FreeIPA server version which runs an updates. > >>>> > >>>> I was thinking about it some more and seems to me we could run in problems when > >>>> we for example find out that some permission is too relaxed and we want to > >>>> remove some default attribute. Or when we want to update the permission filter. > >>>> Or when object has anonymous and authenticated permission and we want to move > >>>> attribute from anonymous to authenticated permission. > >>>> > >>>> Changes like this can happen, especially in the first release and we do not > >>>> have means to address them. What about simply versioning the permissions as we > >>>> do with our configs? I.e. > >>>> > >>>> 1) Introduce new MUST numeric attribute ipaPermVersion > >>>> 2) Add 'version' field to managed permissions: > >>>> > >>>> managed_permissions = { > >>>> 'System: Read Roles': { > >>>> 'version': 1, > >>>> 'replaces_global_anonymous_aci': True, > >>>> 'ipapermbindruletype': 'permission', > >>>> 'ipapermright': {'read', 'search', 'compare'}, > >>>> 'ipapermdefaultattr': { > >>>> 'businesscategory', 'cn', 'description', 'member', 'memberof', > >>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', > >>>> }, > >>>> 'default_privileges': {'RBAC Readers'}, > >>>> }, > >>>> } > >>>> 3) Modify updater to only update the permission if it's version is higher than > >>>> the one in LDAP. In that case, it should simply replace the managed permission > >>>> attributes with the new one, no merging (except the attributes that we allow > >>>> users to change). > >>>> > >>>> When we want to change the permission, we simply do the changes, bump the > >>>> version and we are done and we do not need to fear some older FreeIPA will > >>>> overwrite it. That of course assumes that the versioning would be available > >>>> from FreeIPA 4.0. > >>>> > >>>> Makes sense? > >>>> > >>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions > >>> > >>> > >>> Uhmm, yes, and no, let me explain. > >>> > >>> What you say *does* make sense, but you are being too focused :-) > >>> The upgrade issue is not limited to permissions, but affects everything. > >>> > >>> I think that what we need is to add a "ipa schema version" attribute > >>> somewhere in cn=etc, and then always check this number in the updater > >>> script. if this number is higher than what we know we immediately stop > >>> and do not perform updates that affect anything but our own server data. > >>> > >>> This will protect the whole tree from unintentional changes caused by an > >>> older replica. > >>> > >>> Makes sense ? > >> > >> This could lead to new features not working. Those features would rely > >> on containers, ACIs, etc to exist but they wouldn't if the updates > >> aren't run. > > > > Sorry I don't get this, if they are new features, then the version will > > be "older" and the update *will* run and at the end raise the version. > > > > We just prevent old updates from running and current updates from > > running multiple times, for the shared tree. > > > > Do we depend on having updates run multiple times for the data in the > > shared tree ? > > > > Note that I am not saying that all updates should stop, any update for > > cn=config would still need to be run on each server (although setting a > > version there too would probably be beneficial). > > Ok, so the update runs, adds data, which gets replicated out to > potentially old servers, and we're at the place you said we wouldn't be. I am not following you, the aim here is not to avoid replicating new data to old server, the aim is that if you update the rpm of an older replica and the rpm runs the ldap updater with the *old* code, we do not end up with that updater *undoing* what a more recent update did. > Updates are all loaded and sorted so that all changes to a given DN > should be applied at once, so it isn't like applying a old update and a > new update are two separate operations. In fact, it would likely be a > no-op in the case that they have already been applied. > > Do you have any examples to clarify your concerns? I'm not following you. Sure at some point version freeipa version 4.2 is released and it has an update that changes a default object so that now attribute 'foo' is added, this is done through the updater. Later on we release freeipa version 5.0 and we realize we will have again to remove attribute 'foo' because we never really needed it, plus if it is still there it causes issues to new feature XYZ. The admin installs 5.0 and all are happy, then a week later he runs a simply yum update on th eolder replicas still running 4.2 and 4.2.1 is available, and gets installed and ... bah the 4.2.1 updater re-adds attribute 'foo' back ... and 5.0 servers are now broken. If we have an updater version field when the 4.2.1 update goes on it will see that all updates that were necessary (and more) have already been added and just quits. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Apr 18 03:58:59 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 17 Apr 2014 23:58:59 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140417091539.GJ4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> Message-ID: <5350A303.7030008@redhat.com> On 04/17/2014 05:15 AM, Sumit Bose wrote: > On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: >> On 04/15/2014 05:13 AM, Sumit Bose wrote: >>> Hi, >>> >>> I have started to write a design page for 'Migrating existing >>> environments to Trust' >>> http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust >>> It shall cover https://fedorahosted.org/freeipa/ticket/3318 and >>> https://fedorahosted.org/freeipa/ticket/3979 . >>> >>> I came across several questions which need answers so that more details >>> can be added to the design. Besides that comments and suggestions are >>> welcome as well. >>> >>> For your convenience I added the test below as well. >>> >>> bye, >>> Sumit >>> >>> = Overview = >>> >>> This page illustrates how existing solutions which make AD users >>> available to Linux hosts can be migrated to FreeIPA with Trusts. This >>> includes migrations from the FreeIPA WinSync feature or environments >>> where the AD users where correlated to NIS users. >>> >>> The common problem here is that some if not all attributes needed by a >>> POSIX user or group must be overwritten or supplied by the IPA server. >>> The link to the related AD object is preferably the SID but if it is not >>> available on both sides the name of the object must be used. AD will >>> keep the responsibility for authentication and provide the AD >>> group-memberships of the object. >>> >>> = Use Cases = >>> * Migration from the FreeIPA Sync solution to the FreeIPA Trust solution >>> ** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] >>> * Migration/Consolidation of domains currently managed by other solutions, e.g. NIS >>> ** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) >> As I mentioned in the ticket not only that. Based on conversations >> with different potential consumers of the trust functionality the >> ability to use existing POSIX attributes and manage them in IPA >> while user accounts come from AD is a crucial next step. > Thank you for your feedback, it was very helpful but I'm afraid it might > also caused some new questions. > >>> = Design = >>> In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. >>> # Instead of just offering a single override option the introduction of >>> views are suggested. A suitable client can ask for a specific view >>> with override options different from the default override >>> view. >> Yes. >> >>> Questions: >>> #* Will the default view always be applied? I think it makes sense to >>> always apply it to get a consistent default behavior. If there is a >>> reason for a client to get the unmodified data a special view called >>> e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin >>> to be able to send the raw data to the IPA client so that SSSD can use >>> different views on the client which might be needed for docker/container >>> use cases. >> Sounds reasonable to have the default view and apply it always. If >> the view does not contain posix attributes for the specific user we >> should use dynamic mapping based on SIDs. > Quite some time ago we have decided to not mix algorithmic mapping and > manually managed POSIX IDs. E.g. think about the case where a view with > POSIX ID was added for an existing user which already has an algorithmic > ID assigned on some clients. I think this is unfortunate but I can live with this though it is not best. If there is a workaround to have two trusts or two ranges associated with the forest with different mapping properties I am fine but we need to have that be clearly explain on a page because people were asking about this and I unfortunately gave them the wrong answer becuase I was not aware of "the decision". IMO the decision seems contour intuitive to me. Here is the use cases that people explained to me: "I had to put and manage my posix attributes in AD using third party solution. But as soon as I migrate to IPA I want the AD side of the company to stop managing posix attributes." I was under wrong assumption that though we do not have views now they can do what we ask by allowing the algorithmic mapping to kick in for new users. Frankly I do not see a reason why we can't assign posix attributes using algorithmic method if the posix attributes are not explicitly set. I can argue that this can be an optional fall back but it should be possible. I expect that there will be bugs filed about it as people try. We will see. > > I think the admin has to decide what he wants. He wants to use what he already has from AD but then use other mappings on top. Since we do not provide views yet the only expected option is to fall back to algorithmic mapping. > Below you mentioned a > migration use case where old users should keep their IDs but new users > will get algorithmically generated ones. I think this is bad practice > and technically is it next to impossible without additional admin > effort to decide if a given AD user is an old or a new user. May be but IMO it is a deployment choice. I do not see a reason why we would not assign posix attributes always. Even if they are not needed or used. This way we can always get them if user suddenly logs into an operating system rather than logging just over the web to the applications. In the current implementation the user would not be able to do it because before he can do it he has to contact admin and ask him to do something because he can't log into this VM that was setup for him. I am not sure it is a ban practice. It is up to admin to decide. By new users I mean users created after the migration point. It might be just a switch in a policy indicating that migration is complete and that would indicate that any users coming from AD without posix should be treated as new because for those ones that admins wanted the already set posix attributes in AD explicitly. > The admin > either has to add special flags/attributes to the old AD user objects or > we have to keep an immutable list of old users in IPA. Please note that > this has to be done for groups as well. Imo it would be > easier and safer for the admin to either do a full migration to > algorithmically mapped IDs or manage all POSIX IDs manually on the IPA > side. I think it is not possible in real life. They can migrate people they care about and set posix for those but not for everyone else but now with trust you will have a fall back algorythmic option if any of the AD users has to access Linuxz operating system. > > Additionally I think that in your use case there might be even the need > to manually manage POSIX IDs even for new user. E.g. in the case where a > larger amount of new users is added to AD which where managed by a > completely independent system before. In this case they will add new users to AD and either set posix there or will use views. If they do not care about posix for merged users they will just not set anything letting the default algorithmic resolution to do the trick. If they do not like it then can not turn it on and be required to set UIDs manually. >>> #* Will views only be applied to users from other domains or to IPA >>> users as well? >> Design goal will be to allow them to be applied to all users. > Why, what is the use case to override attribute of IPA users which > cannot be solved by adding other attributes with the needed values to > the IPA user object directly? It seems that I was not clear with the use case. There are two use cases really: a) I have scattered NIS and LDAP domain, I would eventually clean them up but right now I want to migrate to IdM and not use 3rd party solution. Can IPA support zones like the 3rd party solution does? Right now no. As you see there is no mention of AD here. b) I want to do a) but I also want to use AD as authoritative source so I want to consolidate everything in IPA but use trusts. The simplified variant of the use case b) is: I have a single NIS or LDAP that I want to migrate to IPA from. In the past I was using ugly sync solutions from AD to NIS/LDAP that I want to replace with a trust. This means that I want to manage POSIX in IPA at least for the users that are migrated and I want to preserve what I had. For other users that are not migrated I will need a choice of managing posix in IPA myself or falling back to algorithmic if I do not want to set up POSIX myself any more. IPA creates new posix attributes for new IPA users it should act similarly for ad users without posix (if I told it to do so). So if we generalize we see that view is really a way to assign different sets of posix attributes and primarily UID/GID to the same account and expose those to separate clients. May be it is all about compat views or CoS. This is implementation detail and for you to design. > >> Implementation goal will be to apply them to external users first. >> Or I should say we need to figure out the procedure: >> 1) Pre migration: AD with no POSIX, LDAP/NIS with POSIX for some/same users. >> 2) Past migration: AD with no POSIX, no duplicate accounts in IdM, >> POSIX attributes for AD users are migrated into a view. >> >> How we do it is the question but we need to have a path. May be it >> would require some kind of tool: >> ipa create-view --check >> >> This will go through all users in IPA and check them against >> available trusted domains and would report which users will be >> removed becuase they are found in a specific domain. > I think it should only report conflicts. The admin should decide how to > solve the conflict. > >> ipa create-view --create --except= >> >> This will actually do the work but if there are special users that >> need to be processed in some special way admin might temporarily put >> them into a specific group and then exclude this group or groups >> from cleanup. >> >> Just a thought... >> >>> #* Do we want stackable views? >> We want client oriented views. I.e. views should be attached to host groups. >> For the legacy clients there should be a way to expose a view as a >> separate base=DN so that one set of legacy clients can be pointed to >> one DN and another to another. > I'm not sure if this will stretch the compat tree too much, I let > Alexander and Nalin decided. Keep in mind that we can potentially have different trees and point different clients to different trees like we do with automount locations. for example ipa-client-install ... --zone=zone3 will point to the cn=zone3, cn=zones, cn=accounts,... instead of the main tree. > >> If the host based views and DN based views do not have data for a >> specific user the data should be fetched from a global default view. >> I think we can use CoS for that in conjunction with the compat >> plugin but I would leave this to experts to decide. >> >> Bottom line: one global fallback view and then specific views for >> host groups and for legacy clients. >> I know I might be asking a lot ;-) > How shall this 'global default view' work? E.g. if there is an AD user > without a POSIX ID in AD and algorithmic mapping is not enabled for this > user. How dows it work now? Based on what you said I assume user would fail to login because posix attributes are not set and I actually want him t succeeded by default. If I misunderstood you please explain. > If there is no override object for this user in the current view > or if the override object does not contains a POSIX ID attribute where > should the ID come from? be algorithmic of allowed or admin has to set it manually if he does not want to fall back to algorithmic. > > Please note that it is a valid use-case that a user does not has a POSIX > ID e.g. web applications. I think it is not necessary to forcefully try > to assign some POSIX ID to a user. Why not? What is the harm? > If the admin decides that the user > does not need one, why shall we try to create one? Why would he not want to? What is the harm? Why he explicitly would care for us to not set the UID? > >> >>> #* Do we want to override everything or shall there be immutable >>> attributes like e.g. the SID or the user name? >> I do not know why would overwrite the SID but I think that >> overwriting the user name would give us an interesting aliasing >> capability as a feature as a side effect. > But is there a use case for such a feature which is not solved better by > creating a new user with the given name? Please note the side effects, > e.g. with respect to the home-directory path. Typically the user name is > part of the of path. What if the original object has a home-directory > path shall we override it implicitly as well or keep it and who shall > decided? Or what about Kerberos principals, who shall user 'abc' know > that his name was overridden and his Kerberos principal is > 'xyz at AD.REALM'? I am not sure there is a use case so frankly I would start with just overwriting UIDs and GIDs in the views and see if we really need to extend it to any other posix attribute and why. But ability to potential overwrite user name sounds interesting though not sure how useful it is and how applicable. We will see. > >>> #* Shall we allow different UIDs/GIDs in different views? >> Yes. > I hope the admin knows what he does in this case. I think it's similar > like with the user name, is there really a user-case for this with > cannot be solved better by creating a new user with the given UID? Think > about what happens if a host is moved to a new host group e.g. to change > the HBAC rules but by chance has now a different view with different > UIDs? > > >From the OS point of view a user with a different UID is a different > user, from the peoples point of view a user with a different name is a > different user. I think what we achieve with allowing different values > for user names and/or UIDs is to allow different users share the same > password, Kerberos credentials etc and I'm not sure we really want this. This is need for historical reasons. I would not repeat Simo's answer it is pretty all inclusive. >>> #* I think overriding UIDs/GIDs should only be allowed for >>> ipa-ad-trust-posix idranges, mixing override with algorithmic mapping >>> does not make sense imo. >> I think it does at least for the migration time. But it might not be >> achievable. >> The idea is that you really should be required to manage UID/GID for >> the users manually via views if it is an old user. >> If it is a new user that never was on the Linux side before the >> algorithmic mapping might be preferred. > see above > >> But I also think that this should be controlled by a policy and >> admin would have to decide whether the IPA should generate UIDs or >> he would prefer to set the manually explicitly. > yes, this can already be controlled by the idrange type. But you have to > choose either algorithmic or manual mapping you cannot have both in a > given domain. What you can do is to create a domain in the AD forest for > the old users and one for the new users. Now you can use manual mapping > for the old-users-domain and algorithmic mapping for the > new-users-domain. If this requires moving users between domains on AD side then this is a non starter. The more I read it the more I think that decision is wrong and it is bug. > >>> # The views will be stored in containers below >>> cn=views,cn=accounts,$SUFFIX with containers for users and groups. The >>> objectclasses will look similar to posixAccount and posixGroup >>> objectclasses but with only optional (MAY) attributes. Questions: >>> #* Do we want to consider to allow to add arbitrary attributes to a view >>> to cover requests like "We have this beautiful application which can get >>> all user data via the SSSD D-BUS responder but our AD admin will not >>> extend the AD LDAP schema to add the required attributes. Can IPA add >>> them for users from trusted domains?" >> Yes but probably not as phase 1. So it is a separate enhancement. >> >>> #* It was suggested to use a UUID to reference the original objects. For >>> AD users and groups the SID would be a good choice because it is unique >>> and already contains a reference to the original domain. I wonder if we >>> should add a type prefix like 'SID:' to be able to add other types like >>> 'IPAUUID:domref:ef2b7400-a3c4-11e3-82e7-525400de2951' where domref will >>> be a reference to the other IPA domain. On the other hand a type can be >>> added later and if the type is missing a SID is assumed. >>> >>> On the SSSD side the views can be stored below the corresponding user or >>> group object in the cache and the SYSDB API has to be enhanced to return >>> merged results. The merging only happens in the responders (NSS, D-BUS) >>> before sending data to the clients. >> Why SSSD should know about different views? >> It should know raw and not raw but it always sees one merged view >> from the server. >> What am I missing? > You miss the docker/container use case where a central SSSD instance is > used by instances with different host names which might belong to > different host groups and hence require different views. So SSSD does > not only need to know all views but the host groups (we already have > them for HBAC) and their corresponding views as well. True but i think that there SSSD would have to be configured in two different ways. For a simple case it can just be pointed to the zone view. In the case of the docker it might have to be pointed to the main tree and then read all the overlays and create the views on the fly for the clients on the system. But I would not go there yet. May be we would have SSSD in a service container and it would be easy to deploy another SSSD pointing to another view instead of re-implementing all the complexity of merging data to create views in SSSD again. > > Although this use case is work-in-progress I think we should include it > from the start because the extra work to read all views quite small and > might be a larger effort when added later. We need to keep it minds but IMO multiple SSSDs in different containers seems a better solution to me for this use case and much easier achievable. > > > bye, > Sumit > >>> To manage the views a new set CLI tools/Web UI pages should be added. >>> Depending if we would like to allow to override IPA users as well or >>> only users from trusted domains the tools might get their own name >>> space, ipa override-*, or can be added below the trust name space, ipa >>> trust-override-*. It has to be noted that changes of a view will only >>> be visible on the client after the related cached object is expired. >> OK. >> >>> = Implementation = >> See comments above. I hope they give enough hints for >> implementation. At least for the first pass. >> >>> =Feature Management = >>> == UI == >>> == CLI == >>> >>> = Major configuration options and enablement = >>> Any configuration options? Any commands to enable/disable the feature or >>> turn on/off its parts? >>> >>> = Replication = >>> Any impact on replication? >>> >>> = Updates and Upgrades = >>> Any impact on updates and upgrades? >>> >>> = Dependencies = >>> Any new package and library dependencies. >>> >>> = External Impact = >>> Impact on other development teams and components >>> >>> = Backup and Restore = >>> Any files or configuration that needs to be taken care of in backup or >>> restore procedure. >>> >>> = Test Plan = >>> Test scenarios that will be transformed to test cases for FreeIPA >>> Continuous Integration during implementation or review phase. >>> >>> = RFE Author = >>> [[User:Sbose|Sumit Bose]] >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> _______________________________________________ >> 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From simo at redhat.com Fri Apr 18 05:48:49 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 18 Apr 2014 01:48:49 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <5350A303.7030008@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <5350A303.7030008@redhat.com> Message-ID: <1397800129.2628.140.camel@willson.li.ssimo.org> On Thu, 2014-04-17 at 23:58 -0400, Dmitri Pal wrote: > Why would he not want to? What is the harm? Why he explicitly would > care > for us to not set the UID? > If the remote domain(s) is/are very big there is a risk of ID exhaustion. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Apr 18 05:53:30 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 18 Apr 2014 01:53:30 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <5350A303.7030008@redhat.com> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <5350A303.7030008@redhat.com> Message-ID: <1397800410.2628.144.camel@willson.li.ssimo.org> On Thu, 2014-04-17 at 23:58 -0400, Dmitri Pal wrote: > > yes, this can already be controlled by the idrange type. But you > have to > > choose either algorithmic or manual mapping you cannot have both in > a > > given domain. What you can do is to create a domain in the AD forest > for > > the old users and one for the new users. Now you can use manual > mapping > > for the old-users-domain and algorithmic mapping for the > > new-users-domain. > > If this requires moving users between domains on AD side then this is > a > non starter. > The more I read it the more I think that decision is wrong and it is > bug. > What we can do is halfway, if an overlay view is activate for an AD domain then in IPA we have options to automatically generate IDs for any AD user (if the admin wants), these IDs get stored in the Ad overlaying view. >From the SSSD pov no algoritmic mapping is occurring as SSSD always looks for the IDs in IPA. Note that we have to do this anyway if you want to allow also legacy clients to see the same ids, so it seem to me the best/only possible way. The only caveat is that it requires some development on the IPA side to do this object creation, but it is not a lot of code as we can reuse DNA for the actual ID allocation, we just need to create the entry in the view. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Apr 18 08:33:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Apr 2014 10:33:46 +0200 Subject: [Freeipa-devel] Client compatibility article Message-ID: <5350E36A.4000109@redhat.com> FYI - I saw numerous questions about "ipa" tool backward compatibility (the most recent is https://bugzilla.redhat.com/show_bug.cgi?id=1089015), so I created a section about it: http://www.freeipa.org/page/Client#Compatibility and added it to FAQ. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From amisnyov at redhat.com Fri Apr 18 08:43:14 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 18 Apr 2014 10:43:14 +0200 Subject: [Freeipa-devel] [PATCH] 14 webui: select all checkbox remains selected after operation Message-ID: <20140418104314.3997c1db@unused-4-246.brq.redhat.com> Hi, this patch fixes select_all checkbox issue, after any bulk modify or delete operation, the checkbox is deselected. https://fedorahosted.org/freeipa/ticket/4245 Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0014-webui-select-all-checkbox-remains-selected-after-operation.patch Type: text/x-patch Size: 1609 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 18 08:44:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Apr 2014 10:44:26 +0200 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5345BBAB.7010607@redhat.com> References: <52D99F70.3060305@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> Message-ID: <5350E5EA.2060106@redhat.com> On 04/09/2014 11:29 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>> [...] >>>>>> >>>>>> Here are a couple more enhancements I'm considering, this seems >>>>>> simpler >>>>>> than inter-diff since it is so small. >>>>> >>>>> Not really. Having a patch file with a sequence+revision number you >>>>> can >>>>> refer to has its merits. Especially in a hairy thread like this one. >>>>> Also one of our MUAs wrapped the lines, I had to undo that manually. >>>>> >>>>>> Here is why I made the changes, in order: >>>>>> >>>>>> I doubled the calls to create the connection but one isn't in a >>>>>> try/except!? Remove the obvious one. >>>>>> >>>>>> We currently completely eat GSSAPI errors, I figure we should log >>>>>> failures. >>>>>> >>>>>> IPA stores the principal in the request context so using that will >>>>>> save >>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>> >>>>>> I included your content-type change. >>>>> >>>>> These changes look good. >>>>> I'm almost done testing but I need to call it a week. >>>> >>>> Awesome, thanks. >>> >>> ACK on the functionality. >>> >>>>> Sorry for not catching that last time, but your patch doesn't add a >>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>> duplicate >>>>> unversioned one. So lint (and thus the build) will fail if the old >>>>> python-kerberos version is installed. >>>>> >>>>> A possible a solution to the build trouble would be to just add a lint >>>>> exception now, and open a ticket to remove it later. That way the >>>>> build >>>>> succeeds despite the older version, and the new python-kerberos is >>>>> only >>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>> That should make everyone happy, including Martin. >>>>> Unfortunately our lint exception mechanism doesn't work on modules, so >>>>> this needs a somewhat nastier hack. >>>>> The attaching a patch that does this (and I'm pasting a simple diff >>>>> below). Does that look okay to push? >>>> >>>> I'm trying to find a better solution to all this. I may end up taking >>>> Martin's suggestion of rawhide-only to avoid this sort of thing. >>> >>> Looks like you'll still need to silence pylint on f20 in that case. >>> >>>> The deal with the smartproxy is that you can/should be able to run >>>> it on >>>> any IPA-enrolled client, so you can run it directly on the Foreman box, >>>> with the IPA server somewhere else. What this means is that someone >>>> could probably fairly easily package this up for other distributions >>>> and >>>> if we end up with a Fedora-only python-kerberos patch then >>>> smartproxy is >>>> Fedora-only as well. >>>> >>>> So I'm trying to get some movement out of upstream on this but it's >>>> been >>>> crickets for weeks. I think in the context of the calendar server >>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll amp up >>>> the >>>> nagging to get some sort of response, even if it is "stop nagging us!" >>>> >>>> rob >>> >>> Good luck! >> >> Ok, taking a different tack on this. Rather than running it as a >> separate server process, run it as a WSGI app inside Apache. This >> required a fair bit of re-tooling and complicates the set up a little >> bit. I think I've got it all covered in the man page. >> >> On the python-kerberos front I've got bugs opened in Ubuntu and Debian >> to see if we can get the patch accepted their until (if) upstream ever >> takes a look. > > I decided to run the new WSGI app in a different process group, using > the smartproxy we use for delegation. This simplifies the connection > code, rather than using ldap2 like I was using, we use the RPC > interface. And it provides to process separation. As a side-effect it > will make running this code on platforms without GSSProxy a bit easier. > > rob > Works great here! The python-kerberos dependency issue still needs to be solved. The man page says: Copy ipa-smartproxy-apache.conf to /etc/httpd/conf.d/ipa-smartproxy.conf. It would be nice to put the whole path here so people don't have to search for the file. The "Configure Apache to use smartproxy" line looks like a step to be performed. It could use some emphasis to make it look like a header. Side note, cherrypy's routing makes requests like this possible: http POST :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass Should that be allowed? -- Petr? From pviktori at redhat.com Fri Apr 18 08:52:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Apr 2014 10:52:29 +0200 Subject: [Freeipa-devel] Client compatibility article In-Reply-To: <5350E36A.4000109@redhat.com> References: <5350E36A.4000109@redhat.com> Message-ID: <5350E7CD.4010900@redhat.com> On 04/18/2014 10:33 AM, Martin Kosek wrote: > FYI - I saw numerous questions about "ipa" tool backward compatibility (the > most recent is https://bugzilla.redhat.com/show_bug.cgi?id=1089015), so I > created a section about it: > > http://www.freeipa.org/page/Client#Compatibility > > and added it to FAQ. > Looking for the version in an internal module doesn't strike me as the best method. Especially if you have to add a warning to not change the file. (And changing it is just "discouraged"? Really?) Should we add API version to the env, and recommend running `ipa env api_version` instead? -- Petr? From jcholast at redhat.com Fri Apr 18 08:57:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 18 Apr 2014 10:57:53 +0200 Subject: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks In-Reply-To: <534FEC16.1040306@redhat.com> References: <533A7CB6.9010400@redhat.com> <534FCA05.9030900@redhat.com> <534FEC16.1040306@redhat.com> Message-ID: <5350E911.2050605@redhat.com> On 17.4.2014 16:58, Petr Viktorin wrote: > On 04/17/2014 02:33 PM, Tomas Babej wrote: >> ACK for 256 - 259. >> >> On 04/01/2014 10:45 AM, Jan Cholasta wrote: >>> Hi, >>> >>> while working with Martin Ba?ti on issues in his dns plugin patches we >>> ran into several limitations in the framework. The attached patches >>> remove these limitations. >>> >>> Also, Tom?? Babej pointed out that when using --raw, all the attribute >>> names should use letter casing as returned by python-ldap. Patch 259 >>> implements that. >>> >>> See commit messages for details. > > Sorry for the delay. > There are some conflicts with master, could you please rebase? Yes. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-255.1-Allow-primary-keys-to-use-different-type-than-unicod.patch Type: text/x-patch Size: 174669 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-256.1-Support-API-version-specific-RPC-marshalling.patch Type: text/x-patch Size: 11077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-257.1-Replace-get_syntax-method-of-IPASimpleObject-with-ne.patch Type: text/x-patch Size: 2980 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-258.1-Use-raw-attribute-values-in-command-result-when-raw-.patch Type: text/x-patch Size: 3568 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-259.1-Keep-original-name-when-setting-attribute-in-LDAPEnt.patch Type: text/x-patch Size: 3955 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 18 10:43:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Apr 2014 12:43:48 +0200 Subject: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks In-Reply-To: <5350E911.2050605@redhat.com> References: <533A7CB6.9010400@redhat.com> <534FCA05.9030900@redhat.com> <534FEC16.1040306@redhat.com> <5350E911.2050605@redhat.com> Message-ID: <535101E4.3040002@redhat.com> On 04/18/2014 10:57 AM, Jan Cholasta wrote: > On 17.4.2014 16:58, Petr Viktorin wrote: >> On 04/17/2014 02:33 PM, Tomas Babej wrote: >>> ACK for 256 - 259. >>> >>> On 04/01/2014 10:45 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> while working with Martin Ba?ti on issues in his dns plugin patches we >>>> ran into several limitations in the framework. The attached patches >>>> remove these limitations. >>>> >>>> Also, Tom?? Babej pointed out that when using --raw, all the attribute >>>> names should use letter casing as returned by python-ldap. Patch 259 >>>> implements that. >>>> >>>> See commit messages for details. >> >> Sorry for the delay. >> There are some conflicts with master, could you please rebase? > > Yes. > Unfortunately, I get lots of test failures with these patches, like this one: ====================================================================== FAIL: test_hostgroup[13]: hostgroup_del: Delete u'testhostgroup1' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/home/pviktori/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in check_output assert_deepequal(expected, got, nice) File "/home/pviktori/freeipa/ipatests/util.py", line 344, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/home/pviktori/freeipa/ipatests/util.py", line 344, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/home/pviktori/freeipa/ipatests/util.py", line 316, in assert_deepequal TYPE % (doc, type(expected), type(got), expected, got, stack) AssertionError: assert_deepequal: type(expected) is not type(got). test_hostgroup[13]: hostgroup_del: Delete u'testhostgroup1' type(expected) = type(got) = expected = [] got = u'' path = ('result', 'failed') -- Petr? From pviktori at redhat.com Fri Apr 18 11:14:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Apr 2014 13:14:43 +0200 Subject: [Freeipa-devel] Ipatests fixes In-Reply-To: <534FE5D6.2050909@redhat.com> References: <53451BE3.2070406@redhat.com> <53452FF5.1080601@redhat.com> <534FAB68.70401@redhat.com> <534FE5D6.2050909@redhat.com> Message-ID: <53510923.5080103@redhat.com> On 04/17/2014 04:31 PM, Petr Viktorin wrote: > On 04/17/2014 12:22 PM, Tomas Babej wrote: >> On 04/09/2014 01:33 PM, Petr Viktorin wrote: >>> On 04/09/2014 12:07 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> the following batch deals with the following: >>>> >>>> * cleans up apache's semaphores prior to installing IPA (CA install can >>>> get stuck when IPA is reinstalled many times) >>> >>> What happens if Apache is running for some reason? Should we also stop >>> it before deleting the semaphores? >> >> Agreed, if for any reason apache is running, we should stop it >> beforehand. Fixed. >> >>> >>>> * allows to pass extra arguments to install_client task >>> >>> Please avoid mutable argument defaults; use `extra_args=()` and then >>> `list(extra_args)` >> >> Fixed. >> >>> >>>> * uses trailing dot in the hostname as fqdn which should not be >>>> overridden by domain name >>> >>> ACK. >>> >>>> * fixes incorrect assert for UIDs/GIDs in legacy client tests >>> >>> ACK, this fixes a lot of failures (though not all of them yet). >>> >> >> Updated patches attached. >> > > ACK, pushed to: > master: f74ab3cba2b02e4726519e602f7de4fc86fca2d1 > ipa-3-3: be8f4768877168720d051ba94c3e908af67f1306 There are some test failures in ipatests/test_integration/test_testconfig.py that I missed. This patch fixes them. Does it look good to you? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0531-test_integration.host-Export-the-hostname-to-dict-as.patch Type: text/x-patch Size: 959 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 18 11:29:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Apr 2014 13:29:01 +0200 Subject: [Freeipa-devel] Client compatibility article In-Reply-To: <5350E7CD.4010900@redhat.com> References: <5350E36A.4000109@redhat.com> <5350E7CD.4010900@redhat.com> Message-ID: <53510C7D.2010902@redhat.com> On 04/18/2014 10:52 AM, Petr Viktorin wrote: > On 04/18/2014 10:33 AM, Martin Kosek wrote: >> FYI - I saw numerous questions about "ipa" tool backward compatibility (the >> most recent is https://bugzilla.redhat.com/show_bug.cgi?id=1089015), so I >> created a section about it: >> >> http://www.freeipa.org/page/Client#Compatibility >> >> and added it to FAQ. >> > > Looking for the version in an internal module doesn't strike me as the best > method. Especially if you have to add a warning to not change the file. (And > changing it is just "discouraged"? Really?) I specifically added the warning about changing it because this is what the user in the Bugzilla did and I really want to discourage people doing that. If you have better wording in mind, please feel free to improve :-) > > Should we add API version to the env, and recommend running `ipa env > api_version` instead? Maybe. It would also not hurt to have --version option so that: # ipa --version Prints you the package and the API version... Martin From sbose at redhat.com Fri Apr 18 11:39:30 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 18 Apr 2014 13:39:30 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <1397749857.2628.34.camel@willson.li.ssimo.org> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <20140417102508.GR20958@redhat.com> <20140417152033.GN4165@localhost.localdomain> <1397749857.2628.34.camel@willson.li.ssimo.org> Message-ID: <20140418113930.GP4165@localhost.localdomain> On Thu, Apr 17, 2014 at 11:50:57AM -0400, Simo Sorce wrote: > On Thu, 2014-04-17 at 17:20 +0200, Sumit Bose wrote: > > On Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote: > > > On Thu, 17 Apr 2014, Sumit Bose wrote: > > > >On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: > > > >>On 04/15/2014 05:13 AM, Sumit Bose wrote: > > > >>>Hi, > > > >>> > > > > > > > > > >>>#* Shall we allow different UIDs/GIDs in different views? > > > >> > > > >>Yes. > > > > > > > >I hope the admin knows what he does in this case. I think it's similar > > > >like with the user name, is there really a user-case for this with > > > >cannot be solved better by creating a new user with the given UID? Think > > > >about what happens if a host is moved to a new host group e.g. to change > > > >the HBAC rules but by chance has now a different view with different > > > >UIDs? Hi Simo, Thank you for the comments. So it looks like supporting legacy setups where a single user has different POSIX IDs on different servers is a use case we want to support. It's fine by me, nevertheless I think it is bad admin practice to keep this kind of setups running and do a proper migration. > > Clearly this and administration mistake, and not something we should try > to address. > > Use different groups for HBAC and UID views, period. If you really think it should be done this way we should make them different group types like hbac_hostgroups and view_hostsgroups (do we need sudo_hostgroups as well :-?). Seriously, I think the purpose of the hostgroups is to collect hosts with the same profile to allow easy management so that when a new host with the same profile is created it has to be put in only one group and automatically get the right HBAC and sudo rules, the right view etc. > > > > Again, question is what purpose would such view serve? Given that only > > > new SSSD version can resolve these views properly and a likely reason > > > for deviating would be to present such a user somewhere on a legacy > > > system, I see certain conflict of use case wishes. > > We cannot do anything for legacy clients, short of presenting multiple > "views" in LDAP, but *how* do you know which view to show a client ? > > > It just came to my mind that it is even more complicated. Although the > > use case is to provide UIDs and GIDs if they are not set in AD we have > > to handle the case where they are set in AD. What if there are now two > > different override views for this AD user one with one without a > > override UID . > > If you centralize them, each view needs its own cache, that is quite > non-negotiable. > > > In the case where a override UID is given imo the > > override UID should be used. > > clearly > > > But I wonder what would be the right way if > > e.g. there is only a shell attribute in the override view for the user? > > The process is simple. > for any one client only one view exist. A view is taking the original > user, and then overlaying on top only the attributes explicitly set for > that user on the specific view. So any attribute that is not overridden > is maintained. > > > Shall we assume that the user will have the UID set in AD and have > > different UIDs in different views again or none at all, because there is > > none given in the view? > > Yes, you shall assume that. > > > I think the best way to solve this is to say that in all views the UID > > will be the same. > > Absolutely not, it would completely defeat the point of having views. > > > If the override UID is set the AD user will get this > > UID. If the override UID is not set then it depends on the AD settings. > > This is correct. > > > If a UID is set in AD the user will get this one from AD if not he will > > have none at all, which is fine for the web apps use-case. > > If there is none and SSSD does automatic mapping, then that's what SSSD > will set. As mentioned before we decided some time ago to not mix manual and automatically (algorithmic) mapping for the same domain. If we wanr to change this it might result in additional effort on the SSSD side. But as said before I do not see a problem to support user without POSIX IDs. bye, Sumit > > > If we can agree on this we should consider to modify the suggested LDAP > > schema so that it is possible to e.g. have different shells and home > > directories in different views but always the same UID/GID settings. > > No, I do not agree at all, the most important feature of views is not > changing home directories, but being able to maintain a different uid > because all the local files (which spread on some shared storage) for a > group of servers have historically a different uid for the user than the > rest of the infrastructure (NIS domains consolidation case). > > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From pviktori at redhat.com Fri Apr 18 11:40:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Apr 2014 13:40:49 +0200 Subject: [Freeipa-devel] Client compatibility article In-Reply-To: <53510C7D.2010902@redhat.com> References: <5350E36A.4000109@redhat.com> <5350E7CD.4010900@redhat.com> <53510C7D.2010902@redhat.com> Message-ID: <53510F41.6090603@redhat.com> On 04/18/2014 01:29 PM, Martin Kosek wrote: > On 04/18/2014 10:52 AM, Petr Viktorin wrote: >> On 04/18/2014 10:33 AM, Martin Kosek wrote: >>> FYI - I saw numerous questions about "ipa" tool backward compatibility (the >>> most recent is https://bugzilla.redhat.com/show_bug.cgi?id=1089015), so I >>> created a section about it: >>> >>> http://www.freeipa.org/page/Client#Compatibility >>> >>> and added it to FAQ. >>> >> >> Looking for the version in an internal module doesn't strike me as the best >> method. Especially if you have to add a warning to not change the file. (And >> changing it is just "discouraged"? Really?) > > I specifically added the warning about changing it because this is what the > user in the Bugzilla did and I really want to discourage people doing that. If > you have better wording in mind, please feel free to improve :-) I'd rather not mention it at all; saying "here is a stupid thing you really shouldn't do" will just make people do it. >> Should we add API version to the env, and recommend running `ipa env >> api_version` instead? > > Maybe. It would also not hurt to have --version option so that: > > # ipa --version > > Prints you the package and the API version... https://fedorahosted.org/freeipa/ticket/4316 -- Petr? From mkosek at redhat.com Fri Apr 18 11:46:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Apr 2014 13:46:18 +0200 Subject: [Freeipa-devel] Client compatibility article In-Reply-To: <53510F41.6090603@redhat.com> References: <5350E36A.4000109@redhat.com> <5350E7CD.4010900@redhat.com> <53510C7D.2010902@redhat.com> <53510F41.6090603@redhat.com> Message-ID: <5351108A.5070808@redhat.com> On 04/18/2014 01:40 PM, Petr Viktorin wrote: > On 04/18/2014 01:29 PM, Martin Kosek wrote: >> On 04/18/2014 10:52 AM, Petr Viktorin wrote: >>> On 04/18/2014 10:33 AM, Martin Kosek wrote: >>>> FYI - I saw numerous questions about "ipa" tool backward compatibility (the >>>> most recent is https://bugzilla.redhat.com/show_bug.cgi?id=1089015), so I >>>> created a section about it: >>>> >>>> http://www.freeipa.org/page/Client#Compatibility >>>> >>>> and added it to FAQ. >>>> >>> >>> Looking for the version in an internal module doesn't strike me as the best >>> method. Especially if you have to add a warning to not change the file. (And >>> changing it is just "discouraged"? Really?) >> >> I specifically added the warning about changing it because this is what the >> user in the Bugzilla did and I really want to discourage people doing that. If >> you have better wording in mind, please feel free to improve :-) > > I'd rather not mention it at all; saying "here is a stupid thing you really > shouldn't do" will just make people do it. Umm, ok, makes sense :) I removed the warning. Martin From jcholast at redhat.com Fri Apr 18 11:50:28 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 18 Apr 2014 13:50:28 +0200 Subject: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks In-Reply-To: <535101E4.3040002@redhat.com> References: <533A7CB6.9010400@redhat.com> <534FCA05.9030900@redhat.com> <534FEC16.1040306@redhat.com> <5350E911.2050605@redhat.com> <535101E4.3040002@redhat.com> Message-ID: <53511184.2070608@redhat.com> On 18.4.2014 12:43, Petr Viktorin wrote: > On 04/18/2014 10:57 AM, Jan Cholasta wrote: >> On 17.4.2014 16:58, Petr Viktorin wrote: >>> On 04/17/2014 02:33 PM, Tomas Babej wrote: >>>> ACK for 256 - 259. >>>> >>>> On 04/01/2014 10:45 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> while working with Martin Ba?ti on issues in his dns plugin patches we >>>>> ran into several limitations in the framework. The attached patches >>>>> remove these limitations. >>>>> >>>>> Also, Tom?? Babej pointed out that when using --raw, all the attribute >>>>> names should use letter casing as returned by python-ldap. Patch 259 >>>>> implements that. >>>>> >>>>> See commit messages for details. >>> >>> Sorry for the delay. >>> There are some conflicts with master, could you please rebase? >> >> Yes. >> > > Unfortunately, I get lots of test failures with these patches, like this > one: > I did a clean build & install & test run before submitting the patches and did not see any relevant failures. Is it possible there is something wrong in your setup? -- Jan Cholasta From pviktori at redhat.com Fri Apr 18 11:50:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Apr 2014 13:50:35 +0200 Subject: [Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers Message-ID: <5351118B.7080108@redhat.com> This extends the "Anonymous read access to containers" ACI to cover cn=etc, as discussed in [0]. A new objectClass is added so we can exclude virtual ops with targetfilter: ipaVirtualOperation (2.16.840.1.113730.3.8.12.23). [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0532-Add-a-new-ipaVirtualOperation-objectClass-to-virtual.patch Type: text/x-patch Size: 7353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0533-Extend-anonymous-read-ACI-for-containers.patch Type: text/x-patch Size: 1538 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 18 11:55:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Apr 2014 13:55:58 +0200 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <20140417201204.GY20958@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> <20140417201204.GY20958@redhat.com> Message-ID: <535112CE.5080009@redhat.com> On 04/17/2014 10:12 PM, Alexander Bokovoy wrote: > On Thu, 17 Apr 2014, Simo Sorce wrote: >> On Thu, 2014-04-17 at 20:30 +0200, Martin Kosek wrote: >>> On 04/17/2014 07:11 PM, Petr Viktorin wrote: >>> > Hello, >>> > While working on the trust permissions I found a typo in the >>> > 'ipanttrustauthoutgoing' attribute in default_attributes. Here is a >>> fix. >>> > >>> >>> I think the right question to ask - do we want to have >>> ipanttrustauth{incoming,outgoing} in default attributes? >>> >>> I do not think so. It is supposed to hold a secret for the trust, I >>> do not >>> think you want it displayed on your terminal by default - even if you >>> have a >>> right to display it. >> >> Yep, should not be returned by default to any command line utility. > Agreed. I wanted to remove it too the other day but forgot to file a > ticket. > I see. Here is a patch to remove them. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0530.2-trust-plugin-Remove-ipatrustauth-incoming-outgoing-f.patch Type: text/x-patch Size: 1603 bytes Desc: not available URL: From pspacek at redhat.com Fri Apr 18 12:12:37 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 18 Apr 2014 14:12:37 +0200 Subject: [Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry() In-Reply-To: <535016B2.2010809@redhat.com> References: <535016B2.2010809@redhat.com> Message-ID: <535116B5.20606@redhat.com> On 17.4.2014 20:00, Petr Spacek wrote: > Hello, > > This patch set attempts to move ldap_parse_master_zoneentry() a little bit > closer to sane code. > > It is preparation for > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 bind-dyndb-ldap-pspacek-0242-2-Refactor-master-zone-configuration.patch fixes zone loading for zones without idnsAllowTransfer attribute in LDAP. Previously, the plugin refused to load such zones with error ISC_R_NOTFOUND - missing attribute was treated as fatal error. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0242-2-Refactor-master-zone-configuration.patch Type: text/x-patch Size: 6539 bytes Desc: not available URL: From amisnyov at redhat.com Fri Apr 18 12:41:50 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 18 Apr 2014 14:41:50 +0200 Subject: [Freeipa-devel] [PATCH] 15 webui doc: typo fixes in guides Message-ID: <20140418144150.3abe1d9e@unused-4-246.brq.redhat.com> Hi, $SUBJ tells everything. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0015-webui-doc-typo-fixes-in-guides.patch Type: text/x-patch Size: 2042 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 18 12:59:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Apr 2014 14:59:46 +0200 Subject: [Freeipa-devel] [PATCHES] 255-259 Framework tweaks In-Reply-To: <53511184.2070608@redhat.com> References: <533A7CB6.9010400@redhat.com> <534FCA05.9030900@redhat.com> <534FEC16.1040306@redhat.com> <5350E911.2050605@redhat.com> <535101E4.3040002@redhat.com> <53511184.2070608@redhat.com> Message-ID: <535121C2.9050605@redhat.com> On 04/18/2014 01:50 PM, Jan Cholasta wrote: > On 18.4.2014 12:43, Petr Viktorin wrote: >> On 04/18/2014 10:57 AM, Jan Cholasta wrote: >>> On 17.4.2014 16:58, Petr Viktorin wrote: >>>> On 04/17/2014 02:33 PM, Tomas Babej wrote: >>>>> ACK for 256 - 259. >>>>> >>>>> On 04/01/2014 10:45 AM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> while working with Martin Ba?ti on issues in his dns plugin >>>>>> patches we >>>>>> ran into several limitations in the framework. The attached patches >>>>>> remove these limitations. >>>>>> >>>>>> Also, Tom?? Babej pointed out that when using --raw, all the >>>>>> attribute >>>>>> names should use letter casing as returned by python-ldap. Patch 259 >>>>>> implements that. >>>>>> >>>>>> See commit messages for details. >>>> >>>> Sorry for the delay. >>>> There are some conflicts with master, could you please rebase? >>> >>> Yes. >>> >> >> Unfortunately, I get lots of test failures with these patches, like this >> one: >> > > I did a clean build & install & test run before submitting the patches > and did not see any relevant failures. Is it possible there is something > wrong in your setup? > You're right, that was my mistake. Sorry for the noise. Pushed to master: 9814b272af6ad94aba675fe17de8883f3bb4b509 -- Petr? From simo at redhat.com Fri Apr 18 13:40:31 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 18 Apr 2014 09:40:31 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140418113930.GP4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <20140417102508.GR20958@redhat.com> <20140417152033.GN4165@localhost.localdomain> <1397749857.2628.34.camel@willson.li.ssimo.org> <20140418113930.GP4165@localhost.localdomain> Message-ID: <1397828431.2628.150.camel@willson.li.ssimo.org> On Fri, 2014-04-18 at 13:39 +0200, Sumit Bose wrote: > Hi Simo, > > Thank you for the comments. So it looks like supporting legacy setups > where a single user has different POSIX IDs on different servers is a > use case we want to support. It's fine by me, nevertheless I think it is > bad admin practice to keep this kind of setups running and do a proper > migration. Much, *much* easier said than done. I have been in this situation with customers before, once you have enough machines cross-sharing disks over NFS, it is almost impossible to do without taking the whole set offline for days or weeks. > > Clearly this and administration mistake, and not something we should try > > to address. > > > > Use different groups for HBAC and UID views, period. > > If you really think it should be done this way we should make them > different group types like hbac_hostgroups and view_hostsgroups (do we > need sudo_hostgroups as well :-?). No, we shouldn't :) > Seriously, I think the purpose of the > hostgroups is to collect hosts with the same profile to allow easy > management so that when a new host with the same profile is created it > has to be put in only one group and automatically get the right HBAC and > sudo rules, the right view etc. Sure, but you will need additional groups if your HBAC access profile and your views profiles do not match. I think in practice hosts using different views will be isolated islands and the chance you want to reuse the hostgroup that define the view for HBAC and that the 2 sets of groups is not an identity or HABC is a subset of the view group will be negligible. I am confident admins understand how to deal with these cases. > > > I think the best way to solve this is to say that in all views the UID > > > will be the same. > > > > Absolutely not, it would completely defeat the point of having views. > > > > > If the override UID is set the AD user will get this > > > UID. If the override UID is not set then it depends on the AD settings. > > > > This is correct. > > > > > If a UID is set in AD the user will get this one from AD if not he will > > > have none at all, which is fine for the web apps use-case. > > > > If there is none and SSSD does automatic mapping, then that's what SSSD > > will set. > > As mentioned before we decided some time ago to not mix manual and > automatically (algorithmic) mapping for the same domain. If we wanr to > change this it might result in additional effort on the SSSD side. But > as said before I do not see a problem to support user without POSIX IDs. See my reply to dimitri, the solution needs to be tackled on the IPA server not in SSSD for this, IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Apr 18 13:40:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Apr 2014 15:40:59 +0200 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <535112CE.5080009@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> <20140417201204.GY20958@redhat.com> <535112CE.5080009@redhat.com> Message-ID: <53512B6B.5040908@redhat.com> On 04/18/2014 01:55 PM, Petr Viktorin wrote: > On 04/17/2014 10:12 PM, Alexander Bokovoy wrote: >> On Thu, 17 Apr 2014, Simo Sorce wrote: >>> On Thu, 2014-04-17 at 20:30 +0200, Martin Kosek wrote: >>>> On 04/17/2014 07:11 PM, Petr Viktorin wrote: >>>> > Hello, >>>> > While working on the trust permissions I found a typo in the >>>> > 'ipanttrustauthoutgoing' attribute in default_attributes. Here is a >>>> fix. >>>> > >>>> >>>> I think the right question to ask - do we want to have >>>> ipanttrustauth{incoming,outgoing} in default attributes? >>>> >>>> I do not think so. It is supposed to hold a secret for the trust, I >>>> do not >>>> think you want it displayed on your terminal by default - even if you >>>> have a >>>> right to display it. >>> >>> Yep, should not be returned by default to any command line utility. >> Agreed. I wanted to remove it too the other day but forgot to file a >> ticket. >> > > I see. > Here is a patch to remove them. > Why did you remove SID blacklists from search_display_attributes? Is this what we want? It changes trust-find behavior from: # ipa trust-find --------------- 1 trust matched --------------- Realm name: tbad.example.com Domain NetBIOS name: TBAD Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 Trust type: Active Directory domain ---------------------------- Number of entries returned 1 ---------------------------- to # ipa trust-find --------------- 1 trust matched --------------- Realm name: tbad.example.com Domain NetBIOS name: TBAD Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 Trust type: Active Directory domain ---------------------------- Number of entries returned 1 ---------------------------- I am not saying it is necessarily a bad thing to do. It IMO actually makes find output consistent with trust-show and better to read. I would personally remove search_display_attributes all together since we are poking in this part and let trust return default attributes in the trust-find command. Martin From ssorce at redhat.com Fri Apr 18 13:43:06 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 18 Apr 2014 09:43:06 -0400 Subject: [Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers In-Reply-To: <5351118B.7080108@redhat.com> References: <5351118B.7080108@redhat.com> Message-ID: <1397828586.2628.151.camel@willson.li.ssimo.org> On Fri, 2014-04-18 at 13:50 +0200, Petr Viktorin wrote: > This extends the "Anonymous read access to containers" ACI to cover > cn=etc, as discussed in [0]. > > A new objectClass is added so we can exclude virtual ops with > targetfilter: ipaVirtualOperation (2.16.840.1.113730.3.8.12.23). > > > [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html > LGTM From mkosek at redhat.com Fri Apr 18 13:49:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Apr 2014 15:49:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers In-Reply-To: <1397828586.2628.151.camel@willson.li.ssimo.org> References: <5351118B.7080108@redhat.com> <1397828586.2628.151.camel@willson.li.ssimo.org> Message-ID: <53512D59.2080604@redhat.com> On 04/18/2014 03:43 PM, Simo Sorce wrote: > On Fri, 2014-04-18 at 13:50 +0200, Petr Viktorin wrote: >> This extends the "Anonymous read access to containers" ACI to cover >> cn=etc, as discussed in [0]. >> >> A new objectClass is added so we can exclude virtual ops with >> targetfilter: ipaVirtualOperation (2.16.840.1.113730.3.8.12.23). >> >> >> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html >> > > LGTM > It works perfectly except one subtree we missed during initial review and which we should discuss: cn=replicas,cn=ipa,cn=etc,SUFFIX It contains list of replicas (not FreeIPA masters) connected to FreeIPA. Currently, this only affects Winsync replicas. I just verified that anonymous user can retrieve list of connected ADs via winsync. Question is, how to prevent it given that this is created dynamically also by older FreeIPA server and given that it has no special objectsclass to base a filtration on. Maybe we would need to add a deny ACI in this case after all? Martin From amisnyov at redhat.com Fri Apr 18 14:01:34 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 18 Apr 2014 16:01:34 +0200 Subject: [Freeipa-devel] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install In-Reply-To: <534FE35F.3070607@redhat.com> References: <20140417145728.7fafe198@unused-4-246.brq.redhat.com> <534FE0F2.6070603@redhat.com> <534FE35F.3070607@redhat.com> Message-ID: <20140418160134.79627e82@unused-4-246.brq.redhat.com> On Thu, 17 Apr 2014 16:21:19 +0200 Martin Kosek wrote: > On 04/17/2014 04:10 PM, Rob Crittenden wrote: > > Misnyovszki Adam wrote: > >> Hi, > >> this patch modifies ipa-server-install to warn the user, if there > >> is a lack of entropy, also runs generate-rndc-key.sh before named > >> restart, to ensure, that it can start before systemd timeouts. > > > > I think the exception should be logged in check_entropy() in case > > this every does fail (the file name changes, the format changes, > > etc). > > > > There should be a try/except around the run() call. > > > > I noticed that /etc/rndc.key isn't removed on uninstall, which I > > guess means the same key will be re-used. Should we be removing > > that? > > > > rob > > Also, bare exceptions are bad! > > + except: > + service.print_msg("Could not determine entropy, possible > long delays") > > Next, you do all the checks in ipa-server-install, while they should > be in service files, like krbinstance.py so that it is also checked > in other installers, like ipa-replica-install. > > Same for DNS, it should be a separate step in bindinstance.py so that > when the installation is hanging, you can see > > [X/Y] Generating rndc key file > > and know that it is hanging on that part. > > I would not misuse "service.print_msg" for regular messages, I would > only do the > > service.print_msg("WARNING: Your system is running out of entropy, > expect long delays!") > > others can be either turn into separate installation step or debug > log message. > > Martin Hi, according to personal discussion with Martin, see the corrected patch! Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0012-2-Call-generate-rndc-key.sh-during-ipa-server-install.patch Type: text/x-patch Size: 4188 bytes Desc: not available URL: From ssorce at redhat.com Fri Apr 18 14:07:08 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 18 Apr 2014 10:07:08 -0400 Subject: [Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers In-Reply-To: <53512D59.2080604@redhat.com> References: <5351118B.7080108@redhat.com> <1397828586.2628.151.camel@willson.li.ssimo.org> <53512D59.2080604@redhat.com> Message-ID: <1397830028.2628.161.camel@willson.li.ssimo.org> On Fri, 2014-04-18 at 15:49 +0200, Martin Kosek wrote: > On 04/18/2014 03:43 PM, Simo Sorce wrote: > > On Fri, 2014-04-18 at 13:50 +0200, Petr Viktorin wrote: > >> This extends the "Anonymous read access to containers" ACI to cover > >> cn=etc, as discussed in [0]. > >> > >> A new objectClass is added so we can exclude virtual ops with > >> targetfilter: ipaVirtualOperation (2.16.840.1.113730.3.8.12.23). > >> > >> > >> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html > >> > > > > LGTM > > > > It works perfectly except one subtree we missed during initial review and which > we should discuss: > > cn=replicas,cn=ipa,cn=etc,SUFFIX > > It contains list of replicas (not FreeIPA masters) connected to FreeIPA. > Currently, this only affects Winsync replicas. > > I just verified that anonymous user can retrieve list of connected ADs via > winsync. Question is, how to prevent it given that this is created dynamically > also by older FreeIPA server and given that it has no special objectsclass to > base a filtration on. > > Maybe we would need to add a deny ACI in this case after all? Or we can add an objectclass here too, the update script will then need to look at existing objects dynamically and update them. However we could also ass a deny aci only in this subtree for now and change it later, if we think that's too much work. We have plans to revisit shared replica information storage anyway, so perhaps it is not worth spending too much time on this now. Simo. From mkosek at redhat.com Fri Apr 18 14:11:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Apr 2014 16:11:25 +0200 Subject: [Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers In-Reply-To: <1397830028.2628.161.camel@willson.li.ssimo.org> References: <5351118B.7080108@redhat.com> <1397828586.2628.151.camel@willson.li.ssimo.org> <53512D59.2080604@redhat.com> <1397830028.2628.161.camel@willson.li.ssimo.org> Message-ID: <5351328D.6070406@redhat.com> On 04/18/2014 04:07 PM, Simo Sorce wrote: > On Fri, 2014-04-18 at 15:49 +0200, Martin Kosek wrote: >> On 04/18/2014 03:43 PM, Simo Sorce wrote: >>> On Fri, 2014-04-18 at 13:50 +0200, Petr Viktorin wrote: >>>> This extends the "Anonymous read access to containers" ACI to cover >>>> cn=etc, as discussed in [0]. >>>> >>>> A new objectClass is added so we can exclude virtual ops with >>>> targetfilter: ipaVirtualOperation (2.16.840.1.113730.3.8.12.23). >>>> >>>> >>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html >>>> >>> >>> LGTM >>> >> >> It works perfectly except one subtree we missed during initial review and which >> we should discuss: >> >> cn=replicas,cn=ipa,cn=etc,SUFFIX >> >> It contains list of replicas (not FreeIPA masters) connected to FreeIPA. >> Currently, this only affects Winsync replicas. >> >> I just verified that anonymous user can retrieve list of connected ADs via >> winsync. Question is, how to prevent it given that this is created dynamically >> also by older FreeIPA server and given that it has no special objectsclass to >> base a filtration on. >> >> Maybe we would need to add a deny ACI in this case after all? > > Or we can add an objectclass here too, the update script will then need > to look at existing objects dynamically and update them. This would not work well as older FreeIPA servers would not use this objectclass when "ipa-replica-manage connect --winsync" is run on them. > However we could also ass a deny aci only in this subtree for now and > change it later, if we think that's too much work. > > We have plans to revisit shared replica information storage anyway, so > perhaps it is not worth spending too much time on this now. > > Simo. deny ACI is preventing access to nsContainer to anonymous users in cn=replica... is probably it is our best shot ATM unless we find a better solution. Martin From ssorce at redhat.com Fri Apr 18 14:17:15 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 18 Apr 2014 10:17:15 -0400 Subject: [Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers In-Reply-To: <5351328D.6070406@redhat.com> References: <5351118B.7080108@redhat.com> <1397828586.2628.151.camel@willson.li.ssimo.org> <53512D59.2080604@redhat.com> <1397830028.2628.161.camel@willson.li.ssimo.org> <5351328D.6070406@redhat.com> Message-ID: <1397830635.2628.165.camel@willson.li.ssimo.org> On Fri, 2014-04-18 at 16:11 +0200, Martin Kosek wrote: > On 04/18/2014 04:07 PM, Simo Sorce wrote: > > On Fri, 2014-04-18 at 15:49 +0200, Martin Kosek wrote: > >> On 04/18/2014 03:43 PM, Simo Sorce wrote: > >>> On Fri, 2014-04-18 at 13:50 +0200, Petr Viktorin wrote: > >>>> This extends the "Anonymous read access to containers" ACI to cover > >>>> cn=etc, as discussed in [0]. > >>>> > >>>> A new objectClass is added so we can exclude virtual ops with > >>>> targetfilter: ipaVirtualOperation (2.16.840.1.113730.3.8.12.23). > >>>> > >>>> > >>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html > >>>> > >>> > >>> LGTM > >>> > >> > >> It works perfectly except one subtree we missed during initial review and which > >> we should discuss: > >> > >> cn=replicas,cn=ipa,cn=etc,SUFFIX > >> > >> It contains list of replicas (not FreeIPA masters) connected to FreeIPA. > >> Currently, this only affects Winsync replicas. > >> > >> I just verified that anonymous user can retrieve list of connected ADs via > >> winsync. Question is, how to prevent it given that this is created dynamically > >> also by older FreeIPA server and given that it has no special objectsclass to > >> base a filtration on. > >> > >> Maybe we would need to add a deny ACI in this case after all? > > > > Or we can add an objectclass here too, the update script will then need > > to look at existing objects dynamically and update them. > > This would not work well as older FreeIPA servers would not use this > objectclass when "ipa-replica-manage connect --winsync" is run on them. I know, although you are probably not supposed to keep creating these kind of agreements until you finish upgrading all the server, we always advice people to upgrade the infra in a matter of weeks. > > However we could also ass a deny aci only in this subtree for now and > > change it later, if we think that's too much work. > > > > We have plans to revisit shared replica information storage anyway, so > > perhaps it is not worth spending too much time on this now. > > > > Simo. > > deny ACI is preventing access to nsContainer to anonymous users in > cn=replica... is probably it is our best shot ATM unless we find a better solution. Agree. simo. From pspacek at redhat.com Fri Apr 18 15:10:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 18 Apr 2014 17:10:19 +0200 Subject: [Freeipa-devel] [PATCH 0244-0245] Add basic support for inline-signingSeparate raw and secure zones in Zone Register Message-ID: <5351405B.7000003@redhat.com> Hello, Add basic support for inline-signing. Inline-signing is enabled for zones with idnsSecInlineSigning attribute = TRUE. Limitations: - Signing configuration is hardcoded in create_zone() as magic constants - idnsSecInlineSigning attribute cannot be changed at run-time - DNS updates are not supported - Signing keys have to be pre-generated and stored in ///keys directory before named is started https://fedorahosted.org/bind-dyndb-ldap/ticket/56 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0244-Separate-raw-and-secure-zones-in-Zone-Register.patch Type: text/x-patch Size: 13680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0245-Add-basic-support-for-inline-signing.patch Type: text/x-patch Size: 8663 bytes Desc: not available URL: From sbose at redhat.com Fri Apr 18 16:52:30 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 18 Apr 2014 18:52:30 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <1397800410.2628.144.camel@willson.li.ssimo.org> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <5350A303.7030008@redhat.com> <1397800410.2628.144.camel@willson.li.ssimo.org> Message-ID: <20140418165230.GR4165@localhost.localdomain> On Fri, Apr 18, 2014 at 01:53:30AM -0400, Simo Sorce wrote: > On Thu, 2014-04-17 at 23:58 -0400, Dmitri Pal wrote: > > > yes, this can already be controlled by the idrange type. But you > > have to > > > choose either algorithmic or manual mapping you cannot have both in > > a > > > given domain. What you can do is to create a domain in the AD forest > > for > > > the old users and one for the new users. Now you can use manual > > mapping > > > for the old-users-domain and algorithmic mapping for the > > > new-users-domain. > > > > If this requires moving users between domains on AD side then this is > > a > > non starter. > > The more I read it the more I think that decision is wrong and it is > > bug. > > > What we can do is halfway, if an overlay view is activate for an AD > domain then in IPA we have options to automatically generate IDs for any > AD user (if the admin wants), these IDs get stored in the Ad overlaying > view. > > >From the SSSD pov no algoritmic mapping is occurring as SSSD always > looks for the IDs in IPA. > > Note that we have to do this anyway if you want to allow also legacy > clients to see the same ids, so it seem to me the best/only possible > way. I agree, this sounds like safe and robust solution to the discussed issues. I wonder if we shouldn't do this always for all users and groups in the AD trusted AD forests? Since it looks like most real-world deployments would need it anyways it might be easier to stop thinking about the few cases where this is not needed. We will have lots of additional objects in the database but on the plus side: - the compat-tree does not have to talk to SSSD and keep the users and groups in memory but can just read of object from the tree, maybe do some modification and deliver the result. - the current extdom plugin won't be needed anymore because all it's operations can be done by SSSD with plain ldapsearch. I'm not sure but it might also be the only way to resolve the user or group name for a given UID or GID in a more complex environment. > > The only caveat is that it requires some development on the IPA side to > do this object creation, but it is not a lot of code as we can reuse DNA > for the actual ID allocation, we just need to create the entry in the > view. Or as an alternative SSSD running in ipa-server-mode can create the missing objects? Since SSSD in ipa-server-mode is currently doing the ID allocation it would be easily to keep compatibility with older versions. bye, Sumit > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From sbose at redhat.com Fri Apr 18 18:03:39 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 18 Apr 2014 20:03:39 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140418165230.GR4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <5350A303.7030008@redhat.com> <1397800410.2628.144.camel@willson.li.ssimo.org> <20140418165230.GR4165@localhost.localdomain> Message-ID: <20140418180339.GS4165@localhost.localdomain> On Fri, Apr 18, 2014 at 06:52:30PM +0200, Sumit Bose wrote: > On Fri, Apr 18, 2014 at 01:53:30AM -0400, Simo Sorce wrote: > > On Thu, 2014-04-17 at 23:58 -0400, Dmitri Pal wrote: > > > > yes, this can already be controlled by the idrange type. But you > > > have to > > > > choose either algorithmic or manual mapping you cannot have both in > > > a > > > > given domain. What you can do is to create a domain in the AD forest > > > for > > > > the old users and one for the new users. Now you can use manual > > > mapping > > > > for the old-users-domain and algorithmic mapping for the > > > > new-users-domain. > > > > > > If this requires moving users between domains on AD side then this is > > > a > > > non starter. > > > The more I read it the more I think that decision is wrong and it is > > > bug. > > > > > What we can do is halfway, if an overlay view is activate for an AD > > domain then in IPA we have options to automatically generate IDs for any > > AD user (if the admin wants), these IDs get stored in the Ad overlaying > > view. > > > > >From the SSSD pov no algoritmic mapping is occurring as SSSD always > > looks for the IDs in IPA. > > > > Note that we have to do this anyway if you want to allow also legacy > > clients to see the same ids, so it seem to me the best/only possible > > way. > > I agree, this sounds like safe and robust solution to the discussed > issues. I wonder if we shouldn't do this always for all users and groups > in the AD trusted AD forests? Since it looks like most real-world > deployments would need it anyways it might be easier to stop thinking > about the few cases where this is not needed. We will have lots of > additional objects in the database but on the plus side: > > - the compat-tree does not have to talk to SSSD and keep the users and > groups in memory but can just read of object from the tree, maybe do > some modification and deliver the result. > - the current extdom plugin won't be needed anymore because all it's > operations can be done by SSSD with plain ldapsearch. Another benefit would be easier group management because since now AD users and group have an object in the IPA tree, they can be added to IPA groups directly without the need of an external group. A positive side-effect is that migrations from the win-sync solution would become much easier. bye, Sumit > > I'm not sure but it might also be the only way to resolve the user or > group name for a given UID or GID in a more complex environment. > > > > The only caveat is that it requires some development on the IPA side to > > do this object creation, but it is not a lot of code as we can reuse DNA > > for the actual ID allocation, we just need to create the entry in the > > view. > > Or as an alternative SSSD running in ipa-server-mode can create the > missing objects? Since SSSD in ipa-server-mode is currently doing the ID > allocation it would be easily to keep compatibility with older versions. > > bye, > Sumit > > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > _______________________________________________ > > 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 dpal at redhat.com Sat Apr 19 16:42:51 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 19 Apr 2014 12:42:51 -0400 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust In-Reply-To: <20140418180339.GS4165@localhost.localdomain> References: <20140415091338.GE4165@localhost.localdomain> <534F2808.5010708@redhat.com> <20140417091539.GJ4165@localhost.localdomain> <5350A303.7030008@redhat.com> <1397800410.2628.144.camel@willson.li.ssimo.org> <20140418165230.GR4165@localhost.localdomain> <20140418180339.GS4165@localhost.localdomain> Message-ID: <5352A78B.4000409@redhat.com> On 04/18/2014 02:03 PM, Sumit Bose wrote: > On Fri, Apr 18, 2014 at 06:52:30PM +0200, Sumit Bose wrote: >> On Fri, Apr 18, 2014 at 01:53:30AM -0400, Simo Sorce wrote: >>> On Thu, 2014-04-17 at 23:58 -0400, Dmitri Pal wrote: >>>>> yes, this can already be controlled by the idrange type. But you >>>> have to >>>>> choose either algorithmic or manual mapping you cannot have both in >>>> a >>>>> given domain. What you can do is to create a domain in the AD forest >>>> for >>>>> the old users and one for the new users. Now you can use manual >>>> mapping >>>>> for the old-users-domain and algorithmic mapping for the >>>>> new-users-domain. >>>> If this requires moving users between domains on AD side then this is >>>> a >>>> non starter. >>>> The more I read it the more I think that decision is wrong and it is >>>> bug. >>>> >>> What we can do is halfway, if an overlay view is activate for an AD >>> domain then in IPA we have options to automatically generate IDs for any >>> AD user (if the admin wants), these IDs get stored in the Ad overlaying >>> view. >>> >>> >From the SSSD pov no algoritmic mapping is occurring as SSSD always >>> looks for the IDs in IPA. >>> >>> Note that we have to do this anyway if you want to allow also legacy >>> clients to see the same ids, so it seem to me the best/only possible >>> way. >> I agree, this sounds like safe and robust solution to the discussed >> issues. I wonder if we shouldn't do this always for all users and groups >> in the AD trusted AD forests? Since it looks like most real-world >> deployments would need it anyways it might be easier to stop thinking >> about the few cases where this is not needed. We will have lots of >> additional objects in the database but on the plus side: >> >> - the compat-tree does not have to talk to SSSD and keep the users and >> groups in memory but can just read of object from the tree, maybe do >> some modification and deliver the result. >> - the current extdom plugin won't be needed anymore because all it's >> operations can be done by SSSD with plain ldapsearch. > Another benefit would be easier group management because since now AD > users and group have an object in the IPA tree, they can be added to IPA > groups directly without the need of an external group. > > A positive side-effect is that migrations from the win-sync solution > would become much easier. Yes this seems like the right direction to go. > > bye, > Sumit > >> I'm not sure but it might also be the only way to resolve the user or >> group name for a given UID or GID in a more complex environment. >>> The only caveat is that it requires some development on the IPA side to >>> do this object creation, but it is not a lot of code as we can reuse DNA >>> for the actual ID allocation, we just need to create the entry in the >>> view. >> Or as an alternative SSSD running in ipa-server-mode can create the >> missing objects? Since SSSD in ipa-server-mode is currently doing the ID >> allocation it would be easily to keep compatibility with older versions. >> >> bye, >> Sumit >> >>> Simo. >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> _______________________________________________ >>> 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Mon Apr 21 12:39:14 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Apr 2014 08:39:14 -0400 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <1397774273.2628.137.camel@willson.li.ssimo.org> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> <535054E6.4020904@redhat.com> <1397774273.2628.137.camel@willson.li.ssimo.org> Message-ID: <53551172.20608@redhat.com> Simo Sorce wrote: > On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: >>>>>> I would like to discuss more on the managed read permissions upgrades [1]. >>>>>> Right now, we simply merge an old permission with the new one, making sure that >>>>>> we only add new attributes instead of just replacing them, to prevent a managed >>>>>> permission to be spoiled by a lower FreeIPA server version which runs an updates. >>>>>> >>>>>> I was thinking about it some more and seems to me we could run in problems when >>>>>> we for example find out that some permission is too relaxed and we want to >>>>>> remove some default attribute. Or when we want to update the permission filter. >>>>>> Or when object has anonymous and authenticated permission and we want to move >>>>>> attribute from anonymous to authenticated permission. >>>>>> >>>>>> Changes like this can happen, especially in the first release and we do not >>>>>> have means to address them. What about simply versioning the permissions as we >>>>>> do with our configs? I.e. >>>>>> >>>>>> 1) Introduce new MUST numeric attribute ipaPermVersion >>>>>> 2) Add 'version' field to managed permissions: >>>>>> >>>>>> managed_permissions = { >>>>>> 'System: Read Roles': { >>>>>> 'version': 1, >>>>>> 'replaces_global_anonymous_aci': True, >>>>>> 'ipapermbindruletype': 'permission', >>>>>> 'ipapermright': {'read', 'search', 'compare'}, >>>>>> 'ipapermdefaultattr': { >>>>>> 'businesscategory', 'cn', 'description', 'member', 'memberof', >>>>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', >>>>>> }, >>>>>> 'default_privileges': {'RBAC Readers'}, >>>>>> }, >>>>>> } >>>>>> 3) Modify updater to only update the permission if it's version is higher than >>>>>> the one in LDAP. In that case, it should simply replace the managed permission >>>>>> attributes with the new one, no merging (except the attributes that we allow >>>>>> users to change). >>>>>> >>>>>> When we want to change the permission, we simply do the changes, bump the >>>>>> version and we are done and we do not need to fear some older FreeIPA will >>>>>> overwrite it. That of course assumes that the versioning would be available >>>>>> from FreeIPA 4.0. >>>>>> >>>>>> Makes sense? >>>>>> >>>>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>> >>>>> >>>>> Uhmm, yes, and no, let me explain. >>>>> >>>>> What you say *does* make sense, but you are being too focused :-) >>>>> The upgrade issue is not limited to permissions, but affects everything. >>>>> >>>>> I think that what we need is to add a "ipa schema version" attribute >>>>> somewhere in cn=etc, and then always check this number in the updater >>>>> script. if this number is higher than what we know we immediately stop >>>>> and do not perform updates that affect anything but our own server data. >>>>> >>>>> This will protect the whole tree from unintentional changes caused by an >>>>> older replica. >>>>> >>>>> Makes sense ? >>>> >>>> This could lead to new features not working. Those features would rely >>>> on containers, ACIs, etc to exist but they wouldn't if the updates >>>> aren't run. >>> >>> Sorry I don't get this, if they are new features, then the version will >>> be "older" and the update *will* run and at the end raise the version. >>> >>> We just prevent old updates from running and current updates from >>> running multiple times, for the shared tree. >>> >>> Do we depend on having updates run multiple times for the data in the >>> shared tree ? >>> >>> Note that I am not saying that all updates should stop, any update for >>> cn=config would still need to be run on each server (although setting a >>> version there too would probably be beneficial). >> >> Ok, so the update runs, adds data, which gets replicated out to >> potentially old servers, and we're at the place you said we wouldn't be. > > I am not following you, the aim here is not to avoid replicating new > data to old server, the aim is that if you update the rpm of an older > replica and the rpm runs the ldap updater with the *old* code, we do not > end up with that updater *undoing* what a more recent update did. > >> Updates are all loaded and sorted so that all changes to a given DN >> should be applied at once, so it isn't like applying a old update and a >> new update are two separate operations. In fact, it would likely be a >> no-op in the case that they have already been applied. >> >> Do you have any examples to clarify your concerns? I'm not following you. > > Sure at some point version freeipa version 4.2 is released and it has an > update that changes a default object so that now attribute 'foo' is > added, this is done through the updater. > > Later on we release freeipa version 5.0 and we realize we will have > again to remove attribute 'foo' because we never really needed it, plus > if it is still there it causes issues to new feature XYZ. > > The admin installs 5.0 and all are happy, then a week later he runs a > simply yum update on th eolder replicas still running 4.2 and 4.2.1 is > available, and gets installed and ... bah the 4.2.1 updater re-adds > attribute 'foo' back ... and 5.0 servers are now broken. > > If we have an updater version field when the 4.2.1 update goes on it > will see that all updates that were necessary (and more) have already > been added and just quits. Ok, this won't happen in a modify case. When changing data we only change a known existing value, so exact match is required. The only risk is in adding and deleting data. So if we delete a permission named "Do cool stuff" in 5.0 and that was something previously added in 4.2 then yeah, re-running the 4.2 updates will re-apply the data. Similarly deletes would always be applied. I would not be keen on adding a global version value though, as we've had issues with updates in the past where re-running the updater would fix things. This would short circuit that. Something more fine-grained might work but carries its own problems. rob From simo at redhat.com Mon Apr 21 12:48:00 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 21 Apr 2014 08:48:00 -0400 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <53551172.20608@redhat.com> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> <535054E6.4020904@redhat.com> <1397774273.2628.137.camel@willson.li.ssimo.org> <53551172.20608@redhat.com> Message-ID: <1398084480.2628.220.camel@willson.li.ssimo.org> On Mon, 2014-04-21 at 08:39 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: > >>>>>> I would like to discuss more on the managed read permissions upgrades [1]. > >>>>>> Right now, we simply merge an old permission with the new one, making sure that > >>>>>> we only add new attributes instead of just replacing them, to prevent a managed > >>>>>> permission to be spoiled by a lower FreeIPA server version which runs an updates. > >>>>>> > >>>>>> I was thinking about it some more and seems to me we could run in problems when > >>>>>> we for example find out that some permission is too relaxed and we want to > >>>>>> remove some default attribute. Or when we want to update the permission filter. > >>>>>> Or when object has anonymous and authenticated permission and we want to move > >>>>>> attribute from anonymous to authenticated permission. > >>>>>> > >>>>>> Changes like this can happen, especially in the first release and we do not > >>>>>> have means to address them. What about simply versioning the permissions as we > >>>>>> do with our configs? I.e. > >>>>>> > >>>>>> 1) Introduce new MUST numeric attribute ipaPermVersion > >>>>>> 2) Add 'version' field to managed permissions: > >>>>>> > >>>>>> managed_permissions = { > >>>>>> 'System: Read Roles': { > >>>>>> 'version': 1, > >>>>>> 'replaces_global_anonymous_aci': True, > >>>>>> 'ipapermbindruletype': 'permission', > >>>>>> 'ipapermright': {'read', 'search', 'compare'}, > >>>>>> 'ipapermdefaultattr': { > >>>>>> 'businesscategory', 'cn', 'description', 'member', 'memberof', > >>>>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', > >>>>>> }, > >>>>>> 'default_privileges': {'RBAC Readers'}, > >>>>>> }, > >>>>>> } > >>>>>> 3) Modify updater to only update the permission if it's version is higher than > >>>>>> the one in LDAP. In that case, it should simply replace the managed permission > >>>>>> attributes with the new one, no merging (except the attributes that we allow > >>>>>> users to change). > >>>>>> > >>>>>> When we want to change the permission, we simply do the changes, bump the > >>>>>> version and we are done and we do not need to fear some older FreeIPA will > >>>>>> overwrite it. That of course assumes that the versioning would be available > >>>>>> from FreeIPA 4.0. > >>>>>> > >>>>>> Makes sense? > >>>>>> > >>>>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions > >>>>> > >>>>> > >>>>> Uhmm, yes, and no, let me explain. > >>>>> > >>>>> What you say *does* make sense, but you are being too focused :-) > >>>>> The upgrade issue is not limited to permissions, but affects everything. > >>>>> > >>>>> I think that what we need is to add a "ipa schema version" attribute > >>>>> somewhere in cn=etc, and then always check this number in the updater > >>>>> script. if this number is higher than what we know we immediately stop > >>>>> and do not perform updates that affect anything but our own server data. > >>>>> > >>>>> This will protect the whole tree from unintentional changes caused by an > >>>>> older replica. > >>>>> > >>>>> Makes sense ? > >>>> > >>>> This could lead to new features not working. Those features would rely > >>>> on containers, ACIs, etc to exist but they wouldn't if the updates > >>>> aren't run. > >>> > >>> Sorry I don't get this, if they are new features, then the version will > >>> be "older" and the update *will* run and at the end raise the version. > >>> > >>> We just prevent old updates from running and current updates from > >>> running multiple times, for the shared tree. > >>> > >>> Do we depend on having updates run multiple times for the data in the > >>> shared tree ? > >>> > >>> Note that I am not saying that all updates should stop, any update for > >>> cn=config would still need to be run on each server (although setting a > >>> version there too would probably be beneficial). > >> > >> Ok, so the update runs, adds data, which gets replicated out to > >> potentially old servers, and we're at the place you said we wouldn't be. > > > > I am not following you, the aim here is not to avoid replicating new > > data to old server, the aim is that if you update the rpm of an older > > replica and the rpm runs the ldap updater with the *old* code, we do not > > end up with that updater *undoing* what a more recent update did. > > > >> Updates are all loaded and sorted so that all changes to a given DN > >> should be applied at once, so it isn't like applying a old update and a > >> new update are two separate operations. In fact, it would likely be a > >> no-op in the case that they have already been applied. > >> > >> Do you have any examples to clarify your concerns? I'm not following you. > > > > Sure at some point version freeipa version 4.2 is released and it has an > > update that changes a default object so that now attribute 'foo' is > > added, this is done through the updater. > > > > Later on we release freeipa version 5.0 and we realize we will have > > again to remove attribute 'foo' because we never really needed it, plus > > if it is still there it causes issues to new feature XYZ. > > > > The admin installs 5.0 and all are happy, then a week later he runs a > > simply yum update on th eolder replicas still running 4.2 and 4.2.1 is > > available, and gets installed and ... bah the 4.2.1 updater re-adds > > attribute 'foo' back ... and 5.0 servers are now broken. > > > > If we have an updater version field when the 4.2.1 update goes on it > > will see that all updates that were necessary (and more) have already > > been added and just quits. > > Ok, this won't happen in a modify case. When changing data we only > change a known existing value, so exact match is required. > > The only risk is in adding and deleting data. > > So if we delete a permission named "Do cool stuff" in 5.0 and that was > something previously added in 4.2 then yeah, re-running the 4.2 updates > will re-apply the data. Similarly deletes would always be applied. > > I would not be keen on adding a global version value though, as we've > had issues with updates in the past where re-running the updater would > fix things. This would short circuit that. Well we could allow the updater to run on "same version" values, this would preserve this ability while still blocking older updaters. Besides modifies can be affected too, say we have default value of 10, we change it to 20 in 4.2 then change it back to 10 in 5.0 as we found an issue with the new value. If you run 4.2 updater it puts it back to 20. All cases of flipping values are also affected. > Something more fine-grained might work but carries its own problems. I think in this case we really want a domain level version, as the tree is shared and we want updates to be consistent, so the update need to be applied in full or not at all IMO. We do have some fine-grained approach as we will have a separate version for he shared tree than the cn=config tree (and I guess another one for the CA tree). Each tree is a Silo, and should have its own tree version. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Apr 21 13:02:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Apr 2014 09:02:56 -0400 Subject: [Freeipa-devel] Client compatibility article In-Reply-To: <5351108A.5070808@redhat.com> References: <5350E36A.4000109@redhat.com> <5350E7CD.4010900@redhat.com> <53510C7D.2010902@redhat.com> <53510F41.6090603@redhat.com> <5351108A.5070808@redhat.com> Message-ID: <53551700.8080605@redhat.com> Martin Kosek wrote: > On 04/18/2014 01:40 PM, Petr Viktorin wrote: >> On 04/18/2014 01:29 PM, Martin Kosek wrote: >>> On 04/18/2014 10:52 AM, Petr Viktorin wrote: >>>> On 04/18/2014 10:33 AM, Martin Kosek wrote: >>>>> FYI - I saw numerous questions about "ipa" tool backward compatibility (the >>>>> most recent is https://bugzilla.redhat.com/show_bug.cgi?id=1089015), so I >>>>> created a section about it: >>>>> >>>>> http://www.freeipa.org/page/Client#Compatibility >>>>> >>>>> and added it to FAQ. >>>>> >>>> >>>> Looking for the version in an internal module doesn't strike me as the best >>>> method. Especially if you have to add a warning to not change the file. (And >>>> changing it is just "discouraged"? Really?) >>> >>> I specifically added the warning about changing it because this is what the >>> user in the Bugzilla did and I really want to discourage people doing that. If >>> you have better wording in mind, please feel free to improve :-) >> >> I'd rather not mention it at all; saying "here is a stupid thing you really >> shouldn't do" will just make people do it. > > Umm, ok, makes sense :) I removed the warning. > As another data pint, ipa ping will show the server version: # rpm -q freeipa-client freeipa-client-3.3.90GIT6044229-0.fc20.x86_64 # ipa ping ------------------------------------------ IPA server version 3.0.0. API version 2.49 ------------------------------------------ # ipa user-show admin ipa: ERROR: 2.81 client incompatible with 2.49 server at ... rob From edewata at redhat.com Mon Apr 21 17:35:59 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 21 Apr 2014 13:35:59 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <1397588080.31462.4.camel@aleeredhat.laptop> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> <53439C4D.6060108@redhat.com> <5343FF31.8050206@redhat.com> <1397486532.29593.8.camel@aleeredhat.laptop> <534D5324.4060802@redhat.com> <1397588080.31462.4.camel@aleeredhat.laptop> Message-ID: <1067369466.6403757.1398101759857.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Attached is a patch that adds the script ipa-drm-install. > > This script will be used to install a drm in any ipa server that > contains a Dogtag CA. Right now, it works for a master. I will add > logic in a subsequent patch to allow the installation on a replica using > the same script. > > This patch is to applied on top of the previous one. > So, patch 2 and then patch 3. > > I will create a patch to address the issues mentioned below, as well as > some other formatting issues reported by pycharm. > > Thanks, > Ade Tested the patches and they seem to be working fine. Discussed over IRC some minor issues and other issues that will be addressed separately. From Dogtag's perspective it's ACK'd. -- Endi S. Dewata From rcritten at redhat.com Mon Apr 21 19:13:10 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Apr 2014 15:13:10 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <1397588080.31462.4.camel@aleeredhat.laptop> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> <53439C4D.6060108@redhat.com> <5343FF31.8050206@redhat.com> <1397486532.29593.8.camel@aleeredhat.laptop> <534D5324.4060802@redhat.com> <1397588080.31462.4.camel@aleeredhat.laptop> Message-ID: <53556DC6.2000900@redhat.com> Ade Lee wrote: > Attached is a patch that adds the script ipa-drm-install. > > This script will be used to install a drm in any ipa server that > contains a Dogtag CA. Right now, it works for a master. I will add > logic in a subsequent patch to allow the installation on a replica using > the same script. > > This patch is to applied on top of the previous one. > So, patch 2 and then patch 3. > > I will create a patch to address the issues mentioned below, as well as > some other formatting issues reported by pycharm. I think the ipa-dns-install change should be committed separately. It is surprising that pylint didn't catch that. Please a comment to find_subject_base() that it can only be executed AFTER the ipa server is configured, the api is initialized elsewhere and requires that a ticket already have been acquired. I understand why this call is here, we just need to be clear it is used post-install and requires some pre-setup by the caller. Need a man page for ipa-drm-install. Running the uninstaller completes, then proceeds to install the DRM. I don't think the certmonger warnings apply because some of the certs are duplicates of the CA certs, so if you untracked them you would eventually end up not renewing the subsystem certs and your clone CA would fail. nit, some trailing white space after add_record_to_hosts() The tool failed to add a DRM in my test. The debug log doesn't seem to contain anything interesting at all. The drm install log contained: 2014-04-21T19:00:44Z DEBUG Starting external process 2014-04-21T19:00:44Z DEBUG args=/usr/sbin/pkispawn -s KRA -f /tmp/tmpWcj8rJ 2014-04-21T19:01:09Z DEBUG Process finished, return code=1 2014-04-21T19:01:09Z DEBUG stdout=Loading deployment configuration from /tmp/tmpWcj8rJ. Installing KRA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/kra/deployment.cfg. Installation failed. 2014-04-21T19:01:09Z DEBUG stderr= 2014-04-21T19:01:09Z CRITICAL failed to configure KRA instance Command '/usr/sbin/pkispawn -s KRA -f /tmp/tmpWcj8rJ' returned non-zero exit status 1 > > Thanks, > Ade > > On Tue, 2014-04-15 at 11:41 -0400, Rob Crittenden wrote: >> Ade Lee wrote: >>> Attached a new patch to address some of the concerns below, specifically >>> I created a new base class DogtagInstance, in which much of the common >>> CA/KRA code is placed. I'm sure we could go further in reducing >>> duplication, and I'm open to further suggestions and refinements. >>> >>> I did not tackle the packaging and spec file dependencies, because I'd >>> like some clearer direction on how we want to proceed here. In any >>> case, I think the splitting of the ipa packages into ca and possibly kra >>> packages should be a separate patch. >>> >>> As before, with this patch you can: >>> - install a ca and drm using ipa-server-install >>> - install a ca and drm replica using >>> ipa-replica-prepare >>> ipa-replica-install --setup-ca --setup-drm >>> >>> You need to use a PKI build from the 10.2 (master) branch). One such >>> build is given below: >>> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo >> >> The terms KRA and DRM tend to be used interchangeably. Should we pick one? >> >> Need to bump the version number in install/conf/ipa-pki-proxy.conf so >> that upgrades get the new LocationMatch. >> >> ipa-replica-install still uses the if/then to set the value of >> enable_drm when it can be reduced like you did in ipa-server-install. >> >> In ipa-server-install you have an extra comment, probably left for >> yourself: # code to create drm here >> >> In dogtaginstance.py there are a few direct references to DRM in >> comments and output. >> >> cainstance.py doesn't need to override is_installed.py >> >> I also don't think you need the explicit definitions for enable, >> start_instance, etc. Those should be inherited from the DogtagInstance >> class, in both cainstance.py and drminstance.py. >> >> I think spawn_instance should take an option to add things to nolog in >> case there are server-independent things we don't want to log. >> >> I don't want to pile too much on, but it seems to me that if we are >> going to copy in default.conf then we can do away with realm_info >> completely and just use default.conf. Both would need to be supported >> for a while though. Martin, what do you think? >> >> I still have quite a bit of functional testing to go. I've only >> installed a fresh standalone master. Still need to do upgrade and >> replication testing. >> >> rob >> > From redhatrises at gmail.com Mon Apr 21 23:48:47 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 21 Apr 2014 17:48:47 -0600 Subject: [Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges Message-ID: Hello, Patch for the following ticket to add note in documentation about bad uid ranges: https://fedorahosted.org/freeipa/ticket/2090 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0016-DOC-Sometimes-users-set-bad-uid-ranges.patch Type: text/x-patch Size: 2115 bytes Desc: not available URL: From jcholast at redhat.com Tue Apr 22 09:34:29 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 22 Apr 2014 11:34:29 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> Message-ID: <535637A5.1020107@redhat.com> On 11.4.2014 17:23, Martin Basti wrote: > Updated patches attached. > > Patch 0047-1 should be applied between patches 0040-2 and 0041-2 > > Patch 0043-1 was squashed into 0038-2 > Patch 0044-1 was squashed into 0039-2 > Patch 0034-1 was squashed into 0032-2 > Patch 0034-2 implements bug fix > > Patches should be applied in order: 0029-0040, 0047, 0041-0042, > 0045-0046. > Patch 29: Please keep line length under 80 characters: - return x[self.obj.primary_key.name][0].lower() + return self.obj.primary_key.sort_key(x[self.obj.primary_key.name][0]) Patch 30: 1) You can shorten DNSName.ToASCII to: def ToASCII(self): return str(self).decode('ascii') 2) Please keep line length under 80 characters: + def choose_relativity(self, origin=None, relativize=True): + return DNSName(super(DNSName, self).choose_relativity(origin=origin, relativize=relativize)) 3) + def is_idn(self): + return any(label.startswith(u'xn--') for label in self.labels) Labels are str, so drop the u from 'xn--'. 4) + + +#DNS public constants +DNSName.root = DNSName(dns.name.root) # '.' +DNSName.empty = DNSName(dns.name.empty) # '@' +DNSName.ip4_rev_zone = DNSName(('in-addr','arpa','')) +DNSName.ip6_rev_zone = DNSName(('ip6','arpa','')) \ No newline at end of file The extra newline at the beginning is not necessary, the constants are part of DNSName definition. Put spaces after commas in tuples. Add the missing newline at the end of the file. Patch 31: 1) + type = DNSName Please also add type_error = _('must be DNS name') 2) + if(value != normalized_domain_name): Why the weird parenthesised if? 3) + error = _("domain name '%(domain)s' and normalized domain name " + "'%(normalized)s' do not match. Please use only " + "normalized domains") % {'domain':value, + 'normalized':normalized_domain_name} Too much indentation, keep line length under 80 characters. 4) + + + def _rule_only_absolute(self, _, value): + if self.only_absolute and not value.is_absolute(): + return _('must be absolute') The extra new line at the beginning should not be there. Patch 32: 1) The patch does not compile: Capability dns_name_values in ipalib, not in API 2) The patch needs a rebase. Patch 33: Still don't know why is this patch necessary (it should not be). Patch 34: 1) The patch does not compile: Arg in dnsrecord_add doesn't match. Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, primary_key=True, query=True, required=True) Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) Arg in dnsrecord_del doesn't match. Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, primary_key=True, query=True, required=True) Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) Arg in dnsrecord_delentry doesn't match. Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, primary_key=True, query=True, required=True) Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) Arg in dnsrecord_find doesn't match. Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, primary_key=True, query=True, required=True) Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) Arg in dnsrecord_mod doesn't match. Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, primary_key=True, query=True, required=True) Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) Arg in dnsrecord_show doesn't match. Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, primary_key=True, query=True, required=True) Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) 2) I think the patch deserves a better commit message. Patch 35: No whitespace changes please: from ipapython.version import API_VERSION - Patch 37: The patch does not compile: Output in dnszone_add_permission doesn't match. Got Output('value', , None) Expected PrimaryKey('value', None, None) Output in dnszone_remove_permission doesn't match. Got Output('value', , None) Expected PrimaryKey('value', None, None) Patch 38: 1) The patch does not compile: Traceback (most recent call last): File "./makeapi", line 457, in sys.exit(main()) File "./makeapi", line 428, in main api.finalize() File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugable.py", line 705, in finalize self.__do_if_not_done('load_plugins') File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugable.py", line 481, in __do_if_not_done getattr(self, name)() File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugable.py", line 642, in load_plugins self.import_plugins('ipalib') File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugable.py", line 686, in import_plugins __import__(fullname) File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugins/dns.py", line 906, in class AFSDBRecord(DNSRecord): File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugins/dns.py", line 916, in AFSDBRecord _bind_hostname_validator, NameError: name '_bind_hostname_validator' is not defined 2) Please keep line length under 80 characters: +from ipalib.util import (validate_zonemgr, normalize_zonemgr, + get_dns_forward_zone_update_policy, + get_dns_reverse_zone_update_policy, get_reverse_zone_default, + REVERSE_DNS_ZONES) - add_records_for_host_validation('ip_address', host, domain, + add_records_for_host_validation('ip_address', DNSName(host), DNSName(domain), - add_records_for_host(host, domain, options['ip_address'], + add_records_for_host(DNSName(host), DNSName(domain), options['ip_address'], 3) No whitespace changes please: + def _create_zone_serial(): + def normalize_zonemgr(zonemgr): - def validate_zonemgr(zonemgr): 4) Why are relative names supported in _hostname_validator? Also, you can shorten it a little bit: def _hostname_validator(ugettext, value): assert isinstance(value, DNSName) if len(value.make_absolute().labels) < 3: return _('invalid domain-name: not fully qualified') 5) + if revdns.is_subdomain(zonename.make_absolute()): + if revzone is None: + revzone = zonename + elif zonename.is_subdomain(revzone): + revzone = zonename I would prefer this: if (revdns.is_subdomain(zonename.make_absolute() and (revzone is None or zonename.is_subdomain(revzone))): revzone = zonename 6) Normalizers should accept only strings and return only strings, normalize_zonemgr should do that as well, there is no need for normalize_zonemgr_str. Also some of the checks are redundant. I think it should look something like this: def normalize_zonemgr(zonemgr): if not zonemgr or not isinstance(zonemgr, basestring): return zonemgr name, at, domain = zonemgr.partition('@') name = name.replace('.', '\\.') return '%s.%s' % (name, domain) 7) I don't think the DNSName branch in normalize_zone is necessary, you can call make_absolute on DNSName objects directly. The function should be for strings only. You can also make it shorter: def normalize_zone(zone): return str(DNSName(zone).make_absolute()) 8) validate_zonemgr does too many things at once. In the dns plugin, after idnssoarname is normalized and converted to DNSName, you just need to validate that it does not contain any "@" and has the right number of labels: def validate_zonemgr(zonemgr): assert isinstance(zonemgr, DNSName) assert zonemgr.is_absolute() if any('@' in label for label in zonemgr.labels): raise ValueError(_('too many \'@\' characters')) if len(zonemgr.labels) < 3: raise ValueError(_('missing address domain')) if not zonemgr.labels[0]: raise ValueError(_('missing mail account')) In bindinstance, you need to normalize and convert the value manually and then you can do the same check as in the dns plugins: def validate_zonemgr_str(zonemgr): zonemgr = normalize_zonemgr(zonemgr) zonemgr = DNSName(zonemgr).make_absolute() return validate_zonemgr(zonemgr) 9) Why strings and not DNSName objects? REVERSE_DNS_ZONES = { - '.in-addr.arpa.' : 4, - '.ip6.arpa.' : 32, + u'in-addr.arpa.' : 4, + u'ip6.arpa.' : 32, } 10) You can shorten zone_is_reverse to: def zone_is_reverse(zone_name): return DNSName(zone_name).is_reverse() Patch 39: 1) The patch does not compile: Traceback (most recent call last): File "./makeapi", line 457, in sys.exit(main()) File "./makeapi", line 428, in main api.finalize() File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugable.py", line 705, in finalize self.__do_if_not_done('load_plugins') File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugable.py", line 481, in __do_if_not_done getattr(self, name)() File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugable.py", line 642, in load_plugins self.import_plugins('ipalib') File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugable.py", line 686, in import_plugins __import__(fullname) File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugins/dns.py", line 1298, in class PTRRecord(DNSRecord): File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugins/dns.py", line 1306, in PTRRecord doc=_('The hostname this reverse record points to'), File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/parameters.py", line 1892, in __init__ super(DNSNameParam, self).__init__(name, *rules, **kw) File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/parameters.py", line 444, in __init__ ', '.join(repr(k) for k in sorted(extra)) TypeError: DNSNameParam('hostname'): takes no such kwargs: 'require_absolute' Traceback (most recent call last): File "./makeapi", line 457, in sys.exit(main()) File "./makeapi", line 428, in main api.finalize() File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugable.py", line 705, in finalize self.__do_if_not_done('load_plugins') File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugable.py", line 481, in __do_if_not_done getattr(self, name)() File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugable.py", line 642, in load_plugins self.import_plugins('ipalib') File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugable.py", line 686, in import_plugins __import__(fullname) File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugins/dns.py", line 1545, in class dnszone(LDAPObject): File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugins/dns.py", line 1588, in dnszone normalizer=normalize_zonemgr_idn, NameError: name 'normalize_zonemgr_idn' is not defined ... and a lot of Str/DNSNameParam mismatches in API.txt 2) You set only_absolute on some DNSNameParams which previously had _bind_hostname_validator and on some you don't. I would think it should be done consistently. 3) The idnssoarname param of dnszone should have only_absolute=True (in the original code the normalizer added the trailing dot). The default_from should be "lambda idnsname: DNSName(('hostmaster')).derelativize(idnsname)". 4) Str('hostname', label=_('Hostname'), + #No need IDN validation and normalization ), The comment seems a little but redundant to me. Patch 40: 1) make-lint reports these errors: ************* Module ipalib.plugins.dns ipalib/plugins/dns.py:408: [E0602(undefined-variable), _domain_name_validator] Undefined variable 'normalize_zone') ipalib/plugins/dns.py:409: [E0602(undefined-variable), _domain_name_validator] Undefined variable 'validate_domain_name') ipalib/plugins/dns.py:409: [E0602(undefined-variable), _domain_name_validator] Undefined variable 'zone_is_reverse') 2) +capability: dns_name_values 2.83 This is already in patch 32. 3) There already is dnsrecord.postprocess_record, IDN postprocessing should be done in there instead of _records_idn_postprocess. 4) - default_from=lambda idnsname: 'hostmaster.%s' % unicode(idnsname), - normalizer=normalize_zonemgr_idn, + default_from=lambda idnsname: u'hostmaster.%s' % unicode(idnsname), + normalizer=normalize_zonemgr, This belongs in patch 39. 5) dnszone.get_dn is unnecessarily complex, keys[-1] will always be an absolute DNSName, so you can drop the code path for relative names: def get_dn(self, *keys, **options): zone = keys[-1] assert isinstance(zone, DNSName) assert zone.is_absolute() zone = zone.ToASCII() dn = super(dnszone, self).get_dn(zone, **options) try: self.backend.get_entry(dn, ['']) except errors.NotFound: zone = zone[:-1] dn = super(dnszone, self).get_dn(zone, **options) return dn 6) You can shorten dnszone.get_name_in_zone code to: def get_name_in_zone(self, zone, hostname): assert isinstance(zone, DNSName) assert zone.is_absolute() assert isinstance(hostname, DNSName) if not hostname.is_absolute(): return hostname if hostname.is_subdomain(zone): return hostname.relativize(zone) 7) Conversions from string to DNSName in interactive_prompt_callbacks may fail, you should put them in try/except blocks: + zone = DNSName(kw['idnsname']).make_absolute() + ns = DNSName(kw['idnssoamname']) 8) idnssoamname from LDAP is converted to DNSName in patch 36, no need to do it again here: + nameserver = DNSName(entry_attrs['idnssoamname'][0]) + if nameserver.is_absolute(): 9) This should be handled in the realmdomains plugin, by raising a ValidationError: + and not zone.is_idn()): #Realmdomain doesnt support IDN 10) This should be indented better: + if (zone != DNSName(api.env.domain).make_absolute() and + not zone.is_idn() and #Realmdomain doesnt support IDN + not zone.is_reverse()): 11) Searching should work for any input, but you make a lot of assumptions in the IDN search code which may not be true. I think you should not use DNSName in this code, as it does too much validation. Use something like this instead: term = args[-1] if term: term = re.split(r'(? This applies to both dnszone_find and dnsrecord_find. 12) Make sure to store only lists in LDAP entries: + entry_attrs['idnsname'] = keys[-1].relativize(keys[-2]) 13) You don't have to move the "zone = keys[-2]" line here, just delete the normalize_zone line: - zone = keys[-2] if self.is_pkey_zone_record(*keys): - addr = u'' + addr = _dns_zone_record else: addr = keys[-1] - zone = normalize_zone(zone) + zone = keys[-2] 14) You can shorten this: + addr_len = len(addr.labels) if addr != _dns_zone_record else 0 to: addr_len = len(addr.labels) 15) Instead of comparing values to _dns_zone_record: + if idnsname == _dns_zone_record or idnsname == zonename: + if DNSName(kw['idnsname']) == _dns_zone_record: I think it would be better to add .is_empty() to DNSName and use it. 16) dnsrecord.is_pkey_zone_record seems related to dnszone.get_name_in_zone, maybe you can move the common parts to a single place and use it like this: def is_pkey_zone_record(self, *keys): name = get_name_in_zone(keys[-2], keys[-1]) if name is None: return False return name.is_empty() 17) Split this into multiple lines please: + keys = keys[:-1] + (keys[-1].relativize(keys[-2]).ToASCII(),) #Make RR name relative if possible 18) Please keep line length under 80 characters. Patch 47: The patch does not compile: Traceback (most recent call last): File "./makeapi", line 457, in sys.exit(main()) File "./makeapi", line 428, in main api.finalize() File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugable.py", line 705, in finalize self.__do_if_not_done('load_plugins') File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugable.py", line 481, in __do_if_not_done getattr(self, name)() File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugable.py", line 642, in load_plugins self.import_plugins('ipalib') File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugable.py", line 686, in import_plugins __import__(fullname) File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugins/host.py", line 35, in from ipalib.plugins.dns import (dns_container_exists, _record_types, ImportError: cannot import name _hostname_validator Option in dnsrecord_add doesn't match. Got DNSNameParam('ptr_part_hostname', attribute=False, cli_name='ptr_hostname', multivalue=False, option_group=u'PTR Record', required=False) Expected DNSNameParam('ptr_part_hostname', attribute=False, cli_name='ptr_hostname', multivalue=False, only_absolute=True, option_group=u'PTR Record', required=False) Option in dnsrecord_mod doesn't match. Got DNSNameParam('ptr_part_hostname', attribute=False, autofill=False, cli_name='ptr_hostname', multivalue=False, option_group=u'PTR Record', required=False) Expected DNSNameParam('ptr_part_hostname', attribute=False, autofill=False, cli_name='ptr_hostname', multivalue=False, only_absolute=True, option_group=u'PTR Record', required=False) I had some test failures, don't know which patch is to blame: ====================================================================== ERROR: test_dns[88]: dnszone_add: Create reverse zone u'70.16.172.in-addr.arpa.' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 358, in check_output got = api.Command[cmd](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request raise error_class(message=error['message']) NotFound: Nameserver 'ns1.zone3.test.' does not have a corresponding A/AAAA record ====================================================================== ERROR: test_dns[90]: dnsrecord_add: Add NS record to u'128/25' in revzone u'70.16.172.in-addr.arpa.' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 358, in check_output got = api.Command[cmd](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request raise error_class(message=error['message']) NotFound: 70.16.172.in-addr.arpa.: DNS zone not found ====================================================================== ERROR: test_dns[91]: dnsrecord_add: Add CNAME record to u'129' in revzone u'70.16.172.in-addr.arpa.' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 358, in check_output got = api.Command[cmd](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request raise error_class(message=error['message']) NotFound: 70.16.172.in-addr.arpa.: DNS zone not found Honza -- Jan Cholasta From pspacek at redhat.com Tue Apr 22 09:50:30 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Apr 2014 11:50:30 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <535637A5.1020107@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> Message-ID: <53563B66.2090308@redhat.com> On 22.4.2014 11:34, Jan Cholasta wrote: > On 11.4.2014 17:23, Martin Basti wrote: >> Updated patches attached. >> >> Patch 0047-1 should be applied between patches 0040-2 and 0041-2 >> >> Patch 0043-1 was squashed into 0038-2 >> Patch 0044-1 was squashed into 0039-2 >> Patch 0034-1 was squashed into 0032-2 >> Patch 0034-2 implements bug fix >> >> Patches should be applied in order: 0029-0040, 0047, 0041-0042, >> 0045-0046. >> > > Patch 29: > > Please keep line length under 80 characters: > > - return x[self.obj.primary_key.name][0].lower() > + return > self.obj.primary_key.sort_key(x[self.obj.primary_key.name][0]) > > > Patch 30: > > 1) > > You can shorten DNSName.ToASCII to: > > def ToASCII(self): > return str(self).decode('ascii') > > > 2) > > Please keep line length under 80 characters: > > + def choose_relativity(self, origin=None, relativize=True): > + return DNSName(super(DNSName, self).choose_relativity(origin=origin, > relativize=relativize)) > > > 3) > > + def is_idn(self): > + return any(label.startswith(u'xn--') for label in self.labels) > > Labels are str, so drop the u from 'xn--'. > > > 4) > > + > + > +#DNS public constants > +DNSName.root = DNSName(dns.name.root) # '.' > +DNSName.empty = DNSName(dns.name.empty) # '@' > +DNSName.ip4_rev_zone = DNSName(('in-addr','arpa','')) > +DNSName.ip6_rev_zone = DNSName(('ip6','arpa','')) > \ No newline at end of file > > The extra newline at the beginning is not necessary, the constants are part of > DNSName definition. > > Put spaces after commas in tuples. > > Add the missing newline at the end of the file. > > > Patch 31: > > 1) > > + type = DNSName > > Please also add type_error = _('must be DNS name') > > > 2) > > + if(value != normalized_domain_name): > > Why the weird parenthesised if? > > > 3) > > + error = _("domain name '%(domain)s' and normalized domain name " > + "'%(normalized)s' do not match. > Please use only " > + "normalized domains") % > {'domain':value, > + 'normalized':normalized_domain_name} > > Too much indentation, keep line length under 80 characters. > > > 4) > > + > + > + def _rule_only_absolute(self, _, value): > + if self.only_absolute and not value.is_absolute(): > + return _('must be absolute') > > The extra new line at the beginning should not be there. > > > Patch 32: > > 1) > > The patch does not compile: > > Capability dns_name_values in ipalib, not in API > > > 2) > > The patch needs a rebase. > > > Patch 33: > > Still don't know why is this patch necessary (it should not be). > > > Patch 34: > > 1) > > The patch does not compile: > > Arg in dnsrecord_add doesn't match. > Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, > primary_key=True, query=True, required=True) > Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) > Arg in dnsrecord_del doesn't match. > Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, > primary_key=True, query=True, required=True) > Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) > Arg in dnsrecord_delentry doesn't match. > Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, > primary_key=True, query=True, required=True) > Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) > Arg in dnsrecord_find doesn't match. > Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, > primary_key=True, query=True, required=True) > Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) > Arg in dnsrecord_mod doesn't match. > Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, > primary_key=True, query=True, required=True) > Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) > Arg in dnsrecord_show doesn't match. > Got Str('dnszoneidnsname', cli_name='dnszone', multivalue=False, > primary_key=True, query=True, required=True) > Expected Str('dnszoneidnsname', cli_name='dnszone', query=True, required=True) > > > 2) > > I think the patch deserves a better commit message. > > > Patch 35: > > No whitespace changes please: > > from ipapython.version import API_VERSION > - > > > Patch 37: > > The patch does not compile: > > Output in dnszone_add_permission doesn't match. Got Output('value', 'unicode'>, None) Expected PrimaryKey('value', None, None) > Output in dnszone_remove_permission doesn't match. Got Output('value', 'unicode'>, None) Expected PrimaryKey('value', None, None) > > > Patch 38: > > 1) > > The patch does not compile: > > Traceback (most recent call last): > File "./makeapi", line 457, in > sys.exit(main()) > File "./makeapi", line 428, in main > api.finalize() > File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugable.py", line 705, in > finalize > self.__do_if_not_done('load_plugins') > File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugable.py", line 481, in > __do_if_not_done > getattr(self, name)() > File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugable.py", line 642, in > load_plugins > self.import_plugins('ipalib') > File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugable.py", line 686, in > import_plugins > __import__(fullname) > File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugins/dns.py", line 906, > in > class AFSDBRecord(DNSRecord): > File "/tmp/freeipa-build.pZlGiFr4U7/build/ipalib/plugins/dns.py", line 916, > in AFSDBRecord > _bind_hostname_validator, > NameError: name '_bind_hostname_validator' is not defined > > > 2) > > Please keep line length under 80 characters: > > +from ipalib.util import (validate_zonemgr, normalize_zonemgr, > + get_dns_forward_zone_update_policy, > + get_dns_reverse_zone_update_policy, > get_reverse_zone_default, > + REVERSE_DNS_ZONES) > > > - add_records_for_host_validation('ip_address', host, domain, > + add_records_for_host_validation('ip_address', DNSName(host), > DNSName(domain), > > > - add_records_for_host(host, domain, options['ip_address'], > + add_records_for_host(DNSName(host), DNSName(domain), > options['ip_address'], > > > 3) > > No whitespace changes please: > > + > def _create_zone_serial(): > > > + > def normalize_zonemgr(zonemgr): > > > - > def validate_zonemgr(zonemgr): > > > 4) > > Why are relative names supported in _hostname_validator? > > Also, you can shorten it a little bit: > > def _hostname_validator(ugettext, value): > assert isinstance(value, DNSName) > if len(value.make_absolute().labels) < 3: > return _('invalid domain-name: not fully qualified') > > > 5) > > + if revdns.is_subdomain(zonename.make_absolute()): > + if revzone is None: > + revzone = zonename > + elif zonename.is_subdomain(revzone): > + revzone = zonename > > I would prefer this: > > if (revdns.is_subdomain(zonename.make_absolute() and > (revzone is None or zonename.is_subdomain(revzone))): > revzone = zonename > > > 6) > > Normalizers should accept only strings and return only strings, > normalize_zonemgr should do that as well, there is no need for > normalize_zonemgr_str. Also some of the checks are redundant. I think it > should look something like this: > > def normalize_zonemgr(zonemgr): > if not zonemgr or not isinstance(zonemgr, basestring): > return zonemgr > name, at, domain = zonemgr.partition('@') > name = name.replace('.', '\\.') > return '%s.%s' % (name, domain) > > > 7) > > I don't think the DNSName branch in normalize_zone is necessary, you can call > make_absolute on DNSName objects directly. The function should be for strings > only. You can also make it shorter: > > def normalize_zone(zone): > return str(DNSName(zone).make_absolute()) > > > 8) > > validate_zonemgr does too many things at once. > > In the dns plugin, after idnssoarname is normalized and converted to DNSName, > you just need to validate that it does not contain any "@" and has the right > number of labels: > > def validate_zonemgr(zonemgr): > assert isinstance(zonemgr, DNSName) > assert zonemgr.is_absolute() > if any('@' in label for label in zonemgr.labels): > raise ValueError(_('too many \'@\' characters')) > if len(zonemgr.labels) < 3: > raise ValueError(_('missing address domain')) > if not zonemgr.labels[0]: > raise ValueError(_('missing mail account')) > > In bindinstance, you need to normalize and convert the value manually and then > you can do the same check as in the dns plugins: > > def validate_zonemgr_str(zonemgr): > zonemgr = normalize_zonemgr(zonemgr) > zonemgr = DNSName(zonemgr).make_absolute() > return validate_zonemgr(zonemgr) > > > 9) > > Why strings and not DNSName objects? > > REVERSE_DNS_ZONES = { > - '.in-addr.arpa.' : 4, > - '.ip6.arpa.' : 32, > + u'in-addr.arpa.' : 4, > + u'ip6.arpa.' : 32, > } > > > 10) > > You can shorten zone_is_reverse to: > > def zone_is_reverse(zone_name): > return DNSName(zone_name).is_reverse() > > > Patch 39: > > 1) > > The patch does not compile: > > Traceback (most recent call last): > File "./makeapi", line 457, in > sys.exit(main()) > File "./makeapi", line 428, in main > api.finalize() > File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugable.py", line 705, in > finalize > self.__do_if_not_done('load_plugins') > File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugable.py", line 481, in > __do_if_not_done > getattr(self, name)() > File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugable.py", line 642, in > load_plugins > self.import_plugins('ipalib') > File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugable.py", line 686, in > import_plugins > __import__(fullname) > File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugins/dns.py", line > 1298, in > class PTRRecord(DNSRecord): > File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/plugins/dns.py", line > 1306, in PTRRecord > doc=_('The hostname this reverse record points to'), > File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/parameters.py", line 1892, > in __init__ > super(DNSNameParam, self).__init__(name, *rules, **kw) > File "/tmp/freeipa-build.w7CjNx7hkb/build/ipalib/parameters.py", line 444, > in __init__ > ', '.join(repr(k) for k in sorted(extra)) > TypeError: DNSNameParam('hostname'): takes no such kwargs: 'require_absolute' > > > Traceback (most recent call last): > File "./makeapi", line 457, in > sys.exit(main()) > File "./makeapi", line 428, in main > api.finalize() > File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugable.py", line 705, in > finalize > self.__do_if_not_done('load_plugins') > File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugable.py", line 481, in > __do_if_not_done > getattr(self, name)() > File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugable.py", line 642, in > load_plugins > self.import_plugins('ipalib') > File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugable.py", line 686, in > import_plugins > __import__(fullname) > File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugins/dns.py", line > 1545, in > class dnszone(LDAPObject): > File "/tmp/freeipa-build.8geSL2lbho/build/ipalib/plugins/dns.py", line > 1588, in dnszone > normalizer=normalize_zonemgr_idn, > NameError: name 'normalize_zonemgr_idn' is not defined > > > ... and a lot of Str/DNSNameParam mismatches in API.txt > > > 2) > > You set only_absolute on some DNSNameParams which previously had > _bind_hostname_validator and on some you don't. I would think it should be > done consistently. > > > 3) > > The idnssoarname param of dnszone should have only_absolute=True (in the > original code the normalizer added the trailing dot). > > The default_from should be "lambda idnsname: > DNSName(('hostmaster')).derelativize(idnsname)". > > > 4) > > Str('hostname', > label=_('Hostname'), > + #No need IDN validation and normalization > ), > > The comment seems a little but redundant to me. > > > Patch 40: > > 1) > > make-lint reports these errors: > > ************* Module ipalib.plugins.dns > ipalib/plugins/dns.py:408: [E0602(undefined-variable), _domain_name_validator] > Undefined variable 'normalize_zone') > ipalib/plugins/dns.py:409: [E0602(undefined-variable), _domain_name_validator] > Undefined variable 'validate_domain_name') > ipalib/plugins/dns.py:409: [E0602(undefined-variable), _domain_name_validator] > Undefined variable 'zone_is_reverse') > > > 2) > > +capability: dns_name_values 2.83 > > This is already in patch 32. > > > 3) > > There already is dnsrecord.postprocess_record, IDN postprocessing should be > done in there instead of _records_idn_postprocess. > > > 4) > > - default_from=lambda idnsname: 'hostmaster.%s' % unicode(idnsname), > - normalizer=normalize_zonemgr_idn, > + default_from=lambda idnsname: u'hostmaster.%s' % unicode(idnsname), > + normalizer=normalize_zonemgr, > > This belongs in patch 39. > > > 5) > > dnszone.get_dn is unnecessarily complex, keys[-1] will always be an absolute > DNSName, so you can drop the code path for relative names: > > def get_dn(self, *keys, **options): > zone = keys[-1] > assert isinstance(zone, DNSName) > assert zone.is_absolute() > zone = zone.ToASCII() > > dn = super(dnszone, self).get_dn(zone, **options) > try: > self.backend.get_entry(dn, ['']) > except errors.NotFound: > zone = zone[:-1] > dn = super(dnszone, self).get_dn(zone, **options) > > return dn > > > 6) > > You can shorten dnszone.get_name_in_zone code to: > > def get_name_in_zone(self, zone, hostname): > assert isinstance(zone, DNSName) > assert zone.is_absolute() > assert isinstance(hostname, DNSName) > if not hostname.is_absolute(): > return hostname > if hostname.is_subdomain(zone): > return hostname.relativize(zone) > > > 7) > > Conversions from string to DNSName in interactive_prompt_callbacks may fail, > you should put them in try/except blocks: > > + zone = DNSName(kw['idnsname']).make_absolute() > + ns = DNSName(kw['idnssoamname']) > > > 8) > > idnssoamname from LDAP is converted to DNSName in patch 36, no need to do it > again here: > > + nameserver = DNSName(entry_attrs['idnssoamname'][0]) > + if nameserver.is_absolute(): > > > 9) > > This should be handled in the realmdomains plugin, by raising a ValidationError: > > + and not zone.is_idn()): #Realmdomain doesnt support IDN > > > 10) > > This should be indented better: > > + if (zone != DNSName(api.env.domain).make_absolute() and > + not zone.is_idn() and #Realmdomain doesnt support IDN > + not zone.is_reverse()): > > > 11) > > Searching should work for any input, but you make a lot of assumptions in the > IDN search code which may not be true. I think you should not use DNSName in > this code, as it does too much validation. Use something like this instead: > > term = args[-1] > if term: > term = re.split(r'(? term = u'.'.join(convert_to_punycode(x) for x in term) > if term != args[-1]: > filter = modify_filter_idn(filter, term) > > Also make sure you convert other params to punycode as well, so searches like > this work: > > $ ipa dnszone-find --name= > > This applies to both dnszone_find and dnsrecord_find. > > > 12) > > Make sure to store only lists in LDAP entries: > > + entry_attrs['idnsname'] = keys[-1].relativize(keys[-2]) > > > 13) > > You don't have to move the "zone = keys[-2]" line here, just delete the > normalize_zone line: > > - zone = keys[-2] > if self.is_pkey_zone_record(*keys): > - addr = u'' > + addr = _dns_zone_record > else: > addr = keys[-1] > > - zone = normalize_zone(zone) > + zone = keys[-2] > > > 14) > > You can shorten this: > > + addr_len = len(addr.labels) if addr != _dns_zone_record else 0 > > to: > > addr_len = len(addr.labels) > > > 15) > > Instead of comparing values to _dns_zone_record: > > + if idnsname == _dns_zone_record or idnsname == zonename: > > + if DNSName(kw['idnsname']) == _dns_zone_record: > > I think it would be better to add .is_empty() to DNSName and use it. > > > 16) > > dnsrecord.is_pkey_zone_record seems related to dnszone.get_name_in_zone, maybe > you can move the common parts to a single place and use it like this: > > def is_pkey_zone_record(self, *keys): > name = get_name_in_zone(keys[-2], keys[-1]) > if name is None: > return False > return name.is_empty() > > > 17) > > Split this into multiple lines please: > > + keys = keys[:-1] + (keys[-1].relativize(keys[-2]).ToASCII(),) #Make > RR name relative if possible > > > 18) > > Please keep line length under 80 characters. > > > Patch 47: > > The patch does not compile: > > Traceback (most recent call last): > File "./makeapi", line 457, in > sys.exit(main()) > File "./makeapi", line 428, in main > api.finalize() > File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugable.py", line 705, in > finalize > self.__do_if_not_done('load_plugins') > File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugable.py", line 481, in > __do_if_not_done > getattr(self, name)() > File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugable.py", line 642, in > load_plugins > self.import_plugins('ipalib') > File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugable.py", line 686, in > import_plugins > __import__(fullname) > File "/tmp/freeipa-build.m5sbYb5j0d/build/ipalib/plugins/host.py", line 35, > in > from ipalib.plugins.dns import (dns_container_exists, _record_types, > ImportError: cannot import name _hostname_validator > > > Option in dnsrecord_add doesn't match. Got DNSNameParam('ptr_part_hostname', > attribute=False, cli_name='ptr_hostname', multivalue=False, option_group=u'PTR > Record', required=False) Expected DNSNameParam('ptr_part_hostname', > attribute=False, cli_name='ptr_hostname', multivalue=False, > only_absolute=True, option_group=u'PTR Record', required=False) > Option in dnsrecord_mod doesn't match. Got DNSNameParam('ptr_part_hostname', > attribute=False, autofill=False, cli_name='ptr_hostname', multivalue=False, > option_group=u'PTR Record', required=False) Expected > DNSNameParam('ptr_part_hostname', attribute=False, autofill=False, > cli_name='ptr_hostname', multivalue=False, only_absolute=True, > option_group=u'PTR Record', required=False) > > > I had some test failures, don't know which patch is to blame: > > ====================================================================== > ERROR: test_dns[88]: dnszone_add: Create reverse zone u'70.16.172.in-addr.arpa.' > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 301, in > func = lambda: self.check(nice, **test) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 319, in check > self.check_output(nice, cmd, args, options, expected, extra_check) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 358, in check_output > got = api.Command[cmd](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in > forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward > return self._call_command(command, params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in > _call_command > return command(*params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call > return self.__request(name, args) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request > raise error_class(message=error['message']) > NotFound: Nameserver 'ns1.zone3.test.' does not have a corresponding A/AAAA > record > > ====================================================================== > ERROR: test_dns[90]: dnsrecord_add: Add NS record to u'128/25' in revzone > u'70.16.172.in-addr.arpa.' > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 301, in > func = lambda: self.check(nice, **test) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 319, in check > self.check_output(nice, cmd, args, options, expected, extra_check) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 358, in check_output > got = api.Command[cmd](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in > forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward > return self._call_command(command, params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in > _call_command > return command(*params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call > return self.__request(name, args) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request > raise error_class(message=error['message']) > NotFound: 70.16.172.in-addr.arpa.: DNS zone not found > > ====================================================================== > ERROR: test_dns[91]: dnsrecord_add: Add CNAME record to u'129' in revzone > u'70.16.172.in-addr.arpa.' > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 301, in > func = lambda: self.check(nice, **test) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 319, in check > self.check_output(nice, cmd, args, options, expected, extra_check) > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line > 358, in check_output > got = api.Command[cmd](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in > forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward > return self._call_command(command, params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in > _call_command > return command(*params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call > return self.__request(name, args) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request > raise error_class(message=error['message']) > NotFound: 70.16.172.in-addr.arpa.: DNS zone not found > > > Honza BTW git diff -U0 | pep8 --diff should reveal most of style problems. -- Petr^2 Spacek From tbabej at redhat.com Tue Apr 22 10:50:27 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Apr 2014 12:50:27 +0200 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements In-Reply-To: <20140417124912.GW20958@redhat.com> References: <534FC81F.60507@redhat.com> <20140417124912.GW20958@redhat.com> Message-ID: <53564973.4040908@redhat.com> On 04/17/2014 02:44 PM, Alexander Bokovoy wrote: > You replace this by > range->base_rid_set = (slapi_entry_attr_find(entry, IPA_BASE_RID, &attr) == -1); You probably meant "== 0". Fixed. > I know that is was in your original code, but can we get numbers > replaced by an enum? I'd prefer to see symbolic names used instead of > numbers. Fixed in a separate patch 0178 (attached). > Please expand the message here, may be something like > LOG("Empty forest root map as trusts are not enabled on this IPA server\n"); Fixed. Updated patchset attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0178-2-ipatests-Change-range_check-return-values-from-int-t.patch Type: text/x-patch Size: 6276 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0176-2-ipa_range_check-Fix-typo-when-comparing-strings-usin.patch Type: text/x-patch Size: 1714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0175-2-ipa_range_check-Do-not-fail-when-no-trusted-domain-i.patch Type: text/x-patch Size: 1933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0174-2-ipa_range_check-Make-a-new-copy-of-forest_root_id-at.patch Type: text/x-patch Size: 1379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0173-2-ipa_range_check-Connect-the-new-node-of-the-linked-l.patch Type: text/x-patch Size: 1057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0172-2-ipa_range_check-Use-special-attributes-to-determine-.patch Type: text/x-patch Size: 4542 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 22 10:53:42 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Apr 2014 12:53:42 +0200 Subject: [Freeipa-devel] [PATCH 177] ipatests: Extend test suite for ID ranges Message-ID: <53564A36.40107@redhat.com> Hi, Add tests coverage for recently added ID range checks dependant on the ID range types. Part of: https://fedorahosted.org/freeipa/ticket/4137 -- 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-0177-ipatests-Extend-test-suite-for-ID-ranges.patch Type: text/x-patch Size: 21045 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 22 10:54:34 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Apr 2014 12:54:34 +0200 Subject: [Freeipa-devel] Ipatests fixes In-Reply-To: <53510923.5080103@redhat.com> References: <53451BE3.2070406@redhat.com> <53452FF5.1080601@redhat.com> <534FAB68.70401@redhat.com> <534FE5D6.2050909@redhat.com> <53510923.5080103@redhat.com> Message-ID: <53564A6A.5090707@redhat.com> On 04/18/2014 01:14 PM, Petr Viktorin wrote: > On 04/17/2014 04:31 PM, Petr Viktorin wrote: >> On 04/17/2014 12:22 PM, Tomas Babej wrote: >>> On 04/09/2014 01:33 PM, Petr Viktorin wrote: >>>> On 04/09/2014 12:07 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> the following batch deals with the following: >>>>> >>>>> * cleans up apache's semaphores prior to installing IPA (CA >>>>> install can >>>>> get stuck when IPA is reinstalled many times) >>>> >>>> What happens if Apache is running for some reason? Should we also stop >>>> it before deleting the semaphores? >>> >>> Agreed, if for any reason apache is running, we should stop it >>> beforehand. Fixed. >>> >>>> >>>>> * allows to pass extra arguments to install_client task >>>> >>>> Please avoid mutable argument defaults; use `extra_args=()` and then >>>> `list(extra_args)` >>> >>> Fixed. >>> >>>> >>>>> * uses trailing dot in the hostname as fqdn which should not be >>>>> overridden by domain name >>>> >>>> ACK. >>>> >>>>> * fixes incorrect assert for UIDs/GIDs in legacy client tests >>>> >>>> ACK, this fixes a lot of failures (though not all of them yet). >>>> >>> >>> Updated patches attached. >>> >> >> ACK, pushed to: >> master: f74ab3cba2b02e4726519e602f7de4fc86fca2d1 >> ipa-3-3: be8f4768877168720d051ba94c3e908af67f1306 > > There are some test failures in > ipatests/test_integration/test_testconfig.py that I missed. This patch > fixes them. Does it look good to you? > > Yes, thank you for the catch. ACK. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Tue Apr 22 10:56:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 22 Apr 2014 12:56:22 +0200 Subject: [Freeipa-devel] Ipatests fixes In-Reply-To: <53564A6A.5090707@redhat.com> References: <53451BE3.2070406@redhat.com> <53452FF5.1080601@redhat.com> <534FAB68.70401@redhat.com> <534FE5D6.2050909@redhat.com> <53510923.5080103@redhat.com> <53564A6A.5090707@redhat.com> Message-ID: <53564AD6.7020301@redhat.com> On 04/22/2014 12:54 PM, Tomas Babej wrote: > On 04/18/2014 01:14 PM, Petr Viktorin wrote: [...] >> There are some test failures in >> ipatests/test_integration/test_testconfig.py that I missed. This patch >> fixes them. Does it look good to you? >> >> > > Yes, thank you for the catch. ACK. Thanks, pushed to: master: d28d37ebdb7f454451975efbd55bceb6c3533430 ipa-3-3: 794d0030328b587a85276d872383bc0888549edb -- Petr? From pviktori at redhat.com Tue Apr 22 11:07:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 22 Apr 2014 13:07:02 +0200 Subject: [Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers In-Reply-To: <1397830635.2628.165.camel@willson.li.ssimo.org> References: <5351118B.7080108@redhat.com> <1397828586.2628.151.camel@willson.li.ssimo.org> <53512D59.2080604@redhat.com> <1397830028.2628.161.camel@willson.li.ssimo.org> <5351328D.6070406@redhat.com> <1397830635.2628.165.camel@willson.li.ssimo.org> Message-ID: <53564D56.6000608@redhat.com> On 04/18/2014 04:17 PM, Simo Sorce wrote: > On Fri, 2014-04-18 at 16:11 +0200, Martin Kosek wrote: >> On 04/18/2014 04:07 PM, Simo Sorce wrote: >>> On Fri, 2014-04-18 at 15:49 +0200, Martin Kosek wrote: >>>> On 04/18/2014 03:43 PM, Simo Sorce wrote: >>>>> On Fri, 2014-04-18 at 13:50 +0200, Petr Viktorin wrote: >>>>>> This extends the "Anonymous read access to containers" ACI to cover >>>>>> cn=etc, as discussed in [0]. >>>>>> >>>>>> A new objectClass is added so we can exclude virtual ops with >>>>>> targetfilter: ipaVirtualOperation (2.16.840.1.113730.3.8.12.23). >>>>>> >>>>>> >>>>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html >>>>>> >>>>> >>>>> LGTM >>>>> >>>> >>>> It works perfectly except one subtree we missed during initial review and which >>>> we should discuss: >>>> >>>> cn=replicas,cn=ipa,cn=etc,SUFFIX >>>> >>>> It contains list of replicas (not FreeIPA masters) connected to FreeIPA. >>>> Currently, this only affects Winsync replicas. >>>> >>>> I just verified that anonymous user can retrieve list of connected ADs via >>>> winsync. Question is, how to prevent it given that this is created dynamically >>>> also by older FreeIPA server and given that it has no special objectsclass to >>>> base a filtration on. >>>> >>>> Maybe we would need to add a deny ACI in this case after all? >>> >>> Or we can add an objectclass here too, the update script will then need >>> to look at existing objects dynamically and update them. >> >> This would not work well as older FreeIPA servers would not use this >> objectclass when "ipa-replica-manage connect --winsync" is run on them. > > I know, although you are probably not supposed to keep creating these > kind of agreements until you finish upgrading all the server, we always > advice people to upgrade the infra in a matter of weeks. > >>> However we could also ass a deny aci only in this subtree for now and >>> change it later, if we think that's too much work. >>> >>> We have plans to revisit shared replica information storage anyway, so >>> perhaps it is not worth spending too much time on this now. >>> >>> Simo. >> >> deny ACI is preventing access to nsContainer to anonymous users in >> cn=replica... is probably it is our best shot ATM unless we find a better solution. > > Agree. > > simo. Updated patch attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0532.2-Add-a-new-ipaVirtualOperation-objectClass-to-virtual.patch Type: text/x-patch Size: 7353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0533.2-Extend-anonymous-read-ACI-for-containers.patch Type: text/x-patch Size: 1794 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 22 11:32:21 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Apr 2014 13:32:21 +0200 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <531713BF.7010804@redhat.com> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> Message-ID: <53565345.2080407@redhat.com> On 03/05/2014 01:08 PM, Jan Cholasta wrote: > On 25.2.2014 11:15, Tomas Babej wrote: >> >> On 01/14/2014 10:19 AM, Petr Viktorin wrote: >>> On 01/14/2014 09:27 AM, Jan Cholasta wrote: >>>> On 13.1.2014 14:57, Petr Vobornik wrote: >>>>> On 13.1.2014 13:41, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 10.1.2014 21:21, Nathaniel McCallum wrote: >>>>>>> On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Adds a parameter that represents a DateTime format using >>>>>>>> datetime.datetime >>>>>>>> object from python's native datetime library. >>>>>>>> >>>>>>>> In the CLI, accepts one of the following formats: >>>>>>>> Accepts subset of values defined by ISO 8601: >>>>>>>> %Y-%m-%dT%H:%M:%S >>>>>>>> %Y-%m-%dT%H:%M >>>>>>>> '%Y%m%dT%H:%M:%S' >>>>>>>> '%Y%m%dT%H:%M' >>>>>>>> >>>>>>>> Also accepts LDAP Generalized time in the following format: >>>>>>>> '%Y%m%d%H%M%SZ' >>>>>>>> >>>>>>>> As a simplification, it does not deal with timezone info and ISO >>>>>>>> 8601 >>>>>>>> values with timezone info (+-hhmm) are rejected. Values are >>>>>>>> expected >>>>>>>> to be in the UTC timezone. >>>>>>>> >>>>>>>> Values are saved to LDAP as LDAP Generalized time values in the >>>>>>>> format >>>>>>>> '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To >>>>>>>> avoid >>>>>>>> confusion, in addition to subset of ISO 8601 values, the LDAP >>>>>>>> generalized >>>>>>>> time in the format '%Y%m%d%H%M%SZ' is also accepted as an input >>>>>>>> (as >>>>>>>> this >>>>>>>> is the >>>>>>>> format user will see on the output). >>>>>>>> >>>>>>>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >>>>>>> >>>>>>> The date/time syntax formats are not compliant with ISO 8601. You >>>>>>> stated >>>>>>> they are expected to be in UTC timezone, but no 'Z' is expected in >>>>>>> most >>>>>>> of them. This is not only non-standard, but would prevent you from >>>>>>> every >>>>>>> supporting local time in the future. >>>>>> >>>>>> +1, please require the trailing "Z". >>>>>> >>>>>> >>>>>> I think generalized time format should be the preferred one, as >>>>>> it is >>>>>> stored in LDAP and thus returned by commands. Also, do we really >>>>>> need >>>>>> all of these other formats? >>>>> >>>>> +1 That API should accept and always return generalized time. >>>>> >>>>> But UIs(CLI, Web) should display something more human readable. Like: >>>>> %Y-%m-%dT%H:%M:%SZ or IMHO better (but not ISO 8601): %Y-%m-%d >>>>> %H:%M:%SZ >>>>> ie. 2014-03-08 14:16:55Z compared to 2014-03-08T14:16:55Z or >>>>> 20140308141655Z >>>>> >>>>> Both should accept input value in the same format. Usage of different >>>>> output and input formats is confusing. Thus I agree with supporting >>>>> more >>>>> input formats. Decision whether it should be done on API level or >>>>> client >>>>> level is another matter. >>>> >>>> If you want human readable output, you have to do the conversion from >>>> generalized time on clients. If you want to support local time and >>>> timezones, you have to do some processing on the client as well. I >>>> would >>>> be perfectly happy if we supported only generalized time over the wire >>>> and did conversion from/to human readable on clients. >>>> >>>>> >>>>> I has been implementing the Web UI part and I think we should also >>>>> support a formats without time component. My initial impl. supports >>>>> combinations of: >>>>> >>>>> var dates = [ >>>>> ['YYYY-MM-DD', /^(\d{4})-(\d{2})-(\d{2})$/], >>>>> ['YYYYMMDD',/^(\d{4})(\d{2})(\d{2})$/] >>>>> ]; >>>>> >>>>> var times = [ >>>>> ['HH:mm:ss', /^(\d\d):(\d\d):(\d\d)Z$/], >>>>> ['HH:mm', /^(\d\d):(\d\d)Z$/], >>>>> ['HH', /^(\d\d)Z$/] >>>>> ]; >>>>> + generalized time >>>>> ['YYYYMMDDHHmmssZ',/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})Z$/] >>>>> >>>>> with /( |T)/ as divider and time optional. >>>>> >>>>> Both UIs should also tell the user what is the expected format (at >>>>> least >>>>> one of them). Getting incorrect format error without knowing it is >>>>> annoying. >>>> >>>> The current code raises a ValidationError including the list of >>>> formats. >>> >>> On yesterday's meeting, Simo said that on the wire and for CLI output, >>> we should use generalized time. >>> I disagree with using it for CLI ouptut, as I find generalized time >>> unreadable, but for the API it's the obvious choice. >>> >>> I believe we should require the "Z" postfix in all formats, so that 1) >>> users are forced to be aware that it's UTC, and 2) we can >>> theoretically support local time in the future. >>> >>> I think the supported input formats should be: >>> >>> %Y%m%d%H%M%SZ (generalized time) >>> %Y-%m-%dT%H:%M:%SZ (ISO 8601, with seconds) >>> %Y-%m-%dT%H:%MZ (ISO 8601, without seconds) >>> %Y-%m-%dZ (ISO 8601, date only) >>> >>> I also think we should accept a space instead of the "T", as Petr? >>> said above. >>> >> >> Thanks for review, everybody. >> >> * All accepted formats now require explicit Z >> * Accept values with ' ' instead of T >> * LDAP generalized time used on the wire with JSON >> * Minor implementation fixes >> >> Updated patch should address all the issues. > > The first if statement is not necessary here, datetime values are > correctly handled in the super class: > > + def _convert_scalar(self, value, index=None): > + if isinstance(value, datetime.datetime): > + return value > + elif isinstance(value, basestring): > > > Please use ', ' instead of just ',' as the separator to make the error > message more readable here: > > + error = (_("does not match any of accepted formats: ") + > + (','.join(self.accepted_formats))) > > > This if statement is not present on old clients, so the assert below > will fail on them when they receive DateTime: > > + if isinstance(value, DateTime): > + return datetime.datetime.strptime(str(value), "%Y%m%dT%H:%M:%S") > assert type(value) in (unicode, int, float, bool, NoneType) > > But, they will never receive DateTime from us, because LDAP > generalized time is decoded to unicode in ipaldap. > > What I think we should do is decode LDAP generalized time to datetime > objects in ipaldap, add a new capability (e.g. "datetime_values") and > use DateTime only for clients with that capability, otherwise use the > generalized time string. Also, something similar should be done for > JSON, so that clients can infer that a value is datetime and not just > a generic string (e.g. wrap it in a dict with '__datetime__', similar > to how binary values are wrapped with '__base64__'), again only for > clients with the capability. > Thank you for the suggestions. Updated, rebased patch is attached. -- 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-0137-5-ipalib-Add-DateTime-parameter.patch Type: text/x-patch Size: 10643 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 22 11:34:27 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Apr 2014 13:34:27 +0200 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <53171423.8030204@redhat.com> References: <52CEC0C9.70905@redhat.com> <530C478E.4080307@redhat.com> <53171423.8030204@redhat.com> Message-ID: <535653C3.7040406@redhat.com> On 03/05/2014 01:10 PM, Jan Cholasta wrote: > On 25.2.2014 08:34, Tomas Babej wrote: >> Rebased to current master. >> >> On 01/09/2014 04:31 PM, Tomas Babej wrote: >>> Hi, >>> >>> Adds a krbPrincipalExpiration attribute to the user class >>> in user.py ipalib plugin as a DateTime parameter. >>> >>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >>> > > The patch needs to be rebased again. > > I think you can drop the "(UTC)" here, as only values ending with "Z" > are now accepted for DateTime: > > + label=_('Kerberos principal expiration (UTC)'), > Updated, rebased patch attached. -- 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-0138-5-ipalib-Expose-krbPrincipalExpiration-in-CLI.patch Type: text/x-patch Size: 7545 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 22 11:38:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 22 Apr 2014 13:38:44 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <1397663792.19767.401.camel@willson.li.ssimo.org> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> <20140416153414.GP20958@redhat.com> <1397663792.19767.401.camel@willson.li.ssimo.org> Message-ID: <535654C4.5060303@redhat.com> On 04/16/2014 05:56 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: >> On Wed, 16 Apr 2014, Martin Kosek wrote: >>>>>>>>>>> In general I am not sure all authenticated users need access to all this >>>>>>>>>>> info. Alexander ? >>>>>>>>>> SSSD needs to read some of this information for subdomains support. >>>>>>>>>> That would be at least host/*@REALM who needs to access it. >>>>>>>>> >>>>>>>>> Can you please list exactly which ones are needed ? >>>>>>>> SSSD subdomains support needs: >>>>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>>>>> - ipaNTFlatName >>>>>>>> - ipaNTSecurityIdentifier >>>>>>>> - ipaNTTrustedDomainSID >>>>>>>> - cn >>>>>>> >>>>>>> Question is - is there any added value in hiding part of the >>>>>>> trust information from authenticated users? I.e. attributes like >>>>>>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>>>>>> attribute anyway?), SID blacklists... >>>>>> Yes. Some of those attributes are needed as internal detail of ipasam -- >>>>>> part of how Samba stores this information taken from specific DCE RPC >>>>>> structures. >>>>>> >>>>>>> If yes, we would need to split this permission in 2 and have one for >>>>>>> authenticated users and one for "Trust Adminitrators" and "Trust Readers". >>>>>> Yes. Authenticated users shouldn't get any access to those details: >>>>>> ipantsupportedencryptiontypes >>>>>> ipanttrustattributes >>>>>> ipanttrustauthincoming >>>>>> ipanttrustauthoutgoing >>>>>> >>>>>> >>>>> >>>>> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group should >>>>> then have this permission assigned so that samba can operate the attributes. >>>> 'adtrust agents' and 'trust administrators' should have read, modify, >>>> delete, and search on cn=trusts. >>>> >>> >>> Right. We will probably want to turn most of ACIs in >>> install/updates/60-trusts.update in managed permissions (i.e. defined in >>> trust.py) and make "adtrust agents" and "trust admins" it's members. >> I agree. >> > > +1 > > Simo. > All right. Now I'm replacing the global anonymous read ACI; converting the others will come later. The existing agents/admins ACIs grant the 'read' (or 'all') right already. ipaIDRange is covered in the range plugin, so what's left for this patch is the ipaNTTrustedDomain/ipaNTDomainAttrs attributes. Does that sound reasonable? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0529.2-Add-managed-read-permissions-to-trust.patch Type: text/x-patch Size: 1617 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 22 11:41:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 22 Apr 2014 13:41:47 +0200 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <53512B6B.5040908@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> <20140417201204.GY20958@redhat.com> <535112CE.5080009@redhat.com> <53512B6B.5040908@redhat.com> Message-ID: <5356557B.7040806@redhat.com> On 04/18/2014 03:40 PM, Martin Kosek wrote: > On 04/18/2014 01:55 PM, Petr Viktorin wrote: >> On 04/17/2014 10:12 PM, Alexander Bokovoy wrote: >>> On Thu, 17 Apr 2014, Simo Sorce wrote: >>>> On Thu, 2014-04-17 at 20:30 +0200, Martin Kosek wrote: >>>>> On 04/17/2014 07:11 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> While working on the trust permissions I found a typo in the >>>>>> 'ipanttrustauthoutgoing' attribute in default_attributes. Here is a >>>>> fix. >>>>>> >>>>> >>>>> I think the right question to ask - do we want to have >>>>> ipanttrustauth{incoming,outgoing} in default attributes? >>>>> >>>>> I do not think so. It is supposed to hold a secret for the trust, I >>>>> do not >>>>> think you want it displayed on your terminal by default - even if you >>>>> have a >>>>> right to display it. >>>> >>>> Yep, should not be returned by default to any command line utility. >>> Agreed. I wanted to remove it too the other day but forgot to file a >>> ticket. >>> >> >> I see. >> Here is a patch to remove them. >> > > Why did you remove SID blacklists from search_display_attributes? Is this what > we want? Oops, a mistake on my part. > It changes trust-find behavior from: > > # ipa trust-find > --------------- > 1 trust matched > --------------- > Realm name: tbad.example.com > Domain NetBIOS name: TBAD > Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 > SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, > S-1-5-6, S-1-5-5, S-1-5-4, > S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, > S-1-5-14, S-1-5-13, S-1-5-12, > S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, > S-1-5-19, S-1-5-18 > SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, > S-1-5-6, S-1-5-5, S-1-5-4, > S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, > S-1-5-14, S-1-5-13, S-1-5-12, > S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, > S-1-5-19, S-1-5-18 > Trust type: Active Directory domain > ---------------------------- > Number of entries returned 1 > ---------------------------- > > to > > # ipa trust-find > --------------- > 1 trust matched > --------------- > Realm name: tbad.example.com > Domain NetBIOS name: TBAD > Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 > Trust type: Active Directory domain > ---------------------------- > Number of entries returned 1 > ---------------------------- > > I am not saying it is necessarily a bad thing to do. It IMO actually makes find > output consistent with trust-show and better to read. > > I would personally remove search_display_attributes all together since we are > poking in this part and let trust return default attributes in the trust-find > command. > > Martin Alexander, would you be okay with that? -- Petr? From mkosek at redhat.com Wed Apr 23 10:17:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 12:17:28 +0200 Subject: [Freeipa-devel] [PATCH 177] ipatests: Extend test suite for ID ranges In-Reply-To: <53564A36.40107@redhat.com> References: <53564A36.40107@redhat.com> Message-ID: <53579338.2010303@redhat.com> On 04/22/2014 12:53 PM, Tomas Babej wrote: > Hi, > > Add tests coverage for recently added ID range checks dependant > on the ID range types. > > Part of: https://fedorahosted.org/freeipa/ticket/4137 > > > NACK: ====================================================================== FAIL: test_range[21]: idrange_del: Delete non-active AD trusted range u'domain1range1' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in check_output assert_deepequal(expected, got, nice) File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/root/freeipa-master/ipatests/util.py", line 316, in assert_deepequal TYPE % (doc, type(expected), type(got), expected, got, stack) AssertionError: assert_deepequal: type(expected) is not type(got). test_range[21]: idrange_del: Delete non-active AD trusted range u'domain1range1' type(expected) = type(got) = expected = u'' got = [] path = ('result', 'failed') From tbabej at redhat.com Wed Apr 23 10:47:12 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 23 Apr 2014 12:47:12 +0200 Subject: [Freeipa-devel] [PATCH 177] ipatests: Extend test suite for ID ranges In-Reply-To: <53579338.2010303@redhat.com> References: <53564A36.40107@redhat.com> <53579338.2010303@redhat.com> Message-ID: <53579A30.1050405@redhat.com> On 04/23/2014 12:17 PM, Martin Kosek wrote: > On 04/22/2014 12:53 PM, Tomas Babej wrote: >> Hi, >> >> Add tests coverage for recently added ID range checks dependant >> on the ID range types. >> >> Part of: https://fedorahosted.org/freeipa/ticket/4137 >> >> >> > NACK: > > ====================================================================== > FAIL: test_range[21]: idrange_del: Delete non-active AD trusted range > u'domain1range1' > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in > > func = lambda: self.check(nice, **test) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in > check > self.check_output(nice, cmd, args, options, expected, extra_check) > File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in > check_output > assert_deepequal(expected, got, nice) > File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal > assert_deepequal(e_sub, g_sub, doc, stack + (key,)) > File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal > assert_deepequal(e_sub, g_sub, doc, stack + (key,)) > File "/root/freeipa-master/ipatests/util.py", line 316, in assert_deepequal > TYPE % (doc, type(expected), type(got), expected, got, stack) > AssertionError: assert_deepequal: type(expected) is not type(got). > test_range[21]: idrange_del: Delete non-active AD trusted range u'domain1range1' > type(expected) = > type(got) = > expected = u'' > got = [] > path = ('result', 'failed') > Yes, this is a rebase problem I noticed already. Patch fixing the issue attached. -- 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-0177-2-ipatests-Extend-test-suite-for-ID-ranges.patch Type: text/x-patch Size: 21005 bytes Desc: not available URL: From tbabej at redhat.com Wed Apr 23 10:50:18 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 23 Apr 2014 12:50:18 +0200 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements In-Reply-To: <53564973.4040908@redhat.com> References: <534FC81F.60507@redhat.com> <20140417124912.GW20958@redhat.com> <53564973.4040908@redhat.com> Message-ID: <53579AEA.2020607@redhat.com> On 04/22/2014 12:50 PM, Tomas Babej wrote: > On 04/17/2014 02:44 PM, Alexander Bokovoy wrote: >> You replace this by >> range->base_rid_set = (slapi_entry_attr_find(entry, IPA_BASE_RID, > &attr) == -1); > > You probably meant "== 0". Fixed. > >> I know that is was in your original code, but can we get numbers >> replaced by an enum? I'd prefer to see symbolic names used instead of >> numbers. > Fixed in a separate patch 0178 (attached). > >> Please expand the message here, may be something like >> LOG("Empty forest root map as trusts are not enabled on this IPA > server\n"); > > Fixed. > > Updated patchset attached. > > Tomas I amended the commit message in the patch 178, whole patchset attached. -- 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-0176-2-ipa_range_check-Fix-typo-when-comparing-strings-usin.patch Type: text/x-patch Size: 1714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0175-2-ipa_range_check-Do-not-fail-when-no-trusted-domain-i.patch Type: text/x-patch Size: 1933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0174-2-ipa_range_check-Make-a-new-copy-of-forest_root_id-at.patch Type: text/x-patch Size: 1379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0173-2-ipa_range_check-Connect-the-new-node-of-the-linked-l.patch Type: text/x-patch Size: 1057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0172-2-ipa_range_check-Use-special-attributes-to-determine-.patch Type: text/x-patch Size: 4542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0178-3-ipa_range_check-Change-range_check-return-values-fro.patch Type: text/x-patch Size: 6283 bytes Desc: not available URL: From pviktori at redhat.com Wed Apr 23 11:03:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Apr 2014 13:03:05 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <534BBE8A.6080101@redhat.com> References: <534BBE8A.6080101@redhat.com> Message-ID: <53579DE9.2000207@redhat.com> On 04/14/2014 12:55 PM, Martin Kosek wrote: [...] > dn: cn=masters,cn=ipa,cn=etc,SUFFIX > - ADD aci allowing reading hosts (to have it separate from global cn=etc one so > that we can once assign it only to ipamasters hostgroup for example) We don't have an ipamasters hostgroup. Should we? -- Petr? From mkosek at redhat.com Wed Apr 23 11:13:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 13:13:45 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <53579DE9.2000207@redhat.com> References: <534BBE8A.6080101@redhat.com> <53579DE9.2000207@redhat.com> Message-ID: <5357A069.5010700@redhat.com> On 04/23/2014 01:03 PM, Petr Viktorin wrote: > On 04/14/2014 12:55 PM, Martin Kosek wrote: > [...] >> dn: cn=masters,cn=ipa,cn=etc,SUFFIX >> - ADD aci allowing reading hosts (to have it separate from global cn=etc one so >> that we can once assign it only to ipamasters hostgroup for example) > > We don't have an ipamasters hostgroup. Should we? We do not have it currently, but AFAIK Honza planned (or even had patches?) to add it in his CA management utility effort. Honza, is that correct? Until this hostgroup is ready (and managed), I think we can have an ACI to allow read access to all authenticated users. OR, we may chose not have an ACI at all given that utilities (ipactl, ipa-replica-manage, ipa-replica-install) operating with cn=masters bind as DM (either via password or with External bind) and i.e. should not need the ACI. Martin From mkosek at redhat.com Wed Apr 23 11:24:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 13:24:56 +0200 Subject: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements In-Reply-To: <53579AEA.2020607@redhat.com> References: <534FC81F.60507@redhat.com> <20140417124912.GW20958@redhat.com> <53564973.4040908@redhat.com> <53579AEA.2020607@redhat.com> Message-ID: <5357A308.7070808@redhat.com> On 04/23/2014 12:50 PM, Tomas Babej wrote: > > On 04/22/2014 12:50 PM, Tomas Babej wrote: >> On 04/17/2014 02:44 PM, Alexander Bokovoy wrote: >>> You replace this by >>> range->base_rid_set = (slapi_entry_attr_find(entry, IPA_BASE_RID, >> &attr) == -1); >> >> You probably meant "== 0". Fixed. >> >>> I know that is was in your original code, but can we get numbers >>> replaced by an enum? I'd prefer to see symbolic names used instead of >>> numbers. >> Fixed in a separate patch 0178 (attached). >> >>> Please expand the message here, may be something like >>> LOG("Empty forest root map as trusts are not enabled on this IPA >> server\n"); >> >> Fixed. >> >> Updated patchset attached. >> >> Tomas > > I amended the commit message in the patch 178, whole patchset attached. I verified and tested that you addressed all Alexander's findings, it's ok - pushed 172-176 to master. I reviewed 178-2 and it is OK, it indeed improves readibility. ACK and pushed to master. Martin From mkosek at redhat.com Wed Apr 23 11:25:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 13:25:37 +0200 Subject: [Freeipa-devel] [PATCH 177] ipatests: Extend test suite for ID ranges In-Reply-To: <53579A30.1050405@redhat.com> References: <53564A36.40107@redhat.com> <53579338.2010303@redhat.com> <53579A30.1050405@redhat.com> Message-ID: <5357A331.8070401@redhat.com> On 04/23/2014 12:47 PM, Tomas Babej wrote: > On 04/23/2014 12:17 PM, Martin Kosek wrote: >> On 04/22/2014 12:53 PM, Tomas Babej wrote: >>> Hi, >>> >>> Add tests coverage for recently added ID range checks dependant >>> on the ID range types. >>> >>> Part of: https://fedorahosted.org/freeipa/ticket/4137 >>> >>> >>> >> NACK: >> >> ====================================================================== >> FAIL: test_range[21]: idrange_del: Delete non-active AD trusted range >> u'domain1range1' >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest >> self.test(*self.arg) >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in >> >> func = lambda: self.check(nice, **test) >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in >> check >> self.check_output(nice, cmd, args, options, expected, extra_check) >> File "/root/freeipa-master/ipatests/test_xmlrpc/xmlrpc_test.py", line 359, in >> check_output >> assert_deepequal(expected, got, nice) >> File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal >> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >> File "/root/freeipa-master/ipatests/util.py", line 344, in assert_deepequal >> assert_deepequal(e_sub, g_sub, doc, stack + (key,)) >> File "/root/freeipa-master/ipatests/util.py", line 316, in assert_deepequal >> TYPE % (doc, type(expected), type(got), expected, got, stack) >> AssertionError: assert_deepequal: type(expected) is not type(got). >> test_range[21]: idrange_del: Delete non-active AD trusted range u'domain1range1' >> type(expected) = >> type(got) = >> expected = u'' >> got = [] >> path = ('result', 'failed') >> > > Yes, this is a rebase problem I noticed already. Patch fixing the issue > attached. Thanks, this version worked fine in my tests. ACK, pushed to master. Martin From jcholast at redhat.com Wed Apr 23 11:42:52 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 23 Apr 2014 13:42:52 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <5357A069.5010700@redhat.com> References: <534BBE8A.6080101@redhat.com> <53579DE9.2000207@redhat.com> <5357A069.5010700@redhat.com> Message-ID: <5357A73C.8000609@redhat.com> On 23.4.2014 13:13, Martin Kosek wrote: > On 04/23/2014 01:03 PM, Petr Viktorin wrote: >> On 04/14/2014 12:55 PM, Martin Kosek wrote: >> [...] >>> dn: cn=masters,cn=ipa,cn=etc,SUFFIX >>> - ADD aci allowing reading hosts (to have it separate from global cn=etc one so >>> that we can once assign it only to ipamasters hostgroup for example) >> >> We don't have an ipamasters hostgroup. Should we? > > We do not have it currently, but AFAIK Honza planned (or even had patches?) to > add it in his CA management utility effort. Honza, is that correct? It would certainly make things prettier. I don't have any patches, but there is a ticket for that: . > > Until this hostgroup is ready (and managed), I think we can have an ACI to > allow read access to all authenticated users. > > OR, we may chose not have an ACI at all given that utilities (ipactl, > ipa-replica-manage, ipa-replica-install) operating with cn=masters bind as DM > (either via password or with External bind) and i.e. should not need the ACI. Renewal scripts need access to cn=masters and bind as host. > > Martin > -- Jan Cholasta From pviktori at redhat.com Wed Apr 23 11:42:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Apr 2014 13:42:59 +0200 Subject: [Freeipa-devel] [PATCHES] 0534-0535 Add several managed read permissions under cn=etc Message-ID: <5357A743.7020309@redhat.com> This adds managed read permissions to cn=etc. Since these permissions are not bound to objects, the first patch adds support for those. They're defined in the update plugin. The second patch adds permissions for various subtrees/entries in cn=etc, according to the [discussion thread]. I wonder if we should limit the attributes in cn=replication; are all nsds5replica attrs needed? For cn=ad,cn=etc I put the permission in cn=etc and used a target, since cn=ad is not present by default. [discussion thread]: http://www.redhat.com/archives/freeipa-devel/2014-April/msg00250.html -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0534-Add-a-list-of-non-plugin-default-permissions.patch Type: text/x-patch Size: 2401 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0535-Add-several-managed-read-permissions-under-cn-etc.patch Type: text/x-patch Size: 5641 bytes Desc: not available URL: From amisnyov at redhat.com Wed Apr 23 11:46:08 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 23 Apr 2014 13:46:08 +0200 Subject: [Freeipa-devel] [PATCH][RFC] 13 - Log pretty-printed request and response In-Reply-To: <534EA4C8.4060308@redhat.com> References: <20140416150543.0434eb32@unused-4-246.brq.redhat.com> <534EA4C8.4060308@redhat.com> Message-ID: <20140423134608.541d5f03@unused-4-246.brq.redhat.com> On Wed, 16 Apr 2014 11:42:00 -0400 Rob Crittenden wrote: > Misnyovszki Adam wrote: > > Hi, > > this patch enables logging json dumps of request and response, using > > the --log-payload switch in ipa cli. RFC tag is to ensure that I > > handled the --log-payload switch correctly in ipa cli. Be careful, > > it only logs, so --log-payload without -v switch doesn't make the > > dump visible in command line, -v does! > > > > https://fedorahosted.org/freeipa/ticket/4233 > > Not a NACK but using -vvv makes this a much simpler operation as you > can then just compare verbose >= 3. This seems like a lot of work > just to pretty-print some output. > > rob > I've found out, that in RPCClient.create_connection, according to ipalib/backend.py:164, the variable verbose is not an int, rather a bool ( verbose=(self.env.verbose >= 2) ), so I decided not to break the workflow of this variable, but rather create a new one(log-payload). I was thinking, making verbose to an int would cause more work than to do it this way. Adam From pspacek at redhat.com Wed Apr 23 11:55:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Apr 2014 13:55:01 +0200 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <1398084480.2628.220.camel@willson.li.ssimo.org> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> <535054E6.4020904@redhat.com> <1397774273.2628.137.camel@willson.li.ssimo.org> <53551172.20608@redhat.com> <1398084480.2628.220.camel@willson.li.ssimo.org> Message-ID: <5357AA15.7040306@redhat.com> On 21.4.2014 14:48, Simo Sorce wrote: > On Mon, 2014-04-21 at 08:39 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: >>>>>> Simo Sorce wrote: >>>>>>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: >>>>>>>> I would like to discuss more on the managed read permissions upgrades [1]. >>>>>>>> Right now, we simply merge an old permission with the new one, making sure that >>>>>>>> we only add new attributes instead of just replacing them, to prevent a managed >>>>>>>> permission to be spoiled by a lower FreeIPA server version which runs an updates. >>>>>>>> >>>>>>>> I was thinking about it some more and seems to me we could run in problems when >>>>>>>> we for example find out that some permission is too relaxed and we want to >>>>>>>> remove some default attribute. Or when we want to update the permission filter. >>>>>>>> Or when object has anonymous and authenticated permission and we want to move >>>>>>>> attribute from anonymous to authenticated permission. >>>>>>>> >>>>>>>> Changes like this can happen, especially in the first release and we do not >>>>>>>> have means to address them. What about simply versioning the permissions as we >>>>>>>> do with our configs? I.e. >>>>>>>> >>>>>>>> 1) Introduce new MUST numeric attribute ipaPermVersion >>>>>>>> 2) Add 'version' field to managed permissions: >>>>>>>> >>>>>>>> managed_permissions = { >>>>>>>> 'System: Read Roles': { >>>>>>>> 'version': 1, >>>>>>>> 'replaces_global_anonymous_aci': True, >>>>>>>> 'ipapermbindruletype': 'permission', >>>>>>>> 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>> 'ipapermdefaultattr': { >>>>>>>> 'businesscategory', 'cn', 'description', 'member', 'memberof', >>>>>>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', >>>>>>>> }, >>>>>>>> 'default_privileges': {'RBAC Readers'}, >>>>>>>> }, >>>>>>>> } >>>>>>>> 3) Modify updater to only update the permission if it's version is higher than >>>>>>>> the one in LDAP. In that case, it should simply replace the managed permission >>>>>>>> attributes with the new one, no merging (except the attributes that we allow >>>>>>>> users to change). >>>>>>>> >>>>>>>> When we want to change the permission, we simply do the changes, bump the >>>>>>>> version and we are done and we do not need to fear some older FreeIPA will >>>>>>>> overwrite it. That of course assumes that the versioning would be available >>>>>>>> from FreeIPA 4.0. >>>>>>>> >>>>>>>> Makes sense? >>>>>>>> >>>>>>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>>> >>>>>>> >>>>>>> Uhmm, yes, and no, let me explain. >>>>>>> >>>>>>> What you say *does* make sense, but you are being too focused :-) >>>>>>> The upgrade issue is not limited to permissions, but affects everything. >>>>>>> >>>>>>> I think that what we need is to add a "ipa schema version" attribute >>>>>>> somewhere in cn=etc, and then always check this number in the updater >>>>>>> script. if this number is higher than what we know we immediately stop >>>>>>> and do not perform updates that affect anything but our own server data. >>>>>>> >>>>>>> This will protect the whole tree from unintentional changes caused by an >>>>>>> older replica. >>>>>>> >>>>>>> Makes sense ? >>>>>> >>>>>> This could lead to new features not working. Those features would rely >>>>>> on containers, ACIs, etc to exist but they wouldn't if the updates >>>>>> aren't run. >>>>> >>>>> Sorry I don't get this, if they are new features, then the version will >>>>> be "older" and the update *will* run and at the end raise the version. >>>>> >>>>> We just prevent old updates from running and current updates from >>>>> running multiple times, for the shared tree. >>>>> >>>>> Do we depend on having updates run multiple times for the data in the >>>>> shared tree ? >>>>> >>>>> Note that I am not saying that all updates should stop, any update for >>>>> cn=config would still need to be run on each server (although setting a >>>>> version there too would probably be beneficial). >>>> >>>> Ok, so the update runs, adds data, which gets replicated out to >>>> potentially old servers, and we're at the place you said we wouldn't be. >>> >>> I am not following you, the aim here is not to avoid replicating new >>> data to old server, the aim is that if you update the rpm of an older >>> replica and the rpm runs the ldap updater with the *old* code, we do not >>> end up with that updater *undoing* what a more recent update did. >>> >>>> Updates are all loaded and sorted so that all changes to a given DN >>>> should be applied at once, so it isn't like applying a old update and a >>>> new update are two separate operations. In fact, it would likely be a >>>> no-op in the case that they have already been applied. >>>> >>>> Do you have any examples to clarify your concerns? I'm not following you. >>> >>> Sure at some point version freeipa version 4.2 is released and it has an >>> update that changes a default object so that now attribute 'foo' is >>> added, this is done through the updater. >>> >>> Later on we release freeipa version 5.0 and we realize we will have >>> again to remove attribute 'foo' because we never really needed it, plus >>> if it is still there it causes issues to new feature XYZ. >>> >>> The admin installs 5.0 and all are happy, then a week later he runs a >>> simply yum update on th eolder replicas still running 4.2 and 4.2.1 is >>> available, and gets installed and ... bah the 4.2.1 updater re-adds >>> attribute 'foo' back ... and 5.0 servers are now broken. >>> >>> If we have an updater version field when the 4.2.1 update goes on it >>> will see that all updates that were necessary (and more) have already >>> been added and just quits. >> >> Ok, this won't happen in a modify case. When changing data we only >> change a known existing value, so exact match is required. >> >> The only risk is in adding and deleting data. >> >> So if we delete a permission named "Do cool stuff" in 5.0 and that was >> something previously added in 4.2 then yeah, re-running the 4.2 updates >> will re-apply the data. Similarly deletes would always be applied. >> >> I would not be keen on adding a global version value though, as we've >> had issues with updates in the past where re-running the updater would >> fix things. This would short circuit that. > > Well we could allow the updater to run on "same version" values, this > would preserve this ability while still blocking older updaters. > > Besides modifies can be affected too, say we have default value of 10, > we change it to 20 in 4.2 then change it back to 10 in 5.0 as we found > an issue with the new value. If you run 4.2 updater it puts it back to > 20. > > All cases of flipping values are also affected. > >> Something more fine-grained might work but carries its own problems. > > I think in this case we really want a domain level version, as the tree > is shared and we want updates to be consistent, so the update need to be > applied in full or not at all IMO. > > We do have some fine-grained approach as we will have a separate version > for he shared tree than the cn=config tree (and I guess another one for > the CA tree). > Each tree is a Silo, and should have its own tree version. IMHO more granular "versions" would be handy. Specifically for DNSSEC, we need to somehow distinguish old installation with centralized key management from new installation with distributed key management and different key storage etc. etc. Maybe we can invent some generic mechanism for "component versioning"? (Recall Dogtag 9 vs. 10 ...) -- Petr^2 Spacek From pviktori at redhat.com Wed Apr 23 12:14:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Apr 2014 14:14:27 +0200 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <5357AA15.7040306@redhat.com> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> <535054E6.4020904@redhat.com> <1397774273.2628.137.camel@willson.li.ssimo.org> <53551172.20608@redhat.com> <1398084480.2628.220.camel@willson.li.ssimo.org> <5357AA15.7040306@redhat.com> Message-ID: <5357AEA3.8010003@redhat.com> On 04/23/2014 01:55 PM, Petr Spacek wrote: > On 21.4.2014 14:48, Simo Sorce wrote: >> On Mon, 2014-04-21 at 08:39 -0400, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote: >>>>> Simo Sorce wrote: >>>>>> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: >>>>>>> Simo Sorce wrote: >>>>>>>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: >>>>>>>>> I would like to discuss more on the managed read permissions >>>>>>>>> upgrades [1]. >>>>>>>>> Right now, we simply merge an old permission with the new one, >>>>>>>>> making sure that >>>>>>>>> we only add new attributes instead of just replacing them, to >>>>>>>>> prevent a managed >>>>>>>>> permission to be spoiled by a lower FreeIPA server version >>>>>>>>> which runs an updates. >>>>>>>>> >>>>>>>>> I was thinking about it some more and seems to me we could run >>>>>>>>> in problems when >>>>>>>>> we for example find out that some permission is too relaxed and >>>>>>>>> we want to >>>>>>>>> remove some default attribute. Or when we want to update the >>>>>>>>> permission filter. >>>>>>>>> Or when object has anonymous and authenticated permission and >>>>>>>>> we want to move >>>>>>>>> attribute from anonymous to authenticated permission. >>>>>>>>> >>>>>>>>> Changes like this can happen, especially in the first release >>>>>>>>> and we do not >>>>>>>>> have means to address them. What about simply versioning the >>>>>>>>> permissions as we >>>>>>>>> do with our configs? I.e. >>>>>>>>> >>>>>>>>> 1) Introduce new MUST numeric attribute ipaPermVersion >>>>>>>>> 2) Add 'version' field to managed permissions: >>>>>>>>> >>>>>>>>> managed_permissions = { >>>>>>>>> 'System: Read Roles': { >>>>>>>>> 'version': 1, >>>>>>>>> 'replaces_global_anonymous_aci': True, >>>>>>>>> 'ipapermbindruletype': 'permission', >>>>>>>>> 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>> 'ipapermdefaultattr': { >>>>>>>>> 'businesscategory', 'cn', 'description', >>>>>>>>> 'member', 'memberof', >>>>>>>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', >>>>>>>>> }, >>>>>>>>> 'default_privileges': {'RBAC Readers'}, >>>>>>>>> }, >>>>>>>>> } >>>>>>>>> 3) Modify updater to only update the permission if it's version >>>>>>>>> is higher than >>>>>>>>> the one in LDAP. In that case, it should simply replace the >>>>>>>>> managed permission >>>>>>>>> attributes with the new one, no merging (except the attributes >>>>>>>>> that we allow >>>>>>>>> users to change). >>>>>>>>> >>>>>>>>> When we want to change the permission, we simply do the >>>>>>>>> changes, bump the >>>>>>>>> version and we are done and we do not need to fear some older >>>>>>>>> FreeIPA will >>>>>>>>> overwrite it. That of course assumes that the versioning would >>>>>>>>> be available >>>>>>>>> from FreeIPA 4.0. >>>>>>>>> >>>>>>>>> Makes sense? >>>>>>>>> >>>>>>>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>>>> >>>>>>>> >>>>>>>> Uhmm, yes, and no, let me explain. >>>>>>>> >>>>>>>> What you say *does* make sense, but you are being too focused :-) >>>>>>>> The upgrade issue is not limited to permissions, but affects >>>>>>>> everything. >>>>>>>> >>>>>>>> I think that what we need is to add a "ipa schema version" >>>>>>>> attribute >>>>>>>> somewhere in cn=etc, and then always check this number in the >>>>>>>> updater >>>>>>>> script. if this number is higher than what we know we >>>>>>>> immediately stop >>>>>>>> and do not perform updates that affect anything but our own >>>>>>>> server data. >>>>>>>> >>>>>>>> This will protect the whole tree from unintentional changes >>>>>>>> caused by an >>>>>>>> older replica. >>>>>>>> >>>>>>>> Makes sense ? >>>>>>> >>>>>>> This could lead to new features not working. Those features would >>>>>>> rely >>>>>>> on containers, ACIs, etc to exist but they wouldn't if the updates >>>>>>> aren't run. >>>>>> >>>>>> Sorry I don't get this, if they are new features, then the version >>>>>> will >>>>>> be "older" and the update *will* run and at the end raise the >>>>>> version. >>>>>> >>>>>> We just prevent old updates from running and current updates from >>>>>> running multiple times, for the shared tree. >>>>>> >>>>>> Do we depend on having updates run multiple times for the data in the >>>>>> shared tree ? >>>>>> >>>>>> Note that I am not saying that all updates should stop, any update >>>>>> for >>>>>> cn=config would still need to be run on each server (although >>>>>> setting a >>>>>> version there too would probably be beneficial). >>>>> >>>>> Ok, so the update runs, adds data, which gets replicated out to >>>>> potentially old servers, and we're at the place you said we >>>>> wouldn't be. >>>> >>>> I am not following you, the aim here is not to avoid replicating new >>>> data to old server, the aim is that if you update the rpm of an older >>>> replica and the rpm runs the ldap updater with the *old* code, we do >>>> not >>>> end up with that updater *undoing* what a more recent update did. >>>> >>>>> Updates are all loaded and sorted so that all changes to a given DN >>>>> should be applied at once, so it isn't like applying a old update >>>>> and a >>>>> new update are two separate operations. In fact, it would likely be a >>>>> no-op in the case that they have already been applied. >>>>> >>>>> Do you have any examples to clarify your concerns? I'm not >>>>> following you. >>>> >>>> Sure at some point version freeipa version 4.2 is released and it >>>> has an >>>> update that changes a default object so that now attribute 'foo' is >>>> added, this is done through the updater. >>>> >>>> Later on we release freeipa version 5.0 and we realize we will have >>>> again to remove attribute 'foo' because we never really needed it, plus >>>> if it is still there it causes issues to new feature XYZ. >>>> >>>> The admin installs 5.0 and all are happy, then a week later he runs a >>>> simply yum update on th eolder replicas still running 4.2 and 4.2.1 is >>>> available, and gets installed and ... bah the 4.2.1 updater re-adds >>>> attribute 'foo' back ... and 5.0 servers are now broken. >>>> >>>> If we have an updater version field when the 4.2.1 update goes on it >>>> will see that all updates that were necessary (and more) have already >>>> been added and just quits. >>> >>> Ok, this won't happen in a modify case. When changing data we only >>> change a known existing value, so exact match is required. >>> >>> The only risk is in adding and deleting data. >>> >>> So if we delete a permission named "Do cool stuff" in 5.0 and that was >>> something previously added in 4.2 then yeah, re-running the 4.2 updates >>> will re-apply the data. Similarly deletes would always be applied. >>> >>> I would not be keen on adding a global version value though, as we've >>> had issues with updates in the past where re-running the updater would >>> fix things. This would short circuit that. >> >> Well we could allow the updater to run on "same version" values, this >> would preserve this ability while still blocking older updaters. >> >> Besides modifies can be affected too, say we have default value of 10, >> we change it to 20 in 4.2 then change it back to 10 in 5.0 as we found >> an issue with the new value. If you run 4.2 updater it puts it back to >> 20. >> >> All cases of flipping values are also affected. >> >>> Something more fine-grained might work but carries its own problems. >> >> I think in this case we really want a domain level version, as the tree >> is shared and we want updates to be consistent, so the update need to be >> applied in full or not at all IMO. >> >> We do have some fine-grained approach as we will have a separate version >> for he shared tree than the cn=config tree (and I guess another one for >> the CA tree). >> Each tree is a Silo, and should have its own tree version. > > IMHO more granular "versions" would be handy. Specifically for DNSSEC, > we need to somehow distinguish old installation with centralized key > management from new installation with distributed key management and > different key storage etc. etc. > > Maybe we can invent some generic mechanism for "component versioning"? > (Recall Dogtag 9 vs. 10 ...) I don't like this idea. With very granular versioning we'd need to correctly identify which part each particular update belongs to and what happens when components of various versions are mixed. And we couldn't hope to test all the combinations. Making this into a generic mechanism now, with just a few very different current uses, sounds dangerously over-engineered. I'd like to see something very simple: only update if stored version <= current API version; store current API version at end of update. The bugs will be much easier to identify that way. Of course this supposes a monolithic IPA and e.g. isn't very friendly to external plugins, but I don't think we can design a good story for external plugins without actually writing some first. Let's do something simple and iterate later. -- Petr? From pviktori at redhat.com Wed Apr 23 12:22:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Apr 2014 14:22:15 +0200 Subject: [Freeipa-devel] [PATCH] 0520 Add managed read permission to service In-Reply-To: <534BC0CF.9090103@redhat.com> References: <534BC0CF.9090103@redhat.com> Message-ID: <5357B077.6070202@redhat.com> On 04/14/2014 01:04 PM, Petr Viktorin wrote: > Read access is given to all authenticated users. > > Exposed attributes are: > [top] > objectClass > [ipaObject] > ipaUniqueID > [ipaService] > managedBy > memberOf > ipaKrbAuthzData (a.k.a. pac_type) > [pkiUser] > userCertificate > [krbPrincipalAux] > krbPrincipalName > krbCanonicalName > krbPrincipalAliases > krbPrincipalExpiration > krbPasswordExpiration > krbLastPwdChange > [krbTicketPolicyAux] - none > [ipaKrbPrincipal] > krbPrincipalName > ipaKrbPrincipalAlias > [krbPrincipal] > krbPrincipalName > krbObjectReferences > > > Kerberos-related attributes were discussed for hosts here: > http://www.redhat.com/archives/freeipa-devel/2014-April/msg00242.html ping, any takers for the review? -- Petr? From ssorce at redhat.com Wed Apr 23 12:34:08 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 23 Apr 2014 08:34:08 -0400 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <53579DE9.2000207@redhat.com> References: <534BBE8A.6080101@redhat.com> <53579DE9.2000207@redhat.com> Message-ID: <1398256448.2628.329.camel@willson.li.ssimo.org> On Wed, 2014-04-23 at 13:03 +0200, Petr Viktorin wrote: > On 04/14/2014 12:55 PM, Martin Kosek wrote: > [...] > > dn: cn=masters,cn=ipa,cn=etc,SUFFIX > > - ADD aci allowing reading hosts (to have it separate from global cn=etc one so > > that we can once assign it only to ipamasters hostgroup for example) > > We don't have an ipamasters hostgroup. Should we? Yes, we proposed it a few times already. Simo. From pviktori at redhat.com Wed Apr 23 12:38:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Apr 2014 14:38:29 +0200 Subject: [Freeipa-devel] New ACIs for cn=etc In-Reply-To: <5357A73C.8000609@redhat.com> References: <534BBE8A.6080101@redhat.com> <53579DE9.2000207@redhat.com> <5357A069.5010700@redhat.com> <5357A73C.8000609@redhat.com> Message-ID: <5357B445.6050000@redhat.com> On 04/23/2014 01:42 PM, Jan Cholasta wrote: > On 23.4.2014 13:13, Martin Kosek wrote: >> On 04/23/2014 01:03 PM, Petr Viktorin wrote: >>> On 04/14/2014 12:55 PM, Martin Kosek wrote: >>> [...] >>>> dn: cn=masters,cn=ipa,cn=etc,SUFFIX >>>> - ADD aci allowing reading hosts (to have it separate from global >>>> cn=etc one so >>>> that we can once assign it only to ipamasters hostgroup for example) >>> >>> We don't have an ipamasters hostgroup. Should we? >> >> We do not have it currently, but AFAIK Honza planned (or even had >> patches?) to >> add it in his CA management utility effort. Honza, is that correct? > > It would certainly make things prettier. I don't have any patches, but > there is a ticket for that: . Sounds like the best way to do this. I've moved the ticket to Needs triage. >> Until this hostgroup is ready (and managed), I think we can have an >> ACI to >> allow read access to all authenticated users. >> >> OR, we may chose not have an ACI at all given that utilities (ipactl, >> ipa-replica-manage, ipa-replica-install) operating with cn=masters >> bind as DM >> (either via password or with External bind) and i.e. should not need >> the ACI. > > Renewal scripts need access to cn=masters and bind as host. -- Petr? From mkosek at redhat.com Wed Apr 23 12:46:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 14:46:10 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <535654C4.5060303@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> <20140416153414.GP20958@redhat.com> <1397663792.19767.401.camel@willson.li.ssimo.org> <535654C4.5060303@redhat.com> Message-ID: <5357B612.30805@redhat.com> On 04/22/2014 01:38 PM, Petr Viktorin wrote: > On 04/16/2014 05:56 PM, Simo Sorce wrote: >> On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: >>> On Wed, 16 Apr 2014, Martin Kosek wrote: >>>>>>>>>>>> In general I am not sure all authenticated users need access to all >>>>>>>>>>>> this >>>>>>>>>>>> info. Alexander ? >>>>>>>>>>> SSSD needs to read some of this information for subdomains support. >>>>>>>>>>> That would be at least host/*@REALM who needs to access it. >>>>>>>>>> >>>>>>>>>> Can you please list exactly which ones are needed ? >>>>>>>>> SSSD subdomains support needs: >>>>>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>>>>>> - ipaNTFlatName >>>>>>>>> - ipaNTSecurityIdentifier >>>>>>>>> - ipaNTTrustedDomainSID >>>>>>>>> - cn >>>>>>>> >>>>>>>> Question is - is there any added value in hiding part of the >>>>>>>> trust information from authenticated users? I.e. attributes like >>>>>>>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>>>>>>> attribute anyway?), SID blacklists... >>>>>>> Yes. Some of those attributes are needed as internal detail of ipasam -- >>>>>>> part of how Samba stores this information taken from specific DCE RPC >>>>>>> structures. >>>>>>> >>>>>>>> If yes, we would need to split this permission in 2 and have one for >>>>>>>> authenticated users and one for "Trust Adminitrators" and "Trust Readers". >>>>>>> Yes. Authenticated users shouldn't get any access to those details: >>>>>>> ipantsupportedencryptiontypes >>>>>>> ipanttrustattributes >>>>>>> ipanttrustauthincoming >>>>>>> ipanttrustauthoutgoing >>>>>>> >>>>>>> >>>>>> >>>>>> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group >>>>>> should >>>>>> then have this permission assigned so that samba can operate the attributes. >>>>> 'adtrust agents' and 'trust administrators' should have read, modify, >>>>> delete, and search on cn=trusts. >>>>> >>>> >>>> Right. We will probably want to turn most of ACIs in >>>> install/updates/60-trusts.update in managed permissions (i.e. defined in >>>> trust.py) and make "adtrust agents" and "trust admins" it's members. >>> I agree. >>> >> >> +1 >> >> Simo. >> > > All right. Now I'm replacing the global anonymous read ACI; converting the > others will come later. The existing agents/admins ACIs grant the 'read' (or > 'all') right already. > ipaIDRange is covered in the range plugin, so what's left for this patch is the > ipaNTTrustedDomain/ipaNTDomainAttrs attributes. > > Does that sound reasonable? This is all that's needed from SSSD side, I just verified in sssd git. sssd indeed only uses these attributes: #define IPA_CN "cn" #define IPA_FLATNAME "ipaNTFlatName" #define IPA_SID "ipaNTSecurityIdentifier" #define IPA_TRUSTED_DOMAIN_SID "ipaNTTrustedDomainSID" So I am OK with the patch as is. However, with this ACI, regular users will not be able to show Trusts with command line even though they have access to the basic information: # ipa trust-find ---------------- 0 trusts matched ---------------- ---------------------------- Number of entries returned 0 ---------------------------- IMO trust command should be able to return the information that the user is allowed to see. I prepared a patch to make the read part of trust.py more resilient to missing attributes. Attached. With this patch enabled, I have this output as regular user: # ipa trust-find --------------- 1 trust matched --------------- Realm name: tbad.example.com Domain NetBIOS name: TBAD Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 ---------------------------- Number of entries returned 1 ---------------------------- # ipa trust-show tbad.example.com Realm name: tbad.example.com Domain NetBIOS name: TBAD Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 # ipa trustdomain-find tbad.example.com Domain name: child.tbad.example.com Domain NetBIOS name: CHILD Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 Domain name: tbad.example.com Domain NetBIOS name: TBAD Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 ---------------------------- Number of entries returned 2 ---------------------------- The only bigger change I did was to filter trust root domains by ipaNTSecurityIdentifier and not ipaNTSIDBlacklistIncoming which is not available to everyone. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-469-make-trust-objects-available-to-regular-users.patch Type: text/x-patch Size: 4070 bytes Desc: not available URL: From ssorce at redhat.com Wed Apr 23 12:48:09 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 23 Apr 2014 08:48:09 -0400 Subject: [Freeipa-devel] [PATCHES] 0534-0535 Add several managed read permissions under cn=etc In-Reply-To: <5357A743.7020309@redhat.com> References: <5357A743.7020309@redhat.com> Message-ID: <1398257289.2628.330.camel@willson.li.ssimo.org> On Wed, 2014-04-23 at 13:42 +0200, Petr Viktorin wrote: > This adds managed read permissions to cn=etc. Since these permissions > are not bound to objects, the first patch adds support for those. > They're defined in the update plugin. > > The second patch adds permissions for various subtrees/entries in > cn=etc, according to the [discussion thread]. > > I wonder if we should limit the attributes in cn=replication; are all > nsds5replica attrs needed? Nope, IIRC we use this object exclusively to set the next available replica id. > For cn=ad,cn=etc I put the permission in cn=etc and used a target, > since > cn=ad is not present by default. > ok. Simo. > From mkosek at redhat.com Wed Apr 23 14:10:40 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 16:10:40 +0200 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <1398084480.2628.220.camel@willson.li.ssimo.org> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> <535054E6.4020904@redhat.com> <1397774273.2628.137.camel@willson.li.ssimo.org> <53551172.20608@redhat.com> <1398084480.2628.220.camel@willson.li.ssimo.org> Message-ID: <5357C9E0.1020507@redhat.com> On 04/21/2014 02:48 PM, Simo Sorce wrote: > On Mon, 2014-04-21 at 08:39 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: >>>>>> Simo Sorce wrote: >>>>>>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: >>>>>>>> I would like to discuss more on the managed read permissions upgrades [1]. >>>>>>>> Right now, we simply merge an old permission with the new one, making sure that >>>>>>>> we only add new attributes instead of just replacing them, to prevent a managed >>>>>>>> permission to be spoiled by a lower FreeIPA server version which runs an updates. >>>>>>>> >>>>>>>> I was thinking about it some more and seems to me we could run in problems when >>>>>>>> we for example find out that some permission is too relaxed and we want to >>>>>>>> remove some default attribute. Or when we want to update the permission filter. >>>>>>>> Or when object has anonymous and authenticated permission and we want to move >>>>>>>> attribute from anonymous to authenticated permission. >>>>>>>> >>>>>>>> Changes like this can happen, especially in the first release and we do not >>>>>>>> have means to address them. What about simply versioning the permissions as we >>>>>>>> do with our configs? I.e. >>>>>>>> >>>>>>>> 1) Introduce new MUST numeric attribute ipaPermVersion >>>>>>>> 2) Add 'version' field to managed permissions: >>>>>>>> >>>>>>>> managed_permissions = { >>>>>>>> 'System: Read Roles': { >>>>>>>> 'version': 1, >>>>>>>> 'replaces_global_anonymous_aci': True, >>>>>>>> 'ipapermbindruletype': 'permission', >>>>>>>> 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>> 'ipapermdefaultattr': { >>>>>>>> 'businesscategory', 'cn', 'description', 'member', 'memberof', >>>>>>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', >>>>>>>> }, >>>>>>>> 'default_privileges': {'RBAC Readers'}, >>>>>>>> }, >>>>>>>> } >>>>>>>> 3) Modify updater to only update the permission if it's version is higher than >>>>>>>> the one in LDAP. In that case, it should simply replace the managed permission >>>>>>>> attributes with the new one, no merging (except the attributes that we allow >>>>>>>> users to change). >>>>>>>> >>>>>>>> When we want to change the permission, we simply do the changes, bump the >>>>>>>> version and we are done and we do not need to fear some older FreeIPA will >>>>>>>> overwrite it. That of course assumes that the versioning would be available >>>>>>>> from FreeIPA 4.0. >>>>>>>> >>>>>>>> Makes sense? >>>>>>>> >>>>>>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>>> >>>>>>> >>>>>>> Uhmm, yes, and no, let me explain. >>>>>>> >>>>>>> What you say *does* make sense, but you are being too focused :-) >>>>>>> The upgrade issue is not limited to permissions, but affects everything. >>>>>>> >>>>>>> I think that what we need is to add a "ipa schema version" attribute >>>>>>> somewhere in cn=etc, and then always check this number in the updater >>>>>>> script. if this number is higher than what we know we immediately stop >>>>>>> and do not perform updates that affect anything but our own server data. >>>>>>> >>>>>>> This will protect the whole tree from unintentional changes caused by an >>>>>>> older replica. >>>>>>> >>>>>>> Makes sense ? >>>>>> >>>>>> This could lead to new features not working. Those features would rely >>>>>> on containers, ACIs, etc to exist but they wouldn't if the updates >>>>>> aren't run. >>>>> >>>>> Sorry I don't get this, if they are new features, then the version will >>>>> be "older" and the update *will* run and at the end raise the version. >>>>> >>>>> We just prevent old updates from running and current updates from >>>>> running multiple times, for the shared tree. >>>>> >>>>> Do we depend on having updates run multiple times for the data in the >>>>> shared tree ? >>>>> >>>>> Note that I am not saying that all updates should stop, any update for >>>>> cn=config would still need to be run on each server (although setting a >>>>> version there too would probably be beneficial). >>>> >>>> Ok, so the update runs, adds data, which gets replicated out to >>>> potentially old servers, and we're at the place you said we wouldn't be. >>> >>> I am not following you, the aim here is not to avoid replicating new >>> data to old server, the aim is that if you update the rpm of an older >>> replica and the rpm runs the ldap updater with the *old* code, we do not >>> end up with that updater *undoing* what a more recent update did. >>> >>>> Updates are all loaded and sorted so that all changes to a given DN >>>> should be applied at once, so it isn't like applying a old update and a >>>> new update are two separate operations. In fact, it would likely be a >>>> no-op in the case that they have already been applied. >>>> >>>> Do you have any examples to clarify your concerns? I'm not following you. >>> >>> Sure at some point version freeipa version 4.2 is released and it has an >>> update that changes a default object so that now attribute 'foo' is >>> added, this is done through the updater. >>> >>> Later on we release freeipa version 5.0 and we realize we will have >>> again to remove attribute 'foo' because we never really needed it, plus >>> if it is still there it causes issues to new feature XYZ. >>> >>> The admin installs 5.0 and all are happy, then a week later he runs a >>> simply yum update on th eolder replicas still running 4.2 and 4.2.1 is >>> available, and gets installed and ... bah the 4.2.1 updater re-adds >>> attribute 'foo' back ... and 5.0 servers are now broken. >>> >>> If we have an updater version field when the 4.2.1 update goes on it >>> will see that all updates that were necessary (and more) have already >>> been added and just quits. >> >> Ok, this won't happen in a modify case. When changing data we only >> change a known existing value, so exact match is required. >> >> The only risk is in adding and deleting data. >> >> So if we delete a permission named "Do cool stuff" in 5.0 and that was >> something previously added in 4.2 then yeah, re-running the 4.2 updates >> will re-apply the data. Similarly deletes would always be applied. >> >> I would not be keen on adding a global version value though, as we've >> had issues with updates in the past where re-running the updater would >> fix things. This would short circuit that. > > Well we could allow the updater to run on "same version" values, this > would preserve this ability while still blocking older updaters. > > Besides modifies can be affected too, say we have default value of 10, > we change it to 20 in 4.2 then change it back to 10 in 5.0 as we found > an issue with the new value. If you run 4.2 updater it puts it back to > 20. > > All cases of flipping values are also affected. > >> Something more fine-grained might work but carries its own problems. > > I think in this case we really want a domain level version, as the tree > is shared and we want updates to be consistent, so the update need to be > applied in full or not at all IMO. > > We do have some fine-grained approach as we will have a separate version > for he shared tree than the cn=config tree (and I guess another one for > the CA tree). > Each tree is a Silo, and should have its own tree version. > > Simo. > I think you are just designing https://fedorahosted.org/freeipa/ticket/2961 The idea to only run updates when the version of the tree is the same or higher than your FreeIPA package's. I am thinking this should work properly except the case when you have shared version replicas. It would not work for example if you have stable FreeIPA 3.3 servers and then you try installing FreeIPA 4.0 replica. Now until you move all your FreeIPA 3.4 servers to FreeIPA 4.0, you will be cut out of LDAP updates. For example, if we release security release FreeIPA 3.4.1, it's LDAP updates would not be updated as tree version would be 4.0. As for new permissions, with your scheme we would need to go through all permissions and forcefully overwrite what is in LDAP instead of just comparing the permission versions and updating if necessary. Martin From mbasti at redhat.com Wed Apr 23 14:25:20 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Apr 2014 10:25:20 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <535637A5.1020107@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> Message-ID: <315368937.9284002.1398263120742.JavaMail.zimbra@redhat.com> ----- Original Message ----- From: "Jan Cholasta" To: "Martin Basti" Cc: freeipa-devel at redhat.com Sent: Tuesday, April 22, 2014 11:34:29 AM Subject: Re: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin On 11.4.2014 17:23, Martin Basti wrote: > Updated patches attached. > > Patch 0047-1 should be applied between patches 0040-2 and 0041-2 > > Patch 0043-1 was squashed into 0038-2 > Patch 0044-1 was squashed into 0039-2 > Patch 0034-1 was squashed into 0032-2 > Patch 0034-2 implements bug fix > > Patches should be applied in order: 0029-0040, 0047, 0041-0042, > 0045-0046. > I had some test failures, don't know which patch is to blame: ====================================================================== ERROR: test_dns[88]: dnszone_add: Create reverse zone u'70.16.172.in-addr.arpa.' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 358, in check_output got = api.Command[cmd](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request raise error_class(message=error['message']) NotFound: Nameserver 'ns1.zone3.test.' does not have a corresponding A/AAAA record ====================================================================== ERROR: test_dns[90]: dnsrecord_add: Add NS record to u'128/25' in revzone u'70.16.172.in-addr.arpa.' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 358, in check_output got = api.Command[cmd](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request raise error_class(message=error['message']) NotFound: 70.16.172.in-addr.arpa.: DNS zone not found ====================================================================== ERROR: test_dns[91]: dnsrecord_add: Add CNAME record to u'129' in revzone u'70.16.172.in-addr.arpa.' ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 301, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 319, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 358, in check_output got = api.Command[cmd](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 854, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 831, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 971, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 965, in __request raise error_class(message=error['message']) NotFound: 70.16.172.in-addr.arpa.: DNS zone not found Honza Than you for review. I'm getting these errors if I forgot to configure /etc/resolv.conf nameserver address to ipa server itself. If it doesnt help, try to add 'wait_for_dns 5' option into IPA config file. Martin From mkosek at redhat.com Wed Apr 23 14:37:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 16:37:29 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <534FBEC2.1040809@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> Message-ID: <5357D029.3010403@redhat.com> On 04/17/2014 01:45 PM, Petr Viktorin wrote: > On 04/16/2014 03:41 PM, Simo Sorce wrote: >> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: >>> On 04/15/2014 04:55 PM, Petr Viktorin wrote: >>>> Hello, >>>> At Devconf, we decided what most of the default read permissions should look >>>> like, but we did not get to user. >>>> Here is a draft of 4 read permissions. Please comment. >>>> >>>> >>>> Basic info (anonymous): >>>> [top] >>>> objectclass >>>> [person] >>>> cn, sn, description >>>> [organizationalPerson] >>>> title >>>> [inetOrgPerson] >>>> uid >>>> displayName, givenName, initials >>>> manager >>>> [inetUser] >>>> memberOf >>> >>> <== We originally specifically hidden memberOf attribute from anonymous users. >>> I think we should continue hiding it. > > OK > >>>> [ipaObject] >>>> ipaUniqueID >>>> [ipaSshUser] >>>> ipaSshPubKey >>>> [ipaUserAuthTypeClass] >>>> ipaUserAuthType >>>> [posixAccount] >>>> gecos, gidNumber, homeDirectory, loginShell, uidNumber >>>> >>>> >>>> Details (all authenticated): >>>> [person] >>>> seeAlso, telephoneNumber >>>> [organizationalPerson] >>>> fax, l, ou, st, postalCode, street >>>> destinationIndicator, internationalISDNNumber, >>>> physicalDeliveryOfficeName, >>>> postalAddress, postOfficeBox, preferredDeliveryMethod, >>>> registeredAddress, teletexTerminalIdentifier, telexNumber, >>>> x121Address >>>> [inetOrgPerson] >>>> carLicense, departmentNumber, employeeNumber, employeeType, >>>> preferredLanguage, mail, mobile, pager >>>> audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, >>>> labeledURI, o, photo, roomNumber, secretary, userCertificate, >>>> userPKCS12, userSMIMECertificate, x500UniqueIdentifier >>>> [inetUser] >>>> inetUserHttpURL, inetUserStatus >>>> [ipaUser] >>>> userClass >>> >>> I would personally not divide the attributes as basic and detailed. IMO it is >>> our artificial distinction and may vary between deployments. Why would we for >>> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to >>> everyone? > > I thought it would be helpful to have a distinction between what needs > anonymous read, and what's optional. I know, my point was that I would leave this distinction to FreeIPA admins as the visibility to anonymous/authenticated will depend on their policies. I would create stricter rules only about attributes we are sure about, like the ones below. If some admin wants to hide some attribute, removing it from our user permission and adding a user read permission for authenticated users is very simple, I do not think the second permission needs to be managed. > > I can move individual attributes, of course. > >>> My proposal would be to have a permission "Read User Information" for all >>> attributes above. > > This way a paranoid admin would need to go through the attributes one by one to > decide what needs to stay anonymous and what doesn't. Having two permissions > makes this easier to tune. > > But of course I can merge them. > I am not sure how is that simpler. If admin does not like an attribute being open for authenticated and not for anonymous, he would need to remove it first from authenticated permission and add it to anonymous permission. I am personally for having all attributes above (except memberOf) open for anonymous. Rob or Simo, are you OK with it? Martin From pvoborni at redhat.com Wed Apr 23 14:57:35 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 23 Apr 2014 16:57:35 +0200 Subject: [Freeipa-devel] [PATCH] 14 webui: select all checkbox remains selected after operation In-Reply-To: <20140418104314.3997c1db@unused-4-246.brq.redhat.com> References: <20140418104314.3997c1db@unused-4-246.brq.redhat.com> Message-ID: <5357D4DF.3000206@redhat.com> On 18.4.2014 10:43, Misnyovszki Adam wrote: > Hi, > this patch fixes select_all checkbox issue, after any bulk modify or > delete operation, the checkbox is deselected. > https://fedorahosted.org/freeipa/ticket/4245 > > Thanks > Adam > The issue still exists in association facets and also maybe in attribute facet (group/external) (not tested). -- Petr Vobornik From pvoborni at redhat.com Wed Apr 23 15:16:50 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 23 Apr 2014 17:16:50 +0200 Subject: [Freeipa-devel] [PATCH] 15 webui doc: typo fixes in guides In-Reply-To: <20140418144150.3abe1d9e@unused-4-246.brq.redhat.com> References: <20140418144150.3abe1d9e@unused-4-246.brq.redhat.com> Message-ID: <5357D962.5080308@redhat.com> On 18.4.2014 14:41, Misnyovszki Adam wrote: > Hi, > $SUBJ tells everything. > Thanks > Adam > ACK Pushed to master: 260c5bd10927d3e01202ed1cccbdf4463c98e8a5 -- Petr Vobornik From simo at redhat.com Wed Apr 23 15:19:00 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 23 Apr 2014 11:19:00 -0400 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <5357C9E0.1020507@redhat.com> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> <535054E6.4020904@redhat.com> <1397774273.2628.137.camel@willson.li.ssimo.org> <53551172.20608@redhat.com> <1398084480.2628.220.camel@willson.li.ssimo.org> <5357C9E0.1020507@redhat.com> Message-ID: <1398266340.2628.344.camel@willson.li.ssimo.org> On Wed, 2014-04-23 at 16:10 +0200, Martin Kosek wrote: > On 04/21/2014 02:48 PM, Simo Sorce wrote: > > On Mon, 2014-04-21 at 08:39 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: > >>>>>> Simo Sorce wrote: > >>>>>>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: > >>>>>>>> I would like to discuss more on the managed read permissions upgrades [1]. > >>>>>>>> Right now, we simply merge an old permission with the new one, making sure that > >>>>>>>> we only add new attributes instead of just replacing them, to prevent a managed > >>>>>>>> permission to be spoiled by a lower FreeIPA server version which runs an updates. > >>>>>>>> > >>>>>>>> I was thinking about it some more and seems to me we could run in problems when > >>>>>>>> we for example find out that some permission is too relaxed and we want to > >>>>>>>> remove some default attribute. Or when we want to update the permission filter. > >>>>>>>> Or when object has anonymous and authenticated permission and we want to move > >>>>>>>> attribute from anonymous to authenticated permission. > >>>>>>>> > >>>>>>>> Changes like this can happen, especially in the first release and we do not > >>>>>>>> have means to address them. What about simply versioning the permissions as we > >>>>>>>> do with our configs? I.e. > >>>>>>>> > >>>>>>>> 1) Introduce new MUST numeric attribute ipaPermVersion > >>>>>>>> 2) Add 'version' field to managed permissions: > >>>>>>>> > >>>>>>>> managed_permissions = { > >>>>>>>> 'System: Read Roles': { > >>>>>>>> 'version': 1, > >>>>>>>> 'replaces_global_anonymous_aci': True, > >>>>>>>> 'ipapermbindruletype': 'permission', > >>>>>>>> 'ipapermright': {'read', 'search', 'compare'}, > >>>>>>>> 'ipapermdefaultattr': { > >>>>>>>> 'businesscategory', 'cn', 'description', 'member', 'memberof', > >>>>>>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', > >>>>>>>> }, > >>>>>>>> 'default_privileges': {'RBAC Readers'}, > >>>>>>>> }, > >>>>>>>> } > >>>>>>>> 3) Modify updater to only update the permission if it's version is higher than > >>>>>>>> the one in LDAP. In that case, it should simply replace the managed permission > >>>>>>>> attributes with the new one, no merging (except the attributes that we allow > >>>>>>>> users to change). > >>>>>>>> > >>>>>>>> When we want to change the permission, we simply do the changes, bump the > >>>>>>>> version and we are done and we do not need to fear some older FreeIPA will > >>>>>>>> overwrite it. That of course assumes that the versioning would be available > >>>>>>>> from FreeIPA 4.0. > >>>>>>>> > >>>>>>>> Makes sense? > >>>>>>>> > >>>>>>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions > >>>>>>> > >>>>>>> > >>>>>>> Uhmm, yes, and no, let me explain. > >>>>>>> > >>>>>>> What you say *does* make sense, but you are being too focused :-) > >>>>>>> The upgrade issue is not limited to permissions, but affects everything. > >>>>>>> > >>>>>>> I think that what we need is to add a "ipa schema version" attribute > >>>>>>> somewhere in cn=etc, and then always check this number in the updater > >>>>>>> script. if this number is higher than what we know we immediately stop > >>>>>>> and do not perform updates that affect anything but our own server data. > >>>>>>> > >>>>>>> This will protect the whole tree from unintentional changes caused by an > >>>>>>> older replica. > >>>>>>> > >>>>>>> Makes sense ? > >>>>>> > >>>>>> This could lead to new features not working. Those features would rely > >>>>>> on containers, ACIs, etc to exist but they wouldn't if the updates > >>>>>> aren't run. > >>>>> > >>>>> Sorry I don't get this, if they are new features, then the version will > >>>>> be "older" and the update *will* run and at the end raise the version. > >>>>> > >>>>> We just prevent old updates from running and current updates from > >>>>> running multiple times, for the shared tree. > >>>>> > >>>>> Do we depend on having updates run multiple times for the data in the > >>>>> shared tree ? > >>>>> > >>>>> Note that I am not saying that all updates should stop, any update for > >>>>> cn=config would still need to be run on each server (although setting a > >>>>> version there too would probably be beneficial). > >>>> > >>>> Ok, so the update runs, adds data, which gets replicated out to > >>>> potentially old servers, and we're at the place you said we wouldn't be. > >>> > >>> I am not following you, the aim here is not to avoid replicating new > >>> data to old server, the aim is that if you update the rpm of an older > >>> replica and the rpm runs the ldap updater with the *old* code, we do not > >>> end up with that updater *undoing* what a more recent update did. > >>> > >>>> Updates are all loaded and sorted so that all changes to a given DN > >>>> should be applied at once, so it isn't like applying a old update and a > >>>> new update are two separate operations. In fact, it would likely be a > >>>> no-op in the case that they have already been applied. > >>>> > >>>> Do you have any examples to clarify your concerns? I'm not following you. > >>> > >>> Sure at some point version freeipa version 4.2 is released and it has an > >>> update that changes a default object so that now attribute 'foo' is > >>> added, this is done through the updater. > >>> > >>> Later on we release freeipa version 5.0 and we realize we will have > >>> again to remove attribute 'foo' because we never really needed it, plus > >>> if it is still there it causes issues to new feature XYZ. > >>> > >>> The admin installs 5.0 and all are happy, then a week later he runs a > >>> simply yum update on th eolder replicas still running 4.2 and 4.2.1 is > >>> available, and gets installed and ... bah the 4.2.1 updater re-adds > >>> attribute 'foo' back ... and 5.0 servers are now broken. > >>> > >>> If we have an updater version field when the 4.2.1 update goes on it > >>> will see that all updates that were necessary (and more) have already > >>> been added and just quits. > >> > >> Ok, this won't happen in a modify case. When changing data we only > >> change a known existing value, so exact match is required. > >> > >> The only risk is in adding and deleting data. > >> > >> So if we delete a permission named "Do cool stuff" in 5.0 and that was > >> something previously added in 4.2 then yeah, re-running the 4.2 updates > >> will re-apply the data. Similarly deletes would always be applied. > >> > >> I would not be keen on adding a global version value though, as we've > >> had issues with updates in the past where re-running the updater would > >> fix things. This would short circuit that. > > > > Well we could allow the updater to run on "same version" values, this > > would preserve this ability while still blocking older updaters. > > > > Besides modifies can be affected too, say we have default value of 10, > > we change it to 20 in 4.2 then change it back to 10 in 5.0 as we found > > an issue with the new value. If you run 4.2 updater it puts it back to > > 20. > > > > All cases of flipping values are also affected. > > > >> Something more fine-grained might work but carries its own problems. > > > > I think in this case we really want a domain level version, as the tree > > is shared and we want updates to be consistent, so the update need to be > > applied in full or not at all IMO. > > > > We do have some fine-grained approach as we will have a separate version > > for he shared tree than the cn=config tree (and I guess another one for > > the CA tree). > > Each tree is a Silo, and should have its own tree version. > > > > Simo. > > > > I think you are just designing > https://fedorahosted.org/freeipa/ticket/2961 > > The idea to only run updates when the version of the tree is the same or higher > than your FreeIPA package's. It is exactly the inverse :-) Run updates if the version is equal or *lower*. > I am thinking this should work properly except the > case when you have shared version replicas. It would not work for example if > you have stable FreeIPA 3.3 servers and then you try installing FreeIPA 4.0 > replica. The ticket you mention is different, it says to not run certain updates if the version is past a certain version, that is also a useful feature, but only for tasks really. > Now until you move all your FreeIPA 3.4 servers to FreeIPA 4.0, you will be cut > out of LDAP updates. For example, if we release security release FreeIPA 3.4.1, > it's LDAP updates would not be updated as tree version would be 4.0. True, but if we release a security release 3.4.1 that requires updates to the tree then we have 2 options: A) The 4.0 versioned tree is not vulnerable because of previous ldap updates, so no updates are necessary. B) We also release 4.0.1 because the vulnerability is also there, so all you need to do is update one of the 4.0 release and the tree will be updated. > As for new permissions, with your scheme we would need to go through all > permissions and forcefully overwrite what is in LDAP instead of just comparing > the permission versions and updating if necessary. I do not understand this comment, sorry. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Apr 23 15:21:37 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 23 Apr 2014 11:21:37 -0400 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <5357D029.3010403@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> Message-ID: <1398266497.2628.345.camel@willson.li.ssimo.org> On Wed, 2014-04-23 at 16:37 +0200, Martin Kosek wrote: > On 04/17/2014 01:45 PM, Petr Viktorin wrote: > > On 04/16/2014 03:41 PM, Simo Sorce wrote: > >> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: > >>> On 04/15/2014 04:55 PM, Petr Viktorin wrote: > >>>> Hello, > >>>> At Devconf, we decided what most of the default read permissions should look > >>>> like, but we did not get to user. > >>>> Here is a draft of 4 read permissions. Please comment. > >>>> > >>>> > >>>> Basic info (anonymous): > >>>> [top] > >>>> objectclass > >>>> [person] > >>>> cn, sn, description > >>>> [organizationalPerson] > >>>> title > >>>> [inetOrgPerson] > >>>> uid > >>>> displayName, givenName, initials > >>>> manager > >>>> [inetUser] > >>>> memberOf > >>> > >>> <== We originally specifically hidden memberOf attribute from anonymous users. > >>> I think we should continue hiding it. > > > > OK > > > >>>> [ipaObject] > >>>> ipaUniqueID > >>>> [ipaSshUser] > >>>> ipaSshPubKey > >>>> [ipaUserAuthTypeClass] > >>>> ipaUserAuthType > >>>> [posixAccount] > >>>> gecos, gidNumber, homeDirectory, loginShell, uidNumber > >>>> > >>>> > >>>> Details (all authenticated): > >>>> [person] > >>>> seeAlso, telephoneNumber > >>>> [organizationalPerson] > >>>> fax, l, ou, st, postalCode, street > >>>> destinationIndicator, internationalISDNNumber, > >>>> physicalDeliveryOfficeName, > >>>> postalAddress, postOfficeBox, preferredDeliveryMethod, > >>>> registeredAddress, teletexTerminalIdentifier, telexNumber, > >>>> x121Address > >>>> [inetOrgPerson] > >>>> carLicense, departmentNumber, employeeNumber, employeeType, > >>>> preferredLanguage, mail, mobile, pager > >>>> audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, > >>>> labeledURI, o, photo, roomNumber, secretary, userCertificate, > >>>> userPKCS12, userSMIMECertificate, x500UniqueIdentifier > >>>> [inetUser] > >>>> inetUserHttpURL, inetUserStatus > >>>> [ipaUser] > >>>> userClass > >>> > >>> I would personally not divide the attributes as basic and detailed. IMO it is > >>> our artificial distinction and may vary between deployments. Why would we for > >>> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to > >>> everyone? > > > > I thought it would be helpful to have a distinction between what needs > > anonymous read, and what's optional. > > I know, my point was that I would leave this distinction to FreeIPA admins as > the visibility to anonymous/authenticated will depend on their policies. I > would create stricter rules only about attributes we are sure about, like the > ones below. > > If some admin wants to hide some attribute, removing it from our user > permission and adding a user read permission for authenticated users is very > simple, I do not think the second permission needs to be managed. > > > > > I can move individual attributes, of course. > > > >>> My proposal would be to have a permission "Read User Information" for all > >>> attributes above. > > > > This way a paranoid admin would need to go through the attributes one by one to > > decide what needs to stay anonymous and what doesn't. Having two permissions > > makes this easier to tune. > > > > But of course I can merge them. > > > > I am not sure how is that simpler. If admin does not like an attribute being > open for authenticated and not for anonymous, he would need to remove it first > from authenticated permission and add it to anonymous permission. > > I am personally for having all attributes above (except memberOf) open for > anonymous. Rob or Simo, are you OK with it? I am for exposing them only to authenticated users. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Wed Apr 23 16:14:13 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Apr 2014 18:14:13 +0200 Subject: [Freeipa-devel] [PATCH 0246-0248] Follow query/transfer/update policies for secure zones Message-ID: <5357E6D5.5060704@redhat.com> Hello, This patch set configures secure zones according to policies in LDAP. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0246-Move-secure-zone-configuration-from-create_zone-to-z.patch Type: text/x-patch Size: 3570 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0247-Follow-query-transfer-update-policies-for-secure-zon.patch Type: text/x-patch Size: 2368 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0248-Cleanup-logging-in-zone_master_reconfigure.patch Type: text/x-patch Size: 3186 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 23 16:16:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Apr 2014 18:16:24 +0200 Subject: [Freeipa-devel] [PATCH 0249-0250] Propagate DNS updates & changes from LDAP to signed version of the zone Message-ID: <5357E758.2050309@redhat.com> Hello, this patch set enables DNS updates to secure zones and also propagates changes made in LDAP to secure zones. NSEC3 doesn't work for some reason so don't waste time messing with NSEC3PARAM :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0249-Rename-zone-variables-in-update_record.patch Type: text/x-patch Size: 4398 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0250-Propagate-DNS-updates-changes-from-LDAP-to-signed-ve.patch Type: text/x-patch Size: 1161 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 23 16:19:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 18:19:37 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <1398266497.2628.345.camel@willson.li.ssimo.org> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> Message-ID: <5357E819.6060700@redhat.com> On 04/23/2014 05:21 PM, Simo Sorce wrote: > On Wed, 2014-04-23 at 16:37 +0200, Martin Kosek wrote: >> On 04/17/2014 01:45 PM, Petr Viktorin wrote: >>> On 04/16/2014 03:41 PM, Simo Sorce wrote: >>>> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: >>>>> On 04/15/2014 04:55 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> At Devconf, we decided what most of the default read permissions should look >>>>>> like, but we did not get to user. >>>>>> Here is a draft of 4 read permissions. Please comment. >>>>>> >>>>>> >>>>>> Basic info (anonymous): >>>>>> [top] >>>>>> objectclass >>>>>> [person] >>>>>> cn, sn, description >>>>>> [organizationalPerson] >>>>>> title >>>>>> [inetOrgPerson] >>>>>> uid >>>>>> displayName, givenName, initials >>>>>> manager >>>>>> [inetUser] >>>>>> memberOf >>>>> >>>>> <== We originally specifically hidden memberOf attribute from anonymous users. >>>>> I think we should continue hiding it. >>> >>> OK >>> >>>>>> [ipaObject] >>>>>> ipaUniqueID >>>>>> [ipaSshUser] >>>>>> ipaSshPubKey >>>>>> [ipaUserAuthTypeClass] >>>>>> ipaUserAuthType >>>>>> [posixAccount] >>>>>> gecos, gidNumber, homeDirectory, loginShell, uidNumber >>>>>> >>>>>> >>>>>> Details (all authenticated): >>>>>> [person] >>>>>> seeAlso, telephoneNumber >>>>>> [organizationalPerson] >>>>>> fax, l, ou, st, postalCode, street >>>>>> destinationIndicator, internationalISDNNumber, >>>>>> physicalDeliveryOfficeName, >>>>>> postalAddress, postOfficeBox, preferredDeliveryMethod, >>>>>> registeredAddress, teletexTerminalIdentifier, telexNumber, >>>>>> x121Address >>>>>> [inetOrgPerson] >>>>>> carLicense, departmentNumber, employeeNumber, employeeType, >>>>>> preferredLanguage, mail, mobile, pager >>>>>> audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, >>>>>> labeledURI, o, photo, roomNumber, secretary, userCertificate, >>>>>> userPKCS12, userSMIMECertificate, x500UniqueIdentifier >>>>>> [inetUser] >>>>>> inetUserHttpURL, inetUserStatus >>>>>> [ipaUser] >>>>>> userClass >>>>> >>>>> I would personally not divide the attributes as basic and detailed. IMO it is >>>>> our artificial distinction and may vary between deployments. Why would we for >>>>> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to >>>>> everyone? >>> >>> I thought it would be helpful to have a distinction between what needs >>> anonymous read, and what's optional. >> >> I know, my point was that I would leave this distinction to FreeIPA admins as >> the visibility to anonymous/authenticated will depend on their policies. I >> would create stricter rules only about attributes we are sure about, like the >> ones below. >> >> If some admin wants to hide some attribute, removing it from our user >> permission and adding a user read permission for authenticated users is very >> simple, I do not think the second permission needs to be managed. >> >>> >>> I can move individual attributes, of course. >>> >>>>> My proposal would be to have a permission "Read User Information" for all >>>>> attributes above. >>> >>> This way a paranoid admin would need to go through the attributes one by one to >>> decide what needs to stay anonymous and what doesn't. Having two permissions >>> makes this easier to tune. >>> >>> But of course I can merge them. >>> >> >> I am not sure how is that simpler. If admin does not like an attribute being >> open for authenticated and not for anonymous, he would need to remove it first >> from authenticated permission and add it to anonymous permission. >> >> I am personally for having all attributes above (except memberOf) open for >> anonymous. Rob or Simo, are you OK with it? > > I am for exposing them only to authenticated users. > > Simo. > To clarify - you want to have one permission allowing all attributes above (except memberOf) to authenticated users? Note that previously we exposed user data to anonymous so it would be a functional change. Martin From mkosek at redhat.com Wed Apr 23 16:26:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 18:26:17 +0200 Subject: [Freeipa-devel] Managed permission versioning In-Reply-To: <1398266340.2628.344.camel@willson.li.ssimo.org> References: <534FDB99.3070507@redhat.com> <1397760629.2628.97.camel@willson.li.ssimo.org> <535024C3.80202@redhat.com> <1397763699.2628.124.camel@willson.li.ssimo.org> <535054E6.4020904@redhat.com> <1397774273.2628.137.camel@willson.li.ssimo.org> <53551172.20608@redhat.com> <1398084480.2628.220.camel@willson.li.ssimo.org> <5357C9E0.1020507@redhat.com> <1398266340.2628.344.camel@willson.li.ssimo.org> Message-ID: <5357E9A9.4050701@redhat.com> On 04/23/2014 05:19 PM, Simo Sorce wrote: > On Wed, 2014-04-23 at 16:10 +0200, Martin Kosek wrote: >> On 04/21/2014 02:48 PM, Simo Sorce wrote: >>> On Mon, 2014-04-21 at 08:39 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote: >>>>>> Simo Sorce wrote: >>>>>>> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote: >>>>>>>> Simo Sorce wrote: >>>>>>>>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote: >>>>>>>>>> I would like to discuss more on the managed read permissions upgrades [1]. >>>>>>>>>> Right now, we simply merge an old permission with the new one, making sure that >>>>>>>>>> we only add new attributes instead of just replacing them, to prevent a managed >>>>>>>>>> permission to be spoiled by a lower FreeIPA server version which runs an updates. >>>>>>>>>> >>>>>>>>>> I was thinking about it some more and seems to me we could run in problems when >>>>>>>>>> we for example find out that some permission is too relaxed and we want to >>>>>>>>>> remove some default attribute. Or when we want to update the permission filter. >>>>>>>>>> Or when object has anonymous and authenticated permission and we want to move >>>>>>>>>> attribute from anonymous to authenticated permission. >>>>>>>>>> >>>>>>>>>> Changes like this can happen, especially in the first release and we do not >>>>>>>>>> have means to address them. What about simply versioning the permissions as we >>>>>>>>>> do with our configs? I.e. >>>>>>>>>> >>>>>>>>>> 1) Introduce new MUST numeric attribute ipaPermVersion >>>>>>>>>> 2) Add 'version' field to managed permissions: >>>>>>>>>> >>>>>>>>>> managed_permissions = { >>>>>>>>>> 'System: Read Roles': { >>>>>>>>>> 'version': 1, >>>>>>>>>> 'replaces_global_anonymous_aci': True, >>>>>>>>>> 'ipapermbindruletype': 'permission', >>>>>>>>>> 'ipapermright': {'read', 'search', 'compare'}, >>>>>>>>>> 'ipapermdefaultattr': { >>>>>>>>>> 'businesscategory', 'cn', 'description', 'member', 'memberof', >>>>>>>>>> 'o', 'objectclass', 'ou', 'owner', 'seealso', >>>>>>>>>> }, >>>>>>>>>> 'default_privileges': {'RBAC Readers'}, >>>>>>>>>> }, >>>>>>>>>> } >>>>>>>>>> 3) Modify updater to only update the permission if it's version is higher than >>>>>>>>>> the one in LDAP. In that case, it should simply replace the managed permission >>>>>>>>>> attributes with the new one, no merging (except the attributes that we allow >>>>>>>>>> users to change). >>>>>>>>>> >>>>>>>>>> When we want to change the permission, we simply do the changes, bump the >>>>>>>>>> version and we are done and we do not need to fear some older FreeIPA will >>>>>>>>>> overwrite it. That of course assumes that the versioning would be available >>>>>>>>>> from FreeIPA 4.0. >>>>>>>>>> >>>>>>>>>> Makes sense? >>>>>>>>>> >>>>>>>>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions >>>>>>>>> >>>>>>>>> >>>>>>>>> Uhmm, yes, and no, let me explain. >>>>>>>>> >>>>>>>>> What you say *does* make sense, but you are being too focused :-) >>>>>>>>> The upgrade issue is not limited to permissions, but affects everything. >>>>>>>>> >>>>>>>>> I think that what we need is to add a "ipa schema version" attribute >>>>>>>>> somewhere in cn=etc, and then always check this number in the updater >>>>>>>>> script. if this number is higher than what we know we immediately stop >>>>>>>>> and do not perform updates that affect anything but our own server data. >>>>>>>>> >>>>>>>>> This will protect the whole tree from unintentional changes caused by an >>>>>>>>> older replica. >>>>>>>>> >>>>>>>>> Makes sense ? >>>>>>>> >>>>>>>> This could lead to new features not working. Those features would rely >>>>>>>> on containers, ACIs, etc to exist but they wouldn't if the updates >>>>>>>> aren't run. >>>>>>> >>>>>>> Sorry I don't get this, if they are new features, then the version will >>>>>>> be "older" and the update *will* run and at the end raise the version. >>>>>>> >>>>>>> We just prevent old updates from running and current updates from >>>>>>> running multiple times, for the shared tree. >>>>>>> >>>>>>> Do we depend on having updates run multiple times for the data in the >>>>>>> shared tree ? >>>>>>> >>>>>>> Note that I am not saying that all updates should stop, any update for >>>>>>> cn=config would still need to be run on each server (although setting a >>>>>>> version there too would probably be beneficial). >>>>>> >>>>>> Ok, so the update runs, adds data, which gets replicated out to >>>>>> potentially old servers, and we're at the place you said we wouldn't be. >>>>> >>>>> I am not following you, the aim here is not to avoid replicating new >>>>> data to old server, the aim is that if you update the rpm of an older >>>>> replica and the rpm runs the ldap updater with the *old* code, we do not >>>>> end up with that updater *undoing* what a more recent update did. >>>>> >>>>>> Updates are all loaded and sorted so that all changes to a given DN >>>>>> should be applied at once, so it isn't like applying a old update and a >>>>>> new update are two separate operations. In fact, it would likely be a >>>>>> no-op in the case that they have already been applied. >>>>>> >>>>>> Do you have any examples to clarify your concerns? I'm not following you. >>>>> >>>>> Sure at some point version freeipa version 4.2 is released and it has an >>>>> update that changes a default object so that now attribute 'foo' is >>>>> added, this is done through the updater. >>>>> >>>>> Later on we release freeipa version 5.0 and we realize we will have >>>>> again to remove attribute 'foo' because we never really needed it, plus >>>>> if it is still there it causes issues to new feature XYZ. >>>>> >>>>> The admin installs 5.0 and all are happy, then a week later he runs a >>>>> simply yum update on th eolder replicas still running 4.2 and 4.2.1 is >>>>> available, and gets installed and ... bah the 4.2.1 updater re-adds >>>>> attribute 'foo' back ... and 5.0 servers are now broken. >>>>> >>>>> If we have an updater version field when the 4.2.1 update goes on it >>>>> will see that all updates that were necessary (and more) have already >>>>> been added and just quits. >>>> >>>> Ok, this won't happen in a modify case. When changing data we only >>>> change a known existing value, so exact match is required. >>>> >>>> The only risk is in adding and deleting data. >>>> >>>> So if we delete a permission named "Do cool stuff" in 5.0 and that was >>>> something previously added in 4.2 then yeah, re-running the 4.2 updates >>>> will re-apply the data. Similarly deletes would always be applied. >>>> >>>> I would not be keen on adding a global version value though, as we've >>>> had issues with updates in the past where re-running the updater would >>>> fix things. This would short circuit that. >>> >>> Well we could allow the updater to run on "same version" values, this >>> would preserve this ability while still blocking older updaters. >>> >>> Besides modifies can be affected too, say we have default value of 10, >>> we change it to 20 in 4.2 then change it back to 10 in 5.0 as we found >>> an issue with the new value. If you run 4.2 updater it puts it back to >>> 20. >>> >>> All cases of flipping values are also affected. >>> >>>> Something more fine-grained might work but carries its own problems. >>> >>> I think in this case we really want a domain level version, as the tree >>> is shared and we want updates to be consistent, so the update need to be >>> applied in full or not at all IMO. >>> >>> We do have some fine-grained approach as we will have a separate version >>> for he shared tree than the cn=config tree (and I guess another one for >>> the CA tree). >>> Each tree is a Silo, and should have its own tree version. >>> >>> Simo. >>> >> >> I think you are just designing >> https://fedorahosted.org/freeipa/ticket/2961 >> >> The idea to only run updates when the version of the tree is the same or higher >> than your FreeIPA package's. > > > It is exactly the inverse :-) > > Run updates if the version is equal or *lower*. Umh, right - this is what I actually meant (but not typed) :-) > >> I am thinking this should work properly except the >> case when you have shared version replicas. It would not work for example if >> you have stable FreeIPA 3.3 servers and then you try installing FreeIPA 4.0 >> replica. > > The ticket you mention is different, it says to not run certain updates > if the version is past a certain version, that is also a useful feature, > but only for tasks really. Ah, correct - LDAP updates like # Add the default PAC type to configuration dn: cn=ipaConfig,cn=etc,$SUFFIX addifnew: ipaKrbAuthzData: MS-PAC will still add ipaKrbAuthzData back if someone purposefully deleted the attribute. > >> Now until you move all your FreeIPA 3.4 servers to FreeIPA 4.0, you will be cut >> out of LDAP updates. For example, if we release security release FreeIPA 3.4.1, >> it's LDAP updates would not be updated as tree version would be 4.0. > > True, but if we release a security release 3.4.1 that requires updates > to the tree then we have 2 options: > A) The 4.0 versioned tree is not vulnerable because of previous ldap > updates, so no updates are necessary. > B) We also release 4.0.1 because the vulnerability is also there, so all > you need to do is update one of the 4.0 release and the tree will be > updated. Ok, we just need to be aware of this. > >> As for new permissions, with your scheme we would need to go through all >> permissions and forcefully overwrite what is in LDAP instead of just comparing >> the permission versions and updating if necessary. > > I do not understand this comment, sorry. > > Simo. This comment was specific to how managed permission updater works. With a version per permission, updater could just look at own managed permission versions and versions of managed permissions in LDAP and run update only for those that have lower version. With global tree version, updater will need to run through all own managed permission definitions and overwrite what's in LDAP to be sure that all updates are done. Martin From simo at redhat.com Wed Apr 23 18:07:48 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 23 Apr 2014 14:07:48 -0400 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <5357E819.6060700@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> <5357E819.6060700@redhat.com> Message-ID: <1398276468.2628.362.camel@willson.li.ssimo.org> On Wed, 2014-04-23 at 18:19 +0200, Martin Kosek wrote: > On 04/23/2014 05:21 PM, Simo Sorce wrote: > > On Wed, 2014-04-23 at 16:37 +0200, Martin Kosek wrote: > >> On 04/17/2014 01:45 PM, Petr Viktorin wrote: > >>> On 04/16/2014 03:41 PM, Simo Sorce wrote: > >>>> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: > >>>>> On 04/15/2014 04:55 PM, Petr Viktorin wrote: > >>>>>> Hello, > >>>>>> At Devconf, we decided what most of the default read permissions should look > >>>>>> like, but we did not get to user. > >>>>>> Here is a draft of 4 read permissions. Please comment. > >>>>>> > >>>>>> > >>>>>> Basic info (anonymous): > >>>>>> [top] > >>>>>> objectclass > >>>>>> [person] > >>>>>> cn, sn, description > >>>>>> [organizationalPerson] > >>>>>> title > >>>>>> [inetOrgPerson] > >>>>>> uid > >>>>>> displayName, givenName, initials > >>>>>> manager > >>>>>> [inetUser] > >>>>>> memberOf > >>>>> > >>>>> <== We originally specifically hidden memberOf attribute from anonymous users. > >>>>> I think we should continue hiding it. > >>> > >>> OK > >>> > >>>>>> [ipaObject] > >>>>>> ipaUniqueID > >>>>>> [ipaSshUser] > >>>>>> ipaSshPubKey > >>>>>> [ipaUserAuthTypeClass] > >>>>>> ipaUserAuthType > >>>>>> [posixAccount] > >>>>>> gecos, gidNumber, homeDirectory, loginShell, uidNumber > >>>>>> > >>>>>> > >>>>>> Details (all authenticated): > >>>>>> [person] > >>>>>> seeAlso, telephoneNumber > >>>>>> [organizationalPerson] > >>>>>> fax, l, ou, st, postalCode, street > >>>>>> destinationIndicator, internationalISDNNumber, > >>>>>> physicalDeliveryOfficeName, > >>>>>> postalAddress, postOfficeBox, preferredDeliveryMethod, > >>>>>> registeredAddress, teletexTerminalIdentifier, telexNumber, > >>>>>> x121Address > >>>>>> [inetOrgPerson] > >>>>>> carLicense, departmentNumber, employeeNumber, employeeType, > >>>>>> preferredLanguage, mail, mobile, pager > >>>>>> audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, > >>>>>> labeledURI, o, photo, roomNumber, secretary, userCertificate, > >>>>>> userPKCS12, userSMIMECertificate, x500UniqueIdentifier > >>>>>> [inetUser] > >>>>>> inetUserHttpURL, inetUserStatus > >>>>>> [ipaUser] > >>>>>> userClass > >>>>> > >>>>> I would personally not divide the attributes as basic and detailed. IMO it is > >>>>> our artificial distinction and may vary between deployments. Why would we for > >>>>> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to > >>>>> everyone? > >>> > >>> I thought it would be helpful to have a distinction between what needs > >>> anonymous read, and what's optional. > >> > >> I know, my point was that I would leave this distinction to FreeIPA admins as > >> the visibility to anonymous/authenticated will depend on their policies. I > >> would create stricter rules only about attributes we are sure about, like the > >> ones below. > >> > >> If some admin wants to hide some attribute, removing it from our user > >> permission and adding a user read permission for authenticated users is very > >> simple, I do not think the second permission needs to be managed. > >> > >>> > >>> I can move individual attributes, of course. > >>> > >>>>> My proposal would be to have a permission "Read User Information" for all > >>>>> attributes above. > >>> > >>> This way a paranoid admin would need to go through the attributes one by one to > >>> decide what needs to stay anonymous and what doesn't. Having two permissions > >>> makes this easier to tune. > >>> > >>> But of course I can merge them. > >>> > >> > >> I am not sure how is that simpler. If admin does not like an attribute being > >> open for authenticated and not for anonymous, he would need to remove it first > >> from authenticated permission and add it to anonymous permission. > >> > >> I am personally for having all attributes above (except memberOf) open for > >> anonymous. Rob or Simo, are you OK with it? > > > > I am for exposing them only to authenticated users. > > > > Simo. > > > > To clarify - you want to have one permission allowing all attributes above > (except memberOf) to authenticated users? Note that previously we exposed user > data to anonymous so it would be a functional change. I know, we may need to provide another permission admins can use to turn on anonymous searches for those attributes too. We may also decide that on upgrade vs new install we retain anonymous access. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Apr 23 18:27:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Apr 2014 20:27:24 +0200 Subject: [Freeipa-devel] [PATCH] [CI] Move project definition to a template file Message-ID: <5358060C.1020409@redhat.com> Hello, I've pushed this patch to the CI test definitions repository. To use the repo, you will now need to copy `project.yaml.example` to `project.yaml`, and configure your own values in it. For example, Tom?? can use prefix: "tbabej" and report-mail-address: "tbabej at redhat.com". With this setup, a developer's personal test modifications shouldn't override the main config. https://github.com/encukou/freeipa-ci -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipaci-pviktori-da0dfce-move-project-definition-to-a-template-file.patch Type: text/x-patch Size: 5470 bytes Desc: not available URL: From pviktori at redhat.com Wed Apr 23 18:37:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Apr 2014 20:37:12 +0200 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes Message-ID: <53580858.60908@redhat.com> Admin access to read-only attributes such as ipaUniqueId, memberOf, krbPrincipalName is provided by the anonymous read ACI, which will go away. This patch adds a blanket read ACI for these. I also moved some related ACIs to 20-aci.update. Previously krbPwdHistory was also readable by admins. I don't think we want to include that. Simo, should admins be allowed to read krbExtraData? The second patch makes the test suite pass with the anon read ACI removed. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0536-Add-ACI-for-read-only-admin-attributes.patch Type: text/x-patch Size: 12952 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0537-test_ldap-Read-a-publicly-accessible-attribute-when-.patch Type: text/x-patch Size: 1410 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 23 18:52:18 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Apr 2014 14:52:18 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5350E5EA.2060106@redhat.com> References: <52D99F70.3060305@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> <5350E5EA.2060106@redhat.com> Message-ID: <53580BE2.6050606@redhat.com> Petr Viktorin wrote: > On 04/09/2014 11:29 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>>> [...] >>>>>>> >>>>>>> Here are a couple more enhancements I'm considering, this seems >>>>>>> simpler >>>>>>> than inter-diff since it is so small. >>>>>> >>>>>> Not really. Having a patch file with a sequence+revision number you >>>>>> can >>>>>> refer to has its merits. Especially in a hairy thread like this one. >>>>>> Also one of our MUAs wrapped the lines, I had to undo that manually. >>>>>> >>>>>>> Here is why I made the changes, in order: >>>>>>> >>>>>>> I doubled the calls to create the connection but one isn't in a >>>>>>> try/except!? Remove the obvious one. >>>>>>> >>>>>>> We currently completely eat GSSAPI errors, I figure we should log >>>>>>> failures. >>>>>>> >>>>>>> IPA stores the principal in the request context so using that will >>>>>>> save >>>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>>> >>>>>>> I included your content-type change. >>>>>> >>>>>> These changes look good. >>>>>> I'm almost done testing but I need to call it a week. >>>>> >>>>> Awesome, thanks. >>>> >>>> ACK on the functionality. >>>> >>>>>> Sorry for not catching that last time, but your patch doesn't add a >>>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>>> duplicate >>>>>> unversioned one. So lint (and thus the build) will fail if the old >>>>>> python-kerberos version is installed. >>>>>> >>>>>> A possible a solution to the build trouble would be to just add a >>>>>> lint >>>>>> exception now, and open a ticket to remove it later. That way the >>>>>> build >>>>>> succeeds despite the older version, and the new python-kerberos is >>>>>> only >>>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>>> That should make everyone happy, including Martin. >>>>>> Unfortunately our lint exception mechanism doesn't work on >>>>>> modules, so >>>>>> this needs a somewhat nastier hack. >>>>>> The attaching a patch that does this (and I'm pasting a simple diff >>>>>> below). Does that look okay to push? >>>>> >>>>> I'm trying to find a better solution to all this. I may end up taking >>>>> Martin's suggestion of rawhide-only to avoid this sort of thing. >>>> >>>> Looks like you'll still need to silence pylint on f20 in that case. >>>> >>>>> The deal with the smartproxy is that you can/should be able to run >>>>> it on >>>>> any IPA-enrolled client, so you can run it directly on the Foreman >>>>> box, >>>>> with the IPA server somewhere else. What this means is that someone >>>>> could probably fairly easily package this up for other distributions >>>>> and >>>>> if we end up with a Fedora-only python-kerberos patch then >>>>> smartproxy is >>>>> Fedora-only as well. >>>>> >>>>> So I'm trying to get some movement out of upstream on this but it's >>>>> been >>>>> crickets for weeks. I think in the context of the calendar server >>>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll amp up >>>>> the >>>>> nagging to get some sort of response, even if it is "stop nagging us!" >>>>> >>>>> rob >>>> >>>> Good luck! >>> >>> Ok, taking a different tack on this. Rather than running it as a >>> separate server process, run it as a WSGI app inside Apache. This >>> required a fair bit of re-tooling and complicates the set up a little >>> bit. I think I've got it all covered in the man page. >>> >>> On the python-kerberos front I've got bugs opened in Ubuntu and Debian >>> to see if we can get the patch accepted their until (if) upstream ever >>> takes a look. >> >> I decided to run the new WSGI app in a different process group, using >> the smartproxy we use for delegation. This simplifies the connection >> code, rather than using ldap2 like I was using, we use the RPC >> interface. And it provides to process separation. As a side-effect it >> will make running this code on platforms without GSSProxy a bit easier. >> >> rob >> > > Works great here! > > > The python-kerberos dependency issue still needs to be solved. Build is on the way to updates-testing if you can give it a go. > > The man page says: > Copy ipa-smartproxy-apache.conf to > /etc/httpd/conf.d/ipa-smartproxy.conf. > It would be nice to put the whole path here so people don't have to > search for the file. Done. > > The "Configure Apache to use smartproxy" line looks like a step to be > performed. It could use some emphasis to make it look like a header. I combined it with the subsequent sentence so hopefully it is a bit clearer. I also added a bit on testing so you can confirm that things are working. > Side note, cherrypy's routing makes requests like this possible: > http POST > :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass > > > Should that be allowed? It is definitely ugly but AFAICT it isn't illegal. The zero content-length bothers me more than this horrible-looking URI. It definitely requires some understanding of the ordering of parameters to get this call right. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-10-rest.patch Type: text/x-patch Size: 48319 bytes Desc: not available URL: From ssorce at redhat.com Wed Apr 23 18:56:05 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 23 Apr 2014 14:56:05 -0400 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <53580858.60908@redhat.com> References: <53580858.60908@redhat.com> Message-ID: <1398279365.2628.369.camel@willson.li.ssimo.org> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: > Admin access to read-only attributes such as ipaUniqueId, memberOf, > krbPrincipalName is provided by the anonymous read ACI, which will go > away. This patch adds a blanket read ACI for these. > I also moved some related ACIs to 20-aci.update. > > Previously krbPwdHistory was also readable by admins. I don't think we > want to include that. > Simo, should admins be allowed to read krbExtraData? Probably not necessary but there is nothing secret in it either. Simo. From mkosek at redhat.com Wed Apr 23 20:53:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 23 Apr 2014 22:53:06 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <1398276468.2628.362.camel@willson.li.ssimo.org> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> <5357E819.6060700@redhat.com> <1398276468.2628.362.camel@willson.li.ssimo.org> Message-ID: <53582832.9010807@redhat.com> On 04/23/2014 08:07 PM, Simo Sorce wrote: > On Wed, 2014-04-23 at 18:19 +0200, Martin Kosek wrote: >> On 04/23/2014 05:21 PM, Simo Sorce wrote: >>> On Wed, 2014-04-23 at 16:37 +0200, Martin Kosek wrote: >>>> On 04/17/2014 01:45 PM, Petr Viktorin wrote: >>>>> On 04/16/2014 03:41 PM, Simo Sorce wrote: >>>>>> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: >>>>>>> On 04/15/2014 04:55 PM, Petr Viktorin wrote: >>>>>>>> Hello, >>>>>>>> At Devconf, we decided what most of the default read permissions should look >>>>>>>> like, but we did not get to user. >>>>>>>> Here is a draft of 4 read permissions. Please comment. >>>>>>>> >>>>>>>> >>>>>>>> Basic info (anonymous): >>>>>>>> [top] >>>>>>>> objectclass >>>>>>>> [person] >>>>>>>> cn, sn, description >>>>>>>> [organizationalPerson] >>>>>>>> title >>>>>>>> [inetOrgPerson] >>>>>>>> uid >>>>>>>> displayName, givenName, initials >>>>>>>> manager >>>>>>>> [inetUser] >>>>>>>> memberOf >>>>>>> >>>>>>> <== We originally specifically hidden memberOf attribute from anonymous users. >>>>>>> I think we should continue hiding it. >>>>> >>>>> OK >>>>> >>>>>>>> [ipaObject] >>>>>>>> ipaUniqueID >>>>>>>> [ipaSshUser] >>>>>>>> ipaSshPubKey >>>>>>>> [ipaUserAuthTypeClass] >>>>>>>> ipaUserAuthType >>>>>>>> [posixAccount] >>>>>>>> gecos, gidNumber, homeDirectory, loginShell, uidNumber >>>>>>>> >>>>>>>> >>>>>>>> Details (all authenticated): >>>>>>>> [person] >>>>>>>> seeAlso, telephoneNumber >>>>>>>> [organizationalPerson] >>>>>>>> fax, l, ou, st, postalCode, street >>>>>>>> destinationIndicator, internationalISDNNumber, >>>>>>>> physicalDeliveryOfficeName, >>>>>>>> postalAddress, postOfficeBox, preferredDeliveryMethod, >>>>>>>> registeredAddress, teletexTerminalIdentifier, telexNumber, >>>>>>>> x121Address >>>>>>>> [inetOrgPerson] >>>>>>>> carLicense, departmentNumber, employeeNumber, employeeType, >>>>>>>> preferredLanguage, mail, mobile, pager >>>>>>>> audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, >>>>>>>> labeledURI, o, photo, roomNumber, secretary, userCertificate, >>>>>>>> userPKCS12, userSMIMECertificate, x500UniqueIdentifier >>>>>>>> [inetUser] >>>>>>>> inetUserHttpURL, inetUserStatus >>>>>>>> [ipaUser] >>>>>>>> userClass >>>>>>> >>>>>>> I would personally not divide the attributes as basic and detailed. IMO it is >>>>>>> our artificial distinction and may vary between deployments. Why would we for >>>>>>> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to >>>>>>> everyone? >>>>> >>>>> I thought it would be helpful to have a distinction between what needs >>>>> anonymous read, and what's optional. >>>> >>>> I know, my point was that I would leave this distinction to FreeIPA admins as >>>> the visibility to anonymous/authenticated will depend on their policies. I >>>> would create stricter rules only about attributes we are sure about, like the >>>> ones below. >>>> >>>> If some admin wants to hide some attribute, removing it from our user >>>> permission and adding a user read permission for authenticated users is very >>>> simple, I do not think the second permission needs to be managed. >>>> >>>>> >>>>> I can move individual attributes, of course. >>>>> >>>>>>> My proposal would be to have a permission "Read User Information" for all >>>>>>> attributes above. >>>>> >>>>> This way a paranoid admin would need to go through the attributes one by one to >>>>> decide what needs to stay anonymous and what doesn't. Having two permissions >>>>> makes this easier to tune. >>>>> >>>>> But of course I can merge them. >>>>> >>>> >>>> I am not sure how is that simpler. If admin does not like an attribute being >>>> open for authenticated and not for anonymous, he would need to remove it first >>>> from authenticated permission and add it to anonymous permission. >>>> >>>> I am personally for having all attributes above (except memberOf) open for >>>> anonymous. Rob or Simo, are you OK with it? >>> >>> I am for exposing them only to authenticated users. >>> >>> Simo. >>> >> >> To clarify - you want to have one permission allowing all attributes above >> (except memberOf) to authenticated users? Note that previously we exposed user >> data to anonymous so it would be a functional change. > > I know, we may need to provide another permission admins can use to turn > on anonymous searches for those attributes too. > We may also decide that on upgrade vs new install we retain anonymous > access. > > Simo. > That permission is called $ ipa permission-mod "System: User Information" --bindtype all This is all that's needed to make all the user attributes above readable by authenticated users and not by anonymous. Martin From pviktori at redhat.com Thu Apr 24 07:41:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 24 Apr 2014 09:41:08 +0200 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <1398279365.2628.369.camel@willson.li.ssimo.org> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> Message-ID: <5358C014.3040800@redhat.com> On 04/23/2014 08:56 PM, Simo Sorce wrote: > On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >> Admin access to read-only attributes such as ipaUniqueId, memberOf, >> krbPrincipalName is provided by the anonymous read ACI, which will go >> away. This patch adds a blanket read ACI for these. >> I also moved some related ACIs to 20-aci.update. >> >> Previously krbPwdHistory was also readable by admins. I don't think we >> want to include that. >> Simo, should admins be allowed to read krbExtraData? > > Probably not necessary but there is nothing secret in it either. > > Simo. OK. I'm not a fan of hiding things from the admin, so no changes to the patch are necessary here. -- Petr? From mkosek at redhat.com Thu Apr 24 09:21:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Apr 2014 11:21:19 +0200 Subject: [Freeipa-devel] [PATCHES] 0532-0533 Extend anonymous read ACI for containers In-Reply-To: <53564D56.6000608@redhat.com> References: <5351118B.7080108@redhat.com> <1397828586.2628.151.camel@willson.li.ssimo.org> <53512D59.2080604@redhat.com> <1397830028.2628.161.camel@willson.li.ssimo.org> <5351328D.6070406@redhat.com> <1397830635.2628.165.camel@willson.li.ssimo.org> <53564D56.6000608@redhat.com> Message-ID: <5358D78F.6070202@redhat.com> On 04/22/2014 01:07 PM, Petr Viktorin wrote: > On 04/18/2014 04:17 PM, Simo Sorce wrote: >> On Fri, 2014-04-18 at 16:11 +0200, Martin Kosek wrote: >>> On 04/18/2014 04:07 PM, Simo Sorce wrote: >>>> On Fri, 2014-04-18 at 15:49 +0200, Martin Kosek wrote: >>>>> On 04/18/2014 03:43 PM, Simo Sorce wrote: >>>>>> On Fri, 2014-04-18 at 13:50 +0200, Petr Viktorin wrote: >>>>>>> This extends the "Anonymous read access to containers" ACI to cover >>>>>>> cn=etc, as discussed in [0]. >>>>>>> >>>>>>> A new objectClass is added so we can exclude virtual ops with >>>>>>> targetfilter: ipaVirtualOperation (2.16.840.1.113730.3.8.12.23). >>>>>>> >>>>>>> >>>>>>> [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00319.html >>>>>>> >>>>>> >>>>>> LGTM >>>>>> >>>>> >>>>> It works perfectly except one subtree we missed during initial review and >>>>> which >>>>> we should discuss: >>>>> >>>>> cn=replicas,cn=ipa,cn=etc,SUFFIX >>>>> >>>>> It contains list of replicas (not FreeIPA masters) connected to FreeIPA. >>>>> Currently, this only affects Winsync replicas. >>>>> >>>>> I just verified that anonymous user can retrieve list of connected ADs via >>>>> winsync. Question is, how to prevent it given that this is created >>>>> dynamically >>>>> also by older FreeIPA server and given that it has no special objectsclass to >>>>> base a filtration on. >>>>> >>>>> Maybe we would need to add a deny ACI in this case after all? >>>> >>>> Or we can add an objectclass here too, the update script will then need >>>> to look at existing objects dynamically and update them. >>> >>> This would not work well as older FreeIPA servers would not use this >>> objectclass when "ipa-replica-manage connect --winsync" is run on them. >> >> I know, although you are probably not supposed to keep creating these >> kind of agreements until you finish upgrading all the server, we always >> advice people to upgrade the infra in a matter of weeks. >> >>>> However we could also ass a deny aci only in this subtree for now and >>>> change it later, if we think that's too much work. >>>> >>>> We have plans to revisit shared replica information storage anyway, so >>>> perhaps it is not worth spending too much time on this now. >>>> >>>> Simo. >>> >>> deny ACI is preventing access to nsContainer to anonymous users in >>> cn=replica... is probably it is our best shot ATM unless we find a better >>> solution. >> >> Agree. >> >> simo. > > > Updated patch attached. > Both patches worked well in my tests, ACK. Pushed to master: 1389567ec58dca310edf679af7903013f0bdaf07 Martin From mkosek at redhat.com Thu Apr 24 09:35:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Apr 2014 11:35:58 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <53582832.9010807@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> <5357E819.6060700@redhat.com> <1398276468.2628.362.camel@willson.li.ssimo.org> <53582832.9010807@redhat.com> Message-ID: <5358DAFE.4070505@redhat.com> On 04/23/2014 10:53 PM, Martin Kosek wrote: > On 04/23/2014 08:07 PM, Simo Sorce wrote: >> On Wed, 2014-04-23 at 18:19 +0200, Martin Kosek wrote: >>> On 04/23/2014 05:21 PM, Simo Sorce wrote: >>>> On Wed, 2014-04-23 at 16:37 +0200, Martin Kosek wrote: >>>>> On 04/17/2014 01:45 PM, Petr Viktorin wrote: >>>>>> On 04/16/2014 03:41 PM, Simo Sorce wrote: >>>>>>> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote: >>>>>>>> On 04/15/2014 04:55 PM, Petr Viktorin wrote: >>>>>>>>> Hello, >>>>>>>>> At Devconf, we decided what most of the default read permissions >>>>>>>>> should look >>>>>>>>> like, but we did not get to user. >>>>>>>>> Here is a draft of 4 read permissions. Please comment. >>>>>>>>> >>>>>>>>> >>>>>>>>> Basic info (anonymous): >>>>>>>>> [top] >>>>>>>>> objectclass >>>>>>>>> [person] >>>>>>>>> cn, sn, description >>>>>>>>> [organizationalPerson] >>>>>>>>> title >>>>>>>>> [inetOrgPerson] >>>>>>>>> uid >>>>>>>>> displayName, givenName, initials >>>>>>>>> manager >>>>>>>>> [inetUser] >>>>>>>>> memberOf >>>>>>>> >>>>>>>> <== We originally specifically hidden memberOf attribute from anonymous >>>>>>>> users. >>>>>>>> I think we should continue hiding it. >>>>>> >>>>>> OK >>>>>> >>>>>>>>> [ipaObject] >>>>>>>>> ipaUniqueID >>>>>>>>> [ipaSshUser] >>>>>>>>> ipaSshPubKey >>>>>>>>> [ipaUserAuthTypeClass] >>>>>>>>> ipaUserAuthType >>>>>>>>> [posixAccount] >>>>>>>>> gecos, gidNumber, homeDirectory, loginShell, uidNumber >>>>>>>>> >>>>>>>>> >>>>>>>>> Details (all authenticated): >>>>>>>>> [person] >>>>>>>>> seeAlso, telephoneNumber >>>>>>>>> [organizationalPerson] >>>>>>>>> fax, l, ou, st, postalCode, street >>>>>>>>> destinationIndicator, internationalISDNNumber, >>>>>>>>> physicalDeliveryOfficeName, >>>>>>>>> postalAddress, postOfficeBox, preferredDeliveryMethod, >>>>>>>>> registeredAddress, teletexTerminalIdentifier, telexNumber, >>>>>>>>> x121Address >>>>>>>>> [inetOrgPerson] >>>>>>>>> carLicense, departmentNumber, employeeNumber, employeeType, >>>>>>>>> preferredLanguage, mail, mobile, pager >>>>>>>>> audio, businessCategory, homePhone, homePostalAddress, jpegPhoto, >>>>>>>>> labeledURI, o, photo, roomNumber, secretary, userCertificate, >>>>>>>>> userPKCS12, userSMIMECertificate, x500UniqueIdentifier >>>>>>>>> [inetUser] >>>>>>>>> inetUserHttpURL, inetUserStatus >>>>>>>>> [ipaUser] >>>>>>>>> userClass >>>>>>>> >>>>>>>> I would personally not divide the attributes as basic and detailed. IMO >>>>>>>> it is >>>>>>>> our artificial distinction and may vary between deployments. Why would >>>>>>>> we for >>>>>>>> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to >>>>>>>> everyone? >>>>>> >>>>>> I thought it would be helpful to have a distinction between what needs >>>>>> anonymous read, and what's optional. >>>>> >>>>> I know, my point was that I would leave this distinction to FreeIPA admins as >>>>> the visibility to anonymous/authenticated will depend on their policies. I >>>>> would create stricter rules only about attributes we are sure about, like the >>>>> ones below. >>>>> >>>>> If some admin wants to hide some attribute, removing it from our user >>>>> permission and adding a user read permission for authenticated users is very >>>>> simple, I do not think the second permission needs to be managed. >>>>> >>>>>> >>>>>> I can move individual attributes, of course. >>>>>> >>>>>>>> My proposal would be to have a permission "Read User Information" for all >>>>>>>> attributes above. >>>>>> >>>>>> This way a paranoid admin would need to go through the attributes one by >>>>>> one to >>>>>> decide what needs to stay anonymous and what doesn't. Having two permissions >>>>>> makes this easier to tune. >>>>>> >>>>>> But of course I can merge them. >>>>>> >>>>> >>>>> I am not sure how is that simpler. If admin does not like an attribute being >>>>> open for authenticated and not for anonymous, he would need to remove it >>>>> first >>>>> from authenticated permission and add it to anonymous permission. >>>>> >>>>> I am personally for having all attributes above (except memberOf) open for >>>>> anonymous. Rob or Simo, are you OK with it? >>>> >>>> I am for exposing them only to authenticated users. >>>> >>>> Simo. >>>> >>> >>> To clarify - you want to have one permission allowing all attributes above >>> (except memberOf) to authenticated users? Note that previously we exposed user >>> data to anonymous so it would be a functional change. >> >> I know, we may need to provide another permission admins can use to turn >> on anonymous searches for those attributes too. >> We may also decide that on upgrade vs new install we retain anonymous >> access. >> >> Simo. >> > > That permission is called > > $ ipa permission-mod "System: User Information" --bindtype all > > This is all that's needed to make all the user attributes above readable by > authenticated users and not by anonymous. > > Martin BTW, we already open groups to anonymous - i.e. we might want to keep the same level of default access to users too. Martin From mkosek at redhat.com Thu Apr 24 09:47:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Apr 2014 11:47:48 +0200 Subject: [Freeipa-devel] [PATCH] 0520 Add managed read permission to service In-Reply-To: <5357B077.6070202@redhat.com> References: <534BC0CF.9090103@redhat.com> <5357B077.6070202@redhat.com> Message-ID: <5358DDC4.3080305@redhat.com> On 04/23/2014 02:22 PM, Petr Viktorin wrote: > On 04/14/2014 01:04 PM, Petr Viktorin wrote: >> Read access is given to all authenticated users. >> >> Exposed attributes are: >> [top] >> objectClass >> [ipaObject] >> ipaUniqueID >> [ipaService] >> managedBy >> memberOf >> ipaKrbAuthzData (a.k.a. pac_type) >> [pkiUser] >> userCertificate >> [krbPrincipalAux] >> krbPrincipalName >> krbCanonicalName >> krbPrincipalAliases >> krbPrincipalExpiration >> krbPasswordExpiration >> krbLastPwdChange >> [krbTicketPolicyAux] - none >> [ipaKrbPrincipal] >> krbPrincipalName >> ipaKrbPrincipalAlias >> [krbPrincipal] >> krbPrincipalName >> krbObjectReferences >> >> >> Kerberos-related attributes were discussed for hosts here: >> http://www.redhat.com/archives/freeipa-devel/2014-April/msg00242.html > > ping, any takers for the review? > Works ok and is consistent with our Host access control settings. ACK. Pushed to master: b9f69d4f0b310ed000fc7bde522f3657c032020b Martin From arta.moeini at gmail.com Thu Apr 24 10:43:02 2014 From: arta.moeini at gmail.com (Mohammad Reza Moeini) Date: Thu, 24 Apr 2014 10:43:02 +0000 (UTC) Subject: [Freeipa-devel] Check out my profile on LinkedIn Message-ID: <1854772853.1276982.1398336182234.JavaMail.app@ela4-app1479.prod> LinkedIn ------------ I'd like to include you in my network to share updates and stay in touch. - Mohammad Reza Mohammad Reza Moeini Unix/Linux Administrator at it's not about your bessiness (secret) Iran Confirm that you know Mohammad Reza Moeini: https://www.linkedin.com/e/shch6o-hudx9bkj-68/isd/5865047034716770304/jrUcN4YT/?hs=false&tok=01oi7v1jK3Dmc1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/shch6o-hudx9bkj-68/v8iqM64ia9cP1xqGytYmBFlEa3-S1_pWma0WbA/goo/freeipa-devel%40redhat%2Ecom/20061/I6948836215_1/?hs=false&tok=2F2nWjKkm3Dmc1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Apr 24 11:53:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Apr 2014 13:53:29 +0200 Subject: [Freeipa-devel] [PATCHES] 0534-0535 Add several managed read permissions under cn=etc In-Reply-To: <1398257289.2628.330.camel@willson.li.ssimo.org> References: <5357A743.7020309@redhat.com> <1398257289.2628.330.camel@willson.li.ssimo.org> Message-ID: <5358FB39.6040904@redhat.com> On 04/23/2014 02:48 PM, Simo Sorce wrote: > On Wed, 2014-04-23 at 13:42 +0200, Petr Viktorin wrote: >> This adds managed read permissions to cn=etc. Since these permissions >> are not bound to objects, the first patch adds support for those. >> They're defined in the update plugin. >> >> The second patch adds permissions for various subtrees/entries in >> cn=etc, according to the [discussion thread]. >> >> I wonder if we should limit the attributes in cn=replication; are all >> nsds5replica attrs needed? > > Nope, IIRC we use this object exclusively to set the next available > replica id. > >> For cn=ad,cn=etc I put the permission in cn=etc and used a target, >> since >> cn=ad is not present by default. >> > ok. 534 - ACK. 535: System: Read IPA Masters - ACK System: Read DNA Configuration - ACK System: Read CA Renewal Information - ACK - I tested with "getcert resubmit -i $ID_OF_AUDITCERT" System: Read CA Certificate - should be OK - currently we need just cn,objectclass,cACertificate, but we may allow others for future use System: Read Replication Information - changes needed? - currently, we need/use just cn,objectclass,nsds5replicaid,nsds5replicaroot - I am thinking we may be fine with allowing just those. Simo, what's your take on this? System: Read AD Domains - ACK Martin From mkosek at redhat.com Thu Apr 24 12:17:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Apr 2014 14:17:11 +0200 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <5358C014.3040800@redhat.com> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> Message-ID: <535900C7.7060405@redhat.com> On 04/24/2014 09:41 AM, Petr Viktorin wrote: > On 04/23/2014 08:56 PM, Simo Sorce wrote: >> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >>> Admin access to read-only attributes such as ipaUniqueId, memberOf, >>> krbPrincipalName is provided by the anonymous read ACI, which will go >>> away. This patch adds a blanket read ACI for these. >>> I also moved some related ACIs to 20-aci.update. >>> >>> Previously krbPwdHistory was also readable by admins. I don't think we >>> want to include that. >>> Simo, should admins be allowed to read krbExtraData? >> >> Probably not necessary but there is nothing secret in it either. >> >> Simo. > > OK. I'm not a fan of hiding things from the admin, so no changes to the patch > are necessary here. > 536: As we are touching these ACIs, may it is a time to see the blacklist of attributes that admin cannot write and check if this is still wanted: ipaUniqueId - OK, generated by DS plugin memberOf - OK, generated by DS plugin serverHostName - I did not even find a place where we manipulate it, except host.py -> remove from blacklist? enrolledBy - OK, generated by DS plugin krbExtraData - OK, generated by DS plugin krbPrincipalName - why can't admin change it? It is filled by framework, I would not personally blacklist it krbCanonicalName - same as krbPrincipalName krbPrincipalAliases - same as krbPrincipalName - we need this removed if we want to set aliases anyway krbPasswordExpiration - OK, generated by DS plugin krbLastPwdChange - OK, generated by DS plugin krbUPEnabled - not used, can we remove it? krbTicketPolicyReference - why cannot admin set it? krbPwdPolicyReference - why cannot admin set it? krbPrincipalType - why cannot admin set it? krbLastSuccessfulAuth - OK, generated by DS plugin krbLastFailedAuth - OK, generated by DS plugin krbLoginFailedCount - OK, generated by DS plugin It seems to me that some attributes can be indeed removed from the backlist (and thus from the admin whitelist too). Besides that, the patch looked OK to me. 537: ACK (tests pass) Martin From ssorce at redhat.com Thu Apr 24 12:24:49 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Apr 2014 08:24:49 -0400 Subject: [Freeipa-devel] [PATCHES] 0534-0535 Add several managed read permissions under cn=etc In-Reply-To: <5358FB39.6040904@redhat.com> References: <5357A743.7020309@redhat.com> <1398257289.2628.330.camel@willson.li.ssimo.org> <5358FB39.6040904@redhat.com> Message-ID: <1398342289.2628.415.camel@willson.li.ssimo.org> On Thu, 2014-04-24 at 13:53 +0200, Martin Kosek wrote: > On 04/23/2014 02:48 PM, Simo Sorce wrote: > > On Wed, 2014-04-23 at 13:42 +0200, Petr Viktorin wrote: > >> This adds managed read permissions to cn=etc. Since these permissions > >> are not bound to objects, the first patch adds support for those. > >> They're defined in the update plugin. > >> > >> The second patch adds permissions for various subtrees/entries in > >> cn=etc, according to the [discussion thread]. > >> > >> I wonder if we should limit the attributes in cn=replication; are all > >> nsds5replica attrs needed? > > > > Nope, IIRC we use this object exclusively to set the next available > > replica id. > > > >> For cn=ad,cn=etc I put the permission in cn=etc and used a target, > >> since > >> cn=ad is not present by default. > >> > > ok. > > 534 - ACK. > > 535: > > System: Read IPA Masters - ACK > > System: Read DNA Configuration - ACK > > System: Read CA Renewal Information - ACK > - I tested with "getcert resubmit -i $ID_OF_AUDITCERT" > > System: Read CA Certificate - should be OK > - currently we need just cn,objectclass,cACertificate, but we may allow others > for future use > > System: Read Replication Information - changes needed? > - currently, we need/use just cn,objectclass,nsds5replicaid,nsds5replicaroot > - I am thinking we may be fine with allowing just those. Simo, what's your take > on this? Should be fine, hopefully we will soon overhaul the replication stuff to expose the topology and all, so I am not overly concerned. > System: Read AD Domains - ACK Simo. From ssorce at redhat.com Thu Apr 24 12:28:40 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Apr 2014 08:28:40 -0400 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <535900C7.7060405@redhat.com> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> Message-ID: <1398342520.2628.417.camel@willson.li.ssimo.org> On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: > On 04/24/2014 09:41 AM, Petr Viktorin wrote: > > On 04/23/2014 08:56 PM, Simo Sorce wrote: > >> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: > >>> Admin access to read-only attributes such as ipaUniqueId, memberOf, > >>> krbPrincipalName is provided by the anonymous read ACI, which will go > >>> away. This patch adds a blanket read ACI for these. > >>> I also moved some related ACIs to 20-aci.update. > >>> > >>> Previously krbPwdHistory was also readable by admins. I don't think we > >>> want to include that. > >>> Simo, should admins be allowed to read krbExtraData? > >> > >> Probably not necessary but there is nothing secret in it either. > >> > >> Simo. > > > > OK. I'm not a fan of hiding things from the admin, so no changes to the patch > > are necessary here. > > > > 536: > As we are touching these ACIs, may it is a time to see the blacklist of > attributes that admin cannot write and check if this is still wanted: > > ipaUniqueId - OK, generated by DS plugin > memberOf - OK, generated by DS plugin > serverHostName - I did not even find a place where we manipulate it, except > host.py -> remove from blacklist? > enrolledBy - OK, generated by DS plugin > krbExtraData - OK, generated by DS plugin > krbPrincipalName - why can't admin change it? It is filled by framework, I > would not personally blacklist it It is changed by the ipa rename plugin when the user uid change, that's why we prevent the admin from explicitly change it. > krbCanonicalName - same as krbPrincipalName > krbPrincipalAliases - same as krbPrincipalName - we need this removed if we > want to set aliases anyway > krbPasswordExpiration - OK, generated by DS plugin > krbLastPwdChange - OK, generated by DS plugin > krbUPEnabled - not used, can we remove it? > krbTicketPolicyReference - why cannot admin set it? Unclear why, probably should be able to. > krbPwdPolicyReference - why cannot admin set it? We assign password policy based on groups now, right ? > krbPrincipalType - why cannot admin set it? Unused. > krbLastSuccessfulAuth - OK, generated by DS plugin > krbLastFailedAuth - OK, generated by DS plugin > krbLoginFailedCount - OK, generated by DS plugin > > It seems to me that some attributes can be indeed removed from the backlist > (and thus from the admin whitelist too). > > Besides that, the patch looked OK to me. > > 537: ACK (tests pass) Simo. From mkosek at redhat.com Thu Apr 24 12:43:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Apr 2014 14:43:54 +0200 Subject: [Freeipa-devel] [PATCHES] 0534-0535 Add several managed read permissions under cn=etc In-Reply-To: <1398342289.2628.415.camel@willson.li.ssimo.org> References: <5357A743.7020309@redhat.com> <1398257289.2628.330.camel@willson.li.ssimo.org> <5358FB39.6040904@redhat.com> <1398342289.2628.415.camel@willson.li.ssimo.org> Message-ID: <5359070A.7030409@redhat.com> On 04/24/2014 02:24 PM, Simo Sorce wrote: > On Thu, 2014-04-24 at 13:53 +0200, Martin Kosek wrote: >> On 04/23/2014 02:48 PM, Simo Sorce wrote: >>> On Wed, 2014-04-23 at 13:42 +0200, Petr Viktorin wrote: >>>> This adds managed read permissions to cn=etc. Since these permissions >>>> are not bound to objects, the first patch adds support for those. >>>> They're defined in the update plugin. >>>> >>>> The second patch adds permissions for various subtrees/entries in >>>> cn=etc, according to the [discussion thread]. >>>> >>>> I wonder if we should limit the attributes in cn=replication; are all >>>> nsds5replica attrs needed? >>> >>> Nope, IIRC we use this object exclusively to set the next available >>> replica id. >>> >>>> For cn=ad,cn=etc I put the permission in cn=etc and used a target, >>>> since >>>> cn=ad is not present by default. >>>> >>> ok. >> >> 534 - ACK. >> >> 535: >> >> System: Read IPA Masters - ACK >> >> System: Read DNA Configuration - ACK >> >> System: Read CA Renewal Information - ACK >> - I tested with "getcert resubmit -i $ID_OF_AUDITCERT" >> >> System: Read CA Certificate - should be OK >> - currently we need just cn,objectclass,cACertificate, but we may allow others >> for future use >> >> System: Read Replication Information - changes needed? >> - currently, we need/use just cn,objectclass,nsds5replicaid,nsds5replicaroot >> - I am thinking we may be fine with allowing just those. Simo, what's your take >> on this? > > Should be fine, hopefully we will soon overhaul the replication stuff to > expose the topology and all, so I am not overly concerned. > >> System: Read AD Domains - ACK > > Simo. Ok, thanks. It is an ACK as the "System: Read Replication Information" was the only one I was concerned about. Pushed to master: d893b77fb69ef2e0aedf823e7cd82ca86a2971af Martin From amisnyov at redhat.com Thu Apr 24 12:57:29 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 24 Apr 2014 14:57:29 +0200 Subject: [Freeipa-devel] [PATCH] 14 webui: select all checkbox remains selected after operation In-Reply-To: <5357D4DF.3000206@redhat.com> References: <20140418104314.3997c1db@unused-4-246.brq.redhat.com> <5357D4DF.3000206@redhat.com> Message-ID: <20140424145729.3f66e7bc@unused-4-246.brq.redhat.com> On Wed, 23 Apr 2014 16:57:35 +0200 Petr Vobornik wrote: > On 18.4.2014 10:43, Misnyovszki Adam wrote: > > Hi, > > this patch fixes select_all checkbox issue, after any bulk modify or > > delete operation, the checkbox is deselected. > > https://fedorahosted.org/freeipa/ticket/4245 > > > > Thanks > > Adam > > > > The issue still exists in association facets and also maybe in > attribute facet (group/external) (not tested). Hi, thanks for the review, see the attached corrections! Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0014-2-webui-select-all-checkbox-remains-selected-after-operation.patch Type: text/x-patch Size: 3882 bytes Desc: not available URL: From mkosek at redhat.com Thu Apr 24 13:18:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Apr 2014 15:18:31 +0200 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <1398342520.2628.417.camel@willson.li.ssimo.org> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> Message-ID: <53590F27.3040601@redhat.com> On 04/24/2014 02:28 PM, Simo Sorce wrote: > On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: >> On 04/24/2014 09:41 AM, Petr Viktorin wrote: >>> On 04/23/2014 08:56 PM, Simo Sorce wrote: >>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, >>>>> krbPrincipalName is provided by the anonymous read ACI, which will go >>>>> away. This patch adds a blanket read ACI for these. >>>>> I also moved some related ACIs to 20-aci.update. >>>>> >>>>> Previously krbPwdHistory was also readable by admins. I don't think we >>>>> want to include that. >>>>> Simo, should admins be allowed to read krbExtraData? >>>> >>>> Probably not necessary but there is nothing secret in it either. >>>> >>>> Simo. >>> >>> OK. I'm not a fan of hiding things from the admin, so no changes to the patch >>> are necessary here. >>> >> >> 536: >> As we are touching these ACIs, may it is a time to see the blacklist of >> attributes that admin cannot write and check if this is still wanted: >> >> ipaUniqueId - OK, generated by DS plugin >> memberOf - OK, generated by DS plugin >> serverHostName - I did not even find a place where we manipulate it, except >> host.py -> remove from blacklist? What about this one? >> enrolledBy - OK, generated by DS plugin >> krbExtraData - OK, generated by DS plugin >> krbPrincipalName - why can't admin change it? It is filled by framework, I >> would not personally blacklist it > > It is changed by the ipa rename plugin when the user uid change, that's > why we prevent the admin from explicitly change it. > >> krbCanonicalName - same as krbPrincipalName Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? >> krbPrincipalAliases - same as krbPrincipalName - we need this removed if we >> want to set aliases anyway Allow this one? >> krbPasswordExpiration - OK, generated by DS plugin >> krbLastPwdChange - OK, generated by DS plugin >> krbUPEnabled - not used, can we remove it? What about this one? >> krbTicketPolicyReference - why cannot admin set it? > > Unclear why, probably should be able to. We may want to remove it from blacklist then. > >> krbPwdPolicyReference - why cannot admin set it? > > We assign password policy based on groups now, right ? Yup. > >> krbPrincipalType - why cannot admin set it? > > Unused. So... allow this one? > >> krbLastSuccessfulAuth - OK, generated by DS plugin >> krbLastFailedAuth - OK, generated by DS plugin >> krbLoginFailedCount - OK, generated by DS plugin >> >> It seems to me that some attributes can be indeed removed from the backlist >> (and thus from the admin whitelist too). >> >> Besides that, the patch looked OK to me. >> >> 537: ACK (tests pass) Petr, regarding the "Admin can manage any entry" update - you removed 4 related "remove:aci" definitions, but added just 3. Is that intentional? Martin From pviktori at redhat.com Thu Apr 24 13:28:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 24 Apr 2014 15:28:28 +0200 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <53590F27.3040601@redhat.com> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> <53590F27.3040601@redhat.com> Message-ID: <5359117C.2070805@redhat.com> On 04/24/2014 03:18 PM, Martin Kosek wrote: > On 04/24/2014 02:28 PM, Simo Sorce wrote: >> On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: >>> On 04/24/2014 09:41 AM, Petr Viktorin wrote: >>>> On 04/23/2014 08:56 PM, Simo Sorce wrote: >>>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >>>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, >>>>>> krbPrincipalName is provided by the anonymous read ACI, which will go >>>>>> away. This patch adds a blanket read ACI for these. >>>>>> I also moved some related ACIs to 20-aci.update. >>>>>> >>>>>> Previously krbPwdHistory was also readable by admins. I don't think we >>>>>> want to include that. >>>>>> Simo, should admins be allowed to read krbExtraData? >>>>> >>>>> Probably not necessary but there is nothing secret in it either. >>>>> >>>>> Simo. >>>> >>>> OK. I'm not a fan of hiding things from the admin, so no changes to the patch >>>> are necessary here. >>>> >>> >>> 536: >>> As we are touching these ACIs, may it is a time to see the blacklist of >>> attributes that admin cannot write and check if this is still wanted: >>> >>> ipaUniqueId - OK, generated by DS plugin >>> memberOf - OK, generated by DS plugin >>> serverHostName - I did not even find a place where we manipulate it, except >>> host.py -> remove from blacklist? > > What about this one? > >>> enrolledBy - OK, generated by DS plugin >>> krbExtraData - OK, generated by DS plugin >>> krbPrincipalName - why can't admin change it? It is filled by framework, I >>> would not personally blacklist it >> >> It is changed by the ipa rename plugin when the user uid change, that's >> why we prevent the admin from explicitly change it. >> >>> krbCanonicalName - same as krbPrincipalName > > Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? > >>> krbPrincipalAliases - same as krbPrincipalName - we need this removed if we >>> want to set aliases anyway > > Allow this one? > >>> krbPasswordExpiration - OK, generated by DS plugin >>> krbLastPwdChange - OK, generated by DS plugin >>> krbUPEnabled - not used, can we remove it? > > What about this one? > >>> krbTicketPolicyReference - why cannot admin set it? >> >> Unclear why, probably should be able to. > > We may want to remove it from blacklist then. > >> >>> krbPwdPolicyReference - why cannot admin set it? >> >> We assign password policy based on groups now, right ? > > Yup. > >> >>> krbPrincipalType - why cannot admin set it? >> >> Unused. > > So... allow this one? > >> >>> krbLastSuccessfulAuth - OK, generated by DS plugin >>> krbLastFailedAuth - OK, generated by DS plugin >>> krbLoginFailedCount - OK, generated by DS plugin >>> >>> It seems to me that some attributes can be indeed removed from the backlist >>> (and thus from the admin whitelist too). >>> >>> Besides that, the patch looked OK to me. >>> >>> 537: ACK (tests pass) > > > Petr, regarding the "Admin can manage any entry" update - you removed 4 related > "remove:aci" definitions, but added just 3. Is that intentional? The fourth was exactly the same as the one being added. -- Petr? From ssorce at redhat.com Thu Apr 24 13:42:37 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Apr 2014 09:42:37 -0400 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <53590F27.3040601@redhat.com> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> <53590F27.3040601@redhat.com> Message-ID: <1398346957.2628.431.camel@willson.li.ssimo.org> On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: > On 04/24/2014 02:28 PM, Simo Sorce wrote: > > On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: > >> On 04/24/2014 09:41 AM, Petr Viktorin wrote: > >>> On 04/23/2014 08:56 PM, Simo Sorce wrote: > >>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: > >>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, > >>>>> krbPrincipalName is provided by the anonymous read ACI, which will go > >>>>> away. This patch adds a blanket read ACI for these. > >>>>> I also moved some related ACIs to 20-aci.update. > >>>>> > >>>>> Previously krbPwdHistory was also readable by admins. I don't think we > >>>>> want to include that. > >>>>> Simo, should admins be allowed to read krbExtraData? > >>>> > >>>> Probably not necessary but there is nothing secret in it either. > >>>> > >>>> Simo. > >>> > >>> OK. I'm not a fan of hiding things from the admin, so no changes to the patch > >>> are necessary here. > >>> > >> > >> 536: > >> As we are touching these ACIs, may it is a time to see the blacklist of > >> attributes that admin cannot write and check if this is still wanted: > >> > >> ipaUniqueId - OK, generated by DS plugin > >> memberOf - OK, generated by DS plugin > >> serverHostName - I did not even find a place where we manipulate it, except > >> host.py -> remove from blacklist? > > What about this one? not sure, I did not work much on the hosts objects. > >> enrolledBy - OK, generated by DS plugin > >> krbExtraData - OK, generated by DS plugin > >> krbPrincipalName - why can't admin change it? It is filled by framework, I > >> would not personally blacklist it > > > > It is changed by the ipa rename plugin when the user uid change, that's > > why we prevent the admin from explicitly change it. > > > >> krbCanonicalName - same as krbPrincipalName > > Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? They should be accessible by admin, yes. > >> krbPrincipalAliases - same as krbPrincipalName - we need this removed if we > >> want to set aliases anyway > > Allow this one? This is one I wanted to eventually get rid of, Alexander seem to have introduced it, but we discussed in the past of a way to kill it. I forgot the details thouhg. Alexander did we open a ticket for this ? > >> krbPasswordExpiration - OK, generated by DS plugin > >> krbLastPwdChange - OK, generated by DS plugin > >> krbUPEnabled - not used, can we remove it? > > What about this one? We never use it. > >> krbTicketPolicyReference - why cannot admin set it? > > > > Unclear why, probably should be able to. > > We may want to remove it from blacklist then. We never used it, but we should probably allow admin to modify > >> krbPwdPolicyReference - why cannot admin set it? > > > > We assign password policy based on groups now, right ? > > Yup. > > > > >> krbPrincipalType - why cannot admin set it? > > > > Unused. > > So... allow this one? we never use it so we do not need to allow admins by default. Simo. > >> krbLastSuccessfulAuth - OK, generated by DS plugin > >> krbLastFailedAuth - OK, generated by DS plugin > >> krbLoginFailedCount - OK, generated by DS plugin > >> > >> It seems to me that some attributes can be indeed removed from the backlist > >> (and thus from the admin whitelist too). > >> > >> Besides that, the patch looked OK to me. > >> > >> 537: ACK (tests pass) > > > Petr, regarding the "Admin can manage any entry" update - you removed 4 related > "remove:aci" definitions, but added just 3. Is that intentional? > > Martin From pviktori at redhat.com Thu Apr 24 13:56:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 24 Apr 2014 15:56:00 +0200 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53580BE2.6050606@redhat.com> References: <52D99F70.3060305@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> <5350E5EA.2060106@redhat.com> <53580BE2.6050606@redhat.com> Message-ID: <535917F0.4050107@redhat.com> On 04/23/2014 08:52 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/09/2014 11:29 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>>>> [...] >>>>>>>> >>>>>>>> Here are a couple more enhancements I'm considering, this seems >>>>>>>> simpler >>>>>>>> than inter-diff since it is so small. >>>>>>> >>>>>>> Not really. Having a patch file with a sequence+revision number you >>>>>>> can >>>>>>> refer to has its merits. Especially in a hairy thread like this one. >>>>>>> Also one of our MUAs wrapped the lines, I had to undo that manually. >>>>>>> >>>>>>>> Here is why I made the changes, in order: >>>>>>>> >>>>>>>> I doubled the calls to create the connection but one isn't in a >>>>>>>> try/except!? Remove the obvious one. >>>>>>>> >>>>>>>> We currently completely eat GSSAPI errors, I figure we should log >>>>>>>> failures. >>>>>>>> >>>>>>>> IPA stores the principal in the request context so using that will >>>>>>>> save >>>>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>>>> >>>>>>>> I included your content-type change. >>>>>>> >>>>>>> These changes look good. >>>>>>> I'm almost done testing but I need to call it a week. >>>>>> >>>>>> Awesome, thanks. >>>>> >>>>> ACK on the functionality. >>>>> >>>>>>> Sorry for not catching that last time, but your patch doesn't add a >>>>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>>>> duplicate >>>>>>> unversioned one. So lint (and thus the build) will fail if the old >>>>>>> python-kerberos version is installed. >>>>>>> >>>>>>> A possible a solution to the build trouble would be to just add a >>>>>>> lint >>>>>>> exception now, and open a ticket to remove it later. That way the >>>>>>> build >>>>>>> succeeds despite the older version, and the new python-kerberos is >>>>>>> only >>>>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>>>> That should make everyone happy, including Martin. >>>>>>> Unfortunately our lint exception mechanism doesn't work on >>>>>>> modules, so >>>>>>> this needs a somewhat nastier hack. >>>>>>> The attaching a patch that does this (and I'm pasting a simple diff >>>>>>> below). Does that look okay to push? >>>>>> >>>>>> I'm trying to find a better solution to all this. I may end up taking >>>>>> Martin's suggestion of rawhide-only to avoid this sort of thing. >>>>> >>>>> Looks like you'll still need to silence pylint on f20 in that case. >>>>> >>>>>> The deal with the smartproxy is that you can/should be able to run >>>>>> it on >>>>>> any IPA-enrolled client, so you can run it directly on the Foreman >>>>>> box, >>>>>> with the IPA server somewhere else. What this means is that someone >>>>>> could probably fairly easily package this up for other distributions >>>>>> and >>>>>> if we end up with a Fedora-only python-kerberos patch then >>>>>> smartproxy is >>>>>> Fedora-only as well. >>>>>> >>>>>> So I'm trying to get some movement out of upstream on this but it's >>>>>> been >>>>>> crickets for weeks. I think in the context of the calendar server >>>>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll amp up >>>>>> the >>>>>> nagging to get some sort of response, even if it is "stop nagging >>>>>> us!" >>>>>> >>>>>> rob >>>>> >>>>> Good luck! >>>> >>>> Ok, taking a different tack on this. Rather than running it as a >>>> separate server process, run it as a WSGI app inside Apache. This >>>> required a fair bit of re-tooling and complicates the set up a little >>>> bit. I think I've got it all covered in the man page. >>>> >>>> On the python-kerberos front I've got bugs opened in Ubuntu and Debian >>>> to see if we can get the patch accepted their until (if) upstream ever >>>> takes a look. >>> >>> I decided to run the new WSGI app in a different process group, using >>> the smartproxy we use for delegation. This simplifies the connection >>> code, rather than using ldap2 like I was using, we use the RPC >>> interface. And it provides to process separation. As a side-effect it >>> will make running this code on platforms without GSSProxy a bit easier. >>> >>> rob >>> >> >> Works great here! >> >> >> The python-kerberos dependency issue still needs to be solved. > > Build is on the way to updates-testing if you can give it a go. > >> >> The man page says: >> Copy ipa-smartproxy-apache.conf to >> /etc/httpd/conf.d/ipa-smartproxy.conf. >> It would be nice to put the whole path here so people don't have to >> search for the file. > > Done. > >> >> The "Configure Apache to use smartproxy" line looks like a step to be >> performed. It could use some emphasis to make it look like a header. > > I combined it with the subsequent sentence so hopefully it is a bit > clearer. > > I also added a bit on testing so you can confirm that things are working. > > >> Side note, cherrypy's routing makes requests like this possible: >> http POST >> :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass >> >> >> >> Should that be allowed? > > It is definitely ugly but AFAICT it isn't illegal. The zero > content-length bothers me more than this horrible-looking URI. It > definitely requires some understanding of the ordering of parameters to > get this call right. > > rob Everything works now! Except one thing: json_encode_binary recently got a mandatory version argument. For code that's part of IPA, it should be fine to just use API_VERSION here. I tested with that added; ACK if you agree. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-10+pviktori-rest.patch Type: text/x-patch Size: 48352 bytes Desc: not available URL: From massimiliano.perrone at tirasa.net Thu Apr 24 13:58:21 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Thu, 24 Apr 2014 15:58:21 +0200 Subject: [Freeipa-devel] First beta release of ConnID FreeIPA connector Message-ID: <5359187D.2090208@tirasa.net> Hi guys, this mail only to share with you that ConnID FreeIPA connector (beta version) is released. You can find more informations here [1] Massimiliano [1] http://blog.tirasa.net/unlock-full-freeipa-features.html -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From mkosek at redhat.com Thu Apr 24 14:47:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 24 Apr 2014 16:47:43 +0200 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <1398346957.2628.431.camel@willson.li.ssimo.org> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> <53590F27.3040601@redhat.com> <1398346957.2628.431.camel@willson.li.ssimo.org> Message-ID: <5359240F.6090408@redhat.com> On 04/24/2014 03:42 PM, Simo Sorce wrote: > On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: >> On 04/24/2014 02:28 PM, Simo Sorce wrote: >>> On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: >>>> On 04/24/2014 09:41 AM, Petr Viktorin wrote: >>>>> On 04/23/2014 08:56 PM, Simo Sorce wrote: >>>>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >>>>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, >>>>>>> krbPrincipalName is provided by the anonymous read ACI, which will go >>>>>>> away. This patch adds a blanket read ACI for these. >>>>>>> I also moved some related ACIs to 20-aci.update. >>>>>>> >>>>>>> Previously krbPwdHistory was also readable by admins. I don't think we >>>>>>> want to include that. >>>>>>> Simo, should admins be allowed to read krbExtraData? >>>>>> >>>>>> Probably not necessary but there is nothing secret in it either. >>>>>> >>>>>> Simo. >>>>> >>>>> OK. I'm not a fan of hiding things from the admin, so no changes to the patch >>>>> are necessary here. >>>>> >>>> >>>> 536: >>>> As we are touching these ACIs, may it is a time to see the blacklist of >>>> attributes that admin cannot write and check if this is still wanted: >>>> >>>> ipaUniqueId - OK, generated by DS plugin >>>> memberOf - OK, generated by DS plugin >>>> serverHostName - I did not even find a place where we manipulate it, except >>>> host.py -> remove from blacklist? >> >> What about this one? > > not sure, I did not work much on the hosts objects. Rob? Do you know? >>>> enrolledBy - OK, generated by DS plugin >>>> krbExtraData - OK, generated by DS plugin >>>> krbPrincipalName - why can't admin change it? It is filled by framework, I >>>> would not personally blacklist it >>> >>> It is changed by the ipa rename plugin when the user uid change, that's >>> why we prevent the admin from explicitly change it. >>> >>>> krbCanonicalName - same as krbPrincipalName >> >> Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? > > They should be accessible by admin, yes. Note that we are now discussing write access. I.e. what attributes needs to stay in the admin's global write ACI blacklist and which can be removed -> admin can write in them. IIUC, these should be only readable by admin, not writeable. > >>>> krbPrincipalAliases - same as krbPrincipalName - we need this removed if we >>>> want to set aliases anyway >> >> Allow this one? > > This is one I wanted to eventually get rid of, Alexander seem to have > introduced it, but we discussed in the past of a way to kill it. > I forgot the details thouhg. > Alexander did we open a ticket for this ? Ok, we may eventually get rid of it, but does it need to be blacklisted in admins global write ACI? > >>>> krbPasswordExpiration - OK, generated by DS plugin >>>> krbLastPwdChange - OK, generated by DS plugin >>>> krbUPEnabled - not used, can we remove it? >> >> What about this one? > > We never use it. I read this as "remove it from global admin write ACI blacklist". > >>>> krbTicketPolicyReference - why cannot admin set it? >>> >>> Unclear why, probably should be able to. >> >> We may want to remove it from blacklist then. > > We never used it, but we should probably allow admin to modify Ok, let us remove it from global admin write ACI blacklist. > >>>> krbPwdPolicyReference - why cannot admin set it? >>> >>> We assign password policy based on groups now, right ? >> >> Yup. I see no complains, i.e. I read it as "remove it from global admin write ACI blacklist". >> >>> >>>> krbPrincipalType - why cannot admin set it? >>> >>> Unused. >> >> So... allow this one? > > we never use it so we do not need to allow admins by default. My point was to limit admin write ACI blacklist to the bare minimum. Only to attributes that really needs to be blacklisted as they are operated by DS plugins - like memberOf and others. My proposal is to remove it from global admin write ACI blacklist given it is not used. Martin From ssorce at redhat.com Thu Apr 24 15:15:26 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Apr 2014 11:15:26 -0400 Subject: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes In-Reply-To: <5359240F.6090408@redhat.com> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> <53590F27.3040601@redhat.com> <1398346957.2628.431.camel@willson.li.ssimo.org> <5359240F.6090408@redhat.com> Message-ID: <1398352526.2628.436.camel@willson.li.ssimo.org> On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: > On 04/24/2014 03:42 PM, Simo Sorce wrote: > > On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: > >> On 04/24/2014 02:28 PM, Simo Sorce wrote: > >>> On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: > >>>> On 04/24/2014 09:41 AM, Petr Viktorin wrote: > >>>>> On 04/23/2014 08:56 PM, Simo Sorce wrote: > >>>>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: > >>>>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, > >>>>>>> krbPrincipalName is provided by the anonymous read ACI, which will go > >>>>>>> away. This patch adds a blanket read ACI for these. > >>>>>>> I also moved some related ACIs to 20-aci.update. > >>>>>>> > >>>>>>> Previously krbPwdHistory was also readable by admins. I don't think we > >>>>>>> want to include that. > >>>>>>> Simo, should admins be allowed to read krbExtraData? > >>>>>> > >>>>>> Probably not necessary but there is nothing secret in it either. > >>>>>> > >>>>>> Simo. > >>>>> > >>>>> OK. I'm not a fan of hiding things from the admin, so no changes to the patch > >>>>> are necessary here. > >>>>> > >>>> > >>>> 536: > >>>> As we are touching these ACIs, may it is a time to see the blacklist of > >>>> attributes that admin cannot write and check if this is still wanted: > >>>> > >>>> ipaUniqueId - OK, generated by DS plugin > >>>> memberOf - OK, generated by DS plugin > >>>> serverHostName - I did not even find a place where we manipulate it, except > >>>> host.py -> remove from blacklist? > >> > >> What about this one? > > > > not sure, I did not work much on the hosts objects. > > Rob? Do you know? > > >>>> enrolledBy - OK, generated by DS plugin > >>>> krbExtraData - OK, generated by DS plugin > >>>> krbPrincipalName - why can't admin change it? It is filled by framework, I > >>>> would not personally blacklist it > >>> > >>> It is changed by the ipa rename plugin when the user uid change, that's > >>> why we prevent the admin from explicitly change it. > >>> > >>>> krbCanonicalName - same as krbPrincipalName > >> > >> Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? > > > > They should be accessible by admin, yes. > > Note that we are now discussing write access. I.e. what attributes needs to > stay in the admin's global write ACI blacklist and which can be removed -> > admin can write in them. > > IIUC, these should be only readable by admin, not writeable. > > > > >>>> krbPrincipalAliases - same as krbPrincipalName - we need this removed if we > >>>> want to set aliases anyway > >> > >> Allow this one? > > > > This is one I wanted to eventually get rid of, Alexander seem to have > > introduced it, but we discussed in the past of a way to kill it. > > I forgot the details thouhg. > > Alexander did we open a ticket for this ? > > Ok, we may eventually get rid of it, but does it need to be blacklisted in > admins global write ACI? > > > > >>>> krbPasswordExpiration - OK, generated by DS plugin > >>>> krbLastPwdChange - OK, generated by DS plugin > >>>> krbUPEnabled - not used, can we remove it? > >> > >> What about this one? > > > > We never use it. > > I read this as "remove it from global admin write ACI blacklist". > > > > >>>> krbTicketPolicyReference - why cannot admin set it? > >>> > >>> Unclear why, probably should be able to. > >> > >> We may want to remove it from blacklist then. > > > > We never used it, but we should probably allow admin to modify > > Ok, let us remove it from global admin write ACI blacklist. > > > > >>>> krbPwdPolicyReference - why cannot admin set it? > >>> > >>> We assign password policy based on groups now, right ? > >> > >> Yup. > > I see no complains, i.e. I read it as "remove it from global admin write ACI > blacklist". > > >> > >>> > >>>> krbPrincipalType - why cannot admin set it? > >>> > >>> Unused. > >> > >> So... allow this one? > > > > we never use it so we do not need to allow admins by default. > > My point was to limit admin write ACI blacklist to the bare minimum. Only to > attributes that really needs to be blacklisted as they are operated by DS > plugins - like memberOf and others. > > My proposal is to remove it from global admin write ACI blacklist given it is > not used. Ack, I agree with your intent. Simo. From rcritten at redhat.com Thu Apr 24 21:16:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Apr 2014 17:16:17 -0400 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <534E47A5.9030607@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> Message-ID: <53597F21.1060706@redhat.com> Jan Cholasta wrote: > On 10.4.2014 22:06, Rob Crittenden wrote: >> Some in-line, a whole ton of data appended to end. >> >> Jan Cholasta wrote: >>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> >>>>> 242 >>>>> >>>>> I wonder if it would be clearer to use variables instead of a raw list >>>>> in the return value for these handlers: (result, message) = >>>>> handler(...) >>>>> rather than examining result[0], etc. That may be beyond the scope of >>>>> this patch though. >>> >>> Yes. It would be nice if certmonger included a Python module for helper >>> scripts... >> >> Yes, but what I mean is the internal handling returns tuples of data >> with unique variable names, then plucks them out positionally. > > len(result) depends on result[0], so you can't do "result, message = > handler(...)", because it would blow up when len(result) != 2. OK. > >>>>> >>>>> 243 >>>>> >>>>> You are going to end up with a lot of acis with the same comment >>>>> value. >>>>> Perhaps add the host in there as well. >>>>> >>>>> These are not removed when a master is deleted. >>> >>> I merely did the same thing as the "Add CA Certificates for renewals" >>> and "Modify CA Certificates for renewals" ACIs. >>> >>> I agree it's suboptimal, but IMO it should be fixed in the scope of >>> (the "ipa masters >>> hostgroup" part). >> >> There is a replica_cleanup() method in replication.py. I don't know why >> this couldn't be added there. > > OK, added, see patch 263. But we should do the hostgroup thing anyway, > this solution sucks. I completely agree. > >>>>> >>>>> 247 >>>>> >>>>> We've been burned by hardcoded timeouts in the past. Should this be >>>>> configurable? This module doesn't currently do any logging but it >>>>> might >>>>> be worth spitting out a "waiting" message, at least for debugging. >>> >>> Added a timeout argument. >> >> Did you forget to send this one, I didn't see an update to 247. > > Are you sure you have 247.1 (now 247.2)? > > I can see at > > that I have sent the correct version of the patches. The call has a timeout, the callers don't use it. I guess it'll do for now, but these almost always come back to bite us. > >>>>> >>>>> 251 >>>>> >>>>> The tool should provide some feedback while it's running. For the >>>>> impatient (me) it takes a really long time and it's hard to know >>>>> what is >>>>> going on, something in between nothing and full debug output. >>> >>> Added some messages about what's going on. >> >> I dpn't see an update to 251 either. > > Please make sure you have 251.1 (now 251.2). There is a little bit more output but there are still very long periods of waiting between any visual activity, particularly when doing it on an IPA self-signed CA. > >> >>>>> >>>>> The man page needs some more work too. I think some more >>>>> explanation is >>>>> needed and an example would probably be really helpful as well. I >>>>> think >>>>> particularly an example for external certs and a description of what >>>>> you >>>>> mean by Self-signed CA (I assume you mean IPA-provided). I don't think >>>>> it really matters how many steps there are unless you are going to >>>>> provide progress output. >>> >>> Reworded the man page a little bit. >>> >>>>> >>>>> Got a backtrace when running as non-root: >>>>> >>>>> $ ipa-cacert-manage -v renew >>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >>>>> 168, in >>>>> execute >>>>> self.validate_options() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>>>> >>>>> >>>>> >>>>> >>>>> line 62, in validate_options >>>>> super(CACertManage, self).validate_options(needs_root=True) >>>>> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", >>>>> line >>>>> 189, in validate_options >>>>> raise ScriptError('Must be root to run %s' % >>>>> self.command_name, 1) >>>>> >>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >>>>> ipa-cacert-manage command failed, exception: ScriptError: Must be root >>>>> to run ipa-cacert-manage >>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be >>>>> root to run ipa-cacert-manage >>> >>> That's correct, you can run it only as root, because you can't resubmit >>> certmonger requests as a regular user. >> >> Yes but one shouldn't get a traceback! > > You get the traceback only in verbose mode. I did not invent this, it's > how ipapython.admintool does things. Ok, I'll blame Petr. >>>> >>>> After moving time forward on the replica these certificates are in >>>> CA_WORKING: >>>> >>>> ipaCert >>>> auditSigningCert cert-pki-ca >>>> ocspSigningCert cert-pki-ca >>>> subsystemCert cert-pki-ca >>>> >>>> cn=ca_renewal is completely empty on the replica. On the master it only >>>> has the subsystemCert. I'm guessing this is at least partly due to my >>>> switching time one system at a time rather than (somewhat) >>>> simultaneously, but it still would have blown up with 3 missing certs. >>> >>> Can you post the related log messages from /var/log/messages from the >>> master somewhere? >>> >>> There's not much I can do about broken replication. I think you hit >>> . >>> >>>> >>>> rob >>> >>> Thanks for the review. >>> >>> Updated and rebased patches attached. >>> >> >> Patch 262 has lots of lint errors because you're adding arguments to >> functions that don't currently define one, is_renewal_master() for >> example. > > They are defined in patch 246.1 (now 246.2). > >> >> I think the ipa-cacert-manage man page is missing one really important >> piece: why would you ever need to run this? And when? > > Added a paragraph about this. It's better, couple of comments: Add "the" in between renew and CA in "used to manually renew CA certificate of" and "When IPA CA...". I haven't had any luck renewing the CA certificate yet. I see that it is tracked now. I started moving the system clock forward in order to get to renewal and about the 3rd iteration the requests started failing with an XML error. Did you see this? [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most recent call last): [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 344, in wsgi_execute [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = self.Command[name](*args, **options) [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 382, in execute [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = api.Command['cert_show'](unicode(serial))['result'] [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 514, in execute [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] result=self.Backend.ra.get_certificate(serial_number) [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1502, in get_certificate [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result = self.get_parse_result_xml(http_body, parse_display_cert_xml) [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1363, in get_parse_result_xml [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = etree.fromstring(xml_text, parser) [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File "lxml.etree.pyx", line 3032, in lxml.etree.fromstring (src/lxml/lxml.etree.c:68129) [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:102493) [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File "parser.pxi", line 1673, in lxml.etree._parseDoc (src/lxml/lxml.etree.c:101322) [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc (src/lxml/lxml.etree.c:96504) [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File "parser.pxi", line 582, in lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:91308) [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File "parser.pxi", line 683, in lxml.etree._handleParseResult (src/lxml/lxml.etree.c:92494) [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File "parser.pxi", line 633, in lxml.etree._raiseParseError (src/lxml/lxml.etree.c:91957) [Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] XMLSyntaxError: None [Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: [xmlserver] host/lyra.greyoak.com at GREYOAK.COM: cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/Wm8VPZgm! 3VCtgMvPVk 3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, version=u'2.51'): XMLSyntaxError I noticed that in the external CA case we still have certmonger tracking the CA. What will it do at expiration? >> I updated selinux-policy but I'm not seeing the certs added consistently >> to ca_renewal so there is nothing to do, so it sits in CA_WORKING. I >> verified it isn't a replication issue, the replication is working fine, >> the certs just weren't pushed. > > Fixed renewal scripts not to use ldapi, see patch 264. Renewal in the self-signed case is working a lot smoother now. > Also fixed certificate retrieval from LDAP to check if the certificate > was actually renewed, see patch 265. /etc/ipa/ca.crt isn't being updated on renewal. rob From dpal at redhat.com Thu Apr 24 21:21:00 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 24 Apr 2014 17:21:00 -0400 Subject: [Freeipa-devel] First beta release of ConnID FreeIPA connector In-Reply-To: <5359187D.2090208@tirasa.net> References: <5359187D.2090208@tirasa.net> Message-ID: <5359803C.60906@redhat.com> On 04/24/2014 09:58 AM, Massimiliano Perrone (tirasa.net) wrote: > Hi guys, > this mail only to share with you that ConnID FreeIPA connector (beta > version) is released. > > You can find more informations here [1] > > Massimiliano > > [1] http://blog.tirasa.net/unlock-full-freeipa-features.html > Cool! It might make sense to put something on the IPA wiki to have a cross reference. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From pviktori at redhat.com Fri Apr 25 07:10:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Apr 2014 09:10:26 +0200 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <53597F21.1060706@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> Message-ID: <535A0A62.9020807@redhat.com> On 04/24/2014 11:16 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 10.4.2014 22:06, Rob Crittenden wrote: >>> Some in-line, a whole ton of data appended to end. >>> >>> Jan Cholasta wrote: >>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: [...] >>>>>> $ ipa-cacert-manage -v renew >>>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >>>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >>>>>> 168, in >>>>>> execute >>>>>> self.validate_options() >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> line 62, in validate_options >>>>>> super(CACertManage, self).validate_options(needs_root=True) >>>>>> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", >>>>>> line >>>>>> 189, in validate_options >>>>>> raise ScriptError('Must be root to run %s' % >>>>>> self.command_name, 1) >>>>>> >>>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >>>>>> ipa-cacert-manage command failed, exception: ScriptError: Must be >>>>>> root >>>>>> to run ipa-cacert-manage >>>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be >>>>>> root to run ipa-cacert-manage >>>> >>>> That's correct, you can run it only as root, because you can't resubmit >>>> certmonger requests as a regular user. >>> >>> Yes but one shouldn't get a traceback! >> >> You get the traceback only in verbose mode. I did not invent this, it's >> how ipapython.admintool does things. > > Ok, I'll blame Petr. In verbose mode you get all the debugging information that's written to logs, and that includes the tracebacks. I stand by this decision. If the command is normally so quiet that you need the -v flag for normal operation, that's a problem. Log interesting messages at INFO. http://www.freeipa.org/page/V3/Logging_and_output#Design -- Petr? From mkosek at redhat.com Fri Apr 25 07:50:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Apr 2014 09:50:55 +0200 Subject: [Freeipa-devel] First beta release of ConnID FreeIPA connector In-Reply-To: <5359803C.60906@redhat.com> References: <5359187D.2090208@tirasa.net> <5359803C.60906@redhat.com> Message-ID: <535A13DF.7020901@redhat.com> On 04/24/2014 11:21 PM, Dmitri Pal wrote: > On 04/24/2014 09:58 AM, Massimiliano Perrone (tirasa.net) wrote: >> Hi guys, >> this mail only to share with you that ConnID FreeIPA connector (beta version) >> is released. >> >> You can find more informations here [1] >> >> Massimiliano >> >> [1] http://blog.tirasa.net/unlock-full-freeipa-features.html >> > Cool! > It might make sense to put something on the IPA wiki to have a cross reference. +1. For starters, I at least added link to our HOW TOs: http://www.freeipa.org/page/HowTos#Interoperability_with_other_systems Martin From jcholast at redhat.com Fri Apr 25 08:51:50 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 25 Apr 2014 10:51:50 +0200 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <53597F21.1060706@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> Message-ID: <535A2226.6080803@redhat.com> On 24.4.2014 23:16, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 10.4.2014 22:06, Rob Crittenden wrote: >>> Some in-line, a whole ton of data appended to end. >>> >>> Jan Cholasta wrote: >>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> >>>>>> 247 >>>>>> >>>>>> We've been burned by hardcoded timeouts in the past. Should this be >>>>>> configurable? This module doesn't currently do any logging but it >>>>>> might >>>>>> be worth spitting out a "waiting" message, at least for debugging. >>>> >>>> Added a timeout argument. >>> >>> Did you forget to send this one, I didn't see an update to 247. >> >> Are you sure you have 247.1 (now 247.2)? >> >> I can see at >> >> that I have sent the correct version of the patches. > > The call has a timeout, the callers don't use it. I guess it'll do for > now, but these almost always come back to bite us. Well, I can add --certmonger-timeout option to ipa-cacert-manage, if that's what you want. > >> >>>>>> >>>>>> 251 >>>>>> >>>>>> The tool should provide some feedback while it's running. For the >>>>>> impatient (me) it takes a really long time and it's hard to know >>>>>> what is >>>>>> going on, something in between nothing and full debug output. >>>> >>>> Added some messages about what's going on. >>> >>> I dpn't see an update to 251 either. >> >> Please make sure you have 251.1 (now 251.2). > > There is a little bit more output but there are still very long periods > of waiting between any visual activity, particularly when doing it on an > IPA self-signed CA. This stuff takes time :-) What would you like to see in the output, that's not already there? >>> >>> I think the ipa-cacert-manage man page is missing one really important >>> piece: why would you ever need to run this? And when? >> >> Added a paragraph about this. > > It's better, couple of comments: > > Add "the" in between renew and CA in "used to manually renew CA > certificate of" and "When IPA CA...". OK. > I haven't had any luck renewing > the CA certificate yet. I see that it is tracked now. I started moving > the system clock forward in order to get to renewal and about the 3rd > iteration the requests started failing with an XML error. Did you see this? > > [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most > recent call last): > [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 344, in > wsgi_execute > [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = > self.Command[name](*args, **options) > [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in > __call__ > [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = > self.run(*args, **options) > [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run > [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = > self.execute(*args, **options) > [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 382, in > execute > [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = > api.Command['cert_show'](unicode(serial))['result'] > [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in > __call__ > [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = > self.run(*args, **options) > [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run > [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = > self.execute(*args, **options) > [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 514, in > execute > [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] > result=self.Backend.ra.get_certificate(serial_number) > [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line > 1502, in get_certificate > [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result > = self.get_parse_result_xml(http_body, parse_display_cert_xml) > [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File > "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line > 1363, in get_parse_result_xml > [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = > etree.fromstring(xml_text, parser) > [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File > "lxml.etree.pyx", line 3032, in lxml.etree.fromstring > (src/lxml/lxml.etree.c:68129) > [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File > "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument > (src/lxml/lxml.etree.c:102493) > [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File > "parser.pxi", line 1673, in lxml.etree._parseDoc > (src/lxml/lxml.etree.c:101322) > [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File > "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc > (src/lxml/lxml.etree.c:96504) > [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File > "parser.pxi", line 582, in > lxml.etree._ParserContext._handleParseResultDoc > (src/lxml/lxml.etree.c:91308) > [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File > "parser.pxi", line 683, in lxml.etree._handleParseResult > (src/lxml/lxml.etree.c:92494) > [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File > "parser.pxi", line 633, in lxml.etree._raiseParseError > (src/lxml/lxml.etree.c:91957) > [Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] XMLSyntaxError: None > [Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: > [xmlserver] host/lyra.greyoak.com at GREYOAK.COM: > cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/Wm8VPZ! gm! > > 3VCtgMvPVk > 3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', > principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, > version=u'2.51'): XMLSyntaxError I have never seen this. The error message does not say much... Is there anything interesting in other logs? > > I noticed that in the external CA case we still have certmonger tracking > the CA. What will it do at expiration? It syslogs the message in patch 252, for the lack of better notification mechanism. > > /etc/ipa/ca.crt isn't being updated on renewal. That will be dealt with in the next batch of patches. > > rob -- Jan Cholasta From jcholast at redhat.com Fri Apr 25 09:08:43 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 25 Apr 2014 11:08:43 +0200 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <53565345.2080407@redhat.com> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> Message-ID: <535A261B.9080906@redhat.com> On 22.4.2014 13:32, Tomas Babej wrote: > Thank you for the suggestions. Updated, rebased patch is attached. > This API.txt change from the next patch belongs in this patch: +capability: datetime_values 2.84 I think you should use the LDAP_GENERALIZED_TIME_FORMAT constant here: + accepted_formats = ['%Y%m%d%H%M%SZ', # generalized time This is not right: + elif isinstance(val, datetime.datetime): + return val To actually decode LDAP generalized time attributes to datetime, you need to do this: '2.16.840.1.113719.1.301.4.41.1' : DN, # krbSubTrees '2.16.840.1.113719.1.301.4.52.1' : DN, # krbObjectReferences '2.16.840.1.113719.1.301.4.53.1' : DN, # krbPrincContainerRef + + '1.3.6.1.4.1.1466.115.121.1.24' : datetime.datetime, } # In most cases we lookup the syntax from the schema returned by and this: return val elif target_type is unicode: return val.decode('utf-8') + elif target_type is datetime.datetime: + return datetime.datetime.strptime(val, LDAP_GENERALIZED_TIME_FORMAT) else: return target_type(val) except Exception, e: and add code for formatting datetime values to the textui backend. -- Jan Cholasta From jcholast at redhat.com Fri Apr 25 09:10:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 25 Apr 2014 11:10:21 +0200 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <535653C3.7040406@redhat.com> References: <52CEC0C9.70905@redhat.com> <530C478E.4080307@redhat.com> <53171423.8030204@redhat.com> <535653C3.7040406@redhat.com> Message-ID: <535A267D.9070106@redhat.com> On 22.4.2014 13:34, Tomas Babej wrote: > Updated, rebased patch attached. > This API.txt change belongs in the previous patch: +capability: datetime_values 2.84 -- Jan Cholasta From pviktori at redhat.com Fri Apr 25 11:01:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Apr 2014 13:01:17 +0200 Subject: [Freeipa-devel] [PATCH] 0538 aci-update: Trim the admin write blacklist In-Reply-To: <1398352526.2628.436.camel@willson.li.ssimo.org> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> <53590F27.3040601@redhat.com> <1398346957.2628.431.camel@willson.li.ssimo.org> <5359240F.6090408@redhat.com> <1398352526.2628.436.camel@willson.li.ssimo.org> Message-ID: <535A407D.4070709@redhat.com> On 04/24/2014 05:15 PM, Simo Sorce wrote: > On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: >> On 04/24/2014 03:42 PM, Simo Sorce wrote: >>> On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: >>>> On 04/24/2014 02:28 PM, Simo Sorce wrote: >>>>> On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: >>>>>> On 04/24/2014 09:41 AM, Petr Viktorin wrote: >>>>>>> On 04/23/2014 08:56 PM, Simo Sorce wrote: >>>>>>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >>>>>>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, >>>>>>>>> krbPrincipalName is provided by the anonymous read ACI, which will go >>>>>>>>> away. This patch adds a blanket read ACI for these. >>>>>>>>> I also moved some related ACIs to 20-aci.update. >>>>>>>>> >>>>>>>>> Previously krbPwdHistory was also readable by admins. I don't think we >>>>>>>>> want to include that. >>>>>>>>> Simo, should admins be allowed to read krbExtraData? >>>>>>>> >>>>>>>> Probably not necessary but there is nothing secret in it either. >>>>>>>> >>>>>>>> Simo. >>>>>>> >>>>>>> OK. I'm not a fan of hiding things from the admin, so no changes to the patch >>>>>>> are necessary here. >>>>>>> >>>>>> >>>>>> 536: >>>>>> As we are touching these ACIs, may it is a time to see the blacklist of >>>>>> attributes that admin cannot write and check if this is still wanted: >>>>>> >>>>>> ipaUniqueId - OK, generated by DS plugin >>>>>> memberOf - OK, generated by DS plugin >>>>>> serverHostName - I did not even find a place where we manipulate it, except >>>>>> host.py -> remove from blacklist? >>>> >>>> What about this one? >>> >>> not sure, I did not work much on the hosts objects. >> >> Rob? Do you know? >> >>>>>> enrolledBy - OK, generated by DS plugin >>>>>> krbExtraData - OK, generated by DS plugin >>>>>> krbPrincipalName - why can't admin change it? It is filled by framework, I >>>>>> would not personally blacklist it >>>>> >>>>> It is changed by the ipa rename plugin when the user uid change, that's >>>>> why we prevent the admin from explicitly change it. >>>>> >>>>>> krbCanonicalName - same as krbPrincipalName >>>> >>>> Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? >>> >>> They should be accessible by admin, yes. >> >> Note that we are now discussing write access. I.e. what attributes needs to >> stay in the admin's global write ACI blacklist and which can be removed -> >> admin can write in them. >> >> IIUC, these should be only readable by admin, not writeable. >> >>> >>>>>> krbPrincipalAliases - same as krbPrincipalName - we need this removed if we >>>>>> want to set aliases anyway >>>> >>>> Allow this one? >>> >>> This is one I wanted to eventually get rid of, Alexander seem to have >>> introduced it, but we discussed in the past of a way to kill it. >>> I forgot the details thouhg. >>> Alexander did we open a ticket for this ? >> >> Ok, we may eventually get rid of it, but does it need to be blacklisted in >> admins global write ACI? >> >>> >>>>>> krbPasswordExpiration - OK, generated by DS plugin >>>>>> krbLastPwdChange - OK, generated by DS plugin >>>>>> krbUPEnabled - not used, can we remove it? >>>> >>>> What about this one? >>> >>> We never use it. >> >> I read this as "remove it from global admin write ACI blacklist". >> >>> >>>>>> krbTicketPolicyReference - why cannot admin set it? >>>>> >>>>> Unclear why, probably should be able to. >>>> >>>> We may want to remove it from blacklist then. >>> >>> We never used it, but we should probably allow admin to modify >> >> Ok, let us remove it from global admin write ACI blacklist. >> >>> >>>>>> krbPwdPolicyReference - why cannot admin set it? >>>>> >>>>> We assign password policy based on groups now, right ? >>>> >>>> Yup. >> >> I see no complains, i.e. I read it as "remove it from global admin write ACI >> blacklist". >> >>>> >>>>> >>>>>> krbPrincipalType - why cannot admin set it? >>>>> >>>>> Unused. >>>> >>>> So... allow this one? >>> >>> we never use it so we do not need to allow admins by default. >> >> My point was to limit admin write ACI blacklist to the bare minimum. Only to >> attributes that really needs to be blacklisted as they are operated by DS >> plugins - like memberOf and others. >> >> My proposal is to remove it from global admin write ACI blacklist given it is >> not used. > > Ack, I agree with your intent. > > Simo. > If I understand correctly, we want to allow: - krbPrincipalAliases - krbPrincipalType - krbPwdPolicyReference - krbTicketPolicyReference - krbUPEnabled - serverHostName Here is the patch for that. Martin, just to make sure: 0536-0537 are good to push, right? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0538-aci-update-Trim-the-admin-write-blacklist.patch Type: text/x-patch Size: 5153 bytes Desc: not available URL: From amisnyov at redhat.com Fri Apr 25 11:06:46 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 25 Apr 2014 13:06:46 +0200 Subject: [Freeipa-devel] [PATCH] 16-17 Attribute box in permission UI is too small Message-ID: <20140425130646.62310f4f@unused-4-246.brq.redhat.com> Hi, first patch redesigns attribute box in permission forms, making it a bigger scrollable checkboxlist. Second one adds a filter field to it for better user experience, if the checkboxlist would be too large. Also, webui unit tests for rbac are updated to work properly with the new widget. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0016-Attribute-box-in-permission-UI-is-too-small.patch Type: text/x-patch Size: 5451 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0017-Add-filter-to-attribute-box.patch Type: text/x-patch Size: 4061 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 25 11:08:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Apr 2014 13:08:28 +0200 Subject: [Freeipa-devel] [PATCH] 0538 aci-update: Trim the admin write blacklist In-Reply-To: <535A407D.4070709@redhat.com> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> <53590F27.3040601@redhat.com> <1398346957.2628.431.camel@willson.li.ssimo.org> <5359240F.6090408@redhat.com> <1398352526.2628.436.camel@willson.li.ssimo.org> <535A407D.4070709@redhat.com> Message-ID: <535A422C.9030002@redhat.com> On 04/25/2014 01:01 PM, Petr Viktorin wrote: > On 04/24/2014 05:15 PM, Simo Sorce wrote: >> On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: >>> On 04/24/2014 03:42 PM, Simo Sorce wrote: >>>> On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: >>>>> On 04/24/2014 02:28 PM, Simo Sorce wrote: >>>>>> On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: >>>>>>> On 04/24/2014 09:41 AM, Petr Viktorin wrote: >>>>>>>> On 04/23/2014 08:56 PM, Simo Sorce wrote: >>>>>>>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >>>>>>>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, >>>>>>>>>> krbPrincipalName is provided by the anonymous read ACI, which will go >>>>>>>>>> away. This patch adds a blanket read ACI for these. >>>>>>>>>> I also moved some related ACIs to 20-aci.update. >>>>>>>>>> >>>>>>>>>> Previously krbPwdHistory was also readable by admins. I don't think we >>>>>>>>>> want to include that. >>>>>>>>>> Simo, should admins be allowed to read krbExtraData? >>>>>>>>> >>>>>>>>> Probably not necessary but there is nothing secret in it either. >>>>>>>>> >>>>>>>>> Simo. >>>>>>>> >>>>>>>> OK. I'm not a fan of hiding things from the admin, so no changes to the >>>>>>>> patch >>>>>>>> are necessary here. >>>>>>>> >>>>>>> >>>>>>> 536: >>>>>>> As we are touching these ACIs, may it is a time to see the blacklist of >>>>>>> attributes that admin cannot write and check if this is still wanted: >>>>>>> >>>>>>> ipaUniqueId - OK, generated by DS plugin >>>>>>> memberOf - OK, generated by DS plugin >>>>>>> serverHostName - I did not even find a place where we manipulate it, except >>>>>>> host.py -> remove from blacklist? >>>>> >>>>> What about this one? >>>> >>>> not sure, I did not work much on the hosts objects. >>> >>> Rob? Do you know? >>> >>>>>>> enrolledBy - OK, generated by DS plugin >>>>>>> krbExtraData - OK, generated by DS plugin >>>>>>> krbPrincipalName - why can't admin change it? It is filled by framework, I >>>>>>> would not personally blacklist it >>>>>> >>>>>> It is changed by the ipa rename plugin when the user uid change, that's >>>>>> why we prevent the admin from explicitly change it. >>>>>> >>>>>>> krbCanonicalName - same as krbPrincipalName >>>>> >>>>> Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? >>>> >>>> They should be accessible by admin, yes. >>> >>> Note that we are now discussing write access. I.e. what attributes needs to >>> stay in the admin's global write ACI blacklist and which can be removed -> >>> admin can write in them. >>> >>> IIUC, these should be only readable by admin, not writeable. >>> >>>> >>>>>>> krbPrincipalAliases - same as krbPrincipalName - we need this removed if we >>>>>>> want to set aliases anyway >>>>> >>>>> Allow this one? >>>> >>>> This is one I wanted to eventually get rid of, Alexander seem to have >>>> introduced it, but we discussed in the past of a way to kill it. >>>> I forgot the details thouhg. >>>> Alexander did we open a ticket for this ? >>> >>> Ok, we may eventually get rid of it, but does it need to be blacklisted in >>> admins global write ACI? >>> >>>> >>>>>>> krbPasswordExpiration - OK, generated by DS plugin >>>>>>> krbLastPwdChange - OK, generated by DS plugin >>>>>>> krbUPEnabled - not used, can we remove it? >>>>> >>>>> What about this one? >>>> >>>> We never use it. >>> >>> I read this as "remove it from global admin write ACI blacklist". >>> >>>> >>>>>>> krbTicketPolicyReference - why cannot admin set it? >>>>>> >>>>>> Unclear why, probably should be able to. >>>>> >>>>> We may want to remove it from blacklist then. >>>> >>>> We never used it, but we should probably allow admin to modify >>> >>> Ok, let us remove it from global admin write ACI blacklist. >>> >>>> >>>>>>> krbPwdPolicyReference - why cannot admin set it? >>>>>> >>>>>> We assign password policy based on groups now, right ? >>>>> >>>>> Yup. >>> >>> I see no complains, i.e. I read it as "remove it from global admin write ACI >>> blacklist". >>> >>>>> >>>>>> >>>>>>> krbPrincipalType - why cannot admin set it? >>>>>> >>>>>> Unused. >>>>> >>>>> So... allow this one? >>>> >>>> we never use it so we do not need to allow admins by default. >>> >>> My point was to limit admin write ACI blacklist to the bare minimum. Only to >>> attributes that really needs to be blacklisted as they are operated by DS >>> plugins - like memberOf and others. >>> >>> My proposal is to remove it from global admin write ACI blacklist given it is >>> not used. >> >> Ack, I agree with your intent. >> >> Simo. >> > > If I understand correctly, we want to allow: > - krbPrincipalAliases > - krbPrincipalType > - krbPwdPolicyReference > - krbTicketPolicyReference > - krbUPEnabled > - serverHostName > > Here is the patch for that. The list looks good to me. > Martin, just to make sure: 0536-0537 are good to push, right? One of the reasons why I wanted to prune the blacklist a bit was to make the Admin read ACI (Admin read-only attributes) simpler (read - shorter). So please also update this aci in 536. IMO, 536 and 538 can be squashed, but that's up to you. Martin From pviktori at redhat.com Fri Apr 25 11:08:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Apr 2014 13:08:52 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <5357B612.30805@redhat.com> References: <534E7DCF.9080205@redhat.com> <1397653275.19767.386.camel@willson.li.ssimo.org> <20140416131529.GL20958@redhat.com> <1397655756.19767.396.camel@willson.li.ssimo.org> <20140416135954.GM20958@redhat.com> <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> <20140416153414.GP20958@redhat.com> <1397663792.19767.401.camel@willson.li.ssimo.org> <535654C4.5060303@redhat.com> <5357B612.30805@redhat.com> Message-ID: <535A4244.30405@redhat.com> On 04/23/2014 02:46 PM, Martin Kosek wrote: > On 04/22/2014 01:38 PM, Petr Viktorin wrote: >> On 04/16/2014 05:56 PM, Simo Sorce wrote: >>> On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: >>>> On Wed, 16 Apr 2014, Martin Kosek wrote: >>>>>>>>>>>>> In general I am not sure all authenticated users need access to all >>>>>>>>>>>>> this >>>>>>>>>>>>> info. Alexander ? >>>>>>>>>>>> SSSD needs to read some of this information for subdomains support. >>>>>>>>>>>> That would be at least host/*@REALM who needs to access it. >>>>>>>>>>> >>>>>>>>>>> Can you please list exactly which ones are needed ? >>>>>>>>>> SSSD subdomains support needs: >>>>>>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>>>>>>> - ipaNTFlatName >>>>>>>>>> - ipaNTSecurityIdentifier >>>>>>>>>> - ipaNTTrustedDomainSID >>>>>>>>>> - cn >>>>>>>>> >>>>>>>>> Question is - is there any added value in hiding part of the >>>>>>>>> trust information from authenticated users? I.e. attributes like >>>>>>>>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>>>>>>>> attribute anyway?), SID blacklists... >>>>>>>> Yes. Some of those attributes are needed as internal detail of ipasam -- >>>>>>>> part of how Samba stores this information taken from specific DCE RPC >>>>>>>> structures. >>>>>>>> >>>>>>>>> If yes, we would need to split this permission in 2 and have one for >>>>>>>>> authenticated users and one for "Trust Adminitrators" and "Trust Readers". >>>>>>>> Yes. Authenticated users shouldn't get any access to those details: >>>>>>>> ipantsupportedencryptiontypes >>>>>>>> ipanttrustattributes >>>>>>>> ipanttrustauthincoming >>>>>>>> ipanttrustauthoutgoing >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group >>>>>>> should >>>>>>> then have this permission assigned so that samba can operate the attributes. >>>>>> 'adtrust agents' and 'trust administrators' should have read, modify, >>>>>> delete, and search on cn=trusts. >>>>>> >>>>> >>>>> Right. We will probably want to turn most of ACIs in >>>>> install/updates/60-trusts.update in managed permissions (i.e. defined in >>>>> trust.py) and make "adtrust agents" and "trust admins" it's members. >>>> I agree. >>>> >>> >>> +1 >>> >>> Simo. >>> >> >> All right. Now I'm replacing the global anonymous read ACI; converting the >> others will come later. The existing agents/admins ACIs grant the 'read' (or >> 'all') right already. >> ipaIDRange is covered in the range plugin, so what's left for this patch is the >> ipaNTTrustedDomain/ipaNTDomainAttrs attributes. >> >> Does that sound reasonable? > > This is all that's needed from SSSD side, I just verified in sssd git. sssd > indeed only uses these attributes: > > #define IPA_CN "cn" > #define IPA_FLATNAME "ipaNTFlatName" > #define IPA_SID "ipaNTSecurityIdentifier" > #define IPA_TRUSTED_DOMAIN_SID "ipaNTTrustedDomainSID" > > So I am OK with the patch as is. > > However, with this ACI, regular users will not be able to show Trusts with > command line even though they have access to the basic information: > > # ipa trust-find > ---------------- > 0 trusts matched > ---------------- > ---------------------------- > Number of entries returned 0 > ---------------------------- > > IMO trust command should be able to return the information that the user is > allowed to see. I prepared a patch to make the read part of trust.py more > resilient to missing attributes. Attached. > > With this patch enabled, I have this output as regular user: > > # ipa trust-find > --------------- > 1 trust matched > --------------- > Realm name: tbad.example.com > Domain NetBIOS name: TBAD > Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 > ---------------------------- > Number of entries returned 1 > ---------------------------- > # ipa trust-show tbad.example.com > Realm name: tbad.example.com > Domain NetBIOS name: TBAD > Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 > > # ipa trustdomain-find tbad.example.com > Domain name: child.tbad.example.com > Domain NetBIOS name: CHILD > Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 > > Domain name: tbad.example.com > Domain NetBIOS name: TBAD > Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 > ---------------------------- > Number of entries returned 2 > ---------------------------- > > The only bigger change I did was to filter trust root domains by > ipaNTSecurityIdentifier and not ipaNTSIDBlacklistIncoming which is not > available to everyone. > > Martin > The patch looks good to me, but I think Alexander is better qualified to review it. -- Petr? From pviktori at redhat.com Fri Apr 25 11:29:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Apr 2014 13:29:32 +0200 Subject: [Freeipa-devel] [PATCH] 0537-0539 aci-update: Trim the admin write blacklist & Add ACI for read-only admin attributes In-Reply-To: <535A422C.9030002@redhat.com> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> <53590F27.3040601@redhat.com> <1398346957.2628.431.camel@willson.li.ssimo.org> <5359240F.6090408@redhat.com> <1398352526.2628.436.camel@willson.li.ssimo.org> <535A407D.4070709@redhat.com> <535A422C.9030002@redhat.com> Message-ID: <535A471C.60200@redhat.com> On 04/25/2014 01:08 PM, Martin Kosek wrote: > On 04/25/2014 01:01 PM, Petr Viktorin wrote: >> On 04/24/2014 05:15 PM, Simo Sorce wrote: >>> On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: >>>> On 04/24/2014 03:42 PM, Simo Sorce wrote: >>>>> On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: >>>>>> On 04/24/2014 02:28 PM, Simo Sorce wrote: >>>>>>> On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: >>>>>>>> On 04/24/2014 09:41 AM, Petr Viktorin wrote: >>>>>>>>> On 04/23/2014 08:56 PM, Simo Sorce wrote: >>>>>>>>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >>>>>>>>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, >>>>>>>>>>> krbPrincipalName is provided by the anonymous read ACI, which will go >>>>>>>>>>> away. This patch adds a blanket read ACI for these. >>>>>>>>>>> I also moved some related ACIs to 20-aci.update. >>>>>>>>>>> >>>>>>>>>>> Previously krbPwdHistory was also readable by admins. I don't think we >>>>>>>>>>> want to include that. >>>>>>>>>>> Simo, should admins be allowed to read krbExtraData? >>>>>>>>>> >>>>>>>>>> Probably not necessary but there is nothing secret in it either. >>>>>>>>>> >>>>>>>>>> Simo. >>>>>>>>> >>>>>>>>> OK. I'm not a fan of hiding things from the admin, so no changes to the >>>>>>>>> patch >>>>>>>>> are necessary here. >>>>>>>>> >>>>>>>> >>>>>>>> 536: >>>>>>>> As we are touching these ACIs, may it is a time to see the blacklist of >>>>>>>> attributes that admin cannot write and check if this is still wanted: >>>>>>>> >>>>>>>> ipaUniqueId - OK, generated by DS plugin >>>>>>>> memberOf - OK, generated by DS plugin >>>>>>>> serverHostName - I did not even find a place where we manipulate it, except >>>>>>>> host.py -> remove from blacklist? >>>>>> >>>>>> What about this one? >>>>> >>>>> not sure, I did not work much on the hosts objects. >>>> >>>> Rob? Do you know? >>>> >>>>>>>> enrolledBy - OK, generated by DS plugin >>>>>>>> krbExtraData - OK, generated by DS plugin >>>>>>>> krbPrincipalName - why can't admin change it? It is filled by framework, I >>>>>>>> would not personally blacklist it >>>>>>> >>>>>>> It is changed by the ipa rename plugin when the user uid change, that's >>>>>>> why we prevent the admin from explicitly change it. >>>>>>> >>>>>>>> krbCanonicalName - same as krbPrincipalName >>>>>> >>>>>> Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? >>>>> >>>>> They should be accessible by admin, yes. >>>> >>>> Note that we are now discussing write access. I.e. what attributes needs to >>>> stay in the admin's global write ACI blacklist and which can be removed -> >>>> admin can write in them. >>>> >>>> IIUC, these should be only readable by admin, not writeable. >>>> >>>>> >>>>>>>> krbPrincipalAliases - same as krbPrincipalName - we need this removed if we >>>>>>>> want to set aliases anyway >>>>>> >>>>>> Allow this one? >>>>> >>>>> This is one I wanted to eventually get rid of, Alexander seem to have >>>>> introduced it, but we discussed in the past of a way to kill it. >>>>> I forgot the details thouhg. >>>>> Alexander did we open a ticket for this ? >>>> >>>> Ok, we may eventually get rid of it, but does it need to be blacklisted in >>>> admins global write ACI? >>>> >>>>> >>>>>>>> krbPasswordExpiration - OK, generated by DS plugin >>>>>>>> krbLastPwdChange - OK, generated by DS plugin >>>>>>>> krbUPEnabled - not used, can we remove it? >>>>>> >>>>>> What about this one? >>>>> >>>>> We never use it. >>>> >>>> I read this as "remove it from global admin write ACI blacklist". >>>> >>>>> >>>>>>>> krbTicketPolicyReference - why cannot admin set it? >>>>>>> >>>>>>> Unclear why, probably should be able to. >>>>>> >>>>>> We may want to remove it from blacklist then. >>>>> >>>>> We never used it, but we should probably allow admin to modify >>>> >>>> Ok, let us remove it from global admin write ACI blacklist. >>>> >>>>> >>>>>>>> krbPwdPolicyReference - why cannot admin set it? >>>>>>> >>>>>>> We assign password policy based on groups now, right ? >>>>>> >>>>>> Yup. >>>> >>>> I see no complains, i.e. I read it as "remove it from global admin write ACI >>>> blacklist". >>>> >>>>>> >>>>>>> >>>>>>>> krbPrincipalType - why cannot admin set it? >>>>>>> >>>>>>> Unused. >>>>>> >>>>>> So... allow this one? >>>>> >>>>> we never use it so we do not need to allow admins by default. >>>> >>>> My point was to limit admin write ACI blacklist to the bare minimum. Only to >>>> attributes that really needs to be blacklisted as they are operated by DS >>>> plugins - like memberOf and others. >>>> >>>> My proposal is to remove it from global admin write ACI blacklist given it is >>>> not used. >>> >>> Ack, I agree with your intent. >>> >>> Simo. >>> >> >> If I understand correctly, we want to allow: >> - krbPrincipalAliases >> - krbPrincipalType >> - krbPwdPolicyReference >> - krbTicketPolicyReference >> - krbUPEnabled >> - serverHostName >> >> Here is the patch for that. > > The list looks good to me. > >> Martin, just to make sure: 0536-0537 are good to push, right? > > One of the reasons why I wanted to prune the blacklist a bit was to make the > Admin read ACI (Admin read-only attributes) simpler (read - shorter). So please > also update this aci in 536. Ah, right. > IMO, 536 and 538 can be squashed, but that's up to you. I tried, but I couldn't get the commit message to not read like two unrelated changes, which to me is a clear sign they shouldn't be squashed. (I thought about also split moving the ACIs and the modifications, but maybe that'd be too purist.) I renumbered 0536 to 0538 to keep the order they should be applied in. Entire patchset attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0537.2-test_ldap-Read-a-publicly-accessible-attribute-when-.patch Type: text/x-patch Size: 1410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0538.2-aci-update-Trim-the-admin-write-blacklist.patch Type: text/x-patch Size: 13036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0539.2-aci-update-Add-ACI-for-read-only-admin-attributes.patch Type: text/x-patch Size: 2058 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 25 12:09:00 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Apr 2014 14:09:00 +0200 Subject: [Freeipa-devel] [PATCH] 0537-0539 aci-update: Trim the admin write blacklist & Add ACI for read-only admin attributes In-Reply-To: <535A471C.60200@redhat.com> References: <53580858.60908@redhat.com> <1398279365.2628.369.camel@willson.li.ssimo.org> <5358C014.3040800@redhat.com> <535900C7.7060405@redhat.com> <1398342520.2628.417.camel@willson.li.ssimo.org> <53590F27.3040601@redhat.com> <1398346957.2628.431.camel@willson.li.ssimo.org> <5359240F.6090408@redhat.com> <1398352526.2628.436.camel@willson.li.ssimo.org> <535A407D.4070709@redhat.com> <535A422C.9030002@redhat.com> <535A471C.60200@redhat.com> Message-ID: <535A505C.4030509@redhat.com> On 04/25/2014 01:29 PM, Petr Viktorin wrote: > On 04/25/2014 01:08 PM, Martin Kosek wrote: >> On 04/25/2014 01:01 PM, Petr Viktorin wrote: >>> On 04/24/2014 05:15 PM, Simo Sorce wrote: >>>> On Thu, 2014-04-24 at 16:47 +0200, Martin Kosek wrote: >>>>> On 04/24/2014 03:42 PM, Simo Sorce wrote: >>>>>> On Thu, 2014-04-24 at 15:18 +0200, Martin Kosek wrote: >>>>>>> On 04/24/2014 02:28 PM, Simo Sorce wrote: >>>>>>>> On Thu, 2014-04-24 at 14:17 +0200, Martin Kosek wrote: >>>>>>>>> On 04/24/2014 09:41 AM, Petr Viktorin wrote: >>>>>>>>>> On 04/23/2014 08:56 PM, Simo Sorce wrote: >>>>>>>>>>> On Wed, 2014-04-23 at 20:37 +0200, Petr Viktorin wrote: >>>>>>>>>>>> Admin access to read-only attributes such as ipaUniqueId, memberOf, >>>>>>>>>>>> krbPrincipalName is provided by the anonymous read ACI, which will go >>>>>>>>>>>> away. This patch adds a blanket read ACI for these. >>>>>>>>>>>> I also moved some related ACIs to 20-aci.update. >>>>>>>>>>>> >>>>>>>>>>>> Previously krbPwdHistory was also readable by admins. I don't think we >>>>>>>>>>>> want to include that. >>>>>>>>>>>> Simo, should admins be allowed to read krbExtraData? >>>>>>>>>>> >>>>>>>>>>> Probably not necessary but there is nothing secret in it either. >>>>>>>>>>> >>>>>>>>>>> Simo. >>>>>>>>>> >>>>>>>>>> OK. I'm not a fan of hiding things from the admin, so no changes to the >>>>>>>>>> patch >>>>>>>>>> are necessary here. >>>>>>>>>> >>>>>>>>> >>>>>>>>> 536: >>>>>>>>> As we are touching these ACIs, may it is a time to see the blacklist of >>>>>>>>> attributes that admin cannot write and check if this is still wanted: >>>>>>>>> >>>>>>>>> ipaUniqueId - OK, generated by DS plugin >>>>>>>>> memberOf - OK, generated by DS plugin >>>>>>>>> serverHostName - I did not even find a place where we manipulate it, >>>>>>>>> except >>>>>>>>> host.py -> remove from blacklist? >>>>>>> >>>>>>> What about this one? >>>>>> >>>>>> not sure, I did not work much on the hosts objects. >>>>> >>>>> Rob? Do you know? >>>>> >>>>>>>>> enrolledBy - OK, generated by DS plugin >>>>>>>>> krbExtraData - OK, generated by DS plugin >>>>>>>>> krbPrincipalName - why can't admin change it? It is filled by >>>>>>>>> framework, I >>>>>>>>> would not personally blacklist it >>>>>>>> >>>>>>>> It is changed by the ipa rename plugin when the user uid change, that's >>>>>>>> why we prevent the admin from explicitly change it. >>>>>>>> >>>>>>>>> krbCanonicalName - same as krbPrincipalName >>>>>>> >>>>>>> Ok, in that case krbPrincipalName and krbCanonicalName should stay, right? >>>>>> >>>>>> They should be accessible by admin, yes. >>>>> >>>>> Note that we are now discussing write access. I.e. what attributes needs to >>>>> stay in the admin's global write ACI blacklist and which can be removed -> >>>>> admin can write in them. >>>>> >>>>> IIUC, these should be only readable by admin, not writeable. >>>>> >>>>>> >>>>>>>>> krbPrincipalAliases - same as krbPrincipalName - we need this removed >>>>>>>>> if we >>>>>>>>> want to set aliases anyway >>>>>>> >>>>>>> Allow this one? >>>>>> >>>>>> This is one I wanted to eventually get rid of, Alexander seem to have >>>>>> introduced it, but we discussed in the past of a way to kill it. >>>>>> I forgot the details thouhg. >>>>>> Alexander did we open a ticket for this ? >>>>> >>>>> Ok, we may eventually get rid of it, but does it need to be blacklisted in >>>>> admins global write ACI? >>>>> >>>>>> >>>>>>>>> krbPasswordExpiration - OK, generated by DS plugin >>>>>>>>> krbLastPwdChange - OK, generated by DS plugin >>>>>>>>> krbUPEnabled - not used, can we remove it? >>>>>>> >>>>>>> What about this one? >>>>>> >>>>>> We never use it. >>>>> >>>>> I read this as "remove it from global admin write ACI blacklist". >>>>> >>>>>> >>>>>>>>> krbTicketPolicyReference - why cannot admin set it? >>>>>>>> >>>>>>>> Unclear why, probably should be able to. >>>>>>> >>>>>>> We may want to remove it from blacklist then. >>>>>> >>>>>> We never used it, but we should probably allow admin to modify >>>>> >>>>> Ok, let us remove it from global admin write ACI blacklist. >>>>> >>>>>> >>>>>>>>> krbPwdPolicyReference - why cannot admin set it? >>>>>>>> >>>>>>>> We assign password policy based on groups now, right ? >>>>>>> >>>>>>> Yup. >>>>> >>>>> I see no complains, i.e. I read it as "remove it from global admin write ACI >>>>> blacklist". >>>>> >>>>>>> >>>>>>>> >>>>>>>>> krbPrincipalType - why cannot admin set it? >>>>>>>> >>>>>>>> Unused. >>>>>>> >>>>>>> So... allow this one? >>>>>> >>>>>> we never use it so we do not need to allow admins by default. >>>>> >>>>> My point was to limit admin write ACI blacklist to the bare minimum. Only to >>>>> attributes that really needs to be blacklisted as they are operated by DS >>>>> plugins - like memberOf and others. >>>>> >>>>> My proposal is to remove it from global admin write ACI blacklist given it is >>>>> not used. >>>> >>>> Ack, I agree with your intent. >>>> >>>> Simo. >>>> >>> >>> If I understand correctly, we want to allow: >>> - krbPrincipalAliases >>> - krbPrincipalType >>> - krbPwdPolicyReference >>> - krbTicketPolicyReference >>> - krbUPEnabled >>> - serverHostName >>> >>> Here is the patch for that. >> >> The list looks good to me. >> >>> Martin, just to make sure: 0536-0537 are good to push, right? >> >> One of the reasons why I wanted to prune the blacklist a bit was to make the >> Admin read ACI (Admin read-only attributes) simpler (read - shorter). So please >> also update this aci in 536. > > Ah, right. > >> IMO, 536 and 538 can be squashed, but that's up to you. > > I tried, but I couldn't get the commit message to not read like two unrelated > changes, which to me is a clear sign they shouldn't be squashed. (I thought > about also split moving the ACIs and the modifications, but maybe that'd be too > purist.) > > I renumbered 0536 to 0538 to keep the order they should be applied in. Entire > patchset attached. I think this is fine, I also tested upgrade and it went well. ACK for all 3, pushed to master: 99691d117168e9ed95413f96f839b38320ac17f9 Martin From pvoborni at redhat.com Fri Apr 25 13:01:36 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 25 Apr 2014 15:01:36 +0200 Subject: [Freeipa-devel] [PATCH] webui: regression - enable fields on idrange type change (add) Message-ID: <535A5CB0.6010908@redhat.com> ID range adder dialog was not properly addressed in field binding refactoring. The usage of reset caused some weird loops. https://fedorahosted.org/freeipa/ticket/4326 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0586-webui-regression-enable-fields-on-idrange-type-chang.patch Type: text/x-patch Size: 2668 bytes Desc: not available URL: From pvoborni at redhat.com Fri Apr 25 13:02:27 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 25 Apr 2014 15:02:27 +0200 Subject: [Freeipa-devel] [PATCH] 587 webui-ci: adjust id range tests to new validator Message-ID: <535A5CE3.1070106@redhat.com> SSIA -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0587-webui-ci-adjust-id-range-tests-to-new-validator.patch Type: text/x-patch Size: 7566 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 25 13:10:17 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2014 09:10:17 -0400 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <535A0A62.9020807@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> <535A0A62.9020807@redhat.com> Message-ID: <535A5EB9.301@redhat.com> Petr Viktorin wrote: > On 04/24/2014 11:16 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 10.4.2014 22:06, Rob Crittenden wrote: >>>> Some in-line, a whole ton of data appended to end. >>>> >>>> Jan Cholasta wrote: >>>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: > [...] >>>>>>> $ ipa-cacert-manage -v renew >>>>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File >>>>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line >>>>>>> 168, in >>>>>>> execute >>>>>>> self.validate_options() >>>>>>> File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py", >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> line 62, in validate_options >>>>>>> super(CACertManage, self).validate_options(needs_root=True) >>>>>>> File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", >>>>>>> line >>>>>>> 189, in validate_options >>>>>>> raise ScriptError('Must be root to run %s' % >>>>>>> self.command_name, 1) >>>>>>> >>>>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The >>>>>>> ipa-cacert-manage command failed, exception: ScriptError: Must be >>>>>>> root >>>>>>> to run ipa-cacert-manage >>>>>>> ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be >>>>>>> root to run ipa-cacert-manage >>>>> >>>>> That's correct, you can run it only as root, because you can't >>>>> resubmit >>>>> certmonger requests as a regular user. >>>> >>>> Yes but one shouldn't get a traceback! >>> >>> You get the traceback only in verbose mode. I did not invent this, it's >>> how ipapython.admintool does things. >> >> Ok, I'll blame Petr. > > In verbose mode you get all the debugging information that's written to > logs, and that includes the tracebacks. I stand by this decision. > If the command is normally so quiet that you need the -v flag for normal > operation, that's a problem. Log interesting messages at INFO. > http://www.freeipa.org/page/V3/Logging_and_output#Design > Well, it's just that the traceback is caught and handled, so it seems odd that it is reported. Then again, this is useful for the case of too broad an except, so as usual I have mixed feelings. I think long-term we need to provide some mid-level solution, more info without spamming with everything. The cacert command takes a REALLY long time, and my twitchy fingers nearly killed it a number of times. We have other commands that do similarly long-lived things with no feedback (separate from things that go over the JSON/XML api). If I can come up with any concrete ideas I'll file a ticket, but reserve the right to whine and complain in the meantime. rob From redhatrises at gmail.com Fri Apr 25 14:28:31 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 25 Apr 2014 08:28:31 -0600 Subject: [Freeipa-devel] [PATCH] Stop ntpd before running ntpdate Message-ID: Hello, Here is a patch for https://fedorahosted.org/freeipa/ticket/3735. It seemed better to try to stop ntpd before running ntpdate rather than not running ntpdate if ntpd was already running. I believe this patch only applies to the ipa-3-3 branch as ntpdate is not used anymore in the master. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0017-ipa-client-install-stop-ntpd-before-running-ntpdate.patch Type: text/x-patch Size: 1474 bytes Desc: not available URL: From amisnyov at redhat.com Fri Apr 25 15:16:48 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 25 Apr 2014 17:16:48 +0200 Subject: [Freeipa-devel] [PATCH] 18 webui otptoken test data added Message-ID: <20140425171648.754632d7@unused-4-246.brq.redhat.com> Hi, this patch adds some static test data for the webui otptoken part. Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0018-webui-OTP-token-test-data-added.patch Type: text/x-patch Size: 12479 bytes Desc: not available URL: From pvoborni at redhat.com Fri Apr 25 17:24:35 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 25 Apr 2014 19:24:35 +0200 Subject: [Freeipa-devel] [PATCH] 588 webui: fix switching between multiple_choice_section choices Message-ID: <535A9A53.9080801@redhat.com> - required indicators are not present for all sections except the last - validation has wrong color for the same sections There was only one layout for all choices. Layout should not be reused because `create` method will reset layout's rows therefore it worked properly only for the last choice. https://fedorahosted.org/freeipa/ticket/4327 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0588-webui-fix-switching-between-multiple_choice_section-.patch Type: text/x-patch Size: 1978 bytes Desc: not available URL: From abokovoy at redhat.com Mon Apr 28 08:02:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 28 Apr 2014 11:02:13 +0300 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <535A4244.30405@redhat.com> References: <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> <20140416153414.GP20958@redhat.com> <1397663792.19767.401.camel@willson.li.ssimo.org> <535654C4.5060303@redhat.com> <5357B612.30805@redhat.com> <535A4244.30405@redhat.com> Message-ID: <20140428080213.GC20958@redhat.com> On Fri, 25 Apr 2014, Petr Viktorin wrote: >On 04/23/2014 02:46 PM, Martin Kosek wrote: >>On 04/22/2014 01:38 PM, Petr Viktorin wrote: >>>On 04/16/2014 05:56 PM, Simo Sorce wrote: >>>>On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: >>>>>On Wed, 16 Apr 2014, Martin Kosek wrote: >>>>>>>>>>>>>>In general I am not sure all authenticated users need access to all >>>>>>>>>>>>>>this >>>>>>>>>>>>>>info. Alexander ? >>>>>>>>>>>>>SSSD needs to read some of this information for subdomains support. >>>>>>>>>>>>>That would be at least host/*@REALM who needs to access it. >>>>>>>>>>>> >>>>>>>>>>>>Can you please list exactly which ones are needed ? >>>>>>>>>>>SSSD subdomains support needs: >>>>>>>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>>>>>>>> - ipaNTFlatName >>>>>>>>>>> - ipaNTSecurityIdentifier >>>>>>>>>>> - ipaNTTrustedDomainSID >>>>>>>>>>> - cn >>>>>>>>>> >>>>>>>>>>Question is - is there any added value in hiding part of the >>>>>>>>>>trust information from authenticated users? I.e. attributes like >>>>>>>>>>ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>>>>>>>>>attribute anyway?), SID blacklists... >>>>>>>>>Yes. Some of those attributes are needed as internal detail of ipasam -- >>>>>>>>>part of how Samba stores this information taken from specific DCE RPC >>>>>>>>>structures. >>>>>>>>> >>>>>>>>>>If yes, we would need to split this permission in 2 and have one for >>>>>>>>>>authenticated users and one for "Trust Adminitrators" and "Trust Readers". >>>>>>>>>Yes. Authenticated users shouldn't get any access to those details: >>>>>>>>> ipantsupportedencryptiontypes >>>>>>>>> ipanttrustattributes >>>>>>>>> ipanttrustauthincoming >>>>>>>>> ipanttrustauthoutgoing >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group >>>>>>>>should >>>>>>>>then have this permission assigned so that samba can operate the attributes. >>>>>>>'adtrust agents' and 'trust administrators' should have read, modify, >>>>>>>delete, and search on cn=trusts. >>>>>>> >>>>>> >>>>>>Right. We will probably want to turn most of ACIs in >>>>>>install/updates/60-trusts.update in managed permissions (i.e. defined in >>>>>>trust.py) and make "adtrust agents" and "trust admins" it's members. >>>>>I agree. >>>>> >>>> >>>>+1 >>>> >>>>Simo. >>>> >>> >>>All right. Now I'm replacing the global anonymous read ACI; converting the >>>others will come later. The existing agents/admins ACIs grant the 'read' (or >>>'all') right already. >>>ipaIDRange is covered in the range plugin, so what's left for this patch is the >>>ipaNTTrustedDomain/ipaNTDomainAttrs attributes. >>> >>>Does that sound reasonable? >> >>This is all that's needed from SSSD side, I just verified in sssd git. sssd >>indeed only uses these attributes: >> >>#define IPA_CN "cn" >>#define IPA_FLATNAME "ipaNTFlatName" >>#define IPA_SID "ipaNTSecurityIdentifier" >>#define IPA_TRUSTED_DOMAIN_SID "ipaNTTrustedDomainSID" >> >>So I am OK with the patch as is. >> >>However, with this ACI, regular users will not be able to show Trusts with >>command line even though they have access to the basic information: >> >># ipa trust-find >>---------------- >>0 trusts matched >>---------------- >>---------------------------- >>Number of entries returned 0 >>---------------------------- >> >>IMO trust command should be able to return the information that the user is >>allowed to see. I prepared a patch to make the read part of trust.py more >>resilient to missing attributes. Attached. >> >>With this patch enabled, I have this output as regular user: >> >># ipa trust-find >>--------------- >>1 trust matched >>--------------- >> Realm name: tbad.example.com >> Domain NetBIOS name: TBAD >> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >>---------------------------- >>Number of entries returned 1 >>---------------------------- >># ipa trust-show tbad.example.com >> Realm name: tbad.example.com >> Domain NetBIOS name: TBAD >> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >> >># ipa trustdomain-find tbad.example.com >> Domain name: child.tbad.example.com >> Domain NetBIOS name: CHILD >> Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 >> >> Domain name: tbad.example.com >> Domain NetBIOS name: TBAD >> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >>---------------------------- >>Number of entries returned 2 >>---------------------------- >> >>The only bigger change I did was to filter trust root domains by >>ipaNTSecurityIdentifier and not ipaNTSIDBlacklistIncoming which is not >>available to everyone. >> >>Martin >> > >The patch looks good to me, but I think Alexander is better qualified >to review it. ACK. -- / Alexander Bokovoy From mkosek at redhat.com Mon Apr 28 09:04:57 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 28 Apr 2014 11:04:57 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140428080213.GC20958@redhat.com> References: <534E99E2.5020701@redhat.com> <20140416151019.GN20958@redhat.com> <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> <20140416153414.GP20958@redhat.com> <1397663792.19767.401.camel@willson.li.ssimo.org> <535654C4.5060303@redhat.com> <5357B612.30805@redhat.com> <535A4244.30405@redhat.com> <20140428080213.GC20958@redhat.com> Message-ID: <535E19B9.5090809@redhat.com> On 04/28/2014 10:02 AM, Alexander Bokovoy wrote: > On Fri, 25 Apr 2014, Petr Viktorin wrote: >> On 04/23/2014 02:46 PM, Martin Kosek wrote: >>> On 04/22/2014 01:38 PM, Petr Viktorin wrote: >>>> On 04/16/2014 05:56 PM, Simo Sorce wrote: >>>>> On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: >>>>>> On Wed, 16 Apr 2014, Martin Kosek wrote: >>>>>>>>>>>>>>> In general I am not sure all authenticated users need access to all >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> info. Alexander ? >>>>>>>>>>>>>> SSSD needs to read some of this information for subdomains support. >>>>>>>>>>>>>> That would be at least host/*@REALM who needs to access it. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you please list exactly which ones are needed ? >>>>>>>>>>>> SSSD subdomains support needs: >>>>>>>>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>>>>>>>>> - ipaNTFlatName >>>>>>>>>>>> - ipaNTSecurityIdentifier >>>>>>>>>>>> - ipaNTTrustedDomainSID >>>>>>>>>>>> - cn >>>>>>>>>>> >>>>>>>>>>> Question is - is there any added value in hiding part of the >>>>>>>>>>> trust information from authenticated users? I.e. attributes like >>>>>>>>>>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>>>>>>>>>> attribute anyway?), SID blacklists... >>>>>>>>>> Yes. Some of those attributes are needed as internal detail of ipasam -- >>>>>>>>>> part of how Samba stores this information taken from specific DCE RPC >>>>>>>>>> structures. >>>>>>>>>> >>>>>>>>>>> If yes, we would need to split this permission in 2 and have one for >>>>>>>>>>> authenticated users and one for "Trust Adminitrators" and "Trust >>>>>>>>>>> Readers". >>>>>>>>>> Yes. Authenticated users shouldn't get any access to those details: >>>>>>>>>> ipantsupportedencryptiontypes >>>>>>>>>> ipanttrustattributes >>>>>>>>>> ipanttrustauthincoming >>>>>>>>>> ipanttrustauthoutgoing >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group >>>>>>>>> should >>>>>>>>> then have this permission assigned so that samba can operate the >>>>>>>>> attributes. >>>>>>>> 'adtrust agents' and 'trust administrators' should have read, modify, >>>>>>>> delete, and search on cn=trusts. >>>>>>>> >>>>>>> >>>>>>> Right. We will probably want to turn most of ACIs in >>>>>>> install/updates/60-trusts.update in managed permissions (i.e. defined in >>>>>>> trust.py) and make "adtrust agents" and "trust admins" it's members. >>>>>> I agree. >>>>>> >>>>> >>>>> +1 >>>>> >>>>> Simo. >>>>> >>>> >>>> All right. Now I'm replacing the global anonymous read ACI; converting the >>>> others will come later. The existing agents/admins ACIs grant the 'read' (or >>>> 'all') right already. >>>> ipaIDRange is covered in the range plugin, so what's left for this patch is >>>> the >>>> ipaNTTrustedDomain/ipaNTDomainAttrs attributes. >>>> >>>> Does that sound reasonable? >>> >>> This is all that's needed from SSSD side, I just verified in sssd git. sssd >>> indeed only uses these attributes: >>> >>> #define IPA_CN "cn" >>> #define IPA_FLATNAME "ipaNTFlatName" >>> #define IPA_SID "ipaNTSecurityIdentifier" >>> #define IPA_TRUSTED_DOMAIN_SID "ipaNTTrustedDomainSID" >>> >>> So I am OK with the patch as is. >>> >>> However, with this ACI, regular users will not be able to show Trusts with >>> command line even though they have access to the basic information: >>> >>> # ipa trust-find >>> ---------------- >>> 0 trusts matched >>> ---------------- >>> ---------------------------- >>> Number of entries returned 0 >>> ---------------------------- >>> >>> IMO trust command should be able to return the information that the user is >>> allowed to see. I prepared a patch to make the read part of trust.py more >>> resilient to missing attributes. Attached. >>> >>> With this patch enabled, I have this output as regular user: >>> >>> # ipa trust-find >>> --------------- >>> 1 trust matched >>> --------------- >>> Realm name: tbad.example.com >>> Domain NetBIOS name: TBAD >>> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> # ipa trust-show tbad.example.com >>> Realm name: tbad.example.com >>> Domain NetBIOS name: TBAD >>> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >>> >>> # ipa trustdomain-find tbad.example.com >>> Domain name: child.tbad.example.com >>> Domain NetBIOS name: CHILD >>> Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 >>> >>> Domain name: tbad.example.com >>> Domain NetBIOS name: TBAD >>> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >>> ---------------------------- >>> Number of entries returned 2 >>> ---------------------------- >>> >>> The only bigger change I did was to filter trust root domains by >>> ipaNTSecurityIdentifier and not ipaNTSIDBlacklistIncoming which is not >>> available to everyone. >>> >>> Martin >>> >> >> The patch looks good to me, but I think Alexander is better qualified to >> review it. > ACK. > Thanks Alexander. I assume you are also ok with Petr's 529.2 I used as a base. (there is also a pending patch 530 also touching this trust plugin area. Martin From abokovoy at redhat.com Mon Apr 28 09:14:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 28 Apr 2014 12:14:51 +0300 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <535112CE.5080009@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> <20140417201204.GY20958@redhat.com> <535112CE.5080009@redhat.com> Message-ID: <20140428091451.GD20958@redhat.com> On Fri, 18 Apr 2014, Petr Viktorin wrote: >From 00756cf2c9682b32dba3388e07dda3fad916e284 Mon Sep 17 00:00:00 2001 >From: Petr Viktorin >Date: Thu, 17 Apr 2014 19:06:52 +0200 >Subject: [PATCH] trust plugin: Remove ipatrustauth{incoming,outgoing} from > default attrs > >These attributes contain secrets for the trusts and should not be returned >by default. >--- > ipalib/plugins/trust.py | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > >diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py >index f57cf7d891928903fdbee67697b96db4ad2679b7..8fff1cae306559fb42209cbd1aaabcbd9046a27b 100644 >--- a/ipalib/plugins/trust.py >+++ b/ipalib/plugins/trust.py >@@ -306,12 +306,11 @@ class trust(LDAPObject): > object_name_plural = _('trusts') > object_class = ['ipaNTTrustedDomain'] > default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', >- 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', 'ipanttrustpartner', >- 'ipantauthtrustoutgoing', 'ipanttrustauthincoming', 'ipanttrustforesttrustinfo', >+ 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', >+ 'ipanttrustpartner', 'ipanttrustforesttrustinfo', > 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] > search_display_attributes = ['cn', 'ipantflatname', >- 'ipanttrusteddomainsid', 'ipanttrusttype', >- 'ipantsidblacklistincoming', 'ipantsidblacklistoutgoing' ] >+ 'ipanttrusteddomainsid', 'ipanttrusttype'] > > label = _('Trusts') > label_singular = _('Trust') ACK. This all looks fine, I only have one question -- SID blacklists now became invisible by default to anyone. Even admins can't see them other than with --all. I'm not sure they are really that important to deny access to, but it makes sense to reduce their visibility to normal users. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Apr 28 09:17:30 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 28 Apr 2014 12:17:30 +0300 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <535E19B9.5090809@redhat.com> References: <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> <20140416153414.GP20958@redhat.com> <1397663792.19767.401.camel@willson.li.ssimo.org> <535654C4.5060303@redhat.com> <5357B612.30805@redhat.com> <535A4244.30405@redhat.com> <20140428080213.GC20958@redhat.com> <535E19B9.5090809@redhat.com> Message-ID: <20140428091730.GE20958@redhat.com> On Mon, 28 Apr 2014, Martin Kosek wrote: >On 04/28/2014 10:02 AM, Alexander Bokovoy wrote: >> On Fri, 25 Apr 2014, Petr Viktorin wrote: >>> On 04/23/2014 02:46 PM, Martin Kosek wrote: >>>> On 04/22/2014 01:38 PM, Petr Viktorin wrote: >>>>> On 04/16/2014 05:56 PM, Simo Sorce wrote: >>>>>> On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: >>>>>>> On Wed, 16 Apr 2014, Martin Kosek wrote: >>>>>>>>>>>>>>>> In general I am not sure all authenticated users need access to all >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> info. Alexander ? >>>>>>>>>>>>>>> SSSD needs to read some of this information for subdomains support. >>>>>>>>>>>>>>> That would be at least host/*@REALM who needs to access it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you please list exactly which ones are needed ? >>>>>>>>>>>>> SSSD subdomains support needs: >>>>>>>>>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>>>>>>>>>> - ipaNTFlatName >>>>>>>>>>>>> - ipaNTSecurityIdentifier >>>>>>>>>>>>> - ipaNTTrustedDomainSID >>>>>>>>>>>>> - cn >>>>>>>>>>>> >>>>>>>>>>>> Question is - is there any added value in hiding part of the >>>>>>>>>>>> trust information from authenticated users? I.e. attributes like >>>>>>>>>>>> ipanttrustdirection, ipaNTTrustAttributes (what is the purpose of this >>>>>>>>>>>> attribute anyway?), SID blacklists... >>>>>>>>>>> Yes. Some of those attributes are needed as internal detail of ipasam -- >>>>>>>>>>> part of how Samba stores this information taken from specific DCE RPC >>>>>>>>>>> structures. >>>>>>>>>>> >>>>>>>>>>>> If yes, we would need to split this permission in 2 and have one for >>>>>>>>>>>> authenticated users and one for "Trust Adminitrators" and "Trust >>>>>>>>>>>> Readers". >>>>>>>>>>> Yes. Authenticated users shouldn't get any access to those details: >>>>>>>>>>> ipantsupportedencryptiontypes >>>>>>>>>>> ipanttrustattributes >>>>>>>>>>> ipanttrustauthincoming >>>>>>>>>>> ipanttrustauthoutgoing >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" system group >>>>>>>>>> should >>>>>>>>>> then have this permission assigned so that samba can operate the >>>>>>>>>> attributes. >>>>>>>>> 'adtrust agents' and 'trust administrators' should have read, modify, >>>>>>>>> delete, and search on cn=trusts. >>>>>>>>> >>>>>>>> >>>>>>>> Right. We will probably want to turn most of ACIs in >>>>>>>> install/updates/60-trusts.update in managed permissions (i.e. defined in >>>>>>>> trust.py) and make "adtrust agents" and "trust admins" it's members. >>>>>>> I agree. >>>>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> All right. Now I'm replacing the global anonymous read ACI; converting the >>>>> others will come later. The existing agents/admins ACIs grant the 'read' (or >>>>> 'all') right already. >>>>> ipaIDRange is covered in the range plugin, so what's left for this patch is >>>>> the >>>>> ipaNTTrustedDomain/ipaNTDomainAttrs attributes. >>>>> >>>>> Does that sound reasonable? >>>> >>>> This is all that's needed from SSSD side, I just verified in sssd git. sssd >>>> indeed only uses these attributes: >>>> >>>> #define IPA_CN "cn" >>>> #define IPA_FLATNAME "ipaNTFlatName" >>>> #define IPA_SID "ipaNTSecurityIdentifier" >>>> #define IPA_TRUSTED_DOMAIN_SID "ipaNTTrustedDomainSID" >>>> >>>> So I am OK with the patch as is. >>>> >>>> However, with this ACI, regular users will not be able to show Trusts with >>>> command line even though they have access to the basic information: >>>> >>>> # ipa trust-find >>>> ---------------- >>>> 0 trusts matched >>>> ---------------- >>>> ---------------------------- >>>> Number of entries returned 0 >>>> ---------------------------- >>>> >>>> IMO trust command should be able to return the information that the user is >>>> allowed to see. I prepared a patch to make the read part of trust.py more >>>> resilient to missing attributes. Attached. >>>> >>>> With this patch enabled, I have this output as regular user: >>>> >>>> # ipa trust-find >>>> --------------- >>>> 1 trust matched >>>> --------------- >>>> Realm name: tbad.example.com >>>> Domain NetBIOS name: TBAD >>>> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> # ipa trust-show tbad.example.com >>>> Realm name: tbad.example.com >>>> Domain NetBIOS name: TBAD >>>> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >>>> >>>> # ipa trustdomain-find tbad.example.com >>>> Domain name: child.tbad.example.com >>>> Domain NetBIOS name: CHILD >>>> Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 >>>> >>>> Domain name: tbad.example.com >>>> Domain NetBIOS name: TBAD >>>> Domain Security Identifier: S-1-5-21-2997650941-1802118864-3094776726 >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> The only bigger change I did was to filter trust root domains by >>>> ipaNTSecurityIdentifier and not ipaNTSIDBlacklistIncoming which is not >>>> available to everyone. >>>> >>>> Martin >>>> >>> >>> The patch looks good to me, but I think Alexander is better qualified to >>> review it. >> ACK. >> > >Thanks Alexander. I assume you are also ok with Petr's 529.2 I used as a base. >(there is also a pending patch 530 also touching this trust plugin area. Yes. As I said in the other thread, I only slightly worried with SID blacklists visibility (or lack, there of) with the latest changes but we should handle that as a separate patchset (if any). -- / Alexander Bokovoy From mkosek at redhat.com Mon Apr 28 10:31:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 28 Apr 2014 12:31:16 +0200 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <20140428091451.GD20958@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> <20140417201204.GY20958@redhat.com> <535112CE.5080009@redhat.com> <20140428091451.GD20958@redhat.com> Message-ID: <535E2DF4.7020801@redhat.com> On 04/28/2014 11:14 AM, Alexander Bokovoy wrote: > On Fri, 18 Apr 2014, Petr Viktorin wrote: >> From 00756cf2c9682b32dba3388e07dda3fad916e284 Mon Sep 17 00:00:00 2001 >> From: Petr Viktorin >> Date: Thu, 17 Apr 2014 19:06:52 +0200 >> Subject: [PATCH] trust plugin: Remove ipatrustauth{incoming,outgoing} from >> default attrs >> >> These attributes contain secrets for the trusts and should not be returned >> by default. >> --- >> ipalib/plugins/trust.py | 7 +++---- >> 1 file changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py >> index >> f57cf7d891928903fdbee67697b96db4ad2679b7..8fff1cae306559fb42209cbd1aaabcbd9046a27b >> 100644 >> --- a/ipalib/plugins/trust.py >> +++ b/ipalib/plugins/trust.py >> @@ -306,12 +306,11 @@ class trust(LDAPObject): >> object_name_plural = _('trusts') >> object_class = ['ipaNTTrustedDomain'] >> default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', >> - 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', >> 'ipanttrustpartner', >> - 'ipantauthtrustoutgoing', 'ipanttrustauthincoming', >> 'ipanttrustforesttrustinfo', >> + 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', >> + 'ipanttrustpartner', 'ipanttrustforesttrustinfo', >> 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] >> search_display_attributes = ['cn', 'ipantflatname', >> - 'ipanttrusteddomainsid', 'ipanttrusttype', >> - 'ipantsidblacklistincoming', >> 'ipantsidblacklistoutgoing' ] >> + 'ipanttrusteddomainsid', 'ipanttrusttype'] >> >> label = _('Trusts') >> label_singular = _('Trust') > > ACK. > This all looks fine, I only have one question -- SID blacklists now > became invisible by default to anyone. Even admins can't see them other > than with --all. I'm not sure they are really that important to deny > access to, but it makes sense to reduce their visibility to normal > users. I think we should differentiate 2 aspects of trust plugin patches: 1) SID blacklist access: with current patches, only admin, trust admins and people with appropriate permission/privilege will have access to SID blacklists. Normal users will only see basic trust attributes (see patch 529.2). If this is not OK, and everyone should be able to see them, please yell. 2) SID blacklist visibility: with proposed patches, SID blacklist will be hidden unless --all option is passed. I think this is rather a UX question than functional question. Whether SID blacklist should be printed with each trust-find or trust-show. I would personally not show them to make the display simpler and would remove search_display_attributes entirely (or make blacklist shown in trust-show, but not with trust-find) but I do not insist. Martin From abokovoy at redhat.com Mon Apr 28 10:38:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 28 Apr 2014 13:38:36 +0300 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <535E2DF4.7020801@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> <20140417201204.GY20958@redhat.com> <535112CE.5080009@redhat.com> <20140428091451.GD20958@redhat.com> <535E2DF4.7020801@redhat.com> Message-ID: <20140428103836.GF20958@redhat.com> On Mon, 28 Apr 2014, Martin Kosek wrote: >On 04/28/2014 11:14 AM, Alexander Bokovoy wrote: >> On Fri, 18 Apr 2014, Petr Viktorin wrote: >>> From 00756cf2c9682b32dba3388e07dda3fad916e284 Mon Sep 17 00:00:00 2001 >>> From: Petr Viktorin >>> Date: Thu, 17 Apr 2014 19:06:52 +0200 >>> Subject: [PATCH] trust plugin: Remove ipatrustauth{incoming,outgoing} from >>> default attrs >>> >>> These attributes contain secrets for the trusts and should not be returned >>> by default. >>> --- >>> ipalib/plugins/trust.py | 7 +++---- >>> 1 file changed, 3 insertions(+), 4 deletions(-) >>> >>> diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py >>> index >>> f57cf7d891928903fdbee67697b96db4ad2679b7..8fff1cae306559fb42209cbd1aaabcbd9046a27b >>> 100644 >>> --- a/ipalib/plugins/trust.py >>> +++ b/ipalib/plugins/trust.py >>> @@ -306,12 +306,11 @@ class trust(LDAPObject): >>> object_name_plural = _('trusts') >>> object_class = ['ipaNTTrustedDomain'] >>> default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', >>> - 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', >>> 'ipanttrustpartner', >>> - 'ipantauthtrustoutgoing', 'ipanttrustauthincoming', >>> 'ipanttrustforesttrustinfo', >>> + 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', >>> + 'ipanttrustpartner', 'ipanttrustforesttrustinfo', >>> 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] >>> search_display_attributes = ['cn', 'ipantflatname', >>> - 'ipanttrusteddomainsid', 'ipanttrusttype', >>> - 'ipantsidblacklistincoming', >>> 'ipantsidblacklistoutgoing' ] >>> + 'ipanttrusteddomainsid', 'ipanttrusttype'] >>> >>> label = _('Trusts') >>> label_singular = _('Trust') >> >> ACK. >> This all looks fine, I only have one question -- SID blacklists now >> became invisible by default to anyone. Even admins can't see them other >> than with --all. I'm not sure they are really that important to deny >> access to, but it makes sense to reduce their visibility to normal >> users. > >I think we should differentiate 2 aspects of trust plugin patches: > >1) SID blacklist access: with current patches, only admin, trust admins and >people with appropriate permission/privilege will have access to SID >blacklists. Normal users will only see basic trust attributes (see patch >529.2). If this is not OK, and everyone should be able to see them, please yell. I'm OK with this state. >2) SID blacklist visibility: with proposed patches, SID blacklist will be >hidden unless --all option is passed. I think this is rather a UX question than >functional question. Whether SID blacklist should be printed with each >trust-find or trust-show. > >I would personally not show them to make the display simpler and would remove >search_display_attributes entirely (or make blacklist shown in trust-show, but >not with trust-find) but I do not insist. The only potential issue in not showing them is that this breaks whatever QE tests expected in past. I.e. if they were expecting SID blacklist to be shown, that would be broken. To my knowledge there is no real dependency on such data in the QE scripts yet. -- / Alexander Bokovoy From mkosek at redhat.com Mon Apr 28 10:42:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 28 Apr 2014 12:42:35 +0200 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <20140428103836.GF20958@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> <20140417201204.GY20958@redhat.com> <535112CE.5080009@redhat.com> <20140428091451.GD20958@redhat.com> <535E2DF4.7020801@redhat.com> <20140428103836.GF20958@redhat.com> Message-ID: <535E309B.5040500@redhat.com> On 04/28/2014 12:38 PM, Alexander Bokovoy wrote: > On Mon, 28 Apr 2014, Martin Kosek wrote: >> On 04/28/2014 11:14 AM, Alexander Bokovoy wrote: >>> On Fri, 18 Apr 2014, Petr Viktorin wrote: >>>> From 00756cf2c9682b32dba3388e07dda3fad916e284 Mon Sep 17 00:00:00 2001 >>>> From: Petr Viktorin >>>> Date: Thu, 17 Apr 2014 19:06:52 +0200 >>>> Subject: [PATCH] trust plugin: Remove ipatrustauth{incoming,outgoing} from >>>> default attrs >>>> >>>> These attributes contain secrets for the trusts and should not be returned >>>> by default. >>>> --- >>>> ipalib/plugins/trust.py | 7 +++---- >>>> 1 file changed, 3 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py >>>> index >>>> f57cf7d891928903fdbee67697b96db4ad2679b7..8fff1cae306559fb42209cbd1aaabcbd9046a27b >>>> >>>> 100644 >>>> --- a/ipalib/plugins/trust.py >>>> +++ b/ipalib/plugins/trust.py >>>> @@ -306,12 +306,11 @@ class trust(LDAPObject): >>>> object_name_plural = _('trusts') >>>> object_class = ['ipaNTTrustedDomain'] >>>> default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', >>>> - 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', >>>> 'ipanttrustpartner', >>>> - 'ipantauthtrustoutgoing', 'ipanttrustauthincoming', >>>> 'ipanttrustforesttrustinfo', >>>> + 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', >>>> + 'ipanttrustpartner', 'ipanttrustforesttrustinfo', >>>> 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] >>>> search_display_attributes = ['cn', 'ipantflatname', >>>> - 'ipanttrusteddomainsid', 'ipanttrusttype', >>>> - 'ipantsidblacklistincoming', >>>> 'ipantsidblacklistoutgoing' ] >>>> + 'ipanttrusteddomainsid', 'ipanttrusttype'] >>>> >>>> label = _('Trusts') >>>> label_singular = _('Trust') >>> >>> ACK. >>> This all looks fine, I only have one question -- SID blacklists now >>> became invisible by default to anyone. Even admins can't see them other >>> than with --all. I'm not sure they are really that important to deny >>> access to, but it makes sense to reduce their visibility to normal >>> users. >> >> I think we should differentiate 2 aspects of trust plugin patches: >> >> 1) SID blacklist access: with current patches, only admin, trust admins and >> people with appropriate permission/privilege will have access to SID >> blacklists. Normal users will only see basic trust attributes (see patch >> 529.2). If this is not OK, and everyone should be able to see them, please yell. > I'm OK with this state. > > >> 2) SID blacklist visibility: with proposed patches, SID blacklist will be >> hidden unless --all option is passed. I think this is rather a UX question than >> functional question. Whether SID blacklist should be printed with each >> trust-find or trust-show. >> >> I would personally not show them to make the display simpler and would remove >> search_display_attributes entirely (or make blacklist shown in trust-show, but >> not with trust-find) but I do not insist. > The only potential issue in not showing them is that this breaks > whatever QE tests expected in past. I.e. if they were expecting SID > blacklist to be shown, that would be broken. To my knowledge there is no > real dependency on such data in the QE scripts yet. I would personally drive FreeIPA development by what we see as the right behavior, not by state of a potentially old QE scripts. Tests should reflect such changes in the code and adhere to them, not vice versa, IMO. Martin From pviktori at redhat.com Mon Apr 28 11:46:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Apr 2014 13:46:02 +0200 Subject: [Freeipa-devel] [PATCH] 530 trust plugin: Fix typo in attribute name In-Reply-To: <20140428091451.GD20958@redhat.com> References: <53500B2B.9090700@redhat.com> <53501DC0.8060001@redhat.com> <1397764998.2628.125.camel@willson.li.ssimo.org> <20140417201204.GY20958@redhat.com> <535112CE.5080009@redhat.com> <20140428091451.GD20958@redhat.com> Message-ID: <535E3F7A.9010003@redhat.com> On 04/28/2014 11:14 AM, Alexander Bokovoy wrote: > On Fri, 18 Apr 2014, Petr Viktorin wrote: >> From 00756cf2c9682b32dba3388e07dda3fad916e284 Mon Sep 17 00:00:00 2001 >> From: Petr Viktorin >> Date: Thu, 17 Apr 2014 19:06:52 +0200 >> Subject: [PATCH] trust plugin: Remove ipatrustauth{incoming,outgoing} >> from >> default attrs >> >> These attributes contain secrets for the trusts and should not be >> returned >> by default. >> --- >> ipalib/plugins/trust.py | 7 +++---- >> 1 file changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py >> index >> f57cf7d891928903fdbee67697b96db4ad2679b7..8fff1cae306559fb42209cbd1aaabcbd9046a27b >> 100644 >> --- a/ipalib/plugins/trust.py >> +++ b/ipalib/plugins/trust.py >> @@ -306,12 +306,11 @@ class trust(LDAPObject): >> object_name_plural = _('trusts') >> object_class = ['ipaNTTrustedDomain'] >> default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', >> - 'ipanttrusttype', 'ipanttrustattributes', >> 'ipanttrustdirection', 'ipanttrustpartner', >> - 'ipantauthtrustoutgoing', 'ipanttrustauthincoming', >> 'ipanttrustforesttrustinfo', >> + 'ipanttrusttype', 'ipanttrustattributes', 'ipanttrustdirection', >> + 'ipanttrustpartner', 'ipanttrustforesttrustinfo', >> 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] >> search_display_attributes = ['cn', 'ipantflatname', >> - 'ipanttrusteddomainsid', >> 'ipanttrusttype', >> - 'ipantsidblacklistincoming', >> 'ipantsidblacklistoutgoing' ] >> + 'ipanttrusteddomainsid', >> 'ipanttrusttype'] >> >> label = _('Trusts') >> label_singular = _('Trust') > > ACK. Thanks, pushed to master: e31688909cbc5f7ab6c8d03bb28786a2dd29efe4 > This all looks fine, I only have one question -- SID blacklists now > became invisible by default to anyone. Even admins can't see them other > than with --all. I'm not sure they are really that important to deny > access to, but it makes sense to reduce their visibility to normal > users. -- Petr? From pviktori at redhat.com Mon Apr 28 14:20:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 28 Apr 2014 16:20:28 +0200 Subject: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts In-Reply-To: <20140428091730.GE20958@redhat.com> References: <534E9ED6.2080502@redhat.com> <20140416152255.GO20958@redhat.com> <534EA1E0.6080801@redhat.com> <20140416153414.GP20958@redhat.com> <1397663792.19767.401.camel@willson.li.ssimo.org> <535654C4.5060303@redhat.com> <5357B612.30805@redhat.com> <535A4244.30405@redhat.com> <20140428080213.GC20958@redhat.com> <535E19B9.5090809@redhat.com> <20140428091730.GE20958@redhat.com> Message-ID: <535E63AC.4080309@redhat.com> On 04/28/2014 11:17 AM, Alexander Bokovoy wrote: > On Mon, 28 Apr 2014, Martin Kosek wrote: >> On 04/28/2014 10:02 AM, Alexander Bokovoy wrote: >>> On Fri, 25 Apr 2014, Petr Viktorin wrote: >>>> On 04/23/2014 02:46 PM, Martin Kosek wrote: >>>>> On 04/22/2014 01:38 PM, Petr Viktorin wrote: >>>>>> On 04/16/2014 05:56 PM, Simo Sorce wrote: >>>>>>> On Wed, 2014-04-16 at 18:34 +0300, Alexander Bokovoy wrote: >>>>>>>> On Wed, 16 Apr 2014, Martin Kosek wrote: >>>>>>>>>>>>>>>>> In general I am not sure all authenticated users need >>>>>>>>>>>>>>>>> access to all >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> info. Alexander ? >>>>>>>>>>>>>>>> SSSD needs to read some of this information for >>>>>>>>>>>>>>>> subdomains support. >>>>>>>>>>>>>>>> That would be at least host/*@REALM who needs to access it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you please list exactly which ones are needed ? >>>>>>>>>>>>>> SSSD subdomains support needs: >>>>>>>>>>>>>> - objectclasses ipaNTTrustedDomain/ipaNTDomainAttrs >>>>>>>>>>>>>> - ipaNTFlatName >>>>>>>>>>>>>> - ipaNTSecurityIdentifier >>>>>>>>>>>>>> - ipaNTTrustedDomainSID >>>>>>>>>>>>>> - cn >>>>>>>>>>>>> >>>>>>>>>>>>> Question is - is there any added value in hiding part of the >>>>>>>>>>>>> trust information from authenticated users? I.e. attributes >>>>>>>>>>>>> like >>>>>>>>>>>>> ipanttrustdirection, ipaNTTrustAttributes (what is the >>>>>>>>>>>>> purpose of this >>>>>>>>>>>>> attribute anyway?), SID blacklists... >>>>>>>>>>>> Yes. Some of those attributes are needed as internal detail >>>>>>>>>>>> of ipasam -- >>>>>>>>>>>> part of how Samba stores this information taken from >>>>>>>>>>>> specific DCE RPC >>>>>>>>>>>> structures. >>>>>>>>>>>> >>>>>>>>>>>>> If yes, we would need to split this permission in 2 and >>>>>>>>>>>>> have one for >>>>>>>>>>>>> authenticated users and one for "Trust Adminitrators" and >>>>>>>>>>>>> "Trust >>>>>>>>>>>>> Readers". >>>>>>>>>>>> Yes. Authenticated users shouldn't get any access to those >>>>>>>>>>>> details: >>>>>>>>>>>> ipantsupportedencryptiontypes >>>>>>>>>>>> ipanttrustattributes >>>>>>>>>>>> ipanttrustauthincoming >>>>>>>>>>>> ipanttrustauthoutgoing >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ok. I assume that "cn=adtrust agents,cn=sysaccounts,SUFFIX" >>>>>>>>>>> system group >>>>>>>>>>> should >>>>>>>>>>> then have this permission assigned so that samba can operate the >>>>>>>>>>> attributes. >>>>>>>>>> 'adtrust agents' and 'trust administrators' should have read, >>>>>>>>>> modify, >>>>>>>>>> delete, and search on cn=trusts. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Right. We will probably want to turn most of ACIs in >>>>>>>>> install/updates/60-trusts.update in managed permissions (i.e. >>>>>>>>> defined in >>>>>>>>> trust.py) and make "adtrust agents" and "trust admins" it's >>>>>>>>> members. >>>>>>>> I agree. >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> >>>>>> All right. Now I'm replacing the global anonymous read ACI; >>>>>> converting the >>>>>> others will come later. The existing agents/admins ACIs grant the >>>>>> 'read' (or >>>>>> 'all') right already. >>>>>> ipaIDRange is covered in the range plugin, so what's left for this >>>>>> patch is >>>>>> the >>>>>> ipaNTTrustedDomain/ipaNTDomainAttrs attributes. >>>>>> >>>>>> Does that sound reasonable? >>>>> >>>>> This is all that's needed from SSSD side, I just verified in sssd >>>>> git. sssd >>>>> indeed only uses these attributes: >>>>> >>>>> #define IPA_CN "cn" >>>>> #define IPA_FLATNAME "ipaNTFlatName" >>>>> #define IPA_SID "ipaNTSecurityIdentifier" >>>>> #define IPA_TRUSTED_DOMAIN_SID "ipaNTTrustedDomainSID" >>>>> >>>>> So I am OK with the patch as is. >>>>> >>>>> However, with this ACI, regular users will not be able to show >>>>> Trusts with >>>>> command line even though they have access to the basic information: >>>>> >>>>> # ipa trust-find >>>>> ---------------- >>>>> 0 trusts matched >>>>> ---------------- >>>>> ---------------------------- >>>>> Number of entries returned 0 >>>>> ---------------------------- >>>>> >>>>> IMO trust command should be able to return the information that the >>>>> user is >>>>> allowed to see. I prepared a patch to make the read part of >>>>> trust.py more >>>>> resilient to missing attributes. Attached. >>>>> >>>>> With this patch enabled, I have this output as regular user: >>>>> >>>>> # ipa trust-find >>>>> --------------- >>>>> 1 trust matched >>>>> --------------- >>>>> Realm name: tbad.example.com >>>>> Domain NetBIOS name: TBAD >>>>> Domain Security Identifier: >>>>> S-1-5-21-2997650941-1802118864-3094776726 >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> # ipa trust-show tbad.example.com >>>>> Realm name: tbad.example.com >>>>> Domain NetBIOS name: TBAD >>>>> Domain Security Identifier: >>>>> S-1-5-21-2997650941-1802118864-3094776726 >>>>> >>>>> # ipa trustdomain-find tbad.example.com >>>>> Domain name: child.tbad.example.com >>>>> Domain NetBIOS name: CHILD >>>>> Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 >>>>> >>>>> Domain name: tbad.example.com >>>>> Domain NetBIOS name: TBAD >>>>> Domain Security Identifier: >>>>> S-1-5-21-2997650941-1802118864-3094776726 >>>>> ---------------------------- >>>>> Number of entries returned 2 >>>>> ---------------------------- >>>>> >>>>> The only bigger change I did was to filter trust root domains by >>>>> ipaNTSecurityIdentifier and not ipaNTSIDBlacklistIncoming which is not >>>>> available to everyone. >>>>> >>>>> Martin >>>>> >>>> >>>> The patch looks good to me, but I think Alexander is better >>>> qualified to >>>> review it. >>> ACK. >>> >> >> Thanks Alexander. I assume you are also ok with Petr's 529.2 I used as >> a base. >> (there is also a pending patch 530 also touching this trust plugin area. > Yes. As I said in the other thread, I only slightly worried with SID > blacklists visibility (or lack, there of) with the latest changes but we > should handle that as a separate patchset (if any). > I've rebased my patch, and pushed both to master: 5d832c342608fd567ea258c1d506cae28f6b0abf -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0529.3-Add-managed-read-permissions-to-trust.patch Type: text/x-patch Size: 1592 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 29 06:59:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 29 Apr 2014 08:59:57 +0200 Subject: [Freeipa-devel] [PATCH] Stop ntpd before running ntpdate In-Reply-To: References: Message-ID: <535F4DED.8090004@redhat.com> Hello Gabe! On 25.4.2014 16:28, Gabe Alford wrote: > Here is a patch for https://fedorahosted.org/freeipa/ticket/3735. > It seemed better to try to stop ntpd before running ntpdate rather than not > running ntpdate if ntpd was already running. I believe this patch only > applies to the ipa-3-3 branch as ntpdate is not used anymore in the master. IMHO we should never stop ntpd if it is running. Plain ntpdate opens potential security hole because attacker can fake NTP answers and force the machine to rewind it's clock to the past. This opens potential for replay attacks/re-suing old compromised keys etc. -- Petr^2 Spacek From pviktori at redhat.com Tue Apr 29 11:03:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Apr 2014 13:03:35 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <5358DAFE.4070505@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> <5357E819.6060700@redhat.com> <1398276468.2628.362.camel@willson.li.ssimo.org> <53582832.9010807@redhat.com> <5358DAFE.4070505@redhat.com> Message-ID: <535F8707.609@redhat.com> On 04/24/2014 11:35 AM, Martin Kosek wrote: > On 04/23/2014 10:53 PM, Martin Kosek wrote: >> On 04/23/2014 08:07 PM, Simo Sorce wrote: [...] >>> >>> I know, we may need to provide another permission admins can use to turn >>> on anonymous searches for those attributes too. >>> We may also decide that on upgrade vs new install we retain anonymous >>> access. >>> >>> Simo. This is an interesting challenge. We want the permission to be set to anonymous when: 1) we're creating it, and 2) the updater is *not* run from ipa-server-install (which would mean we're installing a new cluster). Full analysis below, [0] We discussed this on a meeting and it was mentioned that we can just start with anonymous, and simply change to "all authenticated" at the end of ipa-server-install. Thinking about it, I don't like that approach. We may want an ACI audit tool [1] to list differences from defaults. For uses like this, the metadata should list to up-to-date "best practices", i.e. what you'd get with a fresh ipa-server-install. So the metadata should list the bind type as all authenticated, and setting it to anonymous should be handled as a special operation. This will be somewhat harder to code but I think it's worth it. >> That permission is called >> >> $ ipa permission-mod "System: User Information" --bindtype all >> >> This is all that's needed to make all the user attributes above readable by >> authenticated users and not by anonymous. >> >> Martin > > BTW, we already open groups to anonymous - i.e. we might want to keep the same > level of default access to users too. > > Martin -- Petr? [0]: - upgrade - permission doesn't exist (first 4.x master in cluster): - permission created - bind rule: anonymous - permission already exists: - bind rule not changed - ipa-server-install: - permission created - bind rule: all - ipa-replica-install: - permission doesn't exist (first 4.x master in cluster) - permission created - bind rule: anonymous - permission already exists: - bind rule not changed [1] https://fedorahosted.org/freeipa/ticket/4035 From mkosek at redhat.com Tue Apr 29 12:21:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Apr 2014 14:21:55 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <535F8707.609@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> <5357E819.6060700@redhat.com> <1398276468.2628.362.camel@willson.li.ssimo.org> <53582832.9010807@redhat.com> <5358DAFE.4070505@redhat.com> <535F8707.609@redhat.com> Message-ID: <535F9963.1020207@redhat.com> On 04/29/2014 01:03 PM, Petr Viktorin wrote: > On 04/24/2014 11:35 AM, Martin Kosek wrote: >> On 04/23/2014 10:53 PM, Martin Kosek wrote: >>> On 04/23/2014 08:07 PM, Simo Sorce wrote: > [...] >>>> >>>> I know, we may need to provide another permission admins can use to turn >>>> on anonymous searches for those attributes too. >>>> We may also decide that on upgrade vs new install we retain anonymous >>>> access. >>>> >>>> Simo. > > This is an interesting challenge. > We want the permission to be set to anonymous when: > 1) we're creating it, and > 2) the updater is *not* run from ipa-server-install (which would mean we're > installing a new cluster). > Full analysis below, [0] > > We discussed this on a meeting and it was mentioned that we can just start with > anonymous, and simply change to "all authenticated" at the end of > ipa-server-install. Thinking about it, I don't like that approach. > We may want an ACI audit tool [1] to list differences from defaults. > For uses like this, the metadata should list to up-to-date "best practices", > i.e. what you'd get with a fresh ipa-server-install. > So the metadata should list the bind type as all authenticated, and setting it > to anonymous should be handled as a special operation. > > This will be somewhat harder to code but I think it's worth it. I agree with Petr - managed permission definition should state our recommended and default access control that we are convinced that will fit most deployments. Restrictive or benevolent admins can always change the default with simple $ ipa permission-mod --bindtype=(all|anonymous|permission) call. Maybe the easiest way after all will be to list the changes in access control in the release note, compared to FreeIPA 3.x, e.g. 1) Host groups read access change from anonymous to authenticated by default 2) User calendar attributes read access change from anonymous to authenticated by default ... and educate users how they can change it if it does not fit their needs. IMO it may be more transparent and deterministic than to come with some hard coded changes in ipa-server-install that will create different defaults after upgrade and new installation. Martin From simo at redhat.com Tue Apr 29 12:48:38 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Apr 2014 08:48:38 -0400 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <535F9963.1020207@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> <5357E819.6060700@redhat.com> <1398276468.2628.362.camel@willson.li.ssimo.org> <53582832.9010807@redhat.com> <5358DAFE.4070505@redhat.com> <535F8707.609@redhat.com> <535F9963.1020207@redhat.com> Message-ID: <1398775718.10424.73.camel@willson.li.ssimo.org> On Tue, 2014-04-29 at 14:21 +0200, Martin Kosek wrote: > On 04/29/2014 01:03 PM, Petr Viktorin wrote: > > On 04/24/2014 11:35 AM, Martin Kosek wrote: > >> On 04/23/2014 10:53 PM, Martin Kosek wrote: > >>> On 04/23/2014 08:07 PM, Simo Sorce wrote: > > [...] > >>>> > >>>> I know, we may need to provide another permission admins can use to turn > >>>> on anonymous searches for those attributes too. > >>>> We may also decide that on upgrade vs new install we retain anonymous > >>>> access. > >>>> > >>>> Simo. > > > > This is an interesting challenge. > > We want the permission to be set to anonymous when: > > 1) we're creating it, and > > 2) the updater is *not* run from ipa-server-install (which would mean we're > > installing a new cluster). > > Full analysis below, [0] > > > > We discussed this on a meeting and it was mentioned that we can just start with > > anonymous, and simply change to "all authenticated" at the end of > > ipa-server-install. Thinking about it, I don't like that approach. > > We may want an ACI audit tool [1] to list differences from defaults. > > For uses like this, the metadata should list to up-to-date "best practices", > > i.e. what you'd get with a fresh ipa-server-install. > > So the metadata should list the bind type as all authenticated, and setting it > > to anonymous should be handled as a special operation. > > > > This will be somewhat harder to code but I think it's worth it. > > I agree with Petr - managed permission definition should state our recommended > and default access control that we are convinced that will fit most > deployments. Restrictive or benevolent admins can always change the default > with simple > > $ ipa permission-mod --bindtype=(all|anonymous|permission) > > call. > > Maybe the easiest way after all will be to list the changes in access control > in the release note, compared to FreeIPA 3.x, e.g. > > 1) Host groups read access change from anonymous to authenticated by default > 2) User calendar attributes read access change from anonymous to authenticated > by default > ... > > and educate users how they can change it if it does not fit their needs. IMO it > may be more transparent and deterministic than to come with some hard coded > changes in ipa-server-install that will create different defaults after upgrade > and new installation. It will break working servers pretty badly, that's a big NO on my side. You do not want people to scramble understanding a new ACI system at gunpoint because their production environment is broken. It is a little harder for us, true, but it is worth it. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Tue Apr 29 12:51:33 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 29 Apr 2014 14:51:33 +0200 Subject: [Freeipa-devel] [PATCH] 14 webui: select all checkbox remains selected after operation In-Reply-To: <20140424145729.3f66e7bc@unused-4-246.brq.redhat.com> References: <20140418104314.3997c1db@unused-4-246.brq.redhat.com> <5357D4DF.3000206@redhat.com> <20140424145729.3f66e7bc@unused-4-246.brq.redhat.com> Message-ID: <535FA055.70805@redhat.com> On 24.4.2014 14:57, Misnyovszki Adam wrote: > On Wed, 23 Apr 2014 16:57:35 +0200 > Petr Vobornik wrote: > >> On 18.4.2014 10:43, Misnyovszki Adam wrote: >>> Hi, >>> this patch fixes select_all checkbox issue, after any bulk modify or >>> delete operation, the checkbox is deselected. >>> https://fedorahosted.org/freeipa/ticket/4245 >>> >>> Thanks >>> Adam >>> >> >> The issue still exists in association facets and also maybe in >> attribute facet (group/external) (not tested). > > Hi, > thanks for the review, see the attached corrections! > Adam > ACK Pushed to master: 6aeb138e46044f6d2f124dfc3988391cf4906242 -- Petr Vobornik From mkosek at redhat.com Tue Apr 29 13:10:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Apr 2014 15:10:22 +0200 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <1398775718.10424.73.camel@willson.li.ssimo.org> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> <5357E819.6060700@redhat.com> <1398276468.2628.362.camel@willson.li.ssimo.org> <53582832.9010807@redhat.com> <5358DAFE.4070505@redhat.com> <535F8707.609@redhat.com> <535F9963.1020207@redhat.com> <1398775718.10424.73.camel@willson.li.ssimo.org> Message-ID: <535FA4BE.8000105@redhat.com> On 04/29/2014 02:48 PM, Simo Sorce wrote: > On Tue, 2014-04-29 at 14:21 +0200, Martin Kosek wrote: >> On 04/29/2014 01:03 PM, Petr Viktorin wrote: >>> On 04/24/2014 11:35 AM, Martin Kosek wrote: >>>> On 04/23/2014 10:53 PM, Martin Kosek wrote: >>>>> On 04/23/2014 08:07 PM, Simo Sorce wrote: >>> [...] >>>>>> >>>>>> I know, we may need to provide another permission admins can use to turn >>>>>> on anonymous searches for those attributes too. >>>>>> We may also decide that on upgrade vs new install we retain anonymous >>>>>> access. >>>>>> >>>>>> Simo. >>> >>> This is an interesting challenge. >>> We want the permission to be set to anonymous when: >>> 1) we're creating it, and >>> 2) the updater is *not* run from ipa-server-install (which would mean we're >>> installing a new cluster). >>> Full analysis below, [0] >>> >>> We discussed this on a meeting and it was mentioned that we can just start with >>> anonymous, and simply change to "all authenticated" at the end of >>> ipa-server-install. Thinking about it, I don't like that approach. >>> We may want an ACI audit tool [1] to list differences from defaults. >>> For uses like this, the metadata should list to up-to-date "best practices", >>> i.e. what you'd get with a fresh ipa-server-install. >>> So the metadata should list the bind type as all authenticated, and setting it >>> to anonymous should be handled as a special operation. >>> >>> This will be somewhat harder to code but I think it's worth it. >> >> I agree with Petr - managed permission definition should state our recommended >> and default access control that we are convinced that will fit most >> deployments. Restrictive or benevolent admins can always change the default >> with simple >> >> $ ipa permission-mod --bindtype=(all|anonymous|permission) >> >> call. >> >> Maybe the easiest way after all will be to list the changes in access control >> in the release note, compared to FreeIPA 3.x, e.g. >> >> 1) Host groups read access change from anonymous to authenticated by default >> 2) User calendar attributes read access change from anonymous to authenticated >> by default >> ... >> >> and educate users how they can change it if it does not fit their needs. IMO it >> may be more transparent and deterministic than to come with some hard coded >> changes in ipa-server-install that will create different defaults after upgrade >> and new installation. > > It will break working servers pretty badly, that's a big NO on my side. > > You do not want people to scramble understanding a new ACI system at > gunpoint because their production environment is broken. > > It is a little harder for us, true, but it is worth it. > > Simo. > User plugin is just one part of the change we do in access control. What about config object, hosts, host groups, ID ranges, netgroups, permissions, etc.? These are now accessible for authenticated users only and not for the anonymous. Should we then make them anonymous on upgrades as well? Then I doubt anyone would change it after upgrade to be more restricted default. I thought we created the new default to be the access control we recommend for most servers and which we expect to be present at most deployments. I.e. both on upgrades and new installations. Martin From simo at redhat.com Tue Apr 29 13:22:32 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Apr 2014 09:22:32 -0400 Subject: [Freeipa-devel] Draft: Read permissions for user In-Reply-To: <535FA4BE.8000105@redhat.com> References: <534D4852.2000405@redhat.com> <534E80CC.8060901@redhat.com> <1397655692.19767.394.camel@willson.li.ssimo.org> <534FBEC2.1040809@redhat.com> <5357D029.3010403@redhat.com> <1398266497.2628.345.camel@willson.li.ssimo.org> <5357E819.6060700@redhat.com> <1398276468.2628.362.camel@willson.li.ssimo.org> <53582832.9010807@redhat.com> <5358DAFE.4070505@redhat.com> <535F8707.609@redhat.com> <535F9963.1020207@redhat.com> <1398775718.10424.73.camel@willson.li.ssimo.org> <535FA4BE.8000105@redhat.com> Message-ID: <1398777752.10424.87.camel@willson.li.ssimo.org> On Tue, 2014-04-29 at 15:10 +0200, Martin Kosek wrote: > On 04/29/2014 02:48 PM, Simo Sorce wrote: > > On Tue, 2014-04-29 at 14:21 +0200, Martin Kosek wrote: > >> On 04/29/2014 01:03 PM, Petr Viktorin wrote: > >>> On 04/24/2014 11:35 AM, Martin Kosek wrote: > >>>> On 04/23/2014 10:53 PM, Martin Kosek wrote: > >>>>> On 04/23/2014 08:07 PM, Simo Sorce wrote: > >>> [...] > >>>>>> > >>>>>> I know, we may need to provide another permission admins can use to turn > >>>>>> on anonymous searches for those attributes too. > >>>>>> We may also decide that on upgrade vs new install we retain anonymous > >>>>>> access. > >>>>>> > >>>>>> Simo. > >>> > >>> This is an interesting challenge. > >>> We want the permission to be set to anonymous when: > >>> 1) we're creating it, and > >>> 2) the updater is *not* run from ipa-server-install (which would mean we're > >>> installing a new cluster). > >>> Full analysis below, [0] > >>> > >>> We discussed this on a meeting and it was mentioned that we can just start with > >>> anonymous, and simply change to "all authenticated" at the end of > >>> ipa-server-install. Thinking about it, I don't like that approach. > >>> We may want an ACI audit tool [1] to list differences from defaults. > >>> For uses like this, the metadata should list to up-to-date "best practices", > >>> i.e. what you'd get with a fresh ipa-server-install. > >>> So the metadata should list the bind type as all authenticated, and setting it > >>> to anonymous should be handled as a special operation. > >>> > >>> This will be somewhat harder to code but I think it's worth it. > >> > >> I agree with Petr - managed permission definition should state our recommended > >> and default access control that we are convinced that will fit most > >> deployments. Restrictive or benevolent admins can always change the default > >> with simple > >> > >> $ ipa permission-mod --bindtype=(all|anonymous|permission) > >> > >> call. > >> > >> Maybe the easiest way after all will be to list the changes in access control > >> in the release note, compared to FreeIPA 3.x, e.g. > >> > >> 1) Host groups read access change from anonymous to authenticated by default > >> 2) User calendar attributes read access change from anonymous to authenticated > >> by default > >> ... > >> > >> and educate users how they can change it if it does not fit their needs. IMO it > >> may be more transparent and deterministic than to come with some hard coded > >> changes in ipa-server-install that will create different defaults after upgrade > >> and new installation. > > > > It will break working servers pretty badly, that's a big NO on my side. > > > > You do not want people to scramble understanding a new ACI system at > > gunpoint because their production environment is broken. > > > > It is a little harder for us, true, but it is worth it. > > > > Simo. > > > > User plugin is just one part of the change we do in access control. What about > config object, hosts, host groups, ID ranges, netgroups, permissions, etc.? > These are now accessible for authenticated users only and not for the > anonymous. Should we then make them anonymous on upgrades as well? I think yes probably for netgroups ? > Then I doubt anyone would change it after upgrade to be more restricted > default. I thought we created the new default to be the access control we > recommend for most servers and which we expect to be present at most > deployments. I.e. both on upgrades and new installations. As usual this needs careful balance, the reason we use anonymous is for allowing historically challenge systems that do not use authentication to keep working. For those what we care about is only anything related to the old NIS maps, all of those need to be left accessible by anonymous if they are in the system being upgraded. Then we need to make a judgment call for other objects. permissions, host groups, ID ranges and all that are arguably only accessed by authenticated users normally, either by SSSD, which always authenticates, or the 'ipa' command which also authenticates and goes through the framework. The other bits of data that may be accessed anonymously if custom objects and addressbook data. For custom objects there is little we can do, as we have no way to know, and admins already know they need to be careful if they modify the tree, so it is fine to ignore those as long as we clearly document that we are changing the default from "anyone gets access w/o explicit ACIs" to "nobody gets access w/o explicit ACIs". For addressbook entries I think we really need to maintain whatever access is already allowed in the tree being upgraded. Because in most case mail programs are configured by users and if auth is not required people do not go out of their way to add auth credentials. So changing those would break users. Admins should be allowed to easily turn the knob of course. Any other attribute set need to be consider in a similar way: what is the most probable use case ? The answer tells you what we should do on upgrade. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From amisnyov at redhat.com Tue Apr 29 14:25:27 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 29 Apr 2014 16:25:27 +0200 Subject: [Freeipa-devel] [PATCH] webui: regression - enable fields on idrange type change (add) In-Reply-To: <535A5CB0.6010908@redhat.com> References: <535A5CB0.6010908@redhat.com> Message-ID: <20140429162527.1648f51a@unused-4-246.brq.redhat.com> On Fri, 25 Apr 2014 15:01:36 +0200 Petr Vobornik wrote: > ID range adder dialog was not properly addressed in field binding > refactoring. > > The usage of reset caused some weird loops. > > https://fedorahosted.org/freeipa/ticket/4326 tests with and without trusts ran smoothly, manual tests also, so ACK Thanks Adam From rcritten at redhat.com Tue Apr 29 14:27:13 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Apr 2014 10:27:13 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <535917F0.4050107@redhat.com> References: <52D99F70.3060305@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> <5350E5EA.2060106@redhat.com> <53580BE2.6050606@redhat.com> <535917F0.4050107@redhat.com> Message-ID: <535FB6C1.5080900@redhat.com> Petr Viktorin wrote: > On 04/23/2014 08:52 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/09/2014 11:29 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>>>>> [...] >>>>>>>>> >>>>>>>>> Here are a couple more enhancements I'm considering, this seems >>>>>>>>> simpler >>>>>>>>> than inter-diff since it is so small. >>>>>>>> >>>>>>>> Not really. Having a patch file with a sequence+revision number you >>>>>>>> can >>>>>>>> refer to has its merits. Especially in a hairy thread like this >>>>>>>> one. >>>>>>>> Also one of our MUAs wrapped the lines, I had to undo that >>>>>>>> manually. >>>>>>>> >>>>>>>>> Here is why I made the changes, in order: >>>>>>>>> >>>>>>>>> I doubled the calls to create the connection but one isn't in a >>>>>>>>> try/except!? Remove the obvious one. >>>>>>>>> >>>>>>>>> We currently completely eat GSSAPI errors, I figure we should log >>>>>>>>> failures. >>>>>>>>> >>>>>>>>> IPA stores the principal in the request context so using that will >>>>>>>>> save >>>>>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>>>>> >>>>>>>>> I included your content-type change. >>>>>>>> >>>>>>>> These changes look good. >>>>>>>> I'm almost done testing but I need to call it a week. >>>>>>> >>>>>>> Awesome, thanks. >>>>>> >>>>>> ACK on the functionality. >>>>>> >>>>>>>> Sorry for not catching that last time, but your patch doesn't add a >>>>>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>>>>> duplicate >>>>>>>> unversioned one. So lint (and thus the build) will fail if the old >>>>>>>> python-kerberos version is installed. >>>>>>>> >>>>>>>> A possible a solution to the build trouble would be to just add a >>>>>>>> lint >>>>>>>> exception now, and open a ticket to remove it later. That way the >>>>>>>> build >>>>>>>> succeeds despite the older version, and the new python-kerberos is >>>>>>>> only >>>>>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>>>>> That should make everyone happy, including Martin. >>>>>>>> Unfortunately our lint exception mechanism doesn't work on >>>>>>>> modules, so >>>>>>>> this needs a somewhat nastier hack. >>>>>>>> The attaching a patch that does this (and I'm pasting a simple diff >>>>>>>> below). Does that look okay to push? >>>>>>> >>>>>>> I'm trying to find a better solution to all this. I may end up >>>>>>> taking >>>>>>> Martin's suggestion of rawhide-only to avoid this sort of thing. >>>>>> >>>>>> Looks like you'll still need to silence pylint on f20 in that case. >>>>>> >>>>>>> The deal with the smartproxy is that you can/should be able to run >>>>>>> it on >>>>>>> any IPA-enrolled client, so you can run it directly on the Foreman >>>>>>> box, >>>>>>> with the IPA server somewhere else. What this means is that someone >>>>>>> could probably fairly easily package this up for other distributions >>>>>>> and >>>>>>> if we end up with a Fedora-only python-kerberos patch then >>>>>>> smartproxy is >>>>>>> Fedora-only as well. >>>>>>> >>>>>>> So I'm trying to get some movement out of upstream on this but it's >>>>>>> been >>>>>>> crickets for weeks. I think in the context of the calendar server >>>>>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll amp up >>>>>>> the >>>>>>> nagging to get some sort of response, even if it is "stop nagging >>>>>>> us!" >>>>>>> >>>>>>> rob >>>>>> >>>>>> Good luck! >>>>> >>>>> Ok, taking a different tack on this. Rather than running it as a >>>>> separate server process, run it as a WSGI app inside Apache. This >>>>> required a fair bit of re-tooling and complicates the set up a little >>>>> bit. I think I've got it all covered in the man page. >>>>> >>>>> On the python-kerberos front I've got bugs opened in Ubuntu and Debian >>>>> to see if we can get the patch accepted their until (if) upstream ever >>>>> takes a look. >>>> >>>> I decided to run the new WSGI app in a different process group, using >>>> the smartproxy we use for delegation. This simplifies the connection >>>> code, rather than using ldap2 like I was using, we use the RPC >>>> interface. And it provides to process separation. As a side-effect it >>>> will make running this code on platforms without GSSProxy a bit easier. >>>> >>>> rob >>>> >>> >>> Works great here! >>> >>> >>> The python-kerberos dependency issue still needs to be solved. >> >> Build is on the way to updates-testing if you can give it a go. >> >>> >>> The man page says: >>> Copy ipa-smartproxy-apache.conf to >>> /etc/httpd/conf.d/ipa-smartproxy.conf. >>> It would be nice to put the whole path here so people don't have to >>> search for the file. >> >> Done. >> >>> >>> The "Configure Apache to use smartproxy" line looks like a step to be >>> performed. It could use some emphasis to make it look like a header. >> >> I combined it with the subsequent sentence so hopefully it is a bit >> clearer. >> >> I also added a bit on testing so you can confirm that things are working. >> >> >>> Side note, cherrypy's routing makes requests like this possible: >>> http POST >>> :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass >>> >>> >>> >>> >>> Should that be allowed? >> >> It is definitely ugly but AFAICT it isn't illegal. The zero >> content-length bothers me more than this horrible-looking URI. It >> definitely requires some understanding of the ordering of parameters to >> get this call right. >> >> rob > > Everything works now! > Except one thing: json_encode_binary recently got a mandatory version > argument. For code that's part of IPA, it should be fine to just use > API_VERSION here. > > I tested with that added; ACK if you agree. ACK on your change. Sorry, one more set of changes, some fairly significant. This brings our proxy in line with the Foreman proxy functionality-wise. I tested this against a Foremane 1.5.0 RC1 build and it is fine. I didn't go as far as actually deploying any hosts but did confirm that the create/delete functions work ok. Significant changes: - random removed as an option. It is always true unless a user-provided password is sent. - Added an option to Command so that the real IPA error can be raised to make internal error handling possible. - Rather than returning an DuplicateEntry error when POSTing to an existing host, do a host_mod instead. - Add config option to pass updatedns=True when deleting a host. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-11-rest.patch Type: text/x-patch Size: 49931 bytes Desc: not available URL: From amisnyov at redhat.com Tue Apr 29 14:30:28 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 29 Apr 2014 16:30:28 +0200 Subject: [Freeipa-devel] [PATCH] 18 webui otptoken test data added In-Reply-To: <20140425171648.754632d7@unused-4-246.brq.redhat.com> References: <20140425171648.754632d7@unused-4-246.brq.redhat.com> Message-ID: <20140429163028.0ebf165e@unused-4-246.brq.redhat.com> On Fri, 25 Apr 2014 17:16:48 +0200 Misnyovszki Adam wrote: > Hi, > this patch adds some static test data for the webui otptoken part. > Adam Attached corrected DN's. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0018-2-webui-OTP-token-test-data-added.patch Type: text/x-patch Size: 12204 bytes Desc: not available URL: From pvoborni at redhat.com Tue Apr 29 16:11:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 29 Apr 2014 18:11:43 +0200 Subject: [Freeipa-devel] [PATCH] webui: regression - enable fields on idrange type change (add) In-Reply-To: <20140429162527.1648f51a@unused-4-246.brq.redhat.com> References: <535A5CB0.6010908@redhat.com> <20140429162527.1648f51a@unused-4-246.brq.redhat.com> Message-ID: <535FCF3F.2090009@redhat.com> On 29.4.2014 16:25, Misnyovszki Adam wrote: > On Fri, 25 Apr 2014 15:01:36 +0200 > Petr Vobornik wrote: > >> ID range adder dialog was not properly addressed in field binding >> refactoring. >> >> The usage of reset caused some weird loops. >> >> https://fedorahosted.org/freeipa/ticket/4326 > > tests with and without trusts ran smoothly, manual tests also, so > ACK > > Thanks > Adam > Pushed to master: 923c7ab7bc0eb361dae6e6fb3f05854499625368 -- Petr Vobornik From pviktori at redhat.com Tue Apr 29 16:23:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Apr 2014 18:23:33 +0200 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <535FB6C1.5080900@redhat.com> References: <52D99F70.3060305@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> <5350E5EA.2060106@redhat.com> <53580BE2.6050606@redhat.com> <535917F0.4050107@redhat.com> <535FB6C1.5080900@redhat.com> Message-ID: <535FD205.8080909@redhat.com> On 04/29/2014 04:27 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/23/2014 08:52 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 04/09/2014 11:29 PM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Here are a couple more enhancements I'm considering, this seems >>>>>>>>>> simpler >>>>>>>>>> than inter-diff since it is so small. >>>>>>>>> >>>>>>>>> Not really. Having a patch file with a sequence+revision number >>>>>>>>> you >>>>>>>>> can >>>>>>>>> refer to has its merits. Especially in a hairy thread like this >>>>>>>>> one. >>>>>>>>> Also one of our MUAs wrapped the lines, I had to undo that >>>>>>>>> manually. >>>>>>>>> >>>>>>>>>> Here is why I made the changes, in order: >>>>>>>>>> >>>>>>>>>> I doubled the calls to create the connection but one isn't in a >>>>>>>>>> try/except!? Remove the obvious one. >>>>>>>>>> >>>>>>>>>> We currently completely eat GSSAPI errors, I figure we should log >>>>>>>>>> failures. >>>>>>>>>> >>>>>>>>>> IPA stores the principal in the request context so using that >>>>>>>>>> will >>>>>>>>>> save >>>>>>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>>>>>> >>>>>>>>>> I included your content-type change. >>>>>>>>> >>>>>>>>> These changes look good. >>>>>>>>> I'm almost done testing but I need to call it a week. >>>>>>>> >>>>>>>> Awesome, thanks. >>>>>>> >>>>>>> ACK on the functionality. >>>>>>> >>>>>>>>> Sorry for not catching that last time, but your patch doesn't >>>>>>>>> add a >>>>>>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>>>>>> duplicate >>>>>>>>> unversioned one. So lint (and thus the build) will fail if the old >>>>>>>>> python-kerberos version is installed. >>>>>>>>> >>>>>>>>> A possible a solution to the build trouble would be to just add a >>>>>>>>> lint >>>>>>>>> exception now, and open a ticket to remove it later. That way the >>>>>>>>> build >>>>>>>>> succeeds despite the older version, and the new python-kerberos is >>>>>>>>> only >>>>>>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>>>>>> That should make everyone happy, including Martin. >>>>>>>>> Unfortunately our lint exception mechanism doesn't work on >>>>>>>>> modules, so >>>>>>>>> this needs a somewhat nastier hack. >>>>>>>>> The attaching a patch that does this (and I'm pasting a simple >>>>>>>>> diff >>>>>>>>> below). Does that look okay to push? >>>>>>>> >>>>>>>> I'm trying to find a better solution to all this. I may end up >>>>>>>> taking >>>>>>>> Martin's suggestion of rawhide-only to avoid this sort of thing. >>>>>>> >>>>>>> Looks like you'll still need to silence pylint on f20 in that case. >>>>>>> >>>>>>>> The deal with the smartproxy is that you can/should be able to run >>>>>>>> it on >>>>>>>> any IPA-enrolled client, so you can run it directly on the Foreman >>>>>>>> box, >>>>>>>> with the IPA server somewhere else. What this means is that someone >>>>>>>> could probably fairly easily package this up for other >>>>>>>> distributions >>>>>>>> and >>>>>>>> if we end up with a Fedora-only python-kerberos patch then >>>>>>>> smartproxy is >>>>>>>> Fedora-only as well. >>>>>>>> >>>>>>>> So I'm trying to get some movement out of upstream on this but it's >>>>>>>> been >>>>>>>> crickets for weeks. I think in the context of the calendar server >>>>>>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll >>>>>>>> amp up >>>>>>>> the >>>>>>>> nagging to get some sort of response, even if it is "stop nagging >>>>>>>> us!" >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> Good luck! >>>>>> >>>>>> Ok, taking a different tack on this. Rather than running it as a >>>>>> separate server process, run it as a WSGI app inside Apache. This >>>>>> required a fair bit of re-tooling and complicates the set up a little >>>>>> bit. I think I've got it all covered in the man page. >>>>>> >>>>>> On the python-kerberos front I've got bugs opened in Ubuntu and >>>>>> Debian >>>>>> to see if we can get the patch accepted their until (if) upstream >>>>>> ever >>>>>> takes a look. >>>>> >>>>> I decided to run the new WSGI app in a different process group, using >>>>> the smartproxy we use for delegation. This simplifies the connection >>>>> code, rather than using ldap2 like I was using, we use the RPC >>>>> interface. And it provides to process separation. As a side-effect it >>>>> will make running this code on platforms without GSSProxy a bit >>>>> easier. >>>>> >>>>> rob >>>>> >>>> >>>> Works great here! >>>> >>>> >>>> The python-kerberos dependency issue still needs to be solved. >>> >>> Build is on the way to updates-testing if you can give it a go. >>> >>>> >>>> The man page says: >>>> Copy ipa-smartproxy-apache.conf to >>>> /etc/httpd/conf.d/ipa-smartproxy.conf. >>>> It would be nice to put the whole path here so people don't have to >>>> search for the file. >>> >>> Done. >>> >>>> >>>> The "Configure Apache to use smartproxy" line looks like a step to be >>>> performed. It could use some emphasis to make it look like a header. >>> >>> I combined it with the subsequent sentence so hopefully it is a bit >>> clearer. >>> >>> I also added a bit on testing so you can confirm that things are >>> working. >>> >>> >>>> Side note, cherrypy's routing makes requests like this possible: >>>> http POST >>>> :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass >>>> >>>> >>>> >>>> >>>> >>>> Should that be allowed? >>> >>> It is definitely ugly but AFAICT it isn't illegal. The zero >>> content-length bothers me more than this horrible-looking URI. It >>> definitely requires some understanding of the ordering of parameters to >>> get this call right. >>> >>> rob >> >> Everything works now! >> Except one thing: json_encode_binary recently got a mandatory version >> argument. For code that's part of IPA, it should be fine to just use >> API_VERSION here. >> >> I tested with that added; ACK if you agree. > > ACK on your change. > > Sorry, one more set of changes, some fairly significant. This brings our > proxy in line with the Foreman proxy functionality-wise. I tested this > against a Foremane 1.5.0 RC1 build and it is fine. I didn't go as far as > actually deploying any hosts but did confirm that the create/delete > functions work ok. I've eyeballed the changes, no testing yet. Here are my thoughts. > Significant changes: > - random removed as an option. It is always true unless a user-provided > password is sent. > - Added an option to Command so that the real IPA error can be raised to > make internal error handling possible. Please use a bare `raise` for simple re-raising of exceptions in an except: clause. It'll preserve the traceback. The control flow for the masking/re-raising seems convoluted. I've seen code like the following before: if nomaskexception: nonmasked_exceptions = Exception else: nonmasked_exceptions = () try: something() except nonmasked_exceptions as e: raise except ConcreteException as e: raise_masked_exception(e) Also it might be useful to factor raise_masked_exception() out; see below. > - Rather than returning an DuplicateEntry error when POSTing to an > existing host, do a host_mod instead. Could you add a test for this? It looks like ip_address has no effect in this case, should we fail if it's given instead of silently ignoring it? Same for rebuilding new hosts. > - Add config option to pass updatedns=True when deleting a host. In DELETE, the exception handling seems overly broad. With a raise_masked_exception() function and nomaskexception, you could handle the specific error. It should help debugging if nothing else. This way of masking errors seems clumsy when nesting commands; I wonder if they can be handled better at a higher level ('request.error_response'?) -- Petr? From pviktori at redhat.com Tue Apr 29 18:00:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Apr 2014 20:00:48 +0200 Subject: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone Message-ID: <535FE8D0.7030608@redhat.com> This adds the "idnsSecInlineSigning" attribute and related option. https://fedorahosted.org/freeipa/ticket/3801 Simo, is adding a MAY attribute to an existing objectClass okay? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0543-dns-Add-idnsSecInlineSigning-attribute-add-dnssec-op.patch Type: text/x-patch Size: 9681 bytes Desc: not available URL: From ssorce at redhat.com Tue Apr 29 18:17:35 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 29 Apr 2014 14:17:35 -0400 Subject: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone In-Reply-To: <535FE8D0.7030608@redhat.com> References: <535FE8D0.7030608@redhat.com> Message-ID: <1398795455.10424.108.camel@willson.li.ssimo.org> On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote: > This adds the "idnsSecInlineSigning" attribute and related option. > > https://fedorahosted.org/freeipa/ticket/3801 > > Simo, is adding a MAY attribute to an existing objectClass okay? > Not unheard of, however in the past we discovered some schema replication issues that may have an impact, let's make sure DS team also agrees this is not going to cause issue. >From a purely functional pov a MAY attribute will not break any stored object, so it is fine. Simo. From mkosek at redhat.com Tue Apr 29 20:07:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Apr 2014 22:07:42 +0200 Subject: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone In-Reply-To: <1398795455.10424.108.camel@willson.li.ssimo.org> References: <535FE8D0.7030608@redhat.com> <1398795455.10424.108.camel@willson.li.ssimo.org> Message-ID: <5360068E.80805@redhat.com> On 04/29/2014 08:17 PM, Simo Sorce wrote: > On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote: >> This adds the "idnsSecInlineSigning" attribute and related option. >> >> https://fedorahosted.org/freeipa/ticket/3801 >> >> Simo, is adding a MAY attribute to an existing objectClass okay? >> > > Not unheard of, however in the past we discovered some schema > replication issues that may have an impact, let's make sure DS team also > agrees this is not going to cause issue. > >>From a purely functional pov a MAY attribute will not break any stored > object, so it is fine. > > Simo. Adding Thierry to the CC list to evaluate the risks, he was already involved in fixing related issue in the DS for a similar Dogtag schema extension. From pviktori at redhat.com Tue Apr 29 21:00:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Apr 2014 23:00:17 +0200 Subject: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user Message-ID: <536012E1.6080702@redhat.com> Patch 0540 adds a bunch of managed read ACIs for user, as discussed previously [0]. Patch 0541 is some minor refactoring for the next part. Patch 0542 sets the read acces to addressbook attributes to anonymous when upgrading from pre-4.0. I first this by checking if the update is run from ipa-server-install or not, but then I realized the logic I want is simple: if the global anon read ACI exists, we want to preserve its spirit by setting addressbook attribute ACI to anonymous. [0] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et al. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0540-Add-managed-read-permissions-to-user.patch Type: text/x-patch Size: 3731 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0541-update_managed_permissions-Pass-around-anonymous-ACI.patch Type: text/x-patch Size: 4962 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0542-Set-user-addressbook-attribute-read-ACI-to-anonymous.patch Type: text/x-patch Size: 3824 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 29 21:02:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Apr 2014 23:02:57 +0200 Subject: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI Message-ID: <53601381.9050207@redhat.com> I didn't test this as much as I'd like to, but it might come in handy when testing my earlier patches. The ACI is removed in the managed permissions plugin because I want to make sure it's done after all the managed permission updates, which query it. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0544-Remove-the-global-anonymous-read-ACI.patch Type: text/x-patch Size: 8916 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 29 21:34:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 29 Apr 2014 23:34:10 +0200 Subject: [Freeipa-devel] [PATCH 0251-0256] Add support for NSEC3 Message-ID: <53601AD2.9070806@redhat.com> Hello, This patch set adds support for NSEC3. See commit messages for details. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0251-Fix-false-error-message-about-secure-zones.patch Type: text/x-patch Size: 2045 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0252-Separate-LDAP-entry-initialization-and-allocation.patch Type: text/x-patch Size: 3867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0253-Fix-incorrect-ATTR_NONNULLS-usage.patch Type: text/x-patch Size: 2237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0254-Remove-KEY-SIG-DNSKEY-RRSIG-and-NSEC-records-from-LD.patch Type: text/x-patch Size: 2595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0255-Add-new-attributes-required-for-DNSSEC-integration-t.patch Type: text/x-patch Size: 1902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0256-Add-support-for-NSEC3.patch Type: text/x-patch Size: 5156 bytes Desc: not available URL: From redhatrises at gmail.com Wed Apr 30 02:04:36 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 29 Apr 2014 20:04:36 -0600 Subject: [Freeipa-devel] [PATCH] Stop ntpd before running ntpdate In-Reply-To: References: <535F4DED.8090004@redhat.com> Message-ID: Updated patch to not run ntpdate if ntpd is running. Gabe On Tue, Apr 29, 2014 at 8:16 AM, Gabe Alford wrote: > Thanks Petr! > > Will rework patch to just skip ntpdate if ntpd is already running. > > > On Tue, Apr 29, 2014 at 12:59 AM, Petr Spacek wrote: > >> Hello Gabe! >> >> >> On 25.4.2014 16:28, Gabe Alford wrote: >> >>> Here is a patch for https://fedorahosted.org/ >>> freeipa/ticket/3735. >>> It seemed better to try to stop ntpd before running ntpdate rather than >>> not >>> running ntpdate if ntpd was already running. I believe this patch only >>> applies to the ipa-3-3 branch as ntpdate is not used anymore in the >>> master. >>> >> >> IMHO we should never stop ntpd if it is running. Plain ntpdate opens >> potential security hole because attacker can fake NTP answers and force the >> machine to rewind it's clock to the past. >> >> This opens potential for replay attacks/re-suing old compromised keys etc. >> >> -- >> Petr^2 Spacek >> >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0017-2-ipa-client-install-skip-running-ntpdate-if-ntpd-is-r.patch Type: text/x-patch Size: 2663 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 30 03:11:43 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Apr 2014 23:11:43 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <535FD205.8080909@redhat.com> References: <52D99F70.3060305@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> <5350E5EA.2060106@redhat.com> <53580BE2.6050606@redhat.com> <535917F0.4050107@redhat.com> <535FB6C1.5080900@redhat.com> <535FD205.8080909@redhat.com> Message-ID: <536069EF.6090306@redhat.com> Petr Viktorin wrote: > On 04/29/2014 04:27 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/23/2014 08:52 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 04/09/2014 11:29 PM, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>>>>>>> Petr Viktorin wrote: >>>>>>>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>> Here are a couple more enhancements I'm considering, this seems >>>>>>>>>>> simpler >>>>>>>>>>> than inter-diff since it is so small. >>>>>>>>>> >>>>>>>>>> Not really. Having a patch file with a sequence+revision number >>>>>>>>>> you >>>>>>>>>> can >>>>>>>>>> refer to has its merits. Especially in a hairy thread like this >>>>>>>>>> one. >>>>>>>>>> Also one of our MUAs wrapped the lines, I had to undo that >>>>>>>>>> manually. >>>>>>>>>> >>>>>>>>>>> Here is why I made the changes, in order: >>>>>>>>>>> >>>>>>>>>>> I doubled the calls to create the connection but one isn't in a >>>>>>>>>>> try/except!? Remove the obvious one. >>>>>>>>>>> >>>>>>>>>>> We currently completely eat GSSAPI errors, I figure we should >>>>>>>>>>> log >>>>>>>>>>> failures. >>>>>>>>>>> >>>>>>>>>>> IPA stores the principal in the request context so using that >>>>>>>>>>> will >>>>>>>>>>> save >>>>>>>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>>>>>>> >>>>>>>>>>> I included your content-type change. >>>>>>>>>> >>>>>>>>>> These changes look good. >>>>>>>>>> I'm almost done testing but I need to call it a week. >>>>>>>>> >>>>>>>>> Awesome, thanks. >>>>>>>> >>>>>>>> ACK on the functionality. >>>>>>>> >>>>>>>>>> Sorry for not catching that last time, but your patch doesn't >>>>>>>>>> add a >>>>>>>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>>>>>>> duplicate >>>>>>>>>> unversioned one. So lint (and thus the build) will fail if the >>>>>>>>>> old >>>>>>>>>> python-kerberos version is installed. >>>>>>>>>> >>>>>>>>>> A possible a solution to the build trouble would be to just add a >>>>>>>>>> lint >>>>>>>>>> exception now, and open a ticket to remove it later. That way the >>>>>>>>>> build >>>>>>>>>> succeeds despite the older version, and the new >>>>>>>>>> python-kerberos is >>>>>>>>>> only >>>>>>>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>>>>>>> That should make everyone happy, including Martin. >>>>>>>>>> Unfortunately our lint exception mechanism doesn't work on >>>>>>>>>> modules, so >>>>>>>>>> this needs a somewhat nastier hack. >>>>>>>>>> The attaching a patch that does this (and I'm pasting a simple >>>>>>>>>> diff >>>>>>>>>> below). Does that look okay to push? >>>>>>>>> >>>>>>>>> I'm trying to find a better solution to all this. I may end up >>>>>>>>> taking >>>>>>>>> Martin's suggestion of rawhide-only to avoid this sort of thing. >>>>>>>> >>>>>>>> Looks like you'll still need to silence pylint on f20 in that case. >>>>>>>> >>>>>>>>> The deal with the smartproxy is that you can/should be able to run >>>>>>>>> it on >>>>>>>>> any IPA-enrolled client, so you can run it directly on the Foreman >>>>>>>>> box, >>>>>>>>> with the IPA server somewhere else. What this means is that >>>>>>>>> someone >>>>>>>>> could probably fairly easily package this up for other >>>>>>>>> distributions >>>>>>>>> and >>>>>>>>> if we end up with a Fedora-only python-kerberos patch then >>>>>>>>> smartproxy is >>>>>>>>> Fedora-only as well. >>>>>>>>> >>>>>>>>> So I'm trying to get some movement out of upstream on this but >>>>>>>>> it's >>>>>>>>> been >>>>>>>>> crickets for weeks. I think in the context of the calendar server >>>>>>>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll >>>>>>>>> amp up >>>>>>>>> the >>>>>>>>> nagging to get some sort of response, even if it is "stop nagging >>>>>>>>> us!" >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> Good luck! >>>>>>> >>>>>>> Ok, taking a different tack on this. Rather than running it as a >>>>>>> separate server process, run it as a WSGI app inside Apache. This >>>>>>> required a fair bit of re-tooling and complicates the set up a >>>>>>> little >>>>>>> bit. I think I've got it all covered in the man page. >>>>>>> >>>>>>> On the python-kerberos front I've got bugs opened in Ubuntu and >>>>>>> Debian >>>>>>> to see if we can get the patch accepted their until (if) upstream >>>>>>> ever >>>>>>> takes a look. >>>>>> >>>>>> I decided to run the new WSGI app in a different process group, using >>>>>> the smartproxy we use for delegation. This simplifies the connection >>>>>> code, rather than using ldap2 like I was using, we use the RPC >>>>>> interface. And it provides to process separation. As a side-effect it >>>>>> will make running this code on platforms without GSSProxy a bit >>>>>> easier. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> Works great here! >>>>> >>>>> >>>>> The python-kerberos dependency issue still needs to be solved. >>>> >>>> Build is on the way to updates-testing if you can give it a go. >>>> >>>>> >>>>> The man page says: >>>>> Copy ipa-smartproxy-apache.conf to >>>>> /etc/httpd/conf.d/ipa-smartproxy.conf. >>>>> It would be nice to put the whole path here so people don't have to >>>>> search for the file. >>>> >>>> Done. >>>> >>>>> >>>>> The "Configure Apache to use smartproxy" line looks like a step to be >>>>> performed. It could use some emphasis to make it look like a header. >>>> >>>> I combined it with the subsequent sentence so hopefully it is a bit >>>> clearer. >>>> >>>> I also added a bit on testing so you can confirm that things are >>>> working. >>>> >>>> >>>>> Side note, cherrypy's routing makes requests like this possible: >>>>> http POST >>>>> :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Should that be allowed? >>>> >>>> It is definitely ugly but AFAICT it isn't illegal. The zero >>>> content-length bothers me more than this horrible-looking URI. It >>>> definitely requires some understanding of the ordering of parameters to >>>> get this call right. >>>> >>>> rob >>> >>> Everything works now! >>> Except one thing: json_encode_binary recently got a mandatory version >>> argument. For code that's part of IPA, it should be fine to just use >>> API_VERSION here. >>> >>> I tested with that added; ACK if you agree. >> >> ACK on your change. >> >> Sorry, one more set of changes, some fairly significant. This brings our >> proxy in line with the Foreman proxy functionality-wise. I tested this >> against a Foremane 1.5.0 RC1 build and it is fine. I didn't go as far as >> actually deploying any hosts but did confirm that the create/delete >> functions work ok. > > I've eyeballed the changes, no testing yet. Here are my thoughts. > >> Significant changes: >> - random removed as an option. It is always true unless a user-provided >> password is sent. >> - Added an option to Command so that the real IPA error can be raised to >> make internal error handling possible. > > Please use a bare `raise` for simple re-raising of exceptions in an > except: clause. It'll preserve the traceback. > > The control flow for the masking/re-raising seems convoluted. I've seen > code like the following before: > > if nomaskexception: > nonmasked_exceptions = Exception > else: > nonmasked_exceptions = () > > try: > something() > except nonmasked_exceptions as e: > raise > except ConcreteException as e: > raise_masked_exception(e) > > > Also it might be useful to factor raise_masked_exception() out; see below. Good idea. I sort of split the difference. > >> - Rather than returning an DuplicateEntry error when POSTing to an >> existing host, do a host_mod instead. > > Could you add a test for this? > > It looks like ip_address has no effect in this case, should we fail if > it's given instead of silently ignoring it? Same for rebuilding new hosts. Done both. > >> - Add config option to pass updatedns=True when deleting a host. > > In DELETE, the exception handling seems overly broad. With a > raise_masked_exception() function and nomaskexception, you could handle > the specific error. It should help debugging if nothing else. > > This way of masking errors seems clumsy when nesting commands; I wonder > if they can be handled better at a higher level ('request.error_response'?) Yes. I imagine that the Foreman smartproxy is doing this to mask the issue as well. I dropped it, doing a GET instead so we'll get the proper error in any case. It's a bit racy but it won't be as unnerving as running into https://fedorahosted.org/freeipa/ticket/4329 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-12-rest.patch Type: text/x-patch Size: 50986 bytes Desc: not available URL: From ftweedal at redhat.com Wed Apr 30 06:21:30 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 30 Apr 2014 16:21:30 +1000 Subject: [Freeipa-devel] new developer; development environment Message-ID: <20140430062130.GC21845@dhcp-40-8.bne.redhat.com> Hi all, Fraser Tweedale, brand new Red Hatter, working in the Brisbane office on FreeIPA/Dogtag, and needing the wisdom of seasoned IPA developers on how best to set things up. In particular, is it common to be developing in VMs, and if so, do the various components (DS, Dogtag, IPA etc) under (or involved in) development reside on the same host? Are there any developer images that are ready to roll? Or if it is more common to simply develop on one's workstation directly, do you have any tips to doing this sanely? freeipa seemed find to build but the pki build seems to want root, which scares me a little... but perhaps I am just Doing It Wrong. Thanks in advance for any advice, and I look forward to getting to you know you all. Cheers, Fraser From abokovoy at redhat.com Wed Apr 30 06:34:10 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 30 Apr 2014 09:34:10 +0300 Subject: [Freeipa-devel] new developer; development environment In-Reply-To: <20140430062130.GC21845@dhcp-40-8.bne.redhat.com> References: <20140430062130.GC21845@dhcp-40-8.bne.redhat.com> Message-ID: <20140430063410.GP20958@redhat.com> On Wed, 30 Apr 2014, Fraser Tweedale wrote: >Hi all, > >Fraser Tweedale, brand new Red Hatter, working in the Brisbane >office on FreeIPA/Dogtag, and needing the wisdom of seasoned IPA >developers on how best to set things up. Welcome Fraser! >In particular, is it common to be developing in VMs, and if so, do >the various components (DS, Dogtag, IPA etc) under (or involved in) >development reside on the same host? Are there any developer images >that are ready to roll? Almost everyone is developing in VMs these days. The way IPA is installed, all components comprising a single master run on the same host. You can simply start by kicking off a VM based on Fedora 20 ISOs and then either do 'yum install freeipa-server' in the VM or select FreeIPA server target in graphical UI in anaconda installer. Regarding development profile, look at BUILD.txt in freeipa git repo, it has a recipe to install required development packages. -- / Alexander Bokovoy From mkosek at redhat.com Wed Apr 30 07:12:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Apr 2014 09:12:11 +0200 Subject: [Freeipa-devel] new developer; development environment In-Reply-To: <20140430062130.GC21845@dhcp-40-8.bne.redhat.com> References: <20140430062130.GC21845@dhcp-40-8.bne.redhat.com> Message-ID: <5360A24B.9020906@redhat.com> On 04/30/2014 08:21 AM, Fraser Tweedale wrote: > Hi all, > > Fraser Tweedale, brand new Red Hatter, working in the Brisbane > office on FreeIPA/Dogtag, and needing the wisdom of seasoned IPA > developers on how best to set things up. > > In particular, is it common to be developing in VMs, and if so, do > the various components (DS, Dogtag, IPA etc) under (or involved in) > development reside on the same host? Are there any developer images > that are ready to roll? > > Or if it is more common to simply develop on one's workstation > directly, do you have any tips to doing this sanely? freeipa seemed > find to build but the pki build seems to want root, which scares me > a little... but perhaps I am just Doing It Wrong. > > Thanks in advance for any advice, and I look forward to getting to > you know you all. > > Cheers, > > Fraser Welcome Fraser! I can share with you my workflow. I also do everything on VMs in our RHEV-M lab. In basic scenarios, you will be OK with just one Fedora or RHEL VM where you build and install all packages built from git (make rpms). Then you simply add more VMs when dealing with replication, clients, ... We tried to capture all the basic information on this page: http://www.freeipa.org/page/Contribute/Code and the linked pages. You now also have an unique opportunity to see that these pages are helpful to new developers and potentially help and improve them :) Martin From pspacek at redhat.com Wed Apr 30 07:57:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 30 Apr 2014 09:57:27 +0200 Subject: [Freeipa-devel] new developer; development environment In-Reply-To: <5360A24B.9020906@redhat.com> References: <20140430062130.GC21845@dhcp-40-8.bne.redhat.com> <5360A24B.9020906@redhat.com> Message-ID: <5360ACE7.5060908@redhat.com> On 30.4.2014 09:12, Martin Kosek wrote: > On 04/30/2014 08:21 AM, Fraser Tweedale wrote: >> Hi all, >> >> Fraser Tweedale, brand new Red Hatter, working in the Brisbane >> office on FreeIPA/Dogtag, and needing the wisdom of seasoned IPA >> developers on how best to set things up. >> >> In particular, is it common to be developing in VMs, and if so, do >> the various components (DS, Dogtag, IPA etc) under (or involved in) >> development reside on the same host? Are there any developer images >> that are ready to roll? >> >> Or if it is more common to simply develop on one's workstation >> directly, do you have any tips to doing this sanely? freeipa seemed >> find to build but the pki build seems to want root, which scares me >> a little... but perhaps I am just Doing It Wrong. >> >> Thanks in advance for any advice, and I look forward to getting to >> you know you all. >> >> Cheers, >> >> Fraser > > Welcome Fraser! > > I can share with you my workflow. I also do everything on VMs in our RHEV-M lab. > > In basic scenarios, you will be OK with just one Fedora or RHEL VM where you > build and install all packages built from git (make rpms). Then you simply add > more VMs when dealing with replication, clients, ... > > We tried to capture all the basic information on this page: > http://www.freeipa.org/page/Contribute/Code > > and the linked pages. You now also have an unique opportunity to see that these > pages are helpful to new developers and potentially help and improve them :) Yes! Freeipa.org wiki accepts ordinary Fedora Accounts so please correct any mistakes/outdated information you encounter during your journey. Thank you very much! -- Petr^2 Spacek From tbordaz at redhat.com Wed Apr 30 08:00:05 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 30 Apr 2014 10:00:05 +0200 Subject: [Freeipa-devel] [PATCH] 0543 - dns: Add idnsSecInlineSigning attribute, add --dnssec option to zone In-Reply-To: <5360068E.80805@redhat.com> References: <535FE8D0.7030608@redhat.com> <1398795455.10424.108.camel@willson.li.ssimo.org> <5360068E.80805@redhat.com> Message-ID: <5360AD85.9010802@redhat.com> On 04/29/2014 10:07 PM, Martin Kosek wrote: > On 04/29/2014 08:17 PM, Simo Sorce wrote: >> On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote: >>> This adds the "idnsSecInlineSigning" attribute and related option. >>> >>> https://fedorahosted.org/freeipa/ticket/3801 >>> >>> Simo, is adding a MAY attribute to an existing objectClass okay? >>> >> >> Not unheard of, however in the past we discovered some schema >> replication issues that may have an impact, let's make sure DS team also >> agrees this is not going to cause issue. >> >>> From a purely functional pov a MAY attribute will not break any stored >> object, so it is fine. >> >> Simo. > > Adding Thierry to the CC list to evaluate the risks, he was already > involved in fixing related issue in the DS for a similar Dogtag schema > extension. Hello, When an instance in the topology contains schema extensions like new MAY attribute, this extension would be propagated to all instances by replication (no need to copy/merge schema files). This was the purpose of https://fedorahosted.org/389/ticket/47721. So it is fine to add new MAY/MUST attribute or new attribute/objectclasses. During a replication session, a master will check what schema definitions (objectclasses/attributes) of the replica extends its own schema. If such definitions exist the supplier add/replace them in its schema and its user99.ldif file. In your case if a replica contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but not the supplier then the supplier 'learns it' (during a replication session it initiated) and so an entry containing that new attribute can be updated on the supplier as well. There is a similar mechanism, when a replica receives a schema that contains new definitions, it 'learns' them. The fix for 47721 is introduced in 389-ds 1.3.2.17 and after. It was tested with mixing 1.3.2.17 instance with legacy versions (1.3.1, 1,3.0..), and the schema on both side converged to a common one. This, whatever if the extensions are present on both side. A limitation is that a legacy instance (not having the fix), must have a replica agreements to/from an instance with the fix. regards thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Apr 30 08:40:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 30 Apr 2014 10:40:43 +0200 Subject: [Freeipa-devel] [PATCH] 589-590 webui-ci: save screenshot on test failure Message-ID: <5360B70B.7010004@redhat.com> Very handy for debugging failures... New decorator: ui_driver.screenshot created. It should be applied on test methods. Screenshot is saved on each exception except SkipTest. Configuration: - add: `save_screenshots: True` to ~/.ipa/ui_test.conf to enable saving screenshots - optionally add `screenshot_dir: /path/to/dir` to specify target directory otherwise screenshots are saved to current directory -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0590-webui-ci-decorate-all-webui-tests-with-screenshot-de.patch Type: text/x-patch Size: 25212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0589-webui-ci-save-screenshot-on-test-failure.patch Type: text/x-patch Size: 2572 bytes Desc: not available URL: From tbabej at redhat.com Wed Apr 30 09:05:52 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Apr 2014 11:05:52 +0200 Subject: [Freeipa-devel] [PATCH 0167] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <20140324142737.GK3872@redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> <533039CA.2060007@redhat.com> <20140324142737.GK3872@redhat.com> Message-ID: <5360BCF0.1030101@redhat.com> On 03/24/2014 03:27 PM, Jan Pazdziora wrote: > On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: >> On 03/24/2014 02:47 PM, Jan Pazdziora wrote: >>> On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: >>>> Hi, >>>> >>>> Makes ipa-client-install configure SSSD as the data provider >>>> for the sudo service by default. This behaviour can be disabled >>>> by using --no-sudo flag. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3358 >>> Ack. >>> >>> Applied against ipa-client-3.0.0-37.el6.x86_64, tried without >>> --no-sudo and sudo was added to sssd.conf's services list and sudoeers >>> added to /etc/nsswitch.conf. >>> >>> Rerun with --uninstall and run again with the --no-sudo parameter, >>> those settings were not longer there. >>> >> Did you also do the functional test? > No. I do not want to get dragged into the discussion of having the > correct sssd and sudo and glibc versions and SELinux and stuff. The > ticket explicitly talk about setting configuration in config files, > which the patch does. > >> To ack and push this ticket, following >> scenario needs to work: > Consumption of those configuration changes is really different story, > isn't it? > >> 1) IPA clients enroll against IPA server without --no-sudo >> 2) IPA client user logs in, types "sudo -l", gets all allowed commands >> (prerequisite is of course to have sudo commands defined on the IPA server) >> 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all >> allowed commands >> >> For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done >> >> For 3) to work, related systemd service preserving NIS domain name setting >> needs to be enabled > With the commit message only talking about configuring sssd, I assume > the NIS domain name mentioned in the ticket will be done by some other > patch. > > To me, the patch does what is advertised in the commit message, and is > in line with what the ticket asks to be done. > Attached are rebased versions of the patches 113 and 167 (which was marked as 157 in the thread previously by mistake). There is a slight behaviour change in 167, if there is no sudoers line in nsswitch.conf, we add both files and sss as sudoers sources. I also developed CI test that covers the functionality of the IPA - sudo integration feature, which is attached. Please note that the last three tests are expected to fail until: https://fedorahosted.org/freeipa/ticket/4324 is fixed. -- 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-0167-2-ipa-client-install-Configure-sudo-to-use-SSSD-as-dat.patch Type: text/x-patch Size: 4923 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0179-ipatests-Add-Sudo-integration-test.patch Type: text/x-patch Size: 16257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0113-2-ipa-client-Set-NIS-domain-name-in-the-installer.patch Type: text/x-patch Size: 7323 bytes Desc: not available URL: From pvoborni at redhat.com Wed Apr 30 10:28:45 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 30 Apr 2014 12:28:45 +0200 Subject: [Freeipa-devel] [PATCH] 591 webui: add idnsSecInlineSigning option to DNS zone details facet Message-ID: <5360D05D.6090506@redhat.com> Web UI part of pviktori-543 https://fedorahosted.org/freeipa/ticket/3801 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0591-webui-add-idnsSecInlineSigning-option-to-DNS-zone-de.patch Type: text/x-patch Size: 963 bytes Desc: not available URL: From pvoborni at redhat.com Wed Apr 30 11:37:10 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 30 Apr 2014 13:37:10 +0200 Subject: [Freeipa-devel] [PATCH] 18 webui otptoken test data added In-Reply-To: <20140429163028.0ebf165e@unused-4-246.brq.redhat.com> References: <20140425171648.754632d7@unused-4-246.brq.redhat.com> <20140429163028.0ebf165e@unused-4-246.brq.redhat.com> Message-ID: <5360E066.5070804@redhat.com> On 29.4.2014 16:30, Misnyovszki Adam wrote: > On Fri, 25 Apr 2014 17:16:48 +0200 > Misnyovszki Adam wrote: > >> Hi, >> this patch adds some static test data for the webui otptoken part. >> Adam > > Attached corrected DN's. > Thanks > Adam > 1) Why otptoken_batch_del.json ends with error? Also there might be a defect in UI that for batch delete operation it asks for batch.json and not $ENTITY_batch_del.json making otptoken_batch_del.json unused - out of scope of this patch. 2) Why otptoken_mod.json ends with error? 3) otptoken_find.json is not needed since the search facet uses paging (combination of otptoken_get_records.json and otptoken_find_pkeys.json is enough). In general, it's OK to fake the data if there is some bug which causes errors and we know that it will be fixed. -- Petr Vobornik From pviktori at redhat.com Wed Apr 30 12:11:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Apr 2014 14:11:03 +0200 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <536069EF.6090306@redhat.com> References: <52D99F70.3060305@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> <5350E5EA.2060106@redhat.com> <53580BE2.6050606@redhat.com> <535917F0.4050107@redhat.com> <535FB6C1.5080900@redhat.com> <535FD205.8080909@redhat.com> <536069EF.6090306@redhat.com> Message-ID: <5360E857.5030609@redhat.com> On 04/30/2014 05:11 AM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/29/2014 04:27 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 04/23/2014 08:52 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 04/09/2014 11:29 PM, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>>>>>>>> [...] >>>>>>>>>>>> >>>>>>>>>>>> Here are a couple more enhancements I'm considering, this seems >>>>>>>>>>>> simpler >>>>>>>>>>>> than inter-diff since it is so small. >>>>>>>>>>> >>>>>>>>>>> Not really. Having a patch file with a sequence+revision number >>>>>>>>>>> you >>>>>>>>>>> can >>>>>>>>>>> refer to has its merits. Especially in a hairy thread like this >>>>>>>>>>> one. >>>>>>>>>>> Also one of our MUAs wrapped the lines, I had to undo that >>>>>>>>>>> manually. >>>>>>>>>>> >>>>>>>>>>>> Here is why I made the changes, in order: >>>>>>>>>>>> >>>>>>>>>>>> I doubled the calls to create the connection but one isn't in a >>>>>>>>>>>> try/except!? Remove the obvious one. >>>>>>>>>>>> >>>>>>>>>>>> We currently completely eat GSSAPI errors, I figure we should >>>>>>>>>>>> log >>>>>>>>>>>> failures. >>>>>>>>>>>> >>>>>>>>>>>> IPA stores the principal in the request context so using that >>>>>>>>>>>> will >>>>>>>>>>>> save >>>>>>>>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>>>>>>>> >>>>>>>>>>>> I included your content-type change. >>>>>>>>>>> >>>>>>>>>>> These changes look good. >>>>>>>>>>> I'm almost done testing but I need to call it a week. >>>>>>>>>> >>>>>>>>>> Awesome, thanks. >>>>>>>>> >>>>>>>>> ACK on the functionality. >>>>>>>>> >>>>>>>>>>> Sorry for not catching that last time, but your patch doesn't >>>>>>>>>>> add a >>>>>>>>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>>>>>>>> duplicate >>>>>>>>>>> unversioned one. So lint (and thus the build) will fail if the >>>>>>>>>>> old >>>>>>>>>>> python-kerberos version is installed. >>>>>>>>>>> >>>>>>>>>>> A possible a solution to the build trouble would be to just >>>>>>>>>>> add a >>>>>>>>>>> lint >>>>>>>>>>> exception now, and open a ticket to remove it later. That way >>>>>>>>>>> the >>>>>>>>>>> build >>>>>>>>>>> succeeds despite the older version, and the new >>>>>>>>>>> python-kerberos is >>>>>>>>>>> only >>>>>>>>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>>>>>>>> That should make everyone happy, including Martin. >>>>>>>>>>> Unfortunately our lint exception mechanism doesn't work on >>>>>>>>>>> modules, so >>>>>>>>>>> this needs a somewhat nastier hack. >>>>>>>>>>> The attaching a patch that does this (and I'm pasting a simple >>>>>>>>>>> diff >>>>>>>>>>> below). Does that look okay to push? >>>>>>>>>> >>>>>>>>>> I'm trying to find a better solution to all this. I may end up >>>>>>>>>> taking >>>>>>>>>> Martin's suggestion of rawhide-only to avoid this sort of thing. >>>>>>>>> >>>>>>>>> Looks like you'll still need to silence pylint on f20 in that >>>>>>>>> case. >>>>>>>>> >>>>>>>>>> The deal with the smartproxy is that you can/should be able to >>>>>>>>>> run >>>>>>>>>> it on >>>>>>>>>> any IPA-enrolled client, so you can run it directly on the >>>>>>>>>> Foreman >>>>>>>>>> box, >>>>>>>>>> with the IPA server somewhere else. What this means is that >>>>>>>>>> someone >>>>>>>>>> could probably fairly easily package this up for other >>>>>>>>>> distributions >>>>>>>>>> and >>>>>>>>>> if we end up with a Fedora-only python-kerberos patch then >>>>>>>>>> smartproxy is >>>>>>>>>> Fedora-only as well. >>>>>>>>>> >>>>>>>>>> So I'm trying to get some movement out of upstream on this but >>>>>>>>>> it's >>>>>>>>>> been >>>>>>>>>> crickets for weeks. I think in the context of the calendar server >>>>>>>>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll >>>>>>>>>> amp up >>>>>>>>>> the >>>>>>>>>> nagging to get some sort of response, even if it is "stop nagging >>>>>>>>>> us!" >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> Good luck! >>>>>>>> >>>>>>>> Ok, taking a different tack on this. Rather than running it as a >>>>>>>> separate server process, run it as a WSGI app inside Apache. This >>>>>>>> required a fair bit of re-tooling and complicates the set up a >>>>>>>> little >>>>>>>> bit. I think I've got it all covered in the man page. >>>>>>>> >>>>>>>> On the python-kerberos front I've got bugs opened in Ubuntu and >>>>>>>> Debian >>>>>>>> to see if we can get the patch accepted their until (if) upstream >>>>>>>> ever >>>>>>>> takes a look. >>>>>>> >>>>>>> I decided to run the new WSGI app in a different process group, >>>>>>> using >>>>>>> the smartproxy we use for delegation. This simplifies the connection >>>>>>> code, rather than using ldap2 like I was using, we use the RPC >>>>>>> interface. And it provides to process separation. As a >>>>>>> side-effect it >>>>>>> will make running this code on platforms without GSSProxy a bit >>>>>>> easier. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Works great here! >>>>>> >>>>>> >>>>>> The python-kerberos dependency issue still needs to be solved. >>>>> >>>>> Build is on the way to updates-testing if you can give it a go. >>>>> >>>>>> >>>>>> The man page says: >>>>>> Copy ipa-smartproxy-apache.conf to >>>>>> /etc/httpd/conf.d/ipa-smartproxy.conf. >>>>>> It would be nice to put the whole path here so people don't have to >>>>>> search for the file. >>>>> >>>>> Done. >>>>> >>>>>> >>>>>> The "Configure Apache to use smartproxy" line looks like a step to be >>>>>> performed. It could use some emphasis to make it look like a header. >>>>> >>>>> I combined it with the subsequent sentence so hopefully it is a bit >>>>> clearer. >>>>> >>>>> I also added a bit on testing so you can confirm that things are >>>>> working. >>>>> >>>>> >>>>>> Side note, cherrypy's routing makes requests like this possible: >>>>>> http POST >>>>>> :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Should that be allowed? >>>>> >>>>> It is definitely ugly but AFAICT it isn't illegal. The zero >>>>> content-length bothers me more than this horrible-looking URI. It >>>>> definitely requires some understanding of the ordering of >>>>> parameters to >>>>> get this call right. >>>>> >>>>> rob >>>> >>>> Everything works now! >>>> Except one thing: json_encode_binary recently got a mandatory version >>>> argument. For code that's part of IPA, it should be fine to just use >>>> API_VERSION here. >>>> >>>> I tested with that added; ACK if you agree. >>> >>> ACK on your change. >>> >>> Sorry, one more set of changes, some fairly significant. This brings our >>> proxy in line with the Foreman proxy functionality-wise. I tested this >>> against a Foremane 1.5.0 RC1 build and it is fine. I didn't go as far as >>> actually deploying any hosts but did confirm that the create/delete >>> functions work ok. >> >> I've eyeballed the changes, no testing yet. Here are my thoughts. >> >>> Significant changes: >>> - random removed as an option. It is always true unless a user-provided >>> password is sent. >>> - Added an option to Command so that the real IPA error can be raised to >>> make internal error handling possible. >> >> Please use a bare `raise` for simple re-raising of exceptions in an >> except: clause. It'll preserve the traceback. >> >> The control flow for the masking/re-raising seems convoluted. I've seen >> code like the following before: >> >> if nomaskexception: >> nonmasked_exceptions = Exception >> else: >> nonmasked_exceptions = () >> >> try: >> something() >> except nonmasked_exceptions as e: >> raise >> except ConcreteException as e: >> raise_masked_exception(e) >> >> >> Also it might be useful to factor raise_masked_exception() out; see >> below. > > Good idea. I sort of split the difference. Instead of + nomaskexception = options.get('nomaskexception', False) + if 'nomaskexception' in options: + del options['nomaskexception'] you can use: + nomaskexception = options.pop('nomaskexception', False) > >> >>> - Rather than returning an DuplicateEntry error when POSTing to an >>> existing host, do a host_mod instead. >> >> Could you add a test for this? >> >> It looks like ip_address has no effect in this case, should we fail if >> it's given instead of silently ignoring it? Same for rebuilding new >> hosts. > > Done both. Nope, wrong test. 'Update the host' should use POST. Also, when updating using POST, unspecified information is removed, e.g. doing http POST ':8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com?userclass=a_class' removes the description etc. I don't think that's intended. >>> - Add config option to pass updatedns=True when deleting a host. >> >> In DELETE, the exception handling seems overly broad. With a >> raise_masked_exception() function and nomaskexception, you could handle >> the specific error. It should help debugging if nothing else. >> >> This way of masking errors seems clumsy when nesting commands; I wonder >> if they can be handled better at a higher level >> ('request.error_response'?) > > Yes. I imagine that the Foreman smartproxy is doing this to mask the > issue as well. I dropped it, doing a GET instead so we'll get the proper > error in any case. It's a bit racy but it won't be as unnerving as > running into https://fedorahosted.org/freeipa/ticket/4329 Also, add 'add dns entries' and 'update dns entries' to the permission line in the manpage. -- Petr? From jhrozek at redhat.com Wed Apr 30 12:44:36 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 30 Apr 2014 14:44:36 +0200 Subject: [Freeipa-devel] [PATCH 0167] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <5360BCF0.1030101@redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> <533039CA.2060007@redhat.com> <20140324142737.GK3872@redhat.com> <5360BCF0.1030101@redhat.com> Message-ID: <20140430124436.GC4991@hendrix.brq.redhat.com> On Wed, Apr 30, 2014 at 11:05:52AM +0200, Tomas Babej wrote: > On 03/24/2014 03:27 PM, Jan Pazdziora wrote: > > On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: > >> On 03/24/2014 02:47 PM, Jan Pazdziora wrote: > >>> On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: > >>>> Hi, > >>>> > >>>> Makes ipa-client-install configure SSSD as the data provider > >>>> for the sudo service by default. This behaviour can be disabled > >>>> by using --no-sudo flag. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/3358 > >>> Ack. > >>> > >>> Applied against ipa-client-3.0.0-37.el6.x86_64, tried without > >>> --no-sudo and sudo was added to sssd.conf's services list and sudoeers > >>> added to /etc/nsswitch.conf. > >>> > >>> Rerun with --uninstall and run again with the --no-sudo parameter, > >>> those settings were not longer there. > >>> > >> Did you also do the functional test? > > No. I do not want to get dragged into the discussion of having the > > correct sssd and sudo and glibc versions and SELinux and stuff. The > > ticket explicitly talk about setting configuration in config files, > > which the patch does. > > > >> To ack and push this ticket, following > >> scenario needs to work: > > Consumption of those configuration changes is really different story, > > isn't it? > > > >> 1) IPA clients enroll against IPA server without --no-sudo > >> 2) IPA client user logs in, types "sudo -l", gets all allowed commands > >> (prerequisite is of course to have sudo commands defined on the IPA server) > >> 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all > >> allowed commands > >> > >> For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done > >> > >> For 3) to work, related systemd service preserving NIS domain name setting > >> needs to be enabled > > With the commit message only talking about configuring sssd, I assume > > the NIS domain name mentioned in the ticket will be done by some other > > patch. > > > > To me, the patch does what is advertised in the commit message, and is > > in line with what the ticket asks to be done. > > > > Attached are rebased versions of the patches 113 and 167 (which was > marked as 157 in the thread previously by mistake). > > There is a slight behaviour change in 167, if there is no sudoers line > in nsswitch.conf, we add both files and sss as sudoers sources. > > I also developed CI test that covers the functionality of the IPA - sudo > integration feature, which is attached. > > Please note that the last three tests are expected to fail until: > > https://fedorahosted.org/freeipa/ticket/4324 > > is fixed. > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > Hi, I haven't done a thorough review, but the patch looks good to me in general -- in other words, seems to cover what I've been doing manually for my test setups. My only suggestion (maybe for future) would be to split changing the nsswitch.conf into its own separate helper class or a function, because you might want to do the same change for automount or other services in nsswitch.conf. But I think this version is OK at the moment. From tbabej at redhat.com Wed Apr 30 13:59:01 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Apr 2014 15:59:01 +0200 Subject: [Freeipa-devel] [PATCHES 180-182] ipatests: Improvements! Message-ID: <536101A5.4000509@redhat.com> Hi, * patch 180 fixes incorrect hostname usage when connecting to legacy clients * patch 181 sets up SSSD in debug_level 7 by default * patch 182 does the same, but on the legacy clients -- 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-0182-ipatests-Enable-SSSD-debugging-on-legacy-clients-wit.patch Type: text/x-patch Size: 1727 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0181-ipatests-Setup-SSSD-debugging-mode-by-default.patch Type: text/x-patch Size: 4236 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0180-ipatests-legacy-clients-Do-not-use-external-hostname.patch Type: text/x-patch Size: 1315 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 30 14:57:13 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Apr 2014 10:57:13 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5360E857.5030609@redhat.com> References: <52D99F70.3060305@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> <5350E5EA.2060106@redhat.com> <53580BE2.6050606@redhat.com> <535917F0.4050107@redhat.com> <535FB6C1.5080900@redhat.com> <535FD205.8080909@redhat.com> <536069EF.6090306@redhat.com> <5360E857.5030609@redhat.com> Message-ID: <53610F49.50003@redhat.com> Petr Viktorin wrote: > On 04/30/2014 05:11 AM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/29/2014 04:27 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 04/23/2014 08:52 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 04/09/2014 11:29 PM, Rob Crittenden wrote: >>>>>>>> Rob Crittenden wrote: >>>>>>>>> Petr Viktorin wrote: >>>>>>>>>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>>>>>>>>> [...] >>>>>>>>>>>>> >>>>>>>>>>>>> Here are a couple more enhancements I'm considering, this >>>>>>>>>>>>> seems >>>>>>>>>>>>> simpler >>>>>>>>>>>>> than inter-diff since it is so small. >>>>>>>>>>>> >>>>>>>>>>>> Not really. Having a patch file with a sequence+revision number >>>>>>>>>>>> you >>>>>>>>>>>> can >>>>>>>>>>>> refer to has its merits. Especially in a hairy thread like this >>>>>>>>>>>> one. >>>>>>>>>>>> Also one of our MUAs wrapped the lines, I had to undo that >>>>>>>>>>>> manually. >>>>>>>>>>>> >>>>>>>>>>>>> Here is why I made the changes, in order: >>>>>>>>>>>>> >>>>>>>>>>>>> I doubled the calls to create the connection but one isn't >>>>>>>>>>>>> in a >>>>>>>>>>>>> try/except!? Remove the obvious one. >>>>>>>>>>>>> >>>>>>>>>>>>> We currently completely eat GSSAPI errors, I figure we should >>>>>>>>>>>>> log >>>>>>>>>>>>> failures. >>>>>>>>>>>>> >>>>>>>>>>>>> IPA stores the principal in the request context so using that >>>>>>>>>>>>> will >>>>>>>>>>>>> save >>>>>>>>>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>>>>>>>>> >>>>>>>>>>>>> I included your content-type change. >>>>>>>>>>>> >>>>>>>>>>>> These changes look good. >>>>>>>>>>>> I'm almost done testing but I need to call it a week. >>>>>>>>>>> >>>>>>>>>>> Awesome, thanks. >>>>>>>>>> >>>>>>>>>> ACK on the functionality. >>>>>>>>>> >>>>>>>>>>>> Sorry for not catching that last time, but your patch doesn't >>>>>>>>>>>> add a >>>>>>>>>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>>>>>>>>> duplicate >>>>>>>>>>>> unversioned one. So lint (and thus the build) will fail if the >>>>>>>>>>>> old >>>>>>>>>>>> python-kerberos version is installed. >>>>>>>>>>>> >>>>>>>>>>>> A possible a solution to the build trouble would be to just >>>>>>>>>>>> add a >>>>>>>>>>>> lint >>>>>>>>>>>> exception now, and open a ticket to remove it later. That way >>>>>>>>>>>> the >>>>>>>>>>>> build >>>>>>>>>>>> succeeds despite the older version, and the new >>>>>>>>>>>> python-kerberos is >>>>>>>>>>>> only >>>>>>>>>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>>>>>>>>> That should make everyone happy, including Martin. >>>>>>>>>>>> Unfortunately our lint exception mechanism doesn't work on >>>>>>>>>>>> modules, so >>>>>>>>>>>> this needs a somewhat nastier hack. >>>>>>>>>>>> The attaching a patch that does this (and I'm pasting a simple >>>>>>>>>>>> diff >>>>>>>>>>>> below). Does that look okay to push? >>>>>>>>>>> >>>>>>>>>>> I'm trying to find a better solution to all this. I may end up >>>>>>>>>>> taking >>>>>>>>>>> Martin's suggestion of rawhide-only to avoid this sort of thing. >>>>>>>>>> >>>>>>>>>> Looks like you'll still need to silence pylint on f20 in that >>>>>>>>>> case. >>>>>>>>>> >>>>>>>>>>> The deal with the smartproxy is that you can/should be able to >>>>>>>>>>> run >>>>>>>>>>> it on >>>>>>>>>>> any IPA-enrolled client, so you can run it directly on the >>>>>>>>>>> Foreman >>>>>>>>>>> box, >>>>>>>>>>> with the IPA server somewhere else. What this means is that >>>>>>>>>>> someone >>>>>>>>>>> could probably fairly easily package this up for other >>>>>>>>>>> distributions >>>>>>>>>>> and >>>>>>>>>>> if we end up with a Fedora-only python-kerberos patch then >>>>>>>>>>> smartproxy is >>>>>>>>>>> Fedora-only as well. >>>>>>>>>>> >>>>>>>>>>> So I'm trying to get some movement out of upstream on this but >>>>>>>>>>> it's >>>>>>>>>>> been >>>>>>>>>>> crickets for weeks. I think in the context of the calendar >>>>>>>>>>> server >>>>>>>>>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll >>>>>>>>>>> amp up >>>>>>>>>>> the >>>>>>>>>>> nagging to get some sort of response, even if it is "stop >>>>>>>>>>> nagging >>>>>>>>>>> us!" >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>> Good luck! >>>>>>>>> >>>>>>>>> Ok, taking a different tack on this. Rather than running it as a >>>>>>>>> separate server process, run it as a WSGI app inside Apache. This >>>>>>>>> required a fair bit of re-tooling and complicates the set up a >>>>>>>>> little >>>>>>>>> bit. I think I've got it all covered in the man page. >>>>>>>>> >>>>>>>>> On the python-kerberos front I've got bugs opened in Ubuntu and >>>>>>>>> Debian >>>>>>>>> to see if we can get the patch accepted their until (if) upstream >>>>>>>>> ever >>>>>>>>> takes a look. >>>>>>>> >>>>>>>> I decided to run the new WSGI app in a different process group, >>>>>>>> using >>>>>>>> the smartproxy we use for delegation. This simplifies the >>>>>>>> connection >>>>>>>> code, rather than using ldap2 like I was using, we use the RPC >>>>>>>> interface. And it provides to process separation. As a >>>>>>>> side-effect it >>>>>>>> will make running this code on platforms without GSSProxy a bit >>>>>>>> easier. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> Works great here! >>>>>>> >>>>>>> >>>>>>> The python-kerberos dependency issue still needs to be solved. >>>>>> >>>>>> Build is on the way to updates-testing if you can give it a go. >>>>>> >>>>>>> >>>>>>> The man page says: >>>>>>> Copy ipa-smartproxy-apache.conf to >>>>>>> /etc/httpd/conf.d/ipa-smartproxy.conf. >>>>>>> It would be nice to put the whole path here so people don't have to >>>>>>> search for the file. >>>>>> >>>>>> Done. >>>>>> >>>>>>> >>>>>>> The "Configure Apache to use smartproxy" line looks like a step >>>>>>> to be >>>>>>> performed. It could use some emphasis to make it look like a header. >>>>>> >>>>>> I combined it with the subsequent sentence so hopefully it is a bit >>>>>> clearer. >>>>>> >>>>>> I also added a bit on testing so you can confirm that things are >>>>>> working. >>>>>> >>>>>> >>>>>>> Side note, cherrypy's routing makes requests like this possible: >>>>>>> http POST >>>>>>> :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Should that be allowed? >>>>>> >>>>>> It is definitely ugly but AFAICT it isn't illegal. The zero >>>>>> content-length bothers me more than this horrible-looking URI. It >>>>>> definitely requires some understanding of the ordering of >>>>>> parameters to >>>>>> get this call right. >>>>>> >>>>>> rob >>>>> >>>>> Everything works now! >>>>> Except one thing: json_encode_binary recently got a mandatory version >>>>> argument. For code that's part of IPA, it should be fine to just use >>>>> API_VERSION here. >>>>> >>>>> I tested with that added; ACK if you agree. >>>> >>>> ACK on your change. >>>> >>>> Sorry, one more set of changes, some fairly significant. This brings >>>> our >>>> proxy in line with the Foreman proxy functionality-wise. I tested this >>>> against a Foremane 1.5.0 RC1 build and it is fine. I didn't go as >>>> far as >>>> actually deploying any hosts but did confirm that the create/delete >>>> functions work ok. >>> >>> I've eyeballed the changes, no testing yet. Here are my thoughts. >>> >>>> Significant changes: >>>> - random removed as an option. It is always true unless a user-provided >>>> password is sent. >>>> - Added an option to Command so that the real IPA error can be >>>> raised to >>>> make internal error handling possible. >>> >>> Please use a bare `raise` for simple re-raising of exceptions in an >>> except: clause. It'll preserve the traceback. >>> >>> The control flow for the masking/re-raising seems convoluted. I've seen >>> code like the following before: >>> >>> if nomaskexception: >>> nonmasked_exceptions = Exception >>> else: >>> nonmasked_exceptions = () >>> >>> try: >>> something() >>> except nonmasked_exceptions as e: >>> raise >>> except ConcreteException as e: >>> raise_masked_exception(e) >>> >>> >>> Also it might be useful to factor raise_masked_exception() out; see >>> below. >> >> Good idea. I sort of split the difference. > > Instead of > + nomaskexception = options.get('nomaskexception', False) > + if 'nomaskexception' in options: > + del options['nomaskexception'] > you can use: > + nomaskexception = options.pop('nomaskexception', False) Of course. >> >>> >>>> - Rather than returning an DuplicateEntry error when POSTing to an >>>> existing host, do a host_mod instead. >>> >>> Could you add a test for this? >>> >>> It looks like ip_address has no effect in this case, should we fail if >>> it's given instead of silently ignoring it? Same for rebuilding new >>> hosts. >> >> Done both. > > Nope, wrong test. 'Update the host' should use POST. Sorry, did it too quickly for my own good. It also turned out I was still returning 201 on updates which is bad. > > Also, when updating using POST, unspecified information is removed, e.g. > doing > http POST > ':8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com?userclass=a_class' > > removes the description etc. > I don't think that's intended. You're right. I pop off empty values on updates now. This means that one can't wipe the description once set though. We may need to set a magic value for that. I beefed up the data passed into the tests so we can confirm that values don't disappear. >>>> - Add config option to pass updatedns=True when deleting a host. >>> >>> In DELETE, the exception handling seems overly broad. With a >>> raise_masked_exception() function and nomaskexception, you could handle >>> the specific error. It should help debugging if nothing else. >>> >>> This way of masking errors seems clumsy when nesting commands; I wonder >>> if they can be handled better at a higher level >>> ('request.error_response'?) >> >> Yes. I imagine that the Foreman smartproxy is doing this to mask the >> issue as well. I dropped it, doing a GET instead so we'll get the proper >> error in any case. It's a bit racy but it won't be as unnerving as >> running into https://fedorahosted.org/freeipa/ticket/4329 > > Also, add 'add dns entries' and 'update dns entries' to the permission > line in the manpage. > Done, and added 'remove dns entries' as well. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-13-rest.patch Type: text/x-patch Size: 52339 bytes Desc: not available URL: From tbabej at redhat.com Wed Apr 30 15:07:33 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Apr 2014 17:07:33 +0200 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <535A261B.9080906@redhat.com> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> <531713BF.7010804@redhat.com> <53565345.2080407@redhat.com> <535A261B.9080906@redhat.com> Message-ID: <536111B5.8040500@redhat.com> On 04/25/2014 11:08 AM, Jan Cholasta wrote: > On 22.4.2014 13:32, Tomas Babej wrote: >> Thank you for the suggestions. Updated, rebased patch is attached. >> > > This API.txt change from the next patch belongs in this patch: > > +capability: datetime_values 2.84 > > > I think you should use the LDAP_GENERALIZED_TIME_FORMAT constant here: > > + accepted_formats = ['%Y%m%d%H%M%SZ', # generalized time > > > This is not right: > > + elif isinstance(val, datetime.datetime): > + return val > > To actually decode LDAP generalized time attributes to datetime, you > need to do this: > > '2.16.840.1.113719.1.301.4.41.1' : DN, # krbSubTrees > '2.16.840.1.113719.1.301.4.52.1' : DN, # krbObjectReferences > '2.16.840.1.113719.1.301.4.53.1' : DN, # krbPrincContainerRef > + > + '1.3.6.1.4.1.1466.115.121.1.24' : datetime.datetime, > } > > # In most cases we lookup the syntax from the schema returned by > > and this: > > return val > elif target_type is unicode: > return val.decode('utf-8') > + elif target_type is datetime.datetime: > + return datetime.datetime.strptime(val, > LDAP_GENERALIZED_TIME_FORMAT) > else: > return target_type(val) > except Exception, e: > > and add code for formatting datetime values to the textui backend. > Thanks for the review. I fixed all the issues, updated patch is attached. I also added unit tests for the new DateTime parameter. -- 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-0137-7-ipalib-Add-DateTime-parameter.patch Type: text/x-patch Size: 12954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0183-ipatests-Cover-DateTime-in-test_parameters.py.patch Type: text/x-patch Size: 3545 bytes Desc: not available URL: From tbabej at redhat.com Wed Apr 30 15:07:41 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Apr 2014 17:07:41 +0200 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <535A267D.9070106@redhat.com> References: <52CEC0C9.70905@redhat.com> <530C478E.4080307@redhat.com> <53171423.8030204@redhat.com> <535653C3.7040406@redhat.com> <535A267D.9070106@redhat.com> Message-ID: <536111BD.6000007@redhat.com> On 04/25/2014 11:10 AM, Jan Cholasta wrote: > On 22.4.2014 13:34, Tomas Babej wrote: >> Updated, rebased patch attached. >> > > This API.txt change belongs in the previous patch: > > +capability: datetime_values 2.84 > Fixed, updated patch attached. I also added several tests for the user plugin that cover the feature (and related refactoring). -- 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-0138-7-ipalib-Expose-krbPrincipalExpiration-in-CLI.patch Type: text/x-patch Size: 7355 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0185-ipatests-Add-coverage-for-setting-krbPrincipalExpira.patch Type: text/x-patch Size: 2463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0184-ipatests-Fix-formatting-errors-in-test_user_plugin.p.patch Type: text/x-patch Size: 23398 bytes Desc: not available URL: From tbabej at redhat.com Wed Apr 30 15:07:48 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Apr 2014 17:07:48 +0200 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <52CBF76F.5010200@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> Message-ID: <536111C4.1070604@redhat.com> On 01/07/2014 01:47 PM, Tomas Babej wrote: > On 01/07/2014 07:23 AM, Alexander Bokovoy wrote: >> On Mon, 06 Jan 2014, Tomas Babej wrote: >>> On 01/06/2014 12:16 PM, Tomas Babej wrote: >>>> On 04/15/2013 12:43 PM, Tomas Babej wrote: >>>>> On 04/08/2013 03:55 PM, Martin Kosek wrote: >>>>>> On 04/01/2013 09:52 PM, Rob Crittenden wrote: >>>>>>> Tomas Babej wrote: >>>>>>>> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>>>>>>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>>>>>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>>>>>>>> pre_bind operation >>>>>>>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, >>>>>>>>>>> auth is >>>>>>>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error >>>>>>>>>>> message is >>>>>>>>>>> sent back to the client. Since krbprincipalexpiration >>>>>>>>>>> attribute is >>>>>>>>>> not >>>>>>>>>>> mandatory, if there is no value set, the check is passed. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3305 >>>>>>>>> Comments inline. >>>>>>>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock >>>>>>>>>> *pb) >>>>>>>>>> goto done; >>>>>>>>>> } >>>>>>>>>> + /* check the krbPrincipalExpiration attribute is present */ >>>>>>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>>>>>> &attr); >>>>>>>>>> + if (!ret) { >>>>>>>>> ret is not a boolean so probably better ti use (ret != 0) >>>>>>>>> >>>>>>>>>> + /* if it is, check whether the principal has not >>>>>>>>>> expired */ >>>>>>>>>> + >>>>>>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>>>>>> + "krbprincipalexpiration"); >>>>>>>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>>>>>>>> + >>>>>>>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>>>>>>>>> &expire_tm)){ >>>>>>>>> style issue missing space between ) and { >>>>>>>>> >>>>>>>>>> + expire_time = mktime(&expire_tm); >>>>>>>>>> + /* this might have overflown on 32-bit system */ >>>>>>>>> This comment does not help to point out what you want to put in >>>>>>>>> evidence. >>>>>>>>> if there is an overflow what is the consequence ? Or does it >>>>>>>>> mean the >>>>>>>>> next condition is taking that into account ? >>>>>>>> Yeah, this was rather ill-worded. Replaced by a rather verbose >>>>>>>> comment that hopefully clears things out. >>>>>>>>>> + if (current_time > expire_time && expire_time > 0){ >>>>>>>>> style issue missing space between ) and { >>>>>>>>> >>>>>>>>>> + LOG_FATAL("kerberos principal has expired in >>>>>>>>>> user >>>>>>>>>> entry: %s\n", >>>>>>>>>> + dn); >>>>>>>>> I think a better phrasing would be: "The kerberos principal on >>>>>>>>> %s is >>>>>>>>> expired\n" >>>>>>>>> >>>>>>>>>> + errMesg = "Kerberos principal has expired."; >>>>>>>>> s/has/is/ >>>>>>>>> >>>>>>>>> The rest looks good to me. >>>>>>>>> >>>>>>>>> Simo. >>>>>>>> Styling issues fixed and updated patch attached :) >>>>>>> Small nit, the expiration error should probably use 'in' not 'on'. >>>>>>> >>>>>>> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This >>>>>>> implies >>>>>>> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM >>>>>>> is probably >>>>>>> more correct here. It is what we return on other policy failures. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> Additional findings: >>>>>> >>>>>> 1) Lets not try to get current_time every time, but only when its >>>>>> needed (i.e. >>>>>> krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: >>>>>> >>>>>> + /* get current time*/ >>>>>> + current_time = time(NULL); >>>>>> >>>>>> 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find >>>>>> the >>>>>> attribute again when we already have a pointer for the attribute? >>>>>> Would >>>>>> slapi_attr_first_value following slapi_entry_attr_find be faster >>>>>> approach? >>>>>> >>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>> &attr); >>>>>> + if (ret != 0) { >>>>>> + /* if it is, check whether the principal has not expired */ >>>>>> + >>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>> + "krbprincipalexpiration"); >>>>>> >>>>>> This way, we would not create a copy of this attribute value - we do >>>>>> not need a >>>>>> copy, we just do check against it. >>>>>> >>>>>> >>>>>> 3) Shouldn't we return -1 in the end when the auth fails? We do that >>>>>> in other >>>>>> pre_callbacks. Otherwise we just return 0 (success): >>>>>> >>>>>> + if (auth_failed){ >>>>>> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, >>>>>> errMesg, >>>>>> + 0, NULL); >>>>>> + } >>>>>> + >>>>>> return 0; >>>>>> >>>>>> Martin >>>>> Thank you both for the review. I updated and retested the patch, with >>>>> your suggestions incorporated. >>>>> >>>>> Tomas >>>>> >>>> I rebased the patch on top of current master. >>>> >>>> Bumping, since this is planned as part of 3.4 (and there were some >>>> requests for this feature). >>>> >>>> Tomas >>>> >>> I updated the commit message to reflect better what the current version >>> of the patch implements. >>> >>> Tomas >>>> From a93d1ec3ca8c7b6e8e754b474257695ba9018e07 Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Mon, 6 Jan 2014 12:11:24 +0100 >>> Subject: [PATCH] ipa-pwd-extop: Deny LDAP binds for user accounts >>> with expired >>> principal >>> >>> Adds a check for krbprincipalexpiration attribute to pre_bind operation >>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is >>> denied and LDAP_UNWILLING_TO_PERFORM along with the error message is >>> sent back to the client. Since krbprincipalexpiration attribute is not >>> mandatory, if there is no value set, the check is passed. >>> >>> https://fedorahosted.org/freeipa/ticket/3305 >>> --- >>> daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 45 >>> ++++++++++++++++++++++- >>> 1 file changed, 44 insertions(+), 1 deletion(-) >>> >>> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>> b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>> index >>> ef37b5e173359f9404b241c12d8a6dc6e77da128..568cba7189d1575d030b043daee61f713e9bac5f >>> 100644 >>> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>> @@ -1389,13 +1389,17 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>> Slapi_Value *value = NULL; >>> Slapi_Attr *attr = NULL; >>> struct tm expire_tm; >>> + time_t current_time; >>> + time_t expire_time; >>> char *errMesg = "Internal operations error\n"; /* error message */ >>> char *expire = NULL; /* passwordExpirationTime attribute value */ >>> + char *principal_expire = NULL; /* krbPrincipalExpiration >>> attribute value */ >>> char *dn = NULL; /* bind DN */ >>> Slapi_Value *objectclass; >>> int method; /* authentication method */ >>> int ret = 0; >>> char *principal = NULL; >>> + bool auth_failed = false; >>> >>> LOG_TRACE("=>\n"); >>> >>> @@ -1422,7 +1426,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>> const char *attrs_list[] = {SLAPI_USERPWD_ATTR, >>> "krbprincipalkey", "uid", >>> "krbprincipalname", "objectclass", >>> "passwordexpirationtime", >>> "passwordhistory", >>> - NULL}; >>> + "krbprincipalexpiration", NULL}; >>> >>> /* retrieve user entry */ >>> ret = ipapwd_getEntry(dn, &entry, (char **) attrs_list); >>> @@ -1438,6 +1442,39 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>> goto done; >>> } >>> >>> + /* check the krbPrincipalExpiration attribute is present */ >>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>> &attr); >>> + if (ret == 0) { >>> + ret = slapi_attr_first_value(attr, &value); >>> + >>> + if (ret == 0) { >>> + /* if it is, check whether the principal has not expired */ >>> + principal_expire = slapi_value_get_string(value); >>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>> + >>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>> &expire_tm)) { >>> + expire_time = mktime(&expire_tm); >>> + >>> + /* get current time */ >>> + current_time = time(NULL); >>> + >>> + /* mktime returns -1 if the tm struct cannot be >>> represented as >>> + * as calendar time (seconds since the Epoch). This >>> might >>> + * happen with tm structs that are ill-formated or >>> on 32-bit >>> + * platforms with dates that would cause overflow >>> + * (year 2038 and later). >>> + * In such cases, skip the expiration check. */ >>> + >>> + if (current_time > expire_time && expire_time > 0) { >>> + LOG_FATAL("kerberos principal in %s is >>> expired\n", dn); >>> + errMesg = "Kerberos principal is expired."; >>> + auth_failed = true; >>> + goto done; >>> + } >>> + } >> I think indenting is broken for these two brackets. >> >> > Thanks Alexander, fixed. > > Updated version attached. > > Tomas This version is rebased on top of OTP patches, addresses Simo's comments and brings unit tests to cover the functionality (however, they need to be applied on top of my patches 183-185). -- 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-0034-8-ipa-pwd-extop-Deny-LDAP-binds-for-accounts-with-expi.patch Type: text/x-patch Size: 3350 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0186-ipatests-Add-test-for-denying-expired-principals.patch Type: text/x-patch Size: 2841 bytes Desc: not available URL: From alee at redhat.com Wed Apr 30 15:09:47 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 30 Apr 2014 11:09:47 -0400 Subject: [Freeipa-devel] new developer; development environment In-Reply-To: <20140430062130.GC21845@dhcp-40-8.bne.redhat.com> References: <20140430062130.GC21845@dhcp-40-8.bne.redhat.com> Message-ID: <1398870587.11303.5.camel@aleeredhat.laptop> Welcome Fraser, To build dogtag, you should start here: http://pki.fedoraproject.org/wiki/Building_Dogtag_10 and I happen to know you'll be working on IPA/PKI stuff, you'll be interested in reviewing the links under: http://pki.fedoraproject.org/wiki/Dogtag#Resources_for_Client_Developers The PKI build does not require root. Just make sure you have the sudo access required to install the prerequisites. Ade On Wed, 2014-04-30 at 16:21 +1000, Fraser Tweedale wrote: > Hi all, > > Fraser Tweedale, brand new Red Hatter, working in the Brisbane > office on FreeIPA/Dogtag, and needing the wisdom of seasoned IPA > developers on how best to set things up. > > In particular, is it common to be developing in VMs, and if so, do > the various components (DS, Dogtag, IPA etc) under (or involved in) > development reside on the same host? Are there any developer images > that are ready to roll? > > Or if it is more common to simply develop on one's workstation > directly, do you have any tips to doing this sanely? freeipa seemed > find to build but the pki build seems to want root, which scares me > a little... but perhaps I am just Doing It Wrong. > > Thanks in advance for any advice, and I look forward to getting to > you know you all. > > Cheers, > > Fraser > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Wed Apr 30 15:16:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Apr 2014 17:16:18 +0200 Subject: [Freeipa-devel] [PATCH] 0455 Replace "replica admins read access" ACI with a permission Message-ID: <536113C2.40704@redhat.com> This should fix https://fedorahosted.org/freeipa/ticket/3829 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0545-Replace-replica-admins-read-access-ACI-with-a-permis.patch Type: text/x-patch Size: 6499 bytes Desc: not available URL: From alee at redhat.com Wed Apr 30 15:41:57 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 30 Apr 2014 11:41:57 -0400 Subject: [Freeipa-devel] [PATCH] Add DRM to IPA In-Reply-To: <534D5324.4060802@redhat.com> References: <1396637432.8149.30.camel@aleeredhat.laptop> <53430D4F.4000903@redhat.com> <53439C4D.6060108@redhat.com> <5343FF31.8050206@redhat.com> <1397486532.29593.8.camel@aleeredhat.laptop> <534D5324.4060802@redhat.com> Message-ID: <1398872517.11303.9.camel@aleeredhat.laptop> I've attached two new patches to address the problems/ questions raised in the previous patches. I also do a little cleanup of the cainstance.py file. The comments on ipa-drm-install have been addressed too. See specific comments below. Thanks, Ade On Tue, 2014-04-15 at 11:41 -0400, Rob Crittenden wrote: > Ade Lee wrote: > > Attached a new patch to address some of the concerns below, specifically > > I created a new base class DogtagInstance, in which much of the common > > CA/KRA code is placed. I'm sure we could go further in reducing > > duplication, and I'm open to further suggestions and refinements. > > > > I did not tackle the packaging and spec file dependencies, because I'd > > like some clearer direction on how we want to proceed here. In any > > case, I think the splitting of the ipa packages into ca and possibly kra > > packages should be a separate patch. > > > > As before, with this patch you can: > > - install a ca and drm using ipa-server-install > > - install a ca and drm replica using > > ipa-replica-prepare > > ipa-replica-install --setup-ca --setup-drm > > > > You need to use a PKI build from the 10.2 (master) branch). One such > > build is given below: > > http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo > > The terms KRA and DRM tend to be used interchangeably. Should we pick one? > The "official" name of the subsystem is "DRM" so I have used that name wherever possible -- ie. in basedns and log messages. If I missed one, let me know. On the other hand, we use "kra" is many parts of the code - for instance - pkispawn requires kra, and the config files use kra. > Need to bump the version number in install/conf/ipa-pki-proxy.conf so > that upgrades get the new LocationMatch. > done - updated to version 5 > ipa-replica-install still uses the if/then to set the value of > enable_drm when it can be reduced like you did in ipa-server-install. > done. > In ipa-server-install you have an extra comment, probably left for > yourself: # code to create drm here > removed > In dogtaginstance.py there are a few direct references to DRM in > comments and output. > removed > cainstance.py doesn't need to override is_installed.py > removed > I also don't think you need the explicit definitions for enable, > start_instance, etc. Those should be inherited from the DogtagInstance > class, in both cainstance.py and drminstance.py. > Done > I think spawn_instance should take an option to add things to nolog in > case there are server-independent things we don't want to log. > Done > I don't want to pile too much on, but it seems to me that if we are > going to copy in default.conf then we can do away with realm_info > completely and just use default.conf. Both would need to be supported > for a while though. Martin, what do you think? > I propose we make this change in a separate patch as this is really a separate cleanup. > I still have quite a bit of functional testing to go. I've only > installed a fresh standalone master. Still need to do upgrade and > replication testing. > > rob > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 40124 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-a-DRM-to-IPA.patch Type: text/x-patch Size: 73390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Added-ipa-drm-install.patch Type: text/x-patch Size: 22704 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Added-nolog-to-pkispawn-and-some-additional-fixes-fr.patch Type: text/x-patch Size: 13199 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Fix-various-pep-8-issues-and-comments-from-review.patch Type: text/x-patch Size: 31467 bytes Desc: not available URL: From alee at redhat.com Wed Apr 30 15:45:55 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 30 Apr 2014 11:45:55 -0400 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin Message-ID: <1398872755.11303.12.camel@aleeredhat.laptop> I have attached a patch that contains code for the new dogtag DRM plugin vault functionality. This patch should be applied on top of the ones used to install a DRM. Forthcoming is a patch to actually start using this plugin. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Added-dogtag-plugin-for-DRM.patch Type: text/x-patch Size: 21593 bytes Desc: not available URL: From pspacek at redhat.com Wed Apr 30 16:19:38 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 30 Apr 2014 18:19:38 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys Message-ID: <5361229A.7030303@redhat.com> Hello list, following text summarizes schema & DIT layout for DNSSEC key storage in LDAP. This is subset of full PKCS#11 schema [0]. It stores bare keys with few metadata attributes when necessary. The intention is to make transition to full PKCS#11-in-LDAP schema [0] as easy as possible. This transition should happen in next minor version of FreeIPA. In theory, the transition should be just adding few object classes to existing objects and populating few new metadata attributes. Related object classes are marked below with "(in long-term)". Please comment on it soon. We want to implement it ASAP :-) DNSSEC key ========== - Asymmetric - Private key is stored in LDAP as encrypted PKCS#8 blob - Public key is published in LDAP - Encrypted with symmetric "DNSSEC master key" (see below) - Private key - represented as LDAP object with object classes: ipaEPrivateKey [1] # encrypted data ipaWrappedKey [2] # pointer to master key, outside scope of pure PKCS#11 ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata - Public key - represented as LDAP object with object classes: ipaPublicKey [1] # public key data ipk11PublicKey [3] (in long-term) # PKCS#11 metadata Master key ========== - Symmetric - Stored in LDAP as encrypted blob - Encrypted with asymmetric "replica key" (see below) - 1 replica = 1 blob, n replicas = n blobs encrypted with different keys - A replica uses it's own key for master key en/decryption - Represented as LDAP object with object classes: ipaESecretKey [1] ipk11SecretKey [3] (in long-term) Replica key =========== - Asymmetric - Private key is stored on replica's disk only - Public key for all replicas is stored in LDAP - Represented as LDAP object with object classes: ipaPublicKey [1] ipk11PublicKey [3] (in long-term) DIT layout ========== DNSSEC key material ------------------- - Container: cn=keys, cn=sec, cn=dns, dc=example - Private and public keys are stored as separate objects to accommodate all PKCS#11 metadata. - We need to decide about object naming: - One obvious option for RDN is to use uniqueID but I don't like it. It is hard to read for humans. - Other option is to use uniqueID+PKCS#11 label or other attributes to make it more readable. Can we use multi-valued RDN? If not, why? What are technical reasons behind it? It is question if we like: nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda more than: ipk11Label=meaningful_label+ipk11Private=TRUE ipk11Label=meaningful_label+ipk11Private=FALSE DNSSEC key metadata ------------------- - Container (per-zone): cn=keys, idnsname=example.net, cn=dns - Key metadata can be linked to key material via DN or ipk11Id. - This allows key sharing between zones. (DNSSEC-metadata will be specified later. That is not important for key storage.) Replica public keys ------------------- - Container: cn=DNS,cn=,cn=masters,cn=ipa,cn=etc,dc=example - or it's child object like cn=wrappingKey Master keys ----------- - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example - Single key = single object. - We can use ipk11Label or ipk11Id for naming: ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc. Work flows ========== Read DNSSEC private key ----------------------- 1) read DNSSEC private key from LDAP 2) ipaWrappedKey objectClass is present - key is encrypted 3) read master key denoted by ipaWrappingKey attribute in DNSSEC key object 4) use local replica key to decrypt master key 5) use decrypted master key to decrypt DNSSEC private key Add DNSSEC private key ---------------------- 1) use local replica key to decrypt master key 2) encrypt DNSSEC private key with master key 3) add ipaWrappingKey attribute pointing to master key 4) store encrypted blob in a new LDAP object Add a replica ------------- ipa-replica-prepare: 1) generate a new replica-key pair for the new replica 2) store key pair to replica-file (don't scream yet :-) 4) add public key for the new replica to LDAP 3) fetch master key from LDAP 4) encrypt master key with new replica public key 5) store resulting master key blob to LDAP ipa-replica-install: 6) generate a new replica-key pair (!) 7) store new public key to LDAP 8) remove old public key (from replica-file) from LDAP 9) fetch master key 10) decrypt master key using old private key (from replica-file) 11) encrypt master key using new private key (generated locally) 12) replace old master key blob in LDAP with new blob (from step 11) Delete a replica ---------------- This is the tricky part. New master key has to be generated on some other replica. What should we do if the ipa-replica-manage command was run on deleted replica? I propose to split replica master key roll-over to two phases: Any machine in IPA domain (including to-be deleted replica): 1) Delete public key associated with replica from LDAP 2) Flip a bit in master key metadata and say "this key needs to be re-generated" (Maybe we can disable ipk11Wrap boolean to indicate that this key should not be used for key wrapping.) Remaining replicas: 3) Periodically check that master key is obsolete 4) Wait for (random period of time) to limit probability of collision 5) Check that master key is really obsolete and new one is not present 6) Generate a new master key 7) Encrypt new master key with all replica-public-keys stored in LDAP 8) Store new master key blobs to a new LDAP object (Conflicts are not a problem up to now because we are not deleting old key. In worst case, we will have multiple new master keys.) *What should we do now?* 9) ??? Re-encrypt all DNSSEC keys with a new master key? (What if we have write conflict now?) ??? Let old keys there and wait until key rotation mechanism replaces all old DNSSEC keys with new DNSSEC keys encrypted with a new master key (~ one year)? 10) Old master key can be deleted when no other object is referencing to it. Congratulations to people who reached this line and didn't skip anything :-) [0] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 [2] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#FreeIPA_specifics_-_key_wrapping [3] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Storage_objects -- Petr^2 Spacek From pviktori at redhat.com Wed Apr 30 16:27:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Apr 2014 18:27:01 +0200 Subject: [Freeipa-devel] [PATCHES] 0546-0547 Allow alternate "aci" keyword in ACIs Message-ID: <53612455.3000702@redhat.com> Hello, The first patch adds "==" to ACI object to simplify comparisons. The second patch moves existing "tests" to the test suite. The third patch adds support for an alternate "aci" keyword that DS supports (but I couldn't get any documentaion on it). Dogtag adds ACIs with this keyword to cn=config, so we'll need this fix when parsing ACIs there. Rob, you wrote the parser; does this look OK to you? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0546-ipalib.aci-Add-support-for-and-operators-to-ACI.patch Type: text/x-patch Size: 985 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0547-Move-ACI-tests-to-the-testsuite.patch Type: text/x-patch Size: 11392 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0548-aci.py-Allow-alternate-aci-keyword-in-ACIs.patch Type: text/x-patch Size: 2730 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 30 17:25:56 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Apr 2014 13:25:56 -0400 Subject: [Freeipa-devel] [PATCHES] 0546-0547 Allow alternate "aci" keyword in ACIs In-Reply-To: <53612455.3000702@redhat.com> References: <53612455.3000702@redhat.com> Message-ID: <53613224.9080805@redhat.com> Petr Viktorin wrote: > Hello, > The first patch adds "==" to ACI object to simplify comparisons. > The second patch moves existing "tests" to the test suite. > > The third patch adds support for an alternate "aci" keyword that DS > supports (but I couldn't get any documentaion on it). Dogtag adds ACIs > with this keyword to cn=config, so we'll need this fix when parsing ACIs > there. > > > Rob, you wrote the parser; does this look OK to you? > ACK. Only minor quibble is you left a couple of print statements in the tests. As you note, I had some "tests" that I ran when I was implementing the aci module. Moving these to formal testing is definitely the right thing to do. I do wonder one thing though. In the equality test I had reversed some ordering of things to ensure that things were normalized in the same way. For the check_aci_parsing() tests is it worth considering doing something similar? I noticed that we are apparently not normalizing target filters because there is a space in the DN. Something for later. There is no ticket. Probably fine since this is mostly just shuffling deck chairs. rob From pviktori at redhat.com Wed Apr 30 18:24:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Apr 2014 20:24:31 +0200 Subject: [Freeipa-devel] [PATCHES] 0546-0547 Allow alternate "aci" keyword in ACIs In-Reply-To: <53613224.9080805@redhat.com> References: <53612455.3000702@redhat.com> <53613224.9080805@redhat.com> Message-ID: <53613FDF.6040406@redhat.com> On 04/30/2014 07:25 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Hello, >> The first patch adds "==" to ACI object to simplify comparisons. >> The second patch moves existing "tests" to the test suite. >> >> The third patch adds support for an alternate "aci" keyword that DS >> supports (but I couldn't get any documentaion on it). Dogtag adds ACIs >> with this keyword to cn=config, so we'll need this fix when parsing ACIs >> there. >> >> >> Rob, you wrote the parser; does this look OK to you? >> > > ACK. > > Only minor quibble is you left a couple of print statements in the tests. Those are intentional. When a failed test prints something, Nose shows the output. It's pretty nice for debugging. > As you note, I had some "tests" that I ran when I was implementing the > aci module. Moving these to formal testing is definitely the right thing > to do. > > I do wonder one thing though. In the equality test I had reversed some > ordering of things to ensure that things were normalized in the same > way. For the check_aci_parsing() tests is it worth considering doing > something similar? I'm not sure I follow; what part are you referring to? The ordering is problematic for sure; everything relies on dict order. That's the main reason why in my work I only use this class to parse ACIs, and I made a stable routine for generating them. Until we start running the tests with PYTHONHASHSEED=random, I figured we can just use them as they are. > I noticed that we are apparently not normalizing target filters because > there is a space in the DN. Something for later. Or not; I'd like to get rid of the export_to_string part completely. > There is no ticket. Probably fine since this is mostly just shuffling > deck chairs. Yeah, same thinking here. It's part of the general ACI work. -- Petr? From simo at redhat.com Wed Apr 30 18:47:53 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 30 Apr 2014 14:47:53 -0400 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <536111C4.1070604@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> <536111C4.1070604@redhat.com> Message-ID: <1398883673.26263.19.camel@willson.li.ssimo.org> On Wed, 2014-04-30 at 17:07 +0200, Tomas Babej wrote: > On 01/07/2014 01:47 PM, Tomas Babej wrote: > > On 01/07/2014 07:23 AM, Alexander Bokovoy wrote: > >> On Mon, 06 Jan 2014, Tomas Babej wrote: > >>> On 01/06/2014 12:16 PM, Tomas Babej wrote: > >>>> On 04/15/2013 12:43 PM, Tomas Babej wrote: > >>>>> On 04/08/2013 03:55 PM, Martin Kosek wrote: > >>>>>> On 04/01/2013 09:52 PM, Rob Crittenden wrote: > >>>>>>> Tomas Babej wrote: > >>>>>>>> On 02/12/2013 06:23 PM, Simo Sorce wrote: > >>>>>>>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: > >>>>>>>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> This patch adds a check for krbprincipalexpiration attribute to > >>>>>>>>>>> pre_bind operation > >>>>>>>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, > >>>>>>>>>>> auth is > >>>>>>>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error > >>>>>>>>>>> message is > >>>>>>>>>>> sent back to the client. Since krbprincipalexpiration > >>>>>>>>>>> attribute is > >>>>>>>>>> not > >>>>>>>>>>> mandatory, if there is no value set, the check is passed. > >>>>>>>>>>> > >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3305 > >>>>>>>>> Comments inline. > >>>>>>>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock > >>>>>>>>>> *pb) > >>>>>>>>>> goto done; > >>>>>>>>>> } > >>>>>>>>>> + /* check the krbPrincipalExpiration attribute is present */ > >>>>>>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", > >>>>>>>>>> &attr); > >>>>>>>>>> + if (!ret) { > >>>>>>>>> ret is not a boolean so probably better ti use (ret != 0) > >>>>>>>>> > >>>>>>>>>> + /* if it is, check whether the principal has not > >>>>>>>>>> expired */ > >>>>>>>>>> + > >>>>>>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, > >>>>>>>>>> + "krbprincipalexpiration"); > >>>>>>>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); > >>>>>>>>>> + > >>>>>>>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", > >>>>>>>>>> &expire_tm)){ > >>>>>>>>> style issue missing space between ) and { > >>>>>>>>> > >>>>>>>>>> + expire_time = mktime(&expire_tm); > >>>>>>>>>> + /* this might have overflown on 32-bit system */ > >>>>>>>>> This comment does not help to point out what you want to put in > >>>>>>>>> evidence. > >>>>>>>>> if there is an overflow what is the consequence ? Or does it > >>>>>>>>> mean the > >>>>>>>>> next condition is taking that into account ? > >>>>>>>> Yeah, this was rather ill-worded. Replaced by a rather verbose > >>>>>>>> comment that hopefully clears things out. > >>>>>>>>>> + if (current_time > expire_time && expire_time > 0){ > >>>>>>>>> style issue missing space between ) and { > >>>>>>>>> > >>>>>>>>>> + LOG_FATAL("kerberos principal has expired in > >>>>>>>>>> user > >>>>>>>>>> entry: %s\n", > >>>>>>>>>> + dn); > >>>>>>>>> I think a better phrasing would be: "The kerberos principal on > >>>>>>>>> %s is > >>>>>>>>> expired\n" > >>>>>>>>> > >>>>>>>>>> + errMesg = "Kerberos principal has expired."; > >>>>>>>>> s/has/is/ > >>>>>>>>> > >>>>>>>>> The rest looks good to me. > >>>>>>>>> > >>>>>>>>> Simo. > >>>>>>>> Styling issues fixed and updated patch attached :) > >>>>>>> Small nit, the expiration error should probably use 'in' not 'on'. > >>>>>>> > >>>>>>> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This > >>>>>>> implies > >>>>>>> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM > >>>>>>> is probably > >>>>>>> more correct here. It is what we return on other policy failures. > >>>>>>> > >>>>>>> rob > >>>>>>> > >>>>>> Additional findings: > >>>>>> > >>>>>> 1) Lets not try to get current_time every time, but only when its > >>>>>> needed (i.e. > >>>>>> krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: > >>>>>> > >>>>>> + /* get current time*/ > >>>>>> + current_time = time(NULL); > >>>>>> > >>>>>> 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find > >>>>>> the > >>>>>> attribute again when we already have a pointer for the attribute? > >>>>>> Would > >>>>>> slapi_attr_first_value following slapi_entry_attr_find be faster > >>>>>> approach? > >>>>>> > >>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", > >>>>>> &attr); > >>>>>> + if (ret != 0) { > >>>>>> + /* if it is, check whether the principal has not expired */ > >>>>>> + > >>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, > >>>>>> + "krbprincipalexpiration"); > >>>>>> > >>>>>> This way, we would not create a copy of this attribute value - we do > >>>>>> not need a > >>>>>> copy, we just do check against it. > >>>>>> > >>>>>> > >>>>>> 3) Shouldn't we return -1 in the end when the auth fails? We do that > >>>>>> in other > >>>>>> pre_callbacks. Otherwise we just return 0 (success): > >>>>>> > >>>>>> + if (auth_failed){ > >>>>>> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, > >>>>>> errMesg, > >>>>>> + 0, NULL); > >>>>>> + } > >>>>>> + > >>>>>> return 0; > >>>>>> > >>>>>> Martin > >>>>> Thank you both for the review. I updated and retested the patch, with > >>>>> your suggestions incorporated. > >>>>> > >>>>> Tomas > >>>>> > >>>> I rebased the patch on top of current master. > >>>> > >>>> Bumping, since this is planned as part of 3.4 (and there were some > >>>> requests for this feature). > >>>> > >>>> Tomas > >>>> > >>> I updated the commit message to reflect better what the current version > >>> of the patch implements. > >>> > >>> Tomas > >>>> From a93d1ec3ca8c7b6e8e754b474257695ba9018e07 Mon Sep 17 00:00:00 2001 > >>> From: Tomas Babej > >>> Date: Mon, 6 Jan 2014 12:11:24 +0100 > >>> Subject: [PATCH] ipa-pwd-extop: Deny LDAP binds for user accounts > >>> with expired > >>> principal > >>> > >>> Adds a check for krbprincipalexpiration attribute to pre_bind operation > >>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is > >>> denied and LDAP_UNWILLING_TO_PERFORM along with the error message is > >>> sent back to the client. Since krbprincipalexpiration attribute is not > >>> mandatory, if there is no value set, the check is passed. > >>> > >>> https://fedorahosted.org/freeipa/ticket/3305 > >>> --- > >>> daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 45 > >>> ++++++++++++++++++++++- > >>> 1 file changed, 44 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c > >>> b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c > >>> index > >>> ef37b5e173359f9404b241c12d8a6dc6e77da128..568cba7189d1575d030b043daee61f713e9bac5f > >>> 100644 > >>> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c > >>> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c > >>> @@ -1389,13 +1389,17 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > >>> Slapi_Value *value = NULL; > >>> Slapi_Attr *attr = NULL; > >>> struct tm expire_tm; > >>> + time_t current_time; > >>> + time_t expire_time; > >>> char *errMesg = "Internal operations error\n"; /* error message */ > >>> char *expire = NULL; /* passwordExpirationTime attribute value */ > >>> + char *principal_expire = NULL; /* krbPrincipalExpiration > >>> attribute value */ > >>> char *dn = NULL; /* bind DN */ > >>> Slapi_Value *objectclass; > >>> int method; /* authentication method */ > >>> int ret = 0; > >>> char *principal = NULL; > >>> + bool auth_failed = false; > >>> > >>> LOG_TRACE("=>\n"); > >>> > >>> @@ -1422,7 +1426,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > >>> const char *attrs_list[] = {SLAPI_USERPWD_ATTR, > >>> "krbprincipalkey", "uid", > >>> "krbprincipalname", "objectclass", > >>> "passwordexpirationtime", > >>> "passwordhistory", > >>> - NULL}; > >>> + "krbprincipalexpiration", NULL}; > >>> > >>> /* retrieve user entry */ > >>> ret = ipapwd_getEntry(dn, &entry, (char **) attrs_list); > >>> @@ -1438,6 +1442,39 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > >>> goto done; > >>> } > >>> > >>> + /* check the krbPrincipalExpiration attribute is present */ > >>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", > >>> &attr); > >>> + if (ret == 0) { > >>> + ret = slapi_attr_first_value(attr, &value); > >>> + > >>> + if (ret == 0) { > >>> + /* if it is, check whether the principal has not expired */ > >>> + principal_expire = slapi_value_get_string(value); > >>> + memset(&expire_tm, 0, sizeof (expire_tm)); > >>> + > >>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", > >>> &expire_tm)) { > >>> + expire_time = mktime(&expire_tm); > >>> + > >>> + /* get current time */ > >>> + current_time = time(NULL); > >>> + > >>> + /* mktime returns -1 if the tm struct cannot be > >>> represented as > >>> + * as calendar time (seconds since the Epoch). This > >>> might > >>> + * happen with tm structs that are ill-formated or > >>> on 32-bit > >>> + * platforms with dates that would cause overflow > >>> + * (year 2038 and later). > >>> + * In such cases, skip the expiration check. */ > >>> + > >>> + if (current_time > expire_time && expire_time > 0) { > >>> + LOG_FATAL("kerberos principal in %s is > >>> expired\n", dn); > >>> + errMesg = "Kerberos principal is expired."; > >>> + auth_failed = true; > >>> + goto done; > >>> + } > >>> + } > >> I think indenting is broken for these two brackets. > >> > >> > > Thanks Alexander, fixed. > > > > Updated version attached. > > > > Tomas > > This version is rebased on top of OTP patches, addresses Simo's comments > and brings unit tests to cover the functionality (however, they need to > be applied on top of my patches 183-185). > LGTM, but I haven't tested the code live. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Apr 30 18:50:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 30 Apr 2014 21:50:06 +0300 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <1398883673.26263.19.camel@willson.li.ssimo.org> References: <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> <536111C4.1070604@redhat.com> <1398883673.26263.19.camel@willson.li.ssimo.org> Message-ID: <20140430185006.GS20958@redhat.com> On Wed, 30 Apr 2014, Simo Sorce wrote: >> > Updated version attached. >> > >> > Tomas >> >> This version is rebased on top of OTP patches, addresses Simo's comments >> and brings unit tests to cover the functionality (however, they need to >> be applied on top of my patches 183-185). >> > >LGTM, but I haven't tested the code live. I'll do final tests on Friday. -- / Alexander Bokovoy From pviktori at redhat.com Wed Apr 30 20:01:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Apr 2014 22:01:49 +0200 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53610F49.50003@redhat.com> References: <52D99F70.3060305@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> <5326E2DE.3010006@redhat.com> <5345A2B4.1000705@redhat.com> <5345BBAB.7010607@redhat.com> <5350E5EA.2060106@redhat.com> <53580BE2.6050606@redhat.com> <535917F0.4050107@redhat.com> <535FB6C1.5080900@redhat.com> <535FD205.8080909@redhat.com> <536069EF.6090306@redhat.com> <5360E857.5030609@redhat.com> <53610F49.50003@redhat.com> Message-ID: <536156AD.905@redhat.com> On 04/30/2014 04:57 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/30/2014 05:11 AM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 04/29/2014 04:27 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 04/23/2014 08:52 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 04/09/2014 11:29 PM, Rob Crittenden wrote: >>>>>>>>> Rob Crittenden wrote: >>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>> On 03/14/2014 07:58 PM, Rob Crittenden wrote: >>>>>>>>>>>> Petr Viktorin wrote: >>>>>>>>>>>>> On 03/12/2014 07:48 PM, Rob Crittenden wrote: >>>>>>>>>>> [...] >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here are a couple more enhancements I'm considering, this >>>>>>>>>>>>>> seems >>>>>>>>>>>>>> simpler >>>>>>>>>>>>>> than inter-diff since it is so small. >>>>>>>>>>>>> >>>>>>>>>>>>> Not really. Having a patch file with a sequence+revision >>>>>>>>>>>>> number >>>>>>>>>>>>> you >>>>>>>>>>>>> can >>>>>>>>>>>>> refer to has its merits. Especially in a hairy thread like >>>>>>>>>>>>> this >>>>>>>>>>>>> one. >>>>>>>>>>>>> Also one of our MUAs wrapped the lines, I had to undo that >>>>>>>>>>>>> manually. >>>>>>>>>>>>> >>>>>>>>>>>>>> Here is why I made the changes, in order: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I doubled the calls to create the connection but one isn't >>>>>>>>>>>>>> in a >>>>>>>>>>>>>> try/except!? Remove the obvious one. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We currently completely eat GSSAPI errors, I figure we should >>>>>>>>>>>>>> log >>>>>>>>>>>>>> failures. >>>>>>>>>>>>>> >>>>>>>>>>>>>> IPA stores the principal in the request context so using that >>>>>>>>>>>>>> will >>>>>>>>>>>>>> save >>>>>>>>>>>>>> a GSSAPI call (and as we learned, a lock in gssproxy). >>>>>>>>>>>>>> >>>>>>>>>>>>>> I included your content-type change. >>>>>>>>>>>>> >>>>>>>>>>>>> These changes look good. >>>>>>>>>>>>> I'm almost done testing but I need to call it a week. >>>>>>>>>>>> >>>>>>>>>>>> Awesome, thanks. >>>>>>>>>>> >>>>>>>>>>> ACK on the functionality. >>>>>>>>>>> >>>>>>>>>>>>> Sorry for not catching that last time, but your patch doesn't >>>>>>>>>>>>> add a >>>>>>>>>>>>> *versioned* BuildRequres on python-kerberos, instead it adds a >>>>>>>>>>>>> duplicate >>>>>>>>>>>>> unversioned one. So lint (and thus the build) will fail if the >>>>>>>>>>>>> old >>>>>>>>>>>>> python-kerberos version is installed. >>>>>>>>>>>>> >>>>>>>>>>>>> A possible a solution to the build trouble would be to just >>>>>>>>>>>>> add a >>>>>>>>>>>>> lint >>>>>>>>>>>>> exception now, and open a ticket to remove it later. That way >>>>>>>>>>>>> the >>>>>>>>>>>>> build >>>>>>>>>>>>> succeeds despite the older version, and the new >>>>>>>>>>>>> python-kerberos is >>>>>>>>>>>>> only >>>>>>>>>>>>> needed when installing freeipa-server-foreman-smartproxy. >>>>>>>>>>>>> That should make everyone happy, including Martin. >>>>>>>>>>>>> Unfortunately our lint exception mechanism doesn't work on >>>>>>>>>>>>> modules, so >>>>>>>>>>>>> this needs a somewhat nastier hack. >>>>>>>>>>>>> The attaching a patch that does this (and I'm pasting a simple >>>>>>>>>>>>> diff >>>>>>>>>>>>> below). Does that look okay to push? >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to find a better solution to all this. I may end up >>>>>>>>>>>> taking >>>>>>>>>>>> Martin's suggestion of rawhide-only to avoid this sort of >>>>>>>>>>>> thing. >>>>>>>>>>> >>>>>>>>>>> Looks like you'll still need to silence pylint on f20 in that >>>>>>>>>>> case. >>>>>>>>>>> >>>>>>>>>>>> The deal with the smartproxy is that you can/should be able to >>>>>>>>>>>> run >>>>>>>>>>>> it on >>>>>>>>>>>> any IPA-enrolled client, so you can run it directly on the >>>>>>>>>>>> Foreman >>>>>>>>>>>> box, >>>>>>>>>>>> with the IPA server somewhere else. What this means is that >>>>>>>>>>>> someone >>>>>>>>>>>> could probably fairly easily package this up for other >>>>>>>>>>>> distributions >>>>>>>>>>>> and >>>>>>>>>>>> if we end up with a Fedora-only python-kerberos patch then >>>>>>>>>>>> smartproxy is >>>>>>>>>>>> Fedora-only as well. >>>>>>>>>>>> >>>>>>>>>>>> So I'm trying to get some movement out of upstream on this but >>>>>>>>>>>> it's >>>>>>>>>>>> been >>>>>>>>>>>> crickets for weeks. I think in the context of the calendar >>>>>>>>>>>> server >>>>>>>>>>>> PyKerberos is small potatoes so doesn't get much lovin'. I'll >>>>>>>>>>>> amp up >>>>>>>>>>>> the >>>>>>>>>>>> nagging to get some sort of response, even if it is "stop >>>>>>>>>>>> nagging >>>>>>>>>>>> us!" >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>> Good luck! >>>>>>>>>> >>>>>>>>>> Ok, taking a different tack on this. Rather than running it as a >>>>>>>>>> separate server process, run it as a WSGI app inside Apache. This >>>>>>>>>> required a fair bit of re-tooling and complicates the set up a >>>>>>>>>> little >>>>>>>>>> bit. I think I've got it all covered in the man page. >>>>>>>>>> >>>>>>>>>> On the python-kerberos front I've got bugs opened in Ubuntu and >>>>>>>>>> Debian >>>>>>>>>> to see if we can get the patch accepted their until (if) upstream >>>>>>>>>> ever >>>>>>>>>> takes a look. >>>>>>>>> >>>>>>>>> I decided to run the new WSGI app in a different process group, >>>>>>>>> using >>>>>>>>> the smartproxy we use for delegation. This simplifies the >>>>>>>>> connection >>>>>>>>> code, rather than using ldap2 like I was using, we use the RPC >>>>>>>>> interface. And it provides to process separation. As a >>>>>>>>> side-effect it >>>>>>>>> will make running this code on platforms without GSSProxy a bit >>>>>>>>> easier. >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>> >>>>>>>> Works great here! >>>>>>>> >>>>>>>> >>>>>>>> The python-kerberos dependency issue still needs to be solved. >>>>>>> >>>>>>> Build is on the way to updates-testing if you can give it a go. >>>>>>> >>>>>>>> >>>>>>>> The man page says: >>>>>>>> Copy ipa-smartproxy-apache.conf to >>>>>>>> /etc/httpd/conf.d/ipa-smartproxy.conf. >>>>>>>> It would be nice to put the whole path here so people don't have to >>>>>>>> search for the file. >>>>>>> >>>>>>> Done. >>>>>>> >>>>>>>> >>>>>>>> The "Configure Apache to use smartproxy" line looks like a step >>>>>>>> to be >>>>>>>> performed. It could use some emphasis to make it look like a >>>>>>>> header. >>>>>>> >>>>>>> I combined it with the subsequent sentence so hopefully it is a bit >>>>>>> clearer. >>>>>>> >>>>>>> I also added a bit on testing so you can confirm that things are >>>>>>> working. >>>>>>> >>>>>>> >>>>>>>> Side note, cherrypy's routing makes requests like this possible: >>>>>>>> http POST >>>>>>>> :8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com/some_description/True/06-00-00-00-00-00/some_userclass >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Should that be allowed? >>>>>>> >>>>>>> It is definitely ugly but AFAICT it isn't illegal. The zero >>>>>>> content-length bothers me more than this horrible-looking URI. It >>>>>>> definitely requires some understanding of the ordering of >>>>>>> parameters to >>>>>>> get this call right. >>>>>>> >>>>>>> rob >>>>>> >>>>>> Everything works now! >>>>>> Except one thing: json_encode_binary recently got a mandatory version >>>>>> argument. For code that's part of IPA, it should be fine to just use >>>>>> API_VERSION here. >>>>>> >>>>>> I tested with that added; ACK if you agree. >>>>> >>>>> ACK on your change. >>>>> >>>>> Sorry, one more set of changes, some fairly significant. This brings >>>>> our >>>>> proxy in line with the Foreman proxy functionality-wise. I tested this >>>>> against a Foremane 1.5.0 RC1 build and it is fine. I didn't go as >>>>> far as >>>>> actually deploying any hosts but did confirm that the create/delete >>>>> functions work ok. >>>> >>>> I've eyeballed the changes, no testing yet. Here are my thoughts. >>>> >>>>> Significant changes: >>>>> - random removed as an option. It is always true unless a >>>>> user-provided >>>>> password is sent. >>>>> - Added an option to Command so that the real IPA error can be >>>>> raised to >>>>> make internal error handling possible. >>>> >>>> Please use a bare `raise` for simple re-raising of exceptions in an >>>> except: clause. It'll preserve the traceback. >>>> >>>> The control flow for the masking/re-raising seems convoluted. I've seen >>>> code like the following before: >>>> >>>> if nomaskexception: >>>> nonmasked_exceptions = Exception >>>> else: >>>> nonmasked_exceptions = () >>>> >>>> try: >>>> something() >>>> except nonmasked_exceptions as e: >>>> raise >>>> except ConcreteException as e: >>>> raise_masked_exception(e) >>>> >>>> >>>> Also it might be useful to factor raise_masked_exception() out; see >>>> below. >>> >>> Good idea. I sort of split the difference. >> >> Instead of >> + nomaskexception = options.get('nomaskexception', False) >> + if 'nomaskexception' in options: >> + del options['nomaskexception'] >> you can use: >> + nomaskexception = options.pop('nomaskexception', False) > > Of course. > >>> >>>> >>>>> - Rather than returning an DuplicateEntry error when POSTing to an >>>>> existing host, do a host_mod instead. >>>> >>>> Could you add a test for this? >>>> >>>> It looks like ip_address has no effect in this case, should we fail if >>>> it's given instead of silently ignoring it? Same for rebuilding new >>>> hosts. >>> >>> Done both. >> >> Nope, wrong test. 'Update the host' should use POST. > > Sorry, did it too quickly for my own good. > > It also turned out I was still returning 201 on updates which is bad. > >> >> Also, when updating using POST, unspecified information is removed, e.g. >> doing >> http POST >> ':8090/ipa/smartproxy/host/testhost.idm.lab.eng.brq.redhat.com?userclass=a_class' >> >> >> removes the description etc. >> I don't think that's intended. > > You're right. I pop off empty values on updates now. This means that one > can't wipe the description once set though. We may need to set a magic > value for that. Fortunately there already is a magic value, the empty string, which IPA treats as "unset attribute". It works nicely :) > I beefed up the data passed into the tests so we can confirm that values > don't disappear. > >>>>> - Add config option to pass updatedns=True when deleting a host. >>>> >>>> In DELETE, the exception handling seems overly broad. With a >>>> raise_masked_exception() function and nomaskexception, you could handle >>>> the specific error. It should help debugging if nothing else. >>>> >>>> This way of masking errors seems clumsy when nesting commands; I wonder >>>> if they can be handled better at a higher level >>>> ('request.error_response'?) >>> >>> Yes. I imagine that the Foreman smartproxy is doing this to mask the >>> issue as well. I dropped it, doing a GET instead so we'll get the proper >>> error in any case. It's a bit racy but it won't be as unnerving as >>> running into https://fedorahosted.org/freeipa/ticket/4329 >> >> Also, add 'add dns entries' and 'update dns entries' to the permission >> line in the manpage. >> > > Done, and added 'remove dns entries' as well. Great! Enough nitpicking, let's go break master. ACK, pushed to master: 64dcb1ec76fa706320746720431ef815eb3e9ecd -- Petr? From pviktori at redhat.com Wed Apr 30 20:17:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 30 Apr 2014 22:17:04 +0200 Subject: [Freeipa-devel] [PATCHES] 0546-0547 Allow alternate "aci" keyword in ACIs In-Reply-To: <53613FDF.6040406@redhat.com> References: <53612455.3000702@redhat.com> <53613224.9080805@redhat.com> <53613FDF.6040406@redhat.com> Message-ID: <53615A40.9050702@redhat.com> On 04/30/2014 08:24 PM, Petr Viktorin wrote: > On 04/30/2014 07:25 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> Hello, >>> The first patch adds "==" to ACI object to simplify comparisons. >>> The second patch moves existing "tests" to the test suite. >>> >>> The third patch adds support for an alternate "aci" keyword that DS >>> supports (but I couldn't get any documentaion on it). Dogtag adds ACIs >>> with this keyword to cn=config, so we'll need this fix when parsing ACIs >>> there. >>> >>> >>> Rob, you wrote the parser; does this look OK to you? >>> >> >> ACK. Pushed to master: c3d7e66291987149b3b9a019945179c54debfbf1 >> Only minor quibble is you left a couple of print statements in the tests. > > Those are intentional. When a failed test prints something, Nose shows > the output. It's pretty nice for debugging. > >> As you note, I had some "tests" that I ran when I was implementing the >> aci module. Moving these to formal testing is definitely the right thing >> to do. >> >> I do wonder one thing though. In the equality test I had reversed some >> ordering of things to ensure that things were normalized in the same >> way. For the check_aci_parsing() tests is it worth considering doing >> something similar? > > I'm not sure I follow; what part are you referring to? > > The ordering is problematic for sure; everything relies on dict order. > That's the main reason why in my work I only use this class to parse > ACIs, and I made a stable routine for generating them. > > Until we start running the tests with PYTHONHASHSEED=random, I figured > we can just use them as they are. > >> I noticed that we are apparently not normalizing target filters because >> there is a space in the DN. Something for later. > > Or not; I'd like to get rid of the export_to_string part completely. > >> There is no ticket. Probably fine since this is mostly just shuffling >> deck chairs. > > Yeah, same thinking here. It's part of the general ACI work. > -- Petr?