Re: [Freeipa-devel] [PATCH] 0480 permission plugin: Don't crash with empty targetfilter
On 03/07/2014 04:34 PM, Martin Kosek wrote: On 02/28/2014 01:13 PM, Petr Viktorin wrote: Fixing the subject On 02/28/2014 01:11 PM, Petr Viktorin wrote: Hello, This fixes https://fedorahosted.org/freeipa/ticket/4206 Apply on top of my patch 0479, to avoid a conflict in tests. Works fine, ACK Thank you! Pushed to master: d727599aa804aecd91de969a9309c1903d0cfdce (thanks for your care with adding tests every time, this will benefit us in a long run). Not just in the long run; I think I'd go crazy if I had to test this manually... -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0479 permission plugin: Allow multiple values for memberof
On 03/07/2014 04:30 PM, Martin Kosek wrote:
On 02/28/2014 10:42 AM, Petr Viktorin wrote:
Hello,
Here is an additional part for the multivalued target filters: making
--memberof also multivalued.
http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions
https://fedorahosted.org/freeipa/ticket/4074
Works fine. ACK if you remove the conflict on VERSION file.
Martin
Thank you!
Rebased & pushed to master: 0c2aec1be52af311feab15c01d03dfaff4b60fce
--
Petr³
From 1681ce64680f083cdd46daa8bf01aed64f968782 Mon Sep 17 00:00:00 2001
From: Petr Viktorin
Date: Thu, 27 Feb 2014 14:38:16 +0100
Subject: [PATCH] permission plugin: Allow multiple values for memberof
Design: http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions
Additional fix for: https://fedorahosted.org/freeipa/ticket/4074
---
API.txt| 6 ++--
VERSION| 4 +--
ipalib/plugins/permission.py | 16 +++
ipatests/test_xmlrpc/test_permission_plugin.py | 40 ++
4 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/API.txt b/API.txt
index 971edd915da7818263fda35985ac34f4040a71ad..5d106338608698a499be3e56a00eb2a220ec87cf 100644
--- a/API.txt
+++ b/API.txt
@@ -2335,7 +2335,7 @@ command: permission_add
option: StrEnum('ipapermright', attribute=True, cli_name='permissions', multivalue=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all'))
option: DNParam('ipapermtarget', attribute=True, cli_name='target', multivalue=False, required=False)
option: Str('ipapermtargetfilter', attribute=True, cli_name='filter', multivalue=True, required=False)
-option: Str('memberof', alwaysask=True, attribute=False, autofill=False, cli_name='memberof', multivalue=False, query=False, required=False)
+option: Str('memberof', alwaysask=True, attribute=False, autofill=False, cli_name='memberof', multivalue=True, query=False, required=False)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Str('permissions', attribute=False, cli_name='permissions', multivalue=True, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
@@ -2393,7 +2393,7 @@ command: permission_find
option: StrEnum('ipapermright', attribute=True, autofill=False, cli_name='permissions', multivalue=True, query=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all'))
option: DNParam('ipapermtarget', attribute=True, autofill=False, cli_name='target', multivalue=False, query=True, required=False)
option: Str('ipapermtargetfilter', attribute=True, autofill=False, cli_name='filter', multivalue=True, query=True, required=False)
-option: Str('memberof', attribute=False, autofill=False, cli_name='memberof', multivalue=False, query=True, required=False)
+option: Str('memberof', attribute=False, autofill=False, cli_name='memberof', multivalue=True, query=True, required=False)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Str('permissions', attribute=False, autofill=False, cli_name='permissions', multivalue=True, query=True, required=False)
option: Flag('pkey_only?', autofill=True, default=False)
@@ -2423,7 +2423,7 @@ command: permission_mod
option: StrEnum('ipapermright', attribute=True, autofill=False, cli_name='permissions', multivalue=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all'))
option: DNParam('ipapermtarget', attribute=True, autofill=False, cli_name='target', multivalue=False, required=False)
option: Str('ipapermtargetfilter', attribute=True, autofill=False, cli_name='filter', multivalue=True, required=False)
-option: Str('memberof', attribute=False, autofill=False, cli_name='memberof', multivalue=False, required=False)
+option: Str('memberof', attribute=False, autofill=False, cli_name='memberof', multivalue=True, required=False)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Str('permissions', attribute=False, autofill=False, cli_name='permissions', multivalue=True, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
diff --git a/VERSION b/VERSION
index 64472ada17b9f30d3e3cf0a01d178b1d6ab8dd9f..e889bced8a3ad2450555a876236302bb4b58c5db 100644
--- a/VERSION
+++ b/VERSION
@@ -89,5 +89,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=76
-# Last change: npmccallum - otptoken defaults change
+IPA_API_VERSION_MINOR=77
+# Last change: pviktori - permissions: multivalued memberof
diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py
index 79335404a22c54ad2dd12bbb3052b7ea87cb9a88..82272d361a457b11e499cda000b9d0a350ba870e 100644
--- a/ipalib/pl
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/05/2014 11:06 AM, Simo Sorce wrote: On Wed, 2014-03-05 at 16:29 +0100, Martin Kosek wrote: On 03/05/2014 03:04 PM, Simo Sorce wrote: On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Yeah, but the plan is not force people to have the heavy weight Java infrastructure on each server so that they are able to create more lightweight servers only with components they choose: https://fedorahosted.org/freeipa/ticket/4058 Yes, but the Vault does not need to be installed on each server, just on a couple of them like for the CA. In particular it doesn't need to be installed on the same servers that offer the DNS service. Simo. I agree with Simo. From the big picture perspective we have more and more use cases when Vault becomes a requirement: a) Storing passwords for users - initial case b) Storing volume keys for Cinder - OpenStack - Barbican use case c) Storing passwords for external cloud provider accounts - deltacloud/Manage IQ use case d) Storing DNSSEC keys - your use case e) Storing private keys for users - classical PKI escrow the DRM was built for f) Storing private SSH key - there is a ticket for that kind of escrow functionality too. For me it is apparent that vault will be a default component. It is not as heavy weight now as it used to be. All Dogtag components can share same tomcat instance so if you have a CA on the system your incremental impact is very small. So what we need is: a) Solve the problem of the DRM install. Single server work was done by Rob. Ade will be able to take it over and hel;p with the DRM install across several servers (with replication). b) There is REST API for Vault it requires certificate authentication for now. No Kerberos. We can probably live without Kerberos for now since SSSD has host cert. c) We need to hook some kind of access control that would allow specifying policies about who can fetch which keys (this is regardless where they are stored Vault or LDAP) I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0486 permission-mod: Remove attributelevelrights before reverting entry
On 03/03/2014 04:04 PM, Petr Viktorin wrote: > Hello, > This fixes issue #4212 which Petr¹ found in his Web UI work. > > [#4212] https://fedorahosted.org/freeipa/ticket/4212 > ACK. Pushed to master: 02e61961daf87fae22d6891ce2e1d7f8670dd2bf Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0481 permission-find: Cache the root entry for legacy permissions
On 02/28/2014 03:51 PM, Petr Viktorin wrote: > Hello, > This reduces LDAP searches in permission-find when there are legacy > permissions. The root entry (which contains all legacy permission ACIs) is > only > looked up once. > > There is a conflict on one line. But when I manually resolved it, the patch worked for me. We got from 176 OPS per "ipa permission-find" to ~96. This should be OK for now. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò ha scritto: > On 31/01/2014 18:57, Dmitri Pal wrote: >> On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: >>> Are you saying that we should split our development in two: >>> >>> (1) smart proxy, exposing the RESTful interface, developed on the >>> basis of [8] >>> >>> (2) actual ConnId connector, dealing with the proxy above for >>> implementing its own logic >> Correct >> >>> If so, could you please point to the source code of [8]? >>> Will then this eventually become part of FreeIPA? >> Quite soon. I would leave it to the team to suggest whether user and >> host provisioning smart proxies should be a same smart proxy or >> different so that they can be installed independently from each other >> but use the same approach. IMO haveing them separately but share the >> same code and approach will be more valuable to the project. But I am >> open to other ideas here. >> >>> I am actually not sure if it is "lightweight" connector could actually >>> be better than a "loaded" connector (e.g. without proxy), from a >>> deployment point of view, unless you are saying either that (a) a >>> smart proxy is already available that can be reused >> The idea can be reused as a starting point. IMO the easiest would be to >> look at the patches and use same machinery but implement different commands. >> >>> or that (b) incorporating the smart proxy that we are going to develop >>> into FreeIPA will easily happen. >> If done right: i.e. following process and style then yes. >> >> Please become familiar with the coding style [9] page on the wiki and >> other contributer guidelines [10]. >> Also having a design page created as a result of the preliminary >> investigation would go a long way towards acceptance and quality of the >> feature. >> >> We will gladly guide you on the way if you have specific questions >> >> [...] > > Ok then, we'll do it as follows. > > We are currently experimenting with FreeIPA, to get familiar with technology > and options; once we will be confident enough to start the actual work on the > connector, we will check the status of the smart proxy patches from [11]. > > If the implementation status will be close to be ready and about to be > included in the official distribution, we will follow the suggestions above > and develop a REST-based connector. We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. Thanks M > > Otherwise, we will instead specialize the CMD connector [12] to feature the > FreeIPA command-line interface (as suggested at the beginning of this > thread). There will be potentially need, in this case, to include the ConnId > connector server into the Syncope deployment architecture, but this is a > supported pattern. > > Thanks for your support. > Regards. > >>> [2] http://tirasa.github.io/ConnId/ >>> [3] http://java.net/projects/identityconnectors/ >>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >> [5] >> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html > [6] > https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html > > [7] http://www.freeipa.org/page/Documentation > [8] http://www.freeipa.org/page/V3/Smart_Proxy >>> [1] http://syncope.apache.org/ >> [9] http://www.freeipa.org/page/Coding_Style >> [10] http://www.freeipa.org/page/Contribute/Code > [11] https://fedorahosted.org/freeipa/ticket/4128 > [12] https://github.com/Tirasa/ConnIdCMDBundle > [13] https://connid.atlassian.net/wiki/display/BASE/Connector+Servers > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Involved at The Apache Software Foundation: > member, Syncope PMC chair, Cocoon PMC, Olingo PPMC > http://people.apache.org/~ilgrosso/ > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0479 permission plugin: Allow multiple values for memberof
On 02/28/2014 10:42 AM, Petr Viktorin wrote: > Hello, > Here is an additional part for the multivalued target filters: making > --memberof also multivalued. > > http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions > https://fedorahosted.org/freeipa/ticket/4074 Works fine. ACK if you remove the conflict on VERSION file. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0480 permission plugin: Don't crash with empty targetfilter
On 02/28/2014 01:13 PM, Petr Viktorin wrote: > Fixing the subject > On 02/28/2014 01:11 PM, Petr Viktorin wrote: >> Hello, >> This fixes https://fedorahosted.org/freeipa/ticket/4206 >> >> Apply on top of my patch 0479, to avoid a conflict in tests. > > Works fine, ACK (thanks for your care with adding tests every time, this will benefit us in a long run). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 550 webui-css: improve radio, checkbox keyboard support and color
checkboxes and radio buttons:
- do not change color on hover when disabled
- are focusable and checkable by keyboard again. This uses a little
trick where the real checkbox is hidden under the artificial
checkbox. That way it has the same position and therefore it
works even in containers with overflow set.
https://fedorahosted.org/freeipa/ticket/4217
--
Petr Vobornik
From a554df223b33de5c7ede4838cef6e558170761ab Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Thu, 27 Feb 2014 18:21:05 +0100
Subject: [PATCH] webui-css: improve radio,checkbox keyboard support and color
checkboxes and radio buttons:
- do not change color on hover when disabled
- are focusable and checkable be keyboard again. This uses a little
trick where the real checkbox is hidden under the artificial
checkbox. That way it has the same position and therefore it
works even in containers with overflow set.
https://fedorahosted.org/freeipa/ticket/4217
---
install/ui/less/forms-override.less | 40 +
install/ui/src/freeipa/widget.js| 19 +-
2 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/install/ui/less/forms-override.less b/install/ui/less/forms-override.less
index ac442bb0b60a8cbcbedbdd9fc43ae5193c4256c2..b8c2e5d3542a2599cc246ae25e1e7e080fa2eebd 100644
--- a/install/ui/less/forms-override.less
+++ b/install/ui/less/forms-override.less
@@ -30,9 +30,27 @@
@checkbox-selected-color: darken(@checkbox-hover-color, 20%);
/* Checkboxes and Radios */
+
+.radio, .checkbox {
+position: relative;
+padding: 0;
+}
+
input[type="checkbox"],
input[type="radio"] {
-display: none;
+display: inline;
+position: absolute;
+overflow: hidden;
+margin:0;
+padding:0;
+border:0;
+outline:0;
+opacity:0;
+}
+
+input[type="checkbox"]:focus + label:before,
+input[type="radio"]:focus + label:before {
+outline: thin dotted @checkbox-selected-color;
}
input[type="checkbox"] + label,
@@ -45,7 +63,7 @@ input[type="radio"] + label {
.fa;
font-size: 125%;
-vertical-align: -11%;
+vertical-align: -7%;
margin-right: 5px;
}
}
@@ -81,12 +99,22 @@ input[type="checkbox"]:disabled + label {
}
}
+input[type="radio"]:disabled:checked + label,
+input[type="checkbox"]:disabled:checked + label {
+color: @checkbox-color;
+
+&:before,
+&:hover:before {
+color: @checkbox-color;
+}
+}
+
input[type="checkbox"] + label:before {
-content: "@{fa-var-square-o} ";
+content: @fa-var-square-o;
}
input[type="checkbox"]:checked + label:before {
-content: "@{fa-var-check-square-o} ";
+content: @fa-var-check-square-o;
color: @checkbox-selected-color;
}
@@ -99,10 +127,6 @@ input[type="radio"]:checked + label:before {
color: @checkbox-selected-color;
}
-input[type="radio"]:disabled + label {
-color: @checkbox-disabled-color;
-}
-
.form-horizontal {
.controls {
diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js
index bb65b94c903449b5b1fb240470d860c9419a18be..cc2438c8dff1ace98ff714622a923b31fe7b5b54 100644
--- a/install/ui/src/freeipa/widget.js
+++ b/install/ui/src/freeipa/widget.js
@@ -1170,6 +1170,10 @@ IPA.option_widget_base = function(spec, that) {
var id = that._option_next_id + input_name;
var enabled = that.enabled && option.enabled;
+var opt_cont = $('', {
+"class": that.intput_type
+}).appendTo(container);
+
option.input_node = $('', {
id: id,
type: that.input_type,
@@ -1178,13 +1182,13 @@ IPA.option_widget_base = function(spec, that) {
value: option.value,
title: option.tooltip || that.tooltip,
change: that.on_input_change
-}).appendTo(container);
+}).appendTo(opt_cont);
option.label_node = $('', {
html: option.label || '',
title: option.tooltip || that.tooltip,
'for': id
-}).appendTo(container);
+}).appendTo(opt_cont);
that.new_option_id();
};
@@ -1561,6 +1565,10 @@ IPA.standalone_option = function(spec, container, label) {
spec.type = spec.type || 'checkbox';
+var opt_cont = $('', {
+'class': spec.type
+});
+
var input = $('', spec);
if (!label) {
@@ -1575,11 +1583,12 @@ IPA.standalone_option = function(spec, container, label) {
});
if (container) {
-input.appendTo(container);
-label_el.appendTo(container);
+input.appendTo(opt_cont);
+label_el.appendTo(opt_cont);
+opt_cont.appendTo(container);
}
-return [input, label_el];
+return [input, label_el, opt_cont];
};
/**
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 6.3.2014 16:56, Jakub Hrozek wrote: On Wed, Mar 05, 2014 at 05:56:25PM +0100, Jan Cholasta wrote: On 5.3.2014 16:02, Petr Spacek wrote: a) Do not invent any new schema for certificates and public keys. A set of "PKCS-providers" in SSSD will aggregate the data from various sources and transform them to appropriate format. A heavy machinery in SSSD will convert existing data in IPA LDAP tree to PKCS#11 objects presented over PKCS#11 interface. Petr requested a diagram for this scenario; see attachment. Awesome, this is helpful for someone like me who hasn't been following the whole thread on freeipa-devel into the detail. Given that you plan on implementing an AD provider as well, I guess it would make sense to also implement (but maybe not expose unless there is a common schema) a purre LDAP provider that both IPA and AD would share? I did not include pure LDAP only because that would make the diagram too big ;-) Are you going to turn this e-mail into a design page and file SSSD tickets? Who's going to own the feature in SSSD, you, Petr or both? Me, I guess, at least the generic bits and the part related to certificates. I will create a design page. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1
On 03/05/2014 01:48 PM, Petr Viktorin wrote: > On 03/03/2014 04:10 PM, Petr Viktorin wrote: >> On 02/28/2014 02:47 PM, Petr Viktorin wrote: >>> On 02/28/2014 02:12 PM, Martin Kosek wrote: On 02/26/2014 10:44 AM, Petr Viktorin wrote: > Hello, > Here are a few fixes/improvements, and the first part of a managed > permission > updater. > > The patches should go in this order but don't need to be ACKed/pushed > all at once. > > > Design: > http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater > > > > Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 > > > This part is a "preview" of sorts, to get the basic mechanism and the > metadata > format reviewed before I add all of the default read permissions. > It implements the first section of "Default Permission Updater" in > the design; > "Replacing legacy default permissions" and "Removing the global > anonymous read > ACI" is left for later. > Metadata is added for the netgroup plugin* for starters > [...] > 1) 476: Typo in test name: +desc='Search fo rnonexisting permission with ":" in the name', >>> >>> Will fix. > > Fixed > 2) 477: do we want to log anything when permission is up to date? +try: +ldap.update_entry(entry) +except errors.EmptyModlist: +return >>> >>> I don't think that's needed, after all that's the expected behavior in >>> all but the first upgrade. >>> But I'll be happy to add it if you think it would be better. > > I've added a DEBUG message here. > > [...] 4) I have been quite resilient to the prefixes for the permissions, but it seems it is the easier possible approach to fix conflicts with user permissions without having to check that later for every upgrade or doing more complex stuff like multiple RDNs or different container for system and user permissions. I am now just thinking about the prefixing. Now you use this name: ipa:Read Netgroups Would it be "nicer" to use: IPA:Read Netgroups or IPA: Read Netgroups or even [IPA] Read Netgroups ? :-) >>> >>> Bikeshedding time! >>> Everyone on the list, please chime in! >> >> Bikeshedding results from today's meeting: >> >> "ipa: " pviktori++ >> "System: " mkosek++ simo+ ab++ >> "Builtin: " simo++ pvo+ >> "Default: " >> >> The winner is "System: ", so I'll go and change to that. > > Done. Thanks. The patch set looks good now, I just see that the update process may not be optimal After I run the upgrade second time, it still tries to update the ACI even though there was no change done to the permission object and should thus raise errors.EmptyModlist and skip the ACI update: 2014-03-07T09:44:34Z INFO Updating managed permissions for netgroup 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read Netgroups 2014-03-07T09:44:34Z DEBUG Updating ACI for managed permission: System: Read Netgroups 2014-03-07T09:44:34Z DEBUG Removing ACI u'(targetattr = "cn || description || hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:System: Read Netgroups";allow (read,compare,search) userdn = "ldap:///all";;)' from cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com 2014-03-07T09:44:34Z DEBUG Adding ACI u'(targetattr = "cn || description || hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:System: Read Netgroups";allow (read,compare,search) userdn = "ldap:///all";;)' to cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com 2014-03-07T09:44:34Z INFO No changes to ACI 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read Netgroup Membership Any idea what could cause this? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 459 Avoid passing non-terminated string to is_master_host
On Fri, 07 Mar 2014, Martin Kosek wrote:
When string is not terminated, queries with corrupted base may be sent
to LDAP:
... cn=ipa1.example.com,cn=masters...
https://fedorahosted.org/freeipa/ticket/4214
--
Martin Kosek
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
From 74bb082c7c286e9911f1a376ed9ce25845857672 Mon Sep 17 00:00:00 2001
From: Martin Kosek
Date: Fri, 7 Mar 2014 10:06:52 +0100
Subject: [PATCH] Avoid passing non-terminated string to is_master_host
When string is not terminated, queries with corrupted base may be sent
to LDAP:
... cn=ipa1.example.com,cn=masters...
https://fedorahosted.org/freeipa/ticket/4214
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index
9137cd5ad1e6166fd5d6e765fab2c8178ca0587c..c1b018cc80402c2c3488487aee1d9709b902c5b4
100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -488,13 +488,14 @@ static krb5_error_code ipadb_fill_info3(struct
ipadb_context *ipactx,
}
data = krb5_princ_component(ipactx->context, princ, 1);
-strres = malloc(data->length);
+strres = malloc(data->length+1);
if (strres == NULL) {
krb5_free_principal(ipactx->kcontext, princ);
return ENOENT;
}
memcpy(strres, data->data, data->length);
+strres[data->length] = '\0';
krb5_free_principal(ipactx->kcontext, princ);
/* Only add PAC to TGT to services on IPA masters to allow querying
Obvious ACK.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 459 Avoid passing non-terminated string to is_master_host
When string is not terminated, queries with corrupted base may be sent
to LDAP:
... cn=ipa1.example.com,cn=masters...
https://fedorahosted.org/freeipa/ticket/4214
--
Martin Kosek
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
From 74bb082c7c286e9911f1a376ed9ce25845857672 Mon Sep 17 00:00:00 2001
From: Martin Kosek
Date: Fri, 7 Mar 2014 10:06:52 +0100
Subject: [PATCH] Avoid passing non-terminated string to is_master_host
When string is not terminated, queries with corrupted base may be sent
to LDAP:
... cn=ipa1.example.com,cn=masters...
https://fedorahosted.org/freeipa/ticket/4214
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 9137cd5ad1e6166fd5d6e765fab2c8178ca0587c..c1b018cc80402c2c3488487aee1d9709b902c5b4 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -488,13 +488,14 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx,
}
data = krb5_princ_component(ipactx->context, princ, 1);
-strres = malloc(data->length);
+strres = malloc(data->length+1);
if (strres == NULL) {
krb5_free_principal(ipactx->kcontext, princ);
return ENOENT;
}
memcpy(strres, data->data, data->length);
+strres[data->length] = '\0';
krb5_free_principal(ipactx->kcontext, princ);
/* Only add PAC to TGT to services on IPA masters to allow querying
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
