Re: [Freeipa-devel] [PATCH 177] ipatests: Extend test suite for ID ranges
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
lambda
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 'unicode'
type(got) = type 'list'
expected = u''
got = []
path = ('result', 'failed')
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 177] ipatests: Extend test suite for ID ranges
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
lambda
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 'unicode'
type(got) = type 'list'
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
From 1c2f5d2a9b3881896f1ed53cee943041f9f620b5 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 17 Mar 2014 15:44:00 +0100
Subject: [PATCH] ipatests: Extend test suite for ID ranges
Add tests coverage for recently added ID range checks dependant
on the ID range types.
Part of: https://fedorahosted.org/freeipa/ticket/4137
---
ipatests/test_xmlrpc/test_range_plugin.py | 472 --
1 file changed, 387 insertions(+), 85 deletions(-)
diff --git a/ipatests/test_xmlrpc/test_range_plugin.py b/ipatests/test_xmlrpc/test_range_plugin.py
index 3b7a393e8ed33d1027a786cc8266baa5da86407e..349fb73649650f97c3a9464f7e49bbd44863e869 100644
--- a/ipatests/test_xmlrpc/test_range_plugin.py
+++ b/ipatests/test_xmlrpc/test_range_plugin.py
@@ -28,6 +28,8 @@ from ipatests.util import MockLDAP
from ipapython.dn import DN
from ipatests.test_xmlrpc.test_user_plugin import get_user_result
+# Determine the test shift used
+
id_shift = 0
rid_shift = 0
@@ -52,6 +54,8 @@ for idrange in api.Command['idrange_find']()['result']:
if rid_shift rid_end:
rid_shift = rid_end + 100
+# Local ranges definitions
+
testrange1 = u'testrange1'
testrange1_base_id = id_shift + 90
testrange1_size = 9
@@ -100,52 +104,227 @@ testrange8_size = 50
testrange8_base_rid = rid_shift + 700
testrange8_secondary_base_rid = rid_shift + 800
-testrange9 = u'testrange9'
-testrange9_base_id = id_shift + 800
-testrange9_size = 50
-testrange9_base_rid = rid_shift + 800
-
-testrange10 = u'testrange10'
-testrange10_base_id = id_shift + 900
-testrange10_size = 50
-testrange10_base_rid = rid_shift + 900
-
-testrange9_dn = cn={name},cn=ranges,cn=etc,{basedn}.format(name=testrange9,
- basedn=api.env.basedn)
-
-testrange9_add = dict(
-objectClass=[ipaIDrange, ipatrustedaddomainrange],
-ipaBaseID={base_id}.format(base_id=testrange9_base_id),
-ipaBaseRID={base_rid}.format(base_rid=testrange9_base_rid),
-ipaIDRangeSize={size}.format(size=testrange9_size),
-ipaNTTrustedDomainSID=S-1-5-21-259319770-2312917334-591429603,
-ipaRangeType=ipa-ad-trust,
-)
-
-testrange10_dn = cn={name},cn=ranges,cn=etc,{basedn}.format(name=testrange10,
- basedn=api.env.basedn)
-
-testrange10_add = dict(
-objectClass=[ipaIDrange, ipatrustedaddomainrange],
-ipaBaseID={base_id}.format(base_id=testrange10_base_id),
-ipaBaseRID={base_rid}.format(base_rid=testrange10_base_rid),
-ipaIDRangeSize={size}.format(size=testrange10_size),
-ipaNTTrustedDomainSID=S-1-5-21-2997650941-1802118864-3094776726,
-ipaRangeType=ipa-ad-trust,
-)
-
-testtrust = u'testtrust'
-testtrust_dn = cn=testtrust,cn=trusts,{basedn}.format(basedn=api.env.basedn)
-
-testtrust_add = dict(
-objectClass=[ipaNTTrustedDomain, ipaIDobject, top],
-ipaNTFlatName='TESTTRUST',
-ipaNTTrustedDomainSID='S-1-5-21-2997650941-1802118864-3094776726',
-
Re: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements
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
From 2afc058870fea26a5079dd5d09994e2cb7196fe6 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
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 e9f69674ccb45dff9fdd4d78c11b6e90846d179f..b55624912d4de976a036e5fd2531373addcccefc 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
@@ -387,10 +387,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)){
--
1.8.5.3
From e5add061260ccff3a32c2510094a4b8fe5e7acc4 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
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 9a51d4196d4fdee20d053f40fc1b4a79f24df806..e9f69674ccb45dff9fdd4d78c11b6e90846d179f 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(Empty forest root map as trusts are not enabled on this IPA server.\n);
+ret = 0;
+*head = NULL;
+
goto done;
}
--
1.8.5.3
From e9e2b123adeebdbe5623285e83e64b28b0b91647 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
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
Re: [Freeipa-devel] New ACIs for cn=etc
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³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0172-0176] ipa_range_check improvements
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 177] ipatests: Extend test suite for ID ranges
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
lambda
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 'unicode'
type(got) = type 'list'
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
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
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: https://fedorahosted.org/freeipa/ticket/3416. 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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES] 0534-0535 Add several managed read permissions under cn=etc
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³
From ed223228c277028f62de6dd7c01e752a99cb6cb2 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Thu, 27 Mar 2014 15:36:54 +0100
Subject: [PATCH] Add support for non-plugin default permissions
Add support for managed permissions that are not tied to an object
class and thus can't be defined in an Object plugin.
A dict is added to hold templates for the non-plugin permissions.
---
ipaserver/install/plugins/update_managed_permissions.py | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py
index 3bba1f06e75fc2a0e57bce682827992e31f27708..438767f1c5c81709d5bd6efc875264c269ce0a6c 100644
--- a/ipaserver/install/plugins/update_managed_permissions.py
+++ b/ipaserver/install/plugins/update_managed_permissions.py
@@ -34,6 +34,9 @@
},
}
+For permissions not tied to an object plugin, a NONOBJECT_PERMISSIONS
+dict of the same format is defined in this module.
+
The permission name must start with the System: prefix.
The template dictionary can have the following keys:
@@ -41,8 +44,8 @@
- Directly used as attributes on the permission.
- Replaced when upgrading an existing permission
- If not specified, these default to the defaults of a permission of the
-corresponding --type, or (if non_object is specified) to general permission
-defaults.
+corresponding --type, or, if non_object is specified, or if not on an
+object, to general permission defaults .
- ipapermlocation and ipapermtarget must be DNs
- ipapermtargetfilter and objectclass must be iterables of strings
* ipapermbindruletype
@@ -77,6 +80,8 @@
register = Registry()
+NONOBJECT_PERMISSIONS = {}
+
@register()
class update_managed_permissions(PostUpdate):
@@ -123,6 +128,11 @@ def execute(self, **options):
template,
anonymous_read_blacklist)
+self.log.info('Updating non-object managed permissions')
+for name, template in NONOBJECT_PERMISSIONS.iteritems():
+self.update_permission(ldap, None, unicode(name), template,
+ anonymous_read_blacklist)
+
return False, False, ()
def update_permission(self, ldap, obj, name, template,
--
1.9.0
From f40bcb3da0c07dc94627fbb66b135203785c00e2 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 26 Mar 2014 17:11:23 +0100
Subject: [PATCH] Add several managed read permissions under cn=etc
This adds permissions to:
- cn=masters,cn=ipa (with new privilege)
- cn=dna,cn=ipa (authenticated users)
- cn=ca_renewal,cn=ipa (authenticated users)
- cn=CAcert,cn=ipa (anonymous)
- cn=replication (authenticated users)
- cn=ad (authenticated users)
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
---
install/updates/40-delegation.update | 7 ++
.../install/plugins/update_managed_permissions.py | 79 +-
2 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/install/updates/40-delegation.update b/install/updates/40-delegation.update
index 69061ca3df0cde8f66816e2f2f09aa15405a369e..49bb76277c44c0c4cae27839a45c6b4fc7b4f386 100644
--- a/install/updates/40-delegation.update
+++ b/install/updates/40-delegation.update
@@ -422,3 +422,10 @@ dn: cn=Automember Readers,cn=privileges,cn=pbac,$SUFFIX
default:objectClass: top
default:cn: Automember Readers
default:description: Read Automember definitions
+
+dn: cn=IPA Masters Readers,cn=privileges,cn=pbac,$SUFFIX
+default:objectClass: nestedgroup
+default:objectClass: groupofnames
+default:objectClass: top
+default:cn: IPA Masters Readers
+default:description: Read list of IPA masters
diff --git a/ipaserver/install/plugins/update_managed_permissions.py b/ipaserver/install/plugins/update_managed_permissions.py
index 438767f1c5c81709d5bd6efc875264c269ce0a6c..bffd9bbf434e76c9c6d74d0167a718acc96a54b1 100644
--- a/ipaserver/install/plugins/update_managed_permissions.py
+++ b/ipaserver/install/plugins/update_managed_permissions.py
@@ -68,7 +68,7 @@
No other keys are allowed in the template
-from ipalib import errors
+from ipalib import api, errors
from ipapython.dn import DN
from ipalib.plugable import Registry
from ipalib.plugins import aci
@@
Re: [Freeipa-devel] [PATCH][RFC] 13 - Log pretty-printed request and response
On Wed, 16 Apr 2014 11:42:00 -0400 Rob Crittenden rcrit...@redhat.com 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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Managed permission versioning
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
Re: [Freeipa-devel] Managed permission versioning
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
Re: [Freeipa-devel] [PATCH] 0520 Add managed read permission to service
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³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
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. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
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: https://fedorahosted.org/freeipa/ticket/3416. 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³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0529 Add managed read permission to trusts
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
From e3b84761216774f1ff94ea3bd482ec8119e8d19c Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Wed, 23 Apr 2014 14:32:01 +0200
Subject: [PATCH] Make trust objects available to regular users
With global read ACI removed, some of the trust and trustdomain
attributes are not available. Make trust plugin resilient to these
missing attributes and let it return the available information.
---
ipalib/plugins/trust.py | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index de838803f5c1046fedbc3b811ed28282f0890cd9..85b234ce94b3e19a4fb24a8fc316af11b3624e03 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -365,7 +365,7 @@ def get_dn(self, *keys, **kwargs):
ldap = self.backend
filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]]
Re: [Freeipa-devel] [PATCHES] 0534-0535 Add several managed read permissions under cn=etc
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. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Managed permission versioning
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
Re: [Freeipa-devel] [PATCH] 14 webui: select all checkbox remains selected after operation
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 15 webui doc: typo fixes in guides
On 18.4.2014 14:41, Misnyovszki Adam wrote: Hi, $SUBJ tells everything. Thanks Adam ACK Pushed to master: 260c5bd10927d3e01202ed1cccbdf4463c98e8a5 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Managed permission versioning
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
Re: [Freeipa-devel] Draft: Read permissions for user
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0246-0248] Follow query/transfer/update policies for secure zones
Hello,
This patch set configures secure zones according to policies in LDAP.
--
Petr^2 Spacek
From 68a247c0abc6a3ba8c0eb4f849eef2868f85bb82 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 23 Apr 2014 18:04:55 +0200
Subject: [PATCH] Move secure zone configuration from create_zone() to
zone_master_reconfigure().
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 49 +
1 file changed, 33 insertions(+), 16 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index b9afc792862ed6e14b29862ac4d527528aae8e87..c698fd359dd31f12875528ce289cfb801bfaf4f1 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -949,20 +949,6 @@ create_zone(ldap_instance_t * const inst, const char * const dn,
CHECK(dns_zone_setdbtype(secure, 1, rbt_argv));
CHECK(dns_zonemgr_managezone(inst-zmgr, secure));
CHECK(dns_zone_link(secure, raw));
-
- /* Magic constants are taken from zoneconf.c */
- dns_zone_setsigvalidityinterval(secure, 2592000); /* sig-validity-interval */
- dns_zone_setsigresigninginterval(secure, 648000); /* re-sign */
- dns_zone_setsignatures(secure, 10); /* sig-signing-signatures */
- dns_zone_setnodes(secure, 10); /* sig-signing-nodes */
- dns_zone_setprivatetype(secure, 65534); /* sig-signing-type */
- dns_zone_setoption(secure, DNS_ZONEOPT_UPDATECHECKKSK,
- ISC_TRUE); /* update-check-ksk */
- dns_zone_setrefreshkeyinterval(secure, 60); /* dnssec-loadkeys-interval */
- /* auto-dnssec = maintain */
- dns_zone_setkeyopt(secure, DNS_ZONEKEY_ALLOW, ISC_TRUE);
- dns_zone_setkeyopt(secure, DNS_ZONEKEY_MAINTAIN, ISC_TRUE);
-
dns_zone_rekey(secure, ISC_TRUE);
CHECK(configure_paths(inst-mctx, inst, secure, ISC_TRUE));
}
@@ -1881,7 +1867,7 @@ cleanup:
*/
static isc_result_t ATTR_NONNULLS ATTR_CHECKRESULT
zone_master_reconfigure(ldap_entry_t *entry, settings_set_t *zone_settings,
- dns_zone_t *raw, isc_task_t *task) {
+ dns_zone_t *raw, dns_zone_t *secure, isc_task_t *task) {
isc_result_t result;
const char *dn = NULL;
ldap_valuelist_t values;
@@ -1952,6 +1938,37 @@ zone_master_reconfigure(ldap_entry_t *entry, settings_set_t *zone_settings,
result = ISC_R_SUCCESS;
}
+ if (secure != NULL) {
+ /* notifications should be sent from secure zone only */
+ dns_zone_setnotifytype(raw, dns_notifytype_no);
+
+ /* Magic constants are taken from zoneconf.c */
+ /* sig-validity-interval */
+ dns_zone_setsigvalidityinterval(secure, 2592000);
+
+ /* re-sign */
+ dns_zone_setsigresigninginterval(secure, 648000);
+
+ /* sig-signing-signatures */
+ dns_zone_setsignatures(secure, 10);
+
+ /* sig-signing-nodes */
+ dns_zone_setnodes(secure, 10);
+
+ /* sig-signing-type */
+ dns_zone_setprivatetype(secure, 65534);
+
+ /* update-check-ksk */
+ dns_zone_setoption(secure, DNS_ZONEOPT_UPDATECHECKKSK, ISC_TRUE);
+
+ /* dnssec-loadkeys-interval */
+ CHECK(dns_zone_setrefreshkeyinterval(secure, 60));
+
+ /* auto-dnssec = maintain */
+ dns_zone_setkeyopt(secure, DNS_ZONEKEY_ALLOW, ISC_TRUE);
+ dns_zone_setkeyopt(secure, DNS_ZONEKEY_MAINTAIN, ISC_TRUE);
+ }
+
cleanup:
return result;
}
@@ -2162,7 +2179,7 @@ ldap_parse_master_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst,
}
CHECK(zr_get_zone_settings(inst-zone_register, name, zone_settings));
- CHECK(zone_master_reconfigure(entry, zone_settings, raw, task));
+ CHECK(zone_master_reconfigure(entry, zone_settings, raw, secure, task));
sync_state_get(inst-sctx, sync_state);
if (new_zone == ISC_TRUE sync_state == sync_finished)
--
1.9.0
From c6b16f1a183af69740de2c2f1369abd13c28a2ea Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 23 Apr 2014 18:08:05 +0200
Subject: [PATCH] Follow query/transfer/update policies for secure zones.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index c698fd359dd31f12875528ce289cfb801bfaf4f1..23e32928382226662098b5643a3c24b683113b19 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -1873,15 +1873,21 @@ zone_master_reconfigure(ldap_entry_t *entry, settings_set_t *zone_settings,
ldap_valuelist_t values;
isc_mem_t *mctx = NULL;
isc_boolean_t ssu_changed;
+ dns_zone_t *inview = NULL;
REQUIRE(entry != NULL);
REQUIRE(zone_settings != NULL);
REQUIRE(raw != NULL);
REQUIRE(task != NULL);
dn = entry-dn;
mctx = dns_zone_getmctx(raw);
+ if (secure != NULL)
+ dns_zone_attach(secure, inview);
+ else
+ dns_zone_attach(raw, inview);
+
result = setting_update_from_ldap_entry(dyn_update, zone_settings,
idnsAllowDynUpdate, entry, task);
if (result != ISC_R_SUCCESS result != ISC_R_IGNORE)
@@ -1920,17 +1926,17 @@ zone_master_reconfigure(ldap_entry_t *entry, settings_set_t *zone_settings,
Re: [Freeipa-devel] Draft: Read permissions for user
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Managed permission versioning
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
[Freeipa-devel] [PATCH 0249-0250] Propagate DNS updates changes from LDAP to signed version of the zone
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
From 88b3ab38ab9685db2a829b79e302c2cb223c624e Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 23 Apr 2014 18:09:57 +0200
Subject: [PATCH] Rename zone variables in update_record().
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 2b4ba1936e3b9c934cb64259f199c62ef6a2e496..1941bcd6c2181fda4167d674aeda90a9588da200 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -4172,7 +4172,6 @@ update_record(isc_task_t *task, isc_event_t *event)
isc_result_t result;
ldap_instance_t *inst = NULL;
isc_mem_t *mctx;
- dns_zone_t *zone_ptr = NULL;
dns_zone_t *zone_raw = NULL;
isc_boolean_t zone_found = ISC_FALSE;
isc_boolean_t zone_reloaded = ISC_FALSE;
@@ -4216,7 +4215,7 @@ update_record(isc_task_t *task, isc_event_t *event)
CHECK(manager_get_ldap_instance(pevent-dbname, inst));
CHECK(dn_to_dnsname(mctx, pevent-dn, name, origin));
- CHECK(zr_get_zone_ptr(inst-zone_register, origin, zone_ptr, NULL));
+ CHECK(zr_get_zone_ptr(inst-zone_register, origin, zone_raw, NULL));
zone_found = ISC_TRUE;
update_restart:
@@ -4298,11 +4297,12 @@ update_restart:
DNS_DIFFOP_ADD, soa_tuple));
CHECK(update_soa_serial(dns_updatemethod_unixtime,
soa_tuple, serial));
- dns_zone_log(zone_ptr, ISC_LOG_DEBUG(5),
- writing new zone serial %u to LDAP, serial);
+ dns_zone_log(zone_raw, ISC_LOG_DEBUG(5),
+ writing new zone serial %u to LDAP,
+ serial);
result = ldap_replace_serial(inst, origin, serial);
if (result != ISC_R_SUCCESS)
-dns_zone_log(zone_ptr, ISC_LOG_ERROR,
+dns_zone_log(zone_raw, ISC_LOG_ERROR,
serial (%u) write back to LDAP failed,
serial);
dns_diff_append(diff, soa_tuple);
@@ -4315,11 +4315,7 @@ update_restart:
#endif
if (sync_state == sync_finished) {
/* write the transaction to journal */
- dns_zone_getraw(zone_ptr, zone_raw);
- if (zone_raw == NULL)
-journal_filename = dns_zone_getjournal(zone_ptr);
- else
-journal_filename = dns_zone_getjournal(zone_raw);
+ journal_filename = dns_zone_getjournal(zone_raw);
CHECK(dns_journal_open(mctx, journal_filename,
DNS_JOURNAL_CREATE, journal));
CHECK(dns_journal_write_transaction(journal, diff));
@@ -4332,7 +4328,7 @@ update_restart:
/* Check if the zone is loaded or not.
* No other function above returns DNS_R_NOTLOADED. */
if (sync_state == sync_finished)
- result = dns_zone_getserial2(zone_ptr, serial);
+ result = dns_zone_getserial2(zone_raw, serial);
cleanup:
#ifdef RBTDB_DEBUG
@@ -4362,26 +4358,26 @@ cleanup:
reload triggered by change in '%s',
pevent-dn);
- if (zone_ptr != NULL)
- result = dns_zone_load(zone_ptr);
+ if (zone_raw != NULL)
+ result = dns_zone_load(zone_raw);
if (result == ISC_R_SUCCESS || result == DNS_R_UPTODATE ||
result == DNS_R_DYNAMIC || result == DNS_R_CONTINUE) {
/* zone reload succeeded, fire current event again */
log_debug(1, restarting update_record after zone reload
caused by change in '%s', pevent-dn);
zone_reloaded = ISC_TRUE;
- result = dns_zone_getserial2(zone_ptr, serial);
+ result = dns_zone_getserial2(zone_raw, serial);
if (result == ISC_R_SUCCESS) {
-dns_zone_log(zone_ptr, ISC_LOG_INFO,
+dns_zone_log(zone_raw, ISC_LOG_INFO,
reloaded serial %u, serial);
goto update_restart;
} else {
-dns_zone_log(zone_ptr, ISC_LOG_ERROR,
+dns_zone_log(zone_raw, ISC_LOG_ERROR,
could not get serial after
reload);
}
} else {
- dns_zone_log(zone_ptr, ISC_LOG_ERROR,
+ dns_zone_log(zone_raw, ISC_LOG_ERROR,
unable to reload invalid zone;
reload triggered by change in '%s':%s,
pevent-dn, dns_result_totext(result));
@@ -4405,8 +4401,8 @@ cleanup:
if (dns_name_dynamic(prevorigin))
dns_name_free(prevorigin, inst-mctx);
}
- if (zone_ptr != NULL)
- dns_zone_detach(zone_ptr);
+ if (zone_raw != NULL)
+ dns_zone_detach(zone_raw);
ldapdb_rdatalist_destroy(mctx, rdatalist);
isc_mem_free(mctx, pevent-dbname);
if (pevent-prevdn != NULL)
--
1.9.0
From a860cd669a194350d20e876b90838aac6d203b8a Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 23 Apr 2014 18:11:05 +0200
Subject: [PATCH] Propagate DNS updates changes from LDAP to signed version
of the zone.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/ldap_helper.c
Re: [Freeipa-devel] Draft: Read permissions for user
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] [CI] Move project definition to a template file
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: tba...@redhat.com.
With this setup, a developer's personal test modifications shouldn't
override the main config.
https://github.com/encukou/freeipa-ci
--
Petr³
From da0dfceeaca61368ba676695ac1dd033ee8957e5 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 23 Apr 2014 20:09:57 +0200
Subject: [PATCH] Move project definition to a template file
This means that every developer can create her own namespace of jobs
on a Jenkins instance without overwriting the official ones.
Also, my e-mail address is finally not hard-coded in the config.
---
.gitignore | 1 +
README | 2 ++
jenkins-job-builder/docs.yaml| 3 ++-
jenkins-job-builder/freeipa-jobs.yaml| 38 +---
jenkins-job-builder/project.yaml.example | 16 ++
5 files changed, 36 insertions(+), 24 deletions(-)
create mode 100644 .gitignore
create mode 100644 jenkins-job-builder/project.yaml.example
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..7904fea
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+jenkins-job-builder/project.yaml
diff --git a/README b/README
index 05506f0..4ac4092 100644
--- a/README
+++ b/README
@@ -20,6 +20,8 @@ Sample usage:
user=USERNAME
password=PASSWORD
url=JENKINS_URL
+project configuration file:
+Copy 'project.yaml.example' to 'project.yaml' and customize it to your needs
commit to Jenkins:
jenkins-jobs update ./jenkins-job-builder/
diff --git a/jenkins-job-builder/docs.yaml b/jenkins-job-builder/docs.yaml
index afdee53..26b8214 100644
--- a/jenkins-job-builder/docs.yaml
+++ b/jenkins-job-builder/docs.yaml
@@ -30,7 +30,8 @@
cd src/user_guide/
make
publishers:
-- mail-on-fail
+- mail-on-fail:
+report-mail-address: '{report-mail-address}'
- archive:
artifacts: 'src/user_guide/tmp/**'
triggers:
diff --git a/jenkins-job-builder/freeipa-jobs.yaml b/jenkins-job-builder/freeipa-jobs.yaml
index 6e053a7..7fbdf12 100644
--- a/jenkins-job-builder/freeipa-jobs.yaml
+++ b/jenkins-job-builder/freeipa-jobs.yaml
@@ -21,7 +21,7 @@
name: mail-on-fail
publishers:
- email:
-recipients: pvikt...@redhat.com
+recipients: '{report-mail-address}'
- publisher:
name: nosetests-xunit
@@ -168,7 +168,8 @@
- build-rpms
- createrepo
publishers:
-- mail-on-fail
+- mail-on-fail:
+report-mail-address: '{report-mail-address}'
- warnings:
console-log-parsers:
- GNU Compiler 4 (gcc)
@@ -201,7 +202,8 @@
- shell: sudo yum check-update
- shell: rpm -qa | sort
publishers:
-- mail-on-fail
+- mail-on-fail:
+report-mail-address: '{report-mail-address}'
publishers:
- trigger:
project: '{prefix}-intree-tests-{os}'
@@ -261,7 +263,8 @@
- uninstall
publishers:
- nosetests-xunit
-- mail-on-fail
+- mail-on-fail:
+report-mail-address: '{report-mail-address}'
triggers:
- timed:
# Do the check nightly
@@ -293,7 +296,8 @@
- uninstall
publishers:
- nosetests-xunit
-- mail-on-fail
+- mail-on-fail:
+report-mail-address: '{report-mail-address}'
- job-template:
name: '{prefix}-webui-{browser}-{os}-{prettyname}'
@@ -326,7 +330,8 @@
- uninstall
publishers:
- nosetests-xunit
-- mail-on-fail
+- mail-on-fail:
+report-mail-address: '{report-mail-address}'
- job-template:
name: '{prefix}-integration-{os}-{pretty_name}'
@@ -363,7 +368,8 @@
- uninstall
publishers:
- nosetests-xunit
-- mail-on-fail
+- mail-on-fail:
+report-mail-address: '{report-mail-address}'
- job-group:
name: build-and-check
@@ -517,7 +523,8 @@
publishers:
- trigger:
project: '{prefix}-build-{os}'
-- mail-on-fail
+- mail-on-fail:
+report-mail-address: '{report-mail-address}'
- plot:
- title: PEP8+pyflakes problems
yaxis: problems
@@ -532,21 +539,6 @@
report-files: sloccount.sc
charset: UTF-8
-- project:
-name: f20
-os: f20
-prefix: freeipa
-git-branch: master
-git-url: git://git.fedorahosted.org/git/freeipa.git
-git-browser-url: https://git.fedorahosted.org/cgit/freeipa.git/
-options-dns-setup:
---setup-dns
-
[Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes
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³ From c052f61bb0c1395a170fdf88bfbf729cf37d95a0 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Wed, 26 Mar 2014 17:11:23 +0100 Subject: [PATCH] Add ACI for read-only admin attributes Most admin access is granted with the Admin can manage any entry ACI, but before the global anonymous read ACI is removed, read-only admin access must be explicitly given. Add an ACI for read-only attributes. Move the admin ACIs from ldif and trusts.update to aci.update. https://fedorahosted.org/freeipa/ticket/4319 --- install/share/default-aci.ldif | 3 --- install/updates/20-aci.update| 14 ++ install/updates/60-trusts.update | 6 -- 3 files changed, 14 insertions(+), 9 deletions(-) diff --git a/install/share/default-aci.ldif b/install/share/default-aci.ldif index 490a69de0933f02c9268a8fbd0ed8596cecf801c..480facf3294c593c6a2bcf326e20c32157d6d3c6 100644 --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -5,10 +5,7 @@ dn: $SUFFIX add: aci aci: (targetfilter = ((!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenHOTP))(!(objectClass=ipatokenRadiusConfiguration(target != ldap:///idnsname=*,cn=dns,$SUFFIX;)(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;) aci: (targetattr = memberOf || memberHost || memberUser)(version 3.0; acl No anonymous access to member information; deny (read,search,compare) userdn != ldap:///all;;) -aci: (targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbTicketPolicyReference || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || ipaUniqueId || memberOf || serverHostName || enrolledBy || ipaNTHash)(version 3.0; acl Admin can manage any entry; allow (all) groupdn = ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) aci: (targetattr = userpassword || krbprincipalkey || sambalmpassword || sambantpassword)(version 3.0; acl selfservice:Self can write own password; allow (write) userdn=ldap:///self;;) -aci: (targetattr = userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || ipaNTHash)(version 3.0; acl Admins can write passwords; allow (add,delete,write) groupdn=ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) -aci: (targetfilter = (objectClass=krbPwdPolicy))(targetattr = krbMaxPwdLife || krbMinPwdLife || krbPwdMinDiffChars || krbPwdMinLength || krbPwdHistoryLength)(version 3.0;acl Admins can write password policies; allow (read, search, compare, write) groupdn = ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;) aci: (targetattr = *)(target = ldap:///cn=*,ou=SUDOers,$SUFFIX;)(version 3.0; acl No anonymous access to sudo; deny (read,search,compare) userdn != ldap:///all;;) dn: $SUFFIX diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update index 9d8a6392f2ffbfb52dd6725ed4008b29bc164b03..96cae436b836d104414472fe3b71d5327a665fcd 100644 --- a/install/updates/20-aci.update +++ b/install/updates/20-aci.update @@ -28,3 +28,17 @@ dn: $SUFFIX # Read access to Kerberos container (cn=kerberos) and realm containers (cn=$REALM,cn=kerberos) dn: cn=kerberos,$SUFFIX add:aci:'(targetattr = cn || objectclass)(targetfilter = (|(objectclass=krbrealmcontainer)(objectclass=krbcontainer)))(version 3.0;acl Anonymous read access to Kerberos containers;allow (read,compare,search) userdn = ldap:///anyone;;)' + +# Access for high-level admins +dn: $SUFFIX +# Read/write +remove:aci:'(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || krbPrincipalName || krbCanonicalName || krbUPEnabled || krbTicketPolicyReference || krbPrincipalExpiration || krbPasswordExpiration || krbPwdPolicyReference || krbPrincipalType || krbPwdHistory || krbLastPwdChange || krbPrincipalAliases || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || krbLoginFailedCount || krbTicketFlags || ipaUniqueId || memberOf || serverHostName || enrolledBy)(version 3.0; acl Admin can manage any entry; allow (all) groupdn =
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
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 From 5ada61118d8e1c27aac3892fb844e770f9bbc9de Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Tue, 3 Dec 2013 09:14:00 -0700 Subject: [PATCH] Implement an IPA Foreman smartproxy server This currently server supports only host and hostgroup commands for retrieving, adding and deleting entries. The incoming requests are completely unauthenticated and by
Re: [Freeipa-devel] [PATCHES] 0536-0537 Add ACI for read-only admin attributes
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. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Draft: Read permissions for user
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
