Re: [Freeipa-devel] [PATCH 0131-0132] Add missing attributes to named.conf
On 10/03/2014 12:45 PM, Martin Basti wrote: Hello! Patch 131: https://fedorahosted.org/freeipa/ticket/3801#comment:31 Patch 132: I modified named.conf in 131, so I change the rest of paths to be ipaplatform specified. Patches attached ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hi! The upgrade processes looks fine to me. And I didn't find any surprise in the code. So it's A and C/2 from me. For the rest go to Petr^2. -- David Kupka ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code
On 10/09/2014 03:56 PM, David Kupka wrote: On 10/08/2014 01:23 PM, Jan Cholasta wrote: Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a): Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4619. Honza Forgot to delete a line in dogtaginstance.py (thanks to David for noticing). Updated patch attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Works for me, ACK. Thanks, pushed to master. Just to double check - no parts of the fixes should be applied to 4.1 or 4.0 branches, is that correct? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code
On 10/10/2014 08:50 AM, Martin Kosek wrote: On 10/09/2014 03:56 PM, David Kupka wrote: On 10/08/2014 01:23 PM, Jan Cholasta wrote: Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a): Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4619. Honza Forgot to delete a line in dogtaginstance.py (thanks to David for noticing). Updated patch attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Works for me, ACK. Thanks, pushed to master. Just to double check - no parts of the fixes should be applied to 4.1 or 4.0 branches, is that correct? Martin I've never seen or been able to reproduce this bug other than on master branch. AFAIK, the issue was caused by KRA patches that are only in master. -- David Kupka ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview
On 10/09/2014 03:57 PM, Petr Spacek wrote: Hello, it would be great if people could look at current state of DNSSEC patches for FreeIPA. It consist of several relatively independent parts: - python-pkcs#11 interface written by Martin Basti: https://github.com/spacekpe/freeipa-pkcs11 - DNSSEC daemons written by me: https://github.com/spacekpe/ipadnssecd - FreeIPA integration written by Martin Basti: https://github.com/bastiak/freeipa/tree/dnssec For now brief visual inspection is good enough :-) Current state = - It works only on single DNSSEC master server because we still do not have the key wrapping machinery. - The master server has to be configured manually using ipa-dnssec-setmaster utility. - DNSSEC keys are generated on the fly when DNSSEC is enabled for particular zone. - Metadata for BIND are generated on the fly. - BIND automatically signs the zone. It depends on latest softhsm, opendnssec and bind-pkcs11-util bind-pkcs11 packages which are not in Fedora 21 yet. Thank you for your time! Good! I am glad to see a progress. I am also CCing Simo and Rob to be in the loop. It would be especially useful if you also show Simo your special file permissions (setfacl) and sharing config files between daemons. I rather nervous about this part. To comment on FreeIPA integration - I saw you are adding a new config file: - install/tools/ipa-dnssec-setmaster I wonder how consistent and future proof that is. Setting master is currently being done in ipa-*replica-manage, check for example ipa-csreplica-manage. We want to have these operations on a sensible place as we will be refactoring them in 4.2. As for the service installation code itself, I would rather see it in # ipa-dns-install which could have new --dnssec-master and --no-dnssec flag. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin
On 10/09/2014 06:48 PM, thierry bordaz wrote: On 10/09/2014 05:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote: On 10/09/2014 12:15 AM, Nathaniel McCallum wrote: On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote: On Wed, 08 Oct 2014 15:53:39 -0400 Nathaniel McCallumnpmccal...@redhat.com wrote: As I understand my code, all servers will have csnD. Some servers will have valueB and others will have valueD, but valueB == valueD. We *never* discard a CSN. We only discard the counter/watermark mods in the replication operation. What Thierry is saying is that the individual attributes in the entry have associate the last CSN that modified them. Because you remove the mods when ValueD == ValueB the counter attribute will not have the associated CSN changed. But it doesn't really matter because the plugin will always keep things consistent. Attached is a new version. It removes this optimization. If server X has valueB/csnB and receives valueD/csnD and valueB == valueD, the replication will be applied without any modification. However, if valueB valueD and csnD csnB, the counter mods will still be stripped. It also collapses the error check from betxnpre to bepre now that we have a fix forhttps://fedorahosted.org/389/ticket/47919 committed. The betxnpre functions are completely removed. Also, a dependency on 389 1.3.3.4 (not yet released) is added. Nathaniel Hello Nathaniel, For me the code is fine. Ack. New attached patch. I have two minor comments: * in preop_mod, when a direct update moves the counter backward you send UNWILLING to perform with a message. The message is allocated with slapi_ch_smprintf, you may free it with slapi_ch_free_string (rather than 'free'). Fixed. * About this message, for example when you have these MODS (I admit they make no sens): changetype: modify ipatokenHOTPcounter: MOD_DELETE - ipatokenHOTPcounter: MOD_INCREMENT The returned message will be Will not decrement ipatokenHOTPcounter, because 'simulate' will return 'COUNTER_UNSET+1'. Is it the message you expected ? I changed the logic in simulate(). Please review it. Nathaniel Hello Nathaniel, The patch is ok for me. Ack. Thank you thierry Great! Thanks for tough review. However, we will still need to wait for 389 to release so that we can add the new required DS version at least to FreeIPA Copr. Otherwise all development/CI would break. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview
On 10/10/14 09:17, Martin Kosek wrote: On 10/09/2014 03:57 PM, Petr Spacek wrote: Hello, it would be great if people could look at current state of DNSSEC patches for FreeIPA. It consist of several relatively independent parts: - python-pkcs#11 interface written by Martin Basti: https://github.com/spacekpe/freeipa-pkcs11 - DNSSEC daemons written by me: https://github.com/spacekpe/ipadnssecd - FreeIPA integration written by Martin Basti: https://github.com/bastiak/freeipa/tree/dnssec For now brief visual inspection is good enough :-) Current state = - It works only on single DNSSEC master server because we still do not have the key wrapping machinery. - The master server has to be configured manually using ipa-dnssec-setmaster utility. - DNSSEC keys are generated on the fly when DNSSEC is enabled for particular zone. - Metadata for BIND are generated on the fly. - BIND automatically signs the zone. It depends on latest softhsm, opendnssec and bind-pkcs11-util bind-pkcs11 packages which are not in Fedora 21 yet. Thank you for your time! Good! I am glad to see a progress. I am also CCing Simo and Rob to be in the loop. It would be especially useful if you also show Simo your special file permissions (setfacl) and sharing config files between daemons. I rather nervous about this part. We will *not* use setfacl, there were some issues with softhsm, which Petr^2 found yesterday. To comment on FreeIPA integration - I saw you are adding a new config file: - install/tools/ipa-dnssec-setmaster I wonder how consistent and future proof that is. Setting master is currently being done in ipa-*replica-manage, check for example ipa-csreplica-manage. We want to have these operations on a sensible place as we will be refactoring them in 4.2. As for the service installation code itself, I would rather see it in # ipa-dns-install which could have new --dnssec-master and --no-dnssec flag. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
Hi! I'm resending patches 0159 and 0160, and adding two more: 0161 -- support user SSH public keys in ID view user overrides 0162 -- support gidNumber in ID view user override SSH public keys to work require support from SSSD and that one is currently missing. At least, one add/remove the keys to/from the override objects. Compat tree does not support exporting SSH keys. When accessing the tree anonymously, the entry will be filtered out by ACIs but for authenticated users we need to explicitly ignore ipaSshPubKey attribute in the override, so I'm resending updated slapi-nis patch that only adds one more attribute to filter out. -- / Alexander Bokovoy From f28587d5c736600682f4b7dcf3e1158940fd5797 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Tue, 30 Sep 2014 14:54:50 +0300 Subject: [PATCH 2/6] Support idviews in compat tree --- ACI.txt | 6 ++ install/share/71idviews.ldif| 1 + install/share/schema_compat.uldif | 8 install/updates/10-schema_compat.update | 12 ipalib/plugins/group.py | 10 ++ ipalib/plugins/user.py | 11 +++ ipaserver/install/plugins/update_managed_permissions.py | 11 +++ 7 files changed, 59 insertions(+) diff --git a/ACI.txt b/ACI.txt index cebdc2c..87c057e 100644 --- a/ACI.txt +++ b/ACI.txt @@ -54,6 +54,8 @@ dn: dc=ipa,dc=example aci: (targetattr = cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass)(target = ldap:///cn=groups,cn=compat,dc=ipa,dc=example;)(version 3.0;acl permission:System: Read Group Compat Tree;allow (compare,read,search) userdn = ldap:///anyone;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = member || memberhost || memberof || memberuid || memberuser)(targetfilter = (|(objectclass=ipausergroup)(objectclass=posixgroup)))(version 3.0;acl permission:System: Read Group Membership;allow (compare,read,search) userdn = ldap:///all;;) +dn: dc=ipa,dc=example +aci: (targetattr = cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass)(target = ldap:///cn=groups,cn=*,cn=views,cn=compat,dc=ipa,dc=example;)(version 3.0;acl permission:System: Read Group Views Compat Tree;allow (compare,read,search) userdn = ldap:///anyone;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = businesscategory || cn || createtimestamp || description || entryusn || gidnumber || ipaexternalmember || ipantsecurityidentifier || ipauniqueid || mepmanagedby || modifytimestamp || o || objectclass || ou || owner || seealso)(targetfilter = (|(objectclass=ipausergroup)(objectclass=posixgroup)))(version 3.0;acl permission:System: Read Groups;allow (compare,read,search) userdn = ldap:///anyone;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example @@ -256,6 +258,8 @@ dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = memberof)(targetfilter = (objectclass=posixaccount))(version 3.0;acl permission:System: Read User Membership;allow (compare,read,search) userdn = ldap:///all;;) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = cn || createtimestamp || description || displayname || entryusn || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || modifytimestamp || objectclass || sn || title || uid || uidnumber)(targetfilter = (objectclass=posixaccount))(version 3.0;acl permission:System: Read User Standard Attributes;allow (compare,read,search) userdn = ldap:///anyone;;) +dn: dc=ipa,dc=example +aci: (targetattr = cn || createtimestamp || entryusn || gecos || gidnumber || homedirectory || loginshell || modifytimestamp || objectclass || uid || uidnumber)(target = ldap:///cn=users,cn=*,cn=views,cn=compat,dc=ipa,dc=example;)(version 3.0;acl permission:System: Read User Views Compat Tree;allow (compare,read,search) userdn = ldap:///anyone;;) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetfilter = (objectclass=posixaccount))(version 3.0;acl permission:System: Remove Users;allow (delete) groupdn = ldap:///cn=System: Remove Users,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=users,cn=accounts,dc=ipa,dc=example @@ -264,6 +268,8 @@ dn: cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example aci: (target = ldap:///cn=caSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example)(targetfilter = (objectclass=pkiuser))(version 3.0;acl permission:System: Add CA Certificate For Renewal;allow (add) groupdn = ldap:///cn=System: Add CA Certificate For Renewal,cn=permissions,cn=pbac,dc=ipa,dc=example;) dn: cn=certificates,cn=ipa,cn=etc,dc=ipa,dc=example aci: (targetfilter = (objectclass=ipacertificate))(version 3.0;acl permission:System: Add Certificate Store Entry;allow (add) groupdn = ldap:///cn=System: Add
Re: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code
Dne 10.10.2014 v 08:55 David Kupka napsal(a): On 10/10/2014 08:50 AM, Martin Kosek wrote: On 10/09/2014 03:56 PM, David Kupka wrote: On 10/08/2014 01:23 PM, Jan Cholasta wrote: Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a): Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4619. Honza Forgot to delete a line in dogtaginstance.py (thanks to David for noticing). Updated patch attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Works for me, ACK. Thanks, pushed to master. Just to double check - no parts of the fixes should be applied to 4.1 or 4.0 branches, is that correct? Martin I've never seen or been able to reproduce this bug other than on master branch. AFAIK, the issue was caused by KRA patches that are only in master. The patch is master only and applies on top of the KRA changes. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0018 Check that port 8443 is available when installing PKI.
On 10/03/2014 12:18 PM, David Kupka wrote: On 10/02/2014 12:42 PM, Martin Kosek wrote: On 09/29/2014 04:48 PM, David Kupka wrote: https://fedorahosted.org/freeipa/ticket/4564 Looks and works OK. The port checking should be ideally refactored in 4.2 and *instance.py should use some common hooks to define which ports should be checked, but your way be enough for now. What about ipa-replica-install? It could be also run with --setup-ca option. I missed that one. git grep I used did not return it. Thanks. Ok, ACK. Pushed to master, ipa-4-1, ipa-4-0 (with little merge). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 766 idviews: error out if appling Default Trust View on hosts
CLI part of:
https://fedorahosted.org/freeipa/ticket/4615
--
Petr Vobornik
From 72f62454f8e02c5becec31675f018ec23b763e47 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 10 Oct 2014 10:35:30 +0200
Subject: [PATCH] idviews: error out if appling Default Trust View on hosts
https://fedorahosted.org/freeipa/ticket/4615
---
ipalib/plugins/idviews.py | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index 3b0df022389fdaad02c54e7cb8bd6a52bc75d7e0..758d19889db3a43804f94225c2e0ab16d104d6ab 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -238,6 +238,12 @@ class baseidview_apply(LDAPQuery):
# the ipaAssignedIDView to None
view_dn = None
+if view == 'Default Trust View':
+raise errors.ValidationError(
+name=_('ID View'),
+error=_('Default Trust View cannot be applied on hosts')
+)
+
completed = 0
succeeded = {'host': []}
failed = {
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 771 webui: do not offer ipa users to Default Trust View
https://fedorahosted.org/freeipa/ticket/4616
--
Petr Vobornik
From 2370973e869c154b92557a767e6e4f340fc6a283 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 10 Oct 2014 10:50:56 +0200
Subject: [PATCH] webui: do not offer ipa users to Default Trust View
https://fedorahosted.org/freeipa/ticket/4616
---
install/ui/doc/categories.json | 6 +
install/ui/src/freeipa/add.js | 2 +-
install/ui/src/freeipa/idviews.js | 51 +-
install/ui/test/data/ipa_init.json | 6 +++--
ipalib/plugins/internal.py | 2 ++
5 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/install/ui/doc/categories.json b/install/ui/doc/categories.json
index e9507795b9557880cfb4ce34c0808b6bd2d2ab2c..c84077682eafa42981e8a1c1a2f93c712e6421fd 100644
--- a/install/ui/doc/categories.json
+++ b/install/ui/doc/categories.json
@@ -149,6 +149,12 @@
]
},
{
+name: Dialog policies,
+classes: [
+idviews.idoverride_adder_policy
+]
+},
+{
name: Evaluators Summaries,
classes: [
*_evaluator,
diff --git a/install/ui/src/freeipa/add.js b/install/ui/src/freeipa/add.js
index 7f5c29807bae8cc9db00e4e826a68facd1e5758a..8f24c7733d1614aaf05b544ecfb641ff57f292f2 100644
--- a/install/ui/src/freeipa/add.js
+++ b/install/ui/src/freeipa/add.js
@@ -198,7 +198,7 @@ IPA.entity_adder_dialog = function(spec) {
var field = fields[j];
var values = record[field.param];
-if (!values || values.length === 0) continue;
+if (!values || values.length === 0 || !field.enabled) continue;
if (field.flags.indexOf('no_command') -1) continue;
if (field.param === pkey_name) {
diff --git a/install/ui/src/freeipa/idviews.js b/install/ui/src/freeipa/idviews.js
index ee522467501986116c759ef7150db294b9e34157..57fcc490a4579227d14b790548f786ec769b5379 100644
--- a/install/ui/src/freeipa/idviews.js
+++ b/install/ui/src/freeipa/idviews.js
@@ -20,6 +20,7 @@
*/
define([
+'dojo/on',
'./ipa',
'./jquery',
'./menu',
@@ -31,7 +32,7 @@ define([
'./facet',
'./search',
'./entity'],
-function(IPA, $, menu, phases, reg, rpc, text, mod_details, mod_facet) {
+function(on, IPA, $, menu, phases, reg, rpc, text, mod_details, mod_facet) {
/**
* ID Views module
* @class
@@ -260,6 +261,9 @@ return {
],
adder_dialog: {
+policies: [
+{ $factory: idviews.idoverride_adder_policy }
+],
fields: [
{
$type: 'entity_select',
@@ -270,6 +274,14 @@ return {
editable: true,
tooltip: '@i18n:objects.idoverrideuser.anchor_tooltip'
},
+{
+label: '@i18n:objects.idoverrideuser.anchor_label',
+name: 'ipaanchoruuid_default',
+param: 'ipaanchoruuid',
+tooltip: '@i18n:objects.idoverrideuser.anchor_tooltip_ad',
+visible: false,
+enabled: false
+},
'uid',
'uidnumber',
'homedirectory',
@@ -330,6 +342,9 @@ return {
],
adder_dialog: {
+policies: [
+{ $factory: idviews.idoverride_adder_policy }
+],
fields: [
{
$type: 'entity_select',
@@ -340,6 +355,14 @@ return {
editable: true,
tooltip: '@i18n:objects.idoverridegroup.anchor_tooltip'
},
+{
+label: '@i18n:objects.idoverridegroup.anchor_label',
+name: 'ipaanchoruuid_default',
+param: 'ipaanchoruuid',
+tooltip: '@i18n:objects.idoverridegroup.anchor_tooltip_ad',
+visible: false,
+enabled: false
+},
'cn',
'gidnumber',
{
@@ -395,6 +418,32 @@ idviews.idview_facet_header = function(spec) {
};
/**
+ * Switches between combobox and textbox for ipaanchoruuid, depending on if
+ * current view is Default Trust View
+ * @class idviews.idoverride_adder_policy
+ * @extends IPA.facet_policy
+ */
+idviews.idoverride_adder_policy = function (spec) {
+var that = IPA.facet_policy(spec);
+that.init = function() {
+on(that.container, 'open', that.on_open);
+};
+
+that.on_open = function() {
+var d = that.container; // dialog
+var default_view = d.pkey_prefix.slice(-1)[0] === idviews.DEFAULT_TRUST_VIEW;
+var f1 = d.fields.get_field('ipaanchoruuid');
+var f2 = d.fields.get_field('ipaanchoruuid_default');
+f1.set_enabled(!default_view);
+f1.widget.set_visible(!default_view);
+f2.set_enabled(default_view);
+
[Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View
Web UI part of:
https://fedorahosted.org/freeipa/ticket/4615
Patch 767 is a little refactoring needed for $pre_op(as plain object)
work as intended even with instantiated objects + fixes a bug where
Evented objects were not considered a framework object.
Patch 768 switches tabs so we can hide it later
Patch 769 hides the tab
PAtch 770 is not really needed(would like to hear options whether to
include it). It's in effect only if user somehow manages to open
'Applies to hosts' facet for 'Default trust view'. Maybe redirection
would be better - if we need to act.
--
Petr Vobornik
From 1f70f5ebaed8ce52617341a7c8e826923b09030a Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 10 Oct 2014 10:50:35 +0200
Subject: [PATCH] webui: hide (un)apply buttons for Default Trust View
---
install/ui/src/freeipa/idviews.js | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/install/ui/src/freeipa/idviews.js b/install/ui/src/freeipa/idviews.js
index 39424ef3e1e716a1e902a2580fa5fd57b0426371..ee522467501986116c759ef7150db294b9e34157 100644
--- a/install/ui/src/freeipa/idviews.js
+++ b/install/ui/src/freeipa/idviews.js
@@ -185,7 +185,17 @@ return {
target_entity: 'host',
target_facet: 'details'
}
-]
+],
+state: {
+evaluators: [
+{
+$factory: mod_details.value_state_evaluator,
+attribute: 'cn',
+value: idviews.DEFAULT_TRUST_VIEW,
+representation: 'cn_default_trust_view'
+}
+]
+}
}
],
@@ -395,6 +405,7 @@ idviews.apply_action = function(spec) {
spec = spec || {};
spec.name = spec.name || 'idview_apply';
spec.label = spec.label || '@i18n:objects.idview.apply_hosts';
+spec.hide_cond = spec.hide_cond || ['cn_default_trust_view'];
var that = IPA.action(spec);
--
1.9.3
From 10fe2a4e62c4b2423b580d559260da57ca8c9870 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 10 Oct 2014 10:49:43 +0200
Subject: [PATCH] webui: hide applied to hosts tab for Default Trust View
because applying Default Trust view on hosts is not allowed
https://fedorahosted.org/freeipa/ticket/4615
---
install/ui/src/freeipa/facet.js | 5 -
install/ui/src/freeipa/idviews.js | 26 +-
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/install/ui/src/freeipa/facet.js b/install/ui/src/freeipa/facet.js
index 556b17fe71f6a1eb460d40ce76746f868d0791ae..43627d9d531ed700ff780a0773451eaf17b1cbdd 100644
--- a/install/ui/src/freeipa/facet.js
+++ b/install/ui/src/freeipa/facet.js
@@ -211,7 +211,8 @@ exp.facet = IPA.facet = function(spec, no_init) {
* Facet header
* @property {facet.facet_header}
*/
-that.header = spec.header || IPA.facet_header({ facet: that });
+that.header = builder.build('', spec.header || {}, {},
+{ $pre_ops: [{ facet: that }], $factory: IPA.facet_header });
/**
* Hard override for `needs_update()` logic. When set, `needs_update`
@@ -1400,6 +1401,8 @@ exp.facet_header = IPA.facet_header = function(spec) {
that.load();
};
+that.facet_header_set_pkey = that.set_pkey;
+
return that;
};
diff --git a/install/ui/src/freeipa/idviews.js b/install/ui/src/freeipa/idviews.js
index a95806283225c0ab6d064b182df285e755637d04..39424ef3e1e716a1e902a2580fa5fd57b0426371 100644
--- a/install/ui/src/freeipa/idviews.js
+++ b/install/ui/src/freeipa/idviews.js
@@ -37,7 +37,9 @@ define([
* @class
* @singleton
*/
-var idviews = IPA.idviews = {};
+var idviews = IPA.idviews = {
+DEFAULT_TRUST_VIEW: 'Default Trust View'
+};
var make_spec = function() {
return {
@@ -82,6 +84,7 @@ return {
},
{
$type: 'details',
+header: idviews.idview_facet_header,
actions: [
'delete'
],
@@ -104,6 +107,7 @@ return {
{
$type: 'nested_search',
facet_group: 'overrides',
+header: idviews.idview_facet_header,
nested_entity: 'idoverrideuser',
search_all_entries: true,
label: '@mo:idoverrideuser.label',
@@ -123,6 +127,7 @@ return {
{
$type: 'nested_search',
facet_group: 'overrides',
+header: idviews.idview_facet_header,
nested_entity: 'idoverridegroup',
search_all_entries: true,
label: '@mo:idoverridegroup.label',
@@ -360,6 +365,25 @@ idviews.appliedtohosts_facet = function(spec, no_init) {
return that;
};
+idviews.idview_facet_header = function(spec) {
+
+var that = mod_facet.facet_header(spec);
+
+/**
+ * Set pkeys and hides 'appliedtohosts' facet for 'Default Trust View'
+ * @param {string}
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On Fri, 10 Oct 2014, Alexander Bokovoy wrote: Hi! I'm resending patches 0159 and 0160, and adding two more: 0161 -- support user SSH public keys in ID view user overrides 0162 -- support gidNumber in ID view user override SSH public keys to work require support from SSSD and that one is currently missing. At least, one add/remove the keys to/from the override objects. Compat tree does not support exporting SSH keys. When accessing the tree anonymously, the entry will be filtered out by ACIs but for authenticated users we need to explicitly ignore ipaSshPubKey attribute in the override, so I'm resending updated slapi-nis patch that only adds one more attribute to filter out. slapi-nis patches now committed to slapi-nis git repository, version 0.54 is released. Packages for rawhide are built. Fedora 21 update is https://admin.fedoraproject.org/updates/slapi-nis-0.54-1.fc21 -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview
On Fri, 10 Oct 2014 09:17:34 +0200 Martin Kosek mko...@redhat.com wrote: On 10/09/2014 03:57 PM, Petr Spacek wrote: Hello, it would be great if people could look at current state of DNSSEC patches for FreeIPA. It consist of several relatively independent parts: - python-pkcs#11 interface written by Martin Basti: https://github.com/spacekpe/freeipa-pkcs11 - DNSSEC daemons written by me: https://github.com/spacekpe/ipadnssecd Well I have to be honest, it would be easier if commit messages were in English :-) Simo. - FreeIPA integration written by Martin Basti: https://github.com/bastiak/freeipa/tree/dnssec For now brief visual inspection is good enough :-) Current state = - It works only on single DNSSEC master server because we still do not have the key wrapping machinery. - The master server has to be configured manually using ipa-dnssec-setmaster utility. - DNSSEC keys are generated on the fly when DNSSEC is enabled for particular zone. - Metadata for BIND are generated on the fly. - BIND automatically signs the zone. It depends on latest softhsm, opendnssec and bind-pkcs11-util bind-pkcs11 packages which are not in Fedora 21 yet. Thank you for your time! Good! I am glad to see a progress. I am also CCing Simo and Rob to be in the loop. It would be especially useful if you also show Simo your special file permissions (setfacl) and sharing config files between daemons. I rather nervous about this part. To comment on FreeIPA integration - I saw you are adding a new config file: - install/tools/ipa-dnssec-setmaster I wonder how consistent and future proof that is. Setting master is currently being done in ipa-*replica-manage, check for example ipa-csreplica-manage. We want to have these operations on a sensible place as we will be refactoring them in 4.2. As for the service installation code itself, I would rather see it in # ipa-dns-install which could have new --dnssec-master and --no-dnssec flag. Martin -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview
On 10/10/14 14:51, Simo Sorce wrote: On Fri, 10 Oct 2014 09:17:34 +0200 Martin Kosek mko...@redhat.com wrote: On 10/09/2014 03:57 PM, Petr Spacek wrote: Hello, it would be great if people could look at current state of DNSSEC patches for FreeIPA. It consist of several relatively independent parts: - python-pkcs#11 interface written by Martin Basti: https://github.com/spacekpe/freeipa-pkcs11 - DNSSEC daemons written by me: https://github.com/spacekpe/ipadnssecd Well I have to be honest, it would be easier if commit messages were in English :-) Simo. Honestly, those commit messages are not helpful, we plan to merge it into one IPA commit, so we don't use nice commit messages. - FreeIPA integration written by Martin Basti: https://github.com/bastiak/freeipa/tree/dnssec For now brief visual inspection is good enough :-) Current state = - It works only on single DNSSEC master server because we still do not have the key wrapping machinery. - The master server has to be configured manually using ipa-dnssec-setmaster utility. - DNSSEC keys are generated on the fly when DNSSEC is enabled for particular zone. - Metadata for BIND are generated on the fly. - BIND automatically signs the zone. It depends on latest softhsm, opendnssec and bind-pkcs11-util bind-pkcs11 packages which are not in Fedora 21 yet. Thank you for your time! Good! I am glad to see a progress. I am also CCing Simo and Rob to be in the loop. It would be especially useful if you also show Simo your special file permissions (setfacl) and sharing config files between daemons. I rather nervous about this part. To comment on FreeIPA integration - I saw you are adding a new config file: - install/tools/ipa-dnssec-setmaster I wonder how consistent and future proof that is. Setting master is currently being done in ipa-*replica-manage, check for example ipa-csreplica-manage. We want to have these operations on a sensible place as we will be refactoring them in 4.2. As for the service installation code itself, I would rather see it in # ipa-dns-install which could have new --dnssec-master and --no-dnssec flag. Martin -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On 10.10.2014 10:39, Alexander Bokovoy wrote: Hi! I'm resending patches 0159 and 0160, and adding two more: 0161 -- support user SSH public keys in ID view user overrides 0162 -- support gidNumber in ID view user override SSH public keys to work require support from SSSD and that one is currently missing. At least, one add/remove the keys to/from the override objects. Compat tree does not support exporting SSH keys. When accessing the tree anonymously, the entry will be filtered out by ACIs but for authenticated users we need to explicitly ignore ipaSshPubKey attribute in the override, so I'm resending updated slapi-nis patch that only adds one more attribute to filter out. I'm going to prepare Web UI for, 160, 161, 162. Q: ipaUserOverride object class contains also 'gecos' attribute. Will it be handled be CLI and Web UI as well? Comments for these 3 patches: 1. VERSION was not bumped Patch 160: Apart form #1, is OK (not sure if #1 is needed for ACK) Patch 161: 2. idoverrideuser_show and _find should have post_callback with convert_sshpubkey_post as well - to be consistent. 3. Add blank line before new methods - both post_callbacks 4. I have created a helper method for adding object classes in patch 761 (currently on review) - add_missing_object_class. Would be nice fit, but also I don't want to block this patch with mine. Patch 162: Is it good to have different CLI option name in this and user plugin for the same attribute: --gid vs --gidnumber ? That said, it's sad that --gid was not used in user plugin since the beginning. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On 10/10/2014 03:12 PM, Petr Vobornik wrote: On 10.10.2014 10:39, Alexander Bokovoy wrote: Hi! I'm resending patches 0159 and 0160, and adding two more: 0161 -- support user SSH public keys in ID view user overrides 0162 -- support gidNumber in ID view user override SSH public keys to work require support from SSSD and that one is currently missing. At least, one add/remove the keys to/from the override objects. Compat tree does not support exporting SSH keys. When accessing the tree anonymously, the entry will be filtered out by ACIs but for authenticated users we need to explicitly ignore ipaSshPubKey attribute in the override, so I'm resending updated slapi-nis patch that only adds one more attribute to filter out. I'm going to prepare Web UI for, 160, 161, 162. Q: ipaUserOverride object class contains also 'gecos' attribute. Will it be handled be CLI and Web UI as well? Comments for these 3 patches: 1. VERSION was not bumped Patch 160: Apart form #1, is OK (not sure if #1 is needed for ACK) Patch 161: 2. idoverrideuser_show and _find should have post_callback with convert_sshpubkey_post as well - to be consistent. 3. Add blank line before new methods - both post_callbacks 4. I have created a helper method for adding object classes in patch 761 (currently on review) - add_missing_object_class. Would be nice fit, but also I don't want to block this patch with mine. Patch 162: Is it good to have different CLI option name in this and user plugin for the same attribute: --gid vs --gidnumber ? That said, it's sad that --gid was not used in user plugin since the beginning. Also, we will need to have slapi-nis version in the spec file bumped. I already fired a build of slapi-nis to FreeIPA Copr. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0019 Stop dogtag when updating its configuration in, ipa-upgradeconfig
Dne 8.10.2014 v 12:36 David Kupka napsal(a): On 10/08/2014 09:29 AM, Jan Cholasta wrote: Hi, Dne 8.10.2014 v 09:09 David Kupka napsal(a): https://fedorahosted.org/freeipa/ticket/4569 In renew_ca_cert and cainstance.py, dogtag should already be stopped in the places you modified, so why the change? I didn't noticed that it is already stopped, fixed. Also I don't think it's a good idea to backup CS.cfg when dogtag is still running (in cainstance.py). If the file is being modified by dogtag at the time it is backed up, the backup may be corrupted. Fixed, thanks. CAInstance.backup_config should be called only when Dogtag is stopped as well, you don't need to change it. Honza It would be better to stop and start dogtag only once in ipa-upgradeconfig, not every time there is a modification to CS.cfg. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On Fri, 10 Oct 2014, Petr Vobornik wrote: On 10.10.2014 10:39, Alexander Bokovoy wrote: Hi! I'm resending patches 0159 and 0160, and adding two more: 0161 -- support user SSH public keys in ID view user overrides 0162 -- support gidNumber in ID view user override SSH public keys to work require support from SSSD and that one is currently missing. At least, one add/remove the keys to/from the override objects. Compat tree does not support exporting SSH keys. When accessing the tree anonymously, the entry will be filtered out by ACIs but for authenticated users we need to explicitly ignore ipaSshPubKey attribute in the override, so I'm resending updated slapi-nis patch that only adds one more attribute to filter out. I'm going to prepare Web UI for, 160, 161, 162. Q: ipaUserOverride object class contains also 'gecos' attribute. Will it be handled be CLI and Web UI as well? I'll add another patch for that. Comments for these 3 patches: 1. VERSION was not bumped Patch 160: Apart form #1, is OK (not sure if #1 is needed for ACK) I wonder if I should bump it in a separate patch that would be the last one in the series, to avoid proliferation of API version numbers? :) Patch 161: 2. idoverrideuser_show and _find should have post_callback with convert_sshpubkey_post as well - to be consistent. 3. Add blank line before new methods - both post_callbacks 4. I have created a helper method for adding object classes in patch 761 (currently on review) - add_missing_object_class. Would be nice fit, but also I don't want to block this patch with mine. Patch 162: Is it good to have different CLI option name in this and user plugin for the same attribute: --gid vs --gidnumber ? That said, it's sad that --gid was not used in user plugin since the beginning. I'll fix these. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn = ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that you are testing, I will try on that branch That is not really the same test at all.
Re: [Freeipa-devel] [PATCH] 0020 Set IPA CA for freeipa certificates
Hi, Dne 7.10.2014 v 16:56 David Kupka napsal(a): https://fedorahosted.org/freeipa/ticket/4618 This works, but I would prefer if the code did not silently ignore when the CA is not found. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On Fri, 10 Oct 2014, Alexander Bokovoy wrote: On Fri, 10 Oct 2014, Petr Vobornik wrote: On 10.10.2014 10:39, Alexander Bokovoy wrote: Hi! I'm resending patches 0159 and 0160, and adding two more: 0161 -- support user SSH public keys in ID view user overrides 0162 -- support gidNumber in ID view user override SSH public keys to work require support from SSSD and that one is currently missing. At least, one add/remove the keys to/from the override objects. Compat tree does not support exporting SSH keys. When accessing the tree anonymously, the entry will be filtered out by ACIs but for authenticated users we need to explicitly ignore ipaSshPubKey attribute in the override, so I'm resending updated slapi-nis patch that only adds one more attribute to filter out. I'm going to prepare Web UI for, 160, 161, 162. Q: ipaUserOverride object class contains also 'gecos' attribute. Will it be handled be CLI and Web UI as well? I'll add another patch for that. Comments for these 3 patches: 1. VERSION was not bumped Patch 160: Apart form #1, is OK (not sure if #1 is needed for ACK) I wonder if I should bump it in a separate patch that would be the last one in the series, to avoid proliferation of API version numbers? :) Patch 161: 2. idoverrideuser_show and _find should have post_callback with convert_sshpubkey_post as well - to be consistent. 3. Add blank line before new methods - both post_callbacks 4. I have created a helper method for adding object classes in patch 761 (currently on review) - add_missing_object_class. Would be nice fit, but also I don't want to block this patch with mine. Patch 162: Is it good to have different CLI option name in this and user plugin for the same attribute: --gid vs --gidnumber ? That said, it's sad that --gid was not used in user plugin since the beginning. I'll fix these. Fixed patches attached, with three more: patch 0163 -- support GECOS patch 0164 -- increase API patch 0165 -- require slapi-nis 0.54 -- / Alexander Bokovoy From f28587d5c736600682f4b7dcf3e1158940fd5797 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Tue, 30 Sep 2014 14:54:50 +0300 Subject: [PATCH 2/6] Support idviews in compat tree --- ACI.txt | 6 ++ install/share/71idviews.ldif| 1 + install/share/schema_compat.uldif | 8 install/updates/10-schema_compat.update | 12 ipalib/plugins/group.py | 10 ++ ipalib/plugins/user.py | 11 +++ ipaserver/install/plugins/update_managed_permissions.py | 11 +++ 7 files changed, 59 insertions(+) diff --git a/ACI.txt b/ACI.txt index cebdc2c..87c057e 100644 --- a/ACI.txt +++ b/ACI.txt @@ -54,6 +54,8 @@ dn: dc=ipa,dc=example aci: (targetattr = cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass)(target = ldap:///cn=groups,cn=compat,dc=ipa,dc=example;)(version 3.0;acl permission:System: Read Group Compat Tree;allow (compare,read,search) userdn = ldap:///anyone;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = member || memberhost || memberof || memberuid || memberuser)(targetfilter = (|(objectclass=ipausergroup)(objectclass=posixgroup)))(version 3.0;acl permission:System: Read Group Membership;allow (compare,read,search) userdn = ldap:///all;;) +dn: dc=ipa,dc=example +aci: (targetattr = cn || createtimestamp || entryusn || gidnumber || memberuid || modifytimestamp || objectclass)(target = ldap:///cn=groups,cn=*,cn=views,cn=compat,dc=ipa,dc=example;)(version 3.0;acl permission:System: Read Group Views Compat Tree;allow (compare,read,search) userdn = ldap:///anyone;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example aci: (targetattr = businesscategory || cn || createtimestamp || description || entryusn || gidnumber || ipaexternalmember || ipantsecurityidentifier || ipauniqueid || mepmanagedby || modifytimestamp || o || objectclass || ou || owner || seealso)(targetfilter = (|(objectclass=ipausergroup)(objectclass=posixgroup)))(version 3.0;acl permission:System: Read Groups;allow (compare,read,search) userdn = ldap:///anyone;;) dn: cn=groups,cn=accounts,dc=ipa,dc=example @@ -256,6 +258,8 @@ dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = memberof)(targetfilter = (objectclass=posixaccount))(version 3.0;acl permission:System: Read User Membership;allow (compare,read,search) userdn = ldap:///all;;) dn: cn=users,cn=accounts,dc=ipa,dc=example aci: (targetattr = cn || createtimestamp || description || displayname || entryusn || gecos || gidnumber || givenname || homedirectory || initials || ipantsecurityidentifier || loginshell || manager || modifytimestamp || objectclass || sn || title || uid || uidnumber)(targetfilter = (objectclass=posixaccount))(version 3.0;acl permission:System: Read User
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On 10.10.2014 15:36, Alexander Bokovoy wrote: On Fri, 10 Oct 2014, Petr Vobornik wrote: On 10.10.2014 10:39, Alexander Bokovoy wrote: Hi! I'm resending patches 0159 and 0160, and adding two more: 0161 -- support user SSH public keys in ID view user overrides 0162 -- support gidNumber in ID view user override SSH public keys to work require support from SSSD and that one is currently missing. At least, one add/remove the keys to/from the override objects. Compat tree does not support exporting SSH keys. When accessing the tree anonymously, the entry will be filtered out by ACIs but for authenticated users we need to explicitly ignore ipaSshPubKey attribute in the override, so I'm resending updated slapi-nis patch that only adds one more attribute to filter out. I'm going to prepare Web UI for, 160, 161, 162. Q: ipaUserOverride object class contains also 'gecos' attribute. Will it be handled be CLI and Web UI as well? I'll add another patch for that. Comments for these 3 patches: 1. VERSION was not bumped Patch 160: Apart form #1, is OK (not sure if #1 is needed for ACK) I wonder if I should bump it in a separate patch that would be the last one in the series, to avoid proliferation of API version numbers? :) IMHO it should be sufficient. Same outcome as if the patches were squashed. Patch 161: 2. idoverrideuser_show and _find should have post_callback with convert_sshpubkey_post as well - to be consistent. 3. Add blank line before new methods - both post_callbacks 4. I have created a helper method for adding object classes in patch 761 (currently on review) - add_missing_object_class. Would be nice fit, but also I don't want to block this patch with mine. Patch 162: Is it good to have different CLI option name in this and user plugin for the same attribute: --gid vs --gidnumber ? That said, it's sad that --gid was not used in user plugin since the beginning. I'll fix these. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn =ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that you are testing, I will try on that
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On Fri, 10 Oct 2014, Petr Vobornik wrote:
On 10.10.2014 15:36, Alexander Bokovoy wrote:
On Fri, 10 Oct 2014, Petr Vobornik wrote:
On 10.10.2014 10:39, Alexander Bokovoy wrote:
Hi!
I'm resending patches 0159 and 0160, and adding two more:
0161 -- support user SSH public keys in ID view user overrides
0162 -- support gidNumber in ID view user override
SSH public keys to work require support from SSSD and that one is
currently missing. At least, one add/remove the keys to/from the
override objects.
Compat tree does not support exporting SSH keys. When accessing the tree
anonymously, the entry will be filtered out by ACIs but for
authenticated users we need to explicitly ignore ipaSshPubKey attribute
in the override, so I'm resending updated slapi-nis patch that only
adds one more attribute to filter out.
I'm going to prepare Web UI for, 160, 161, 162.
Q: ipaUserOverride object class contains also 'gecos' attribute. Will
it be handled be CLI and Web UI as well?
I'll add another patch for that.
Comments for these 3 patches:
1. VERSION was not bumped
Patch 160:
Apart form #1, is OK (not sure if #1 is needed for ACK)
I wonder if I should bump it in a separate patch that would be the last
one in the series, to avoid proliferation of API version numbers? :)
IMHO it should be sufficient. Same outcome as if the patches were squashed.
Yep.
One more update for patch 0161, Petr noticed we need to call super
post_callback() too.
--
/ Alexander Bokovoy
From bc7eb4c53424412b5488068b49a80f2922f078ab Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Fri, 10 Oct 2014 09:26:13 +0300
Subject: [PATCH 4/9] Allow user overrides to specify SSH public keys
Overrides for users can have SSH public keys. This, however, will not enable
SSH public keys from overrides to be actually used until SSSD gets fixed to
pull them in.
SSSD ticket for SSH public keys in overrides:
https://fedorahosted.org/sssd/ticket/2454
Resolves https://fedorahosted.org/freeipa/ticket/4509
---
API.txt | 6 --
ipalib/plugins/idviews.py | 43 +++
2 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/API.txt b/API.txt
index 41b852b..5316ac2 100644
--- a/API.txt
+++ b/API.txt
@@ -2104,7 +2104,7 @@ output: Entry('result', type 'dict', Gettext('A
dictionary representing an LDA
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
command: idoverrideuser_add
-args: 2,11,3
+args: 2,12,3
arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True,
query=True, required=True)
arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False,
primary_key=True, required=True)
option: Str('addattr*', cli_name='addattr', exclude='webui')
@@ -2112,6 +2112,7 @@ option: Flag('all', autofill=True, cli_name='all',
default=False, exclude='webui
option: Str('description', attribute=True, cli_name='desc', multivalue=False,
required=False)
option: Str('homedirectory', attribute=True, cli_name='homedir',
multivalue=False, required=False)
option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid',
multivalue=False, required=False)
+option: Str('ipasshpubkey', attribute=True, cli_name='sshpubkey', csv=True,
multivalue=True, required=False)
option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False,
required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False,
exclude='webui')
option: Str('setattr*', cli_name='setattr', exclude='webui')
@@ -2152,7 +2153,7 @@ output: ListOfEntries('result', (type 'list', type
'tuple'), Gettext('A list
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('truncated', type 'bool', None)
command: idoverrideuser_mod
-args: 2,14,3
+args: 2,15,3
arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True,
query=True, required=True)
arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False,
primary_key=True, query=True, required=True)
option: Str('addattr*', cli_name='addattr', exclude='webui')
@@ -2161,6 +2162,7 @@ option: Str('delattr*', cli_name='delattr',
exclude='webui')
option: Str('description', attribute=True, autofill=False, cli_name='desc',
multivalue=False, required=False)
option: Str('homedirectory', attribute=True, autofill=False,
cli_name='homedir', multivalue=False, required=False)
option: Str('ipaoriginaluid', attribute=True, autofill=False,
cli_name='ipaoriginaluid', multivalue=False, required=False)
+option: Str('ipasshpubkey', attribute=True, autofill=False,
cli_name='sshpubkey', csv=True, multivalue=True, required=False)
option: Str('loginshell', attribute=True, autofill=False, cli_name='shell',
multivalue=False, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False,
exclude='webui')
option: Str('rename', cli_name='rename', multivalue=False, primary_key=True,
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn =ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 05:16 PM, thierry bordaz wrote: On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn =ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread works if I use USERDN or SELFDN.
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Fri, 2014-10-10 at 17:30 +0200, Ludwig Krispenz wrote: On 10/10/2014 05:16 PM, thierry bordaz wrote: On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn = ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter =
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
https://fedorahosted.org/389/ticket/47924 is it possible to reproduce without IPA ? Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can find another way to reproduce it. well, did think about it again, we probaly also would need all the plugins, so could be difficult Something curious going on that make ACL_EvalTestRights return something different that ACL_RES_ALLOW. Did you already open a ticket for this problem ? thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Fri, 2014-10-10 at 17:38 +0200, Ludwig Krispenz wrote: https://fedorahosted.org/389/ticket/47924 is it possible to reproduce without IPA ? Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can find another way to reproduce it. well, did think about it again, we probaly also would need all the plugins, so could be difficult I'm not sure you need plugins. You do to make OTP authentication work. But we don't care about that. We just care if add returns the post read control. That should be doable with just schema and ACIs. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On 10/10/2014 05:30 PM, Ludwig Krispenz wrote: On 10/10/2014 05:16 PM, thierry bordaz wrote: On 10/10/2014 04:38 PM, Ludwig Krispenz wrote: On 10/10/2014 03:58 PM, thierry bordaz wrote: On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID Hello Nathaniel, The post read control needs access to the modified entry to return it. This access is granted at the condition, the binddn can access attributes. Agreed and understood. My understanding is that the target entry is ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com and the binddn uid=otp,cn=users,cn=accounts,dc=example,dc=com. Correct. The only ACI I found that match this target is: aci: (targetfilter = (objectClass=ipaToken)) (targetattrs = objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner) (version 3.0; acl Users/managers can read basic token info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or userattr = managedBy#USERDN;) Correct. Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? Yes, both. So why is access to objectClass (et cetera) being denied? Good question... I will try to reproduce Thanks! Hello, I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as cn=active guy,cn=accounts,dc=example,dc=com and to do a modify on cn=active otp,cn=otp,dc=example,dc=com. The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson))(target = ldap:///c n=*,cn=otp,dc=example,dc=com)(targetattr = objectclass || description || se eAlso)(version 3.0; acl Active user modify otp entry; allow (write) userdn =ldap:///cn=active guy,cn=accounts,dc=example,dc=com;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) Active user modify otp entry [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= Active user modify otp entry, acidn=cn=otp,dc=example,dc=com The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = (objectclass=organizationalPerson)) (targetattr = obje ctclass || description || seeAlso || cn)(version 3.0; acl Active user can r ead his entries; allow (read, search, compare) userattr = seeAlso#USERDN;) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) Active user can read his entries [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21) The postread
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On 10.10.2014 16:38, Alexander Bokovoy wrote:
On Fri, 10 Oct 2014, Petr Vobornik wrote:
On 10.10.2014 15:36, Alexander Bokovoy wrote:
On Fri, 10 Oct 2014, Petr Vobornik wrote:
On 10.10.2014 10:39, Alexander Bokovoy wrote:
Hi!
I'm resending patches 0159 and 0160, and adding two more:
0161 -- support user SSH public keys in ID view user overrides
0162 -- support gidNumber in ID view user override
SSH public keys to work require support from SSSD and that one is
currently missing. At least, one add/remove the keys to/from the
override objects.
Compat tree does not support exporting SSH keys. When accessing the
tree
anonymously, the entry will be filtered out by ACIs but for
authenticated users we need to explicitly ignore ipaSshPubKey
attribute
in the override, so I'm resending updated slapi-nis patch that only
adds one more attribute to filter out.
I'm going to prepare Web UI for, 160, 161, 162.
Q: ipaUserOverride object class contains also 'gecos' attribute. Will
it be handled be CLI and Web UI as well?
I'll add another patch for that.
Comments for these 3 patches:
1. VERSION was not bumped
Patch 160:
Apart form #1, is OK (not sure if #1 is needed for ACK)
I wonder if I should bump it in a separate patch that would be the last
one in the series, to avoid proliferation of API version numbers? :)
IMHO it should be sufficient. Same outcome as if the patches were
squashed.
Yep.
One more update for patch 0161, Petr noticed we need to call super
post_callback() too.
idoverrideuser_find callback causes internal error. I've attached new
version of the patch which fixes it. Basically it's this change:
diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index 25b9bcf..bfa8675 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -831,11 +831,12 @@ class idoverrideuser_find(baseidoverride_find):
msg_summary = ngettext('%(count)d User ID override matched',
'%(count)d User ID overrides matched', 0)
-def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
-dn = super(idoverrideuser_find, self).post_callback(ldap, dn,
- entry_attrs, *keys, **options)
-convert_sshpubkey_post(ldap, dn, entry_attrs)
-return dn
+def post_callback(self, ldap, entries, truncated, *args, **options):
+truncated = super(idoverrideuser_find, self).post_callback(
+ldap, entries, truncated, *args, **options)
+for entry in entries:
+convert_sshpubkey_post(ldap, entry.dn, entry)
+return truncated
If you are OK with it, then ACK for patches 160, 161-3, 162-1, 164 and 165.
Patch 159 should be reviewed by somebody more versed in Compat tree.
Btw. 10-schema_compat.update contains whitespace warning(git am) -
additional blank line at the end of file.
--
Petr Vobornik
From fb1a6a6481d853d3e374ece5dc8cf013fef44863 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Fri, 10 Oct 2014 09:26:13 +0300
Subject: [PATCH] Allow user overrides to specify SSH public keys
Overrides for users can have SSH public keys. This, however, will not enable
SSH public keys from overrides to be actually used until SSSD gets fixed to
pull them in.
SSSD ticket for SSH public keys in overrides:
https://fedorahosted.org/sssd/ticket/2454
Resolves https://fedorahosted.org/freeipa/ticket/4509
---
API.txt | 6 --
ipalib/plugins/idviews.py | 44
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/API.txt b/API.txt
index 226809e9e22c7e8ab851727b12bf0b93b4e5dcce..60fa32123d5e69c0cb63ed087f30fd9e03c7fa3e 100644
--- a/API.txt
+++ b/API.txt
@@ -2130,7 +2130,7 @@ output: Entry('result', type 'dict', Gettext('A dictionary representing an LDA
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
command: idoverrideuser_add
-args: 2,11,3
+args: 2,12,3
arg: Str('idviewcn', cli_name='idview', multivalue=False, primary_key=True, query=True, required=True)
arg: Str('ipaanchoruuid', attribute=True, cli_name='anchor', multivalue=False, primary_key=True, required=True)
option: Str('addattr*', cli_name='addattr', exclude='webui')
@@ -2138,6 +2138,7 @@ option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui
option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False)
option: Str('homedirectory', attribute=True, cli_name='homedir', multivalue=False, required=False)
option: Str('ipaoriginaluid', attribute=True, cli_name='ipaoriginaluid', multivalue=False, required=False)
+option: Str('ipasshpubkey', attribute=True, cli_name='sshpubkey', csv=True, multivalue=True, required=False)
option: Str('loginshell', attribute=True, cli_name='shell', multivalue=False, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('setattr*',
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
As a result of this ongoing conversation, I have opened two 389 bugs: 1. Post Read - https://fedorahosted.org/389/ticket/47924 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925 On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote: The background of this email is this bug: https://fedorahosted.org/freeipa/ticket/4456 Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: https://fedorahosted.org/389/ticket/47920 There are two outstanding issues: 1. 389 does not send the post read control for normal users. The operation itself succeeds, but no control is sent. The relevant sections from the log are attached. 389 is denying access to the following attributes (* = valid, ! = invalid): ! objectClass ! ipatokenOTPalgorithm ! ipatokenOTPdigits * ipatokenOTPkey * ipatokenHOTPcounter ! ipatokenOwner ! managedBy ! ipatokenUniqueID The ACIs allowing access to most of these attributes are here: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 Note that I am able to query the entry just fine (including all the above invalidly restricted attributes). Hence, I know the ACIs are working just fine. Part of the strange thing is that in the post read control request, I haven't indicated that I want *any* attributes returned (i.e. I want just the DN). So I'm not sure why it is querying all the attributes. I would suspect that the proper behavior would be to only check the ACIs on attributes that will actually be returned. 2. The second patch (0002) modifies the ACI for normal user token addition from this: aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) To this: aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp, $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl Users can create self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;) The idea is to allow users to create tokens which will be expanded by the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are checked. Since the expanded UUID no longer matches the ACI, the addition is denied. Is this truly the correct behavior? I would think that the ACIs would be checked before the UUID plugin, not after. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
On Fri, 10 Oct 2014 17:38:46 +0200 Ludwig Krispenz lkris...@redhat.com wrote: https://fedorahosted.org/389/ticket/47924 is it possible to reproduce without IPA ? Perhaps. You'd need the OTP schema and ACIs from FreeIPA, unless you can find another way to reproduce it. well, did think about it again, we probaly also would need all the plugins, so could be difficult Just a wild guess, for some reason the post-read evaluation is using some cached evaluation of the add. I think the key part here is that we *change* the DN which is key part in determining the access control. I wounder if you can reproduce in 389ds using the DNA plugin ? Use the magic value to generate a number and use the value in the add and read ACIs so that the ADD works only with the magic value. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] move replication topology to shared tree
Hello, this is the current status of my work on #4302, and there are a few pieces still missing, eg the management command needs more input checking and error handling, but - I wanted to give people interested a chance to have a look again and get feedback - there came up the following questions I would like to get an opinion. when thinking how to move from an existing deployment with direct management of replication agreement to the new way, there should not be any intermediate disconnects, and if possible transition should be made easy. So I think we should have defined a few modes of operation for the plugin: - initial/bootstrap [optional] - the plugin detects existing agreements and transforms it to segments in the shared tree - pending - the plugin handles and propagates segments in the shared tree, but does not enforce teh deletion or creation of replication agreements - active - directe management of replicatio agreements is rejected, existing segments ond their modifications are applied I did run my tests of the management command as directory manager since admin did not have permissions to read plugin configuration in cn=config, I can add permissions, probably will also need permissions for the part in the shared tree, so what is the expected operation mode, which user needs access to the shared config data and configuration ? From 31ffd14feab45753599df968722f88151eb45497 Mon Sep 17 00:00:00 2001 From: Ludwig Krispenz lkris...@redhat.com Date: Fri, 10 Oct 2014 17:29:58 +0200 Subject: [PATCH] move replication topology to shared tree Implementation of ticket 4302, still work in progress --- daemons/configure.ac | 1 + daemons/ipa-slapi-plugins/Makefile.am | 1 + daemons/ipa-slapi-plugins/topology/Makefile.am | 50 ++ .../topology/ipa-topology-conf.ldif| 22 + daemons/ipa-slapi-plugins/topology/topology.h | 192 ++ daemons/ipa-slapi-plugins/topology/topology_agmt.c | 254 daemons/ipa-slapi-plugins/topology/topology_cfg.c | 406 + daemons/ipa-slapi-plugins/topology/topology_init.c | 196 ++ daemons/ipa-slapi-plugins/topology/topology_post.c | 181 ++ daemons/ipa-slapi-plugins/topology/topology_pre.c | 119 daemons/ipa-slapi-plugins/topology/topology_util.c | 662 + freeipa.spec.in| 3 + install/share/60ipaconfig.ldif | 6 + install/tools/Makefile.am | 1 + install/tools/ipa-topology-manage | 23 + ipaserver/install/dsinstance.py| 4 + ipaserver/install/ipa_topology_manage.py | 387 17 files changed, 2508 insertions(+) create mode 100644 daemons/ipa-slapi-plugins/topology/Makefile.am create mode 100755 daemons/ipa-slapi-plugins/topology/ipa-topology-conf.ldif create mode 100644 daemons/ipa-slapi-plugins/topology/topology.h create mode 100644 daemons/ipa-slapi-plugins/topology/topology_agmt.c create mode 100644 daemons/ipa-slapi-plugins/topology/topology_cfg.c create mode 100644 daemons/ipa-slapi-plugins/topology/topology_init.c create mode 100644 daemons/ipa-slapi-plugins/topology/topology_post.c create mode 100644 daemons/ipa-slapi-plugins/topology/topology_pre.c create mode 100644 daemons/ipa-slapi-plugins/topology/topology_util.c create mode 100755 install/tools/ipa-topology-manage create mode 100644 ipaserver/install/ipa_topology_manage.py diff --git a/daemons/configure.ac b/daemons/configure.ac index b4507a6d972f854331925e72869898576bdfd76f..afc94069e3b0d8a9e0f6d654642dd95727a86dac 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -323,6 +323,7 @@ AC_CONFIG_FILES([ ipa-slapi-plugins/ipa-modrdn/Makefile ipa-slapi-plugins/ipa-sidgen/Makefile ipa-slapi-plugins/ipa-range-check/Makefile +ipa-slapi-plugins/topology/Makefile ]) AC_OUTPUT diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am index 06e6ee8b86f138cce05f2184ac98c39ffaf9757f..c5412ef6e051fa59fcf084304bf66099832223f0 100644 --- a/daemons/ipa-slapi-plugins/Makefile.am +++ b/daemons/ipa-slapi-plugins/Makefile.am @@ -15,6 +15,7 @@ SUBDIRS = \ ipa-winsync \ ipa-sidgen \ ipa-range-check \ + topology \ $(NULL) EXTRA_DIST = \ diff --git a/daemons/ipa-slapi-plugins/topology/Makefile.am b/daemons/ipa-slapi-plugins/topology/Makefile.am new file mode 100644 index ..d3a555e88381d3dda409c6e5a5854c8156c02000 --- /dev/null +++ b/daemons/ipa-slapi-plugins/topology/Makefile.am @@ -0,0 +1,50 @@ +NULL = + +PLUGIN_COMMON_DIR=../common + +AM_CPPFLAGS = \ + -I. \ + -I$(srcdir) \ + -I$(PLUGIN_COMMON_DIR) \ + -I/usr/include/dirsrv \ + -DPREFIX=\$(prefix)\ \ + -DBINDIR=\$(bindir)\\ + -DLIBDIR=\$(libdir)\ \ + -DLIBEXECDIR=\$(libexecdir)\ \ + -DDATADIR=\$(datadir)\\ +
Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys
On Fri, 10 Oct 2014, Petr Vobornik wrote:
One more update for patch 0161, Petr noticed we need to call super
post_callback() too.
idoverrideuser_find callback causes internal error. I've attached new
version of the patch which fixes it. Basically it's this change:
diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index 25b9bcf..bfa8675 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -831,11 +831,12 @@ class idoverrideuser_find(baseidoverride_find):
msg_summary = ngettext('%(count)d User ID override matched',
'%(count)d User ID overrides matched', 0)
-def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
-dn = super(idoverrideuser_find, self).post_callback(ldap, dn,
- entry_attrs, *keys, **options)
-convert_sshpubkey_post(ldap, dn, entry_attrs)
-return dn
+def post_callback(self, ldap, entries, truncated, *args, **options):
+truncated = super(idoverrideuser_find, self).post_callback(
+ldap, entries, truncated, *args, **options)
+for entry in entries:
+convert_sshpubkey_post(ldap, entry.dn, entry)
+return truncated
If you are OK with it, then ACK for patches 160, 161-3, 162-1, 164 and 165.
I'm fine with your patch, copy/paste error, thanks for fixing it.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 772 webui: add new iduseroverride fields
- add gecos, gidnumber, loginshell, sshkeys fields
depends on ab's 160-165.
Point for discussion:
Before this patch, all fields were included in adder dialog and were
listed on a search pages.
Now:
* Search page lacks: gecos, gidnumber, loginshell, sshkeys fields
* Adder dialog lacks: sshkeys
For reference, other fields are: ipaanchoruuid, description, uid,
uidnumber, homedirectory
We can't show every field on a search page. Is there a field among the
missing ones, which is more important and should be added to a search page?
--
Petr Vobornik
From ab53f98c96b0a9ae15505b4322f4bbc685d8171c Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 10 Oct 2014 16:23:08 +0200
Subject: [PATCH] webui: add new iduseroverride fields
- add gecos, gidnumber, loginshell, sshkeys fields
---
install/ui/src/freeipa/idviews.js | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/install/ui/src/freeipa/idviews.js b/install/ui/src/freeipa/idviews.js
index 57fcc490a4579227d14b790548f786ec769b5379..cbc78ae7c62916b6334a8ef0cdf12a92485b0876 100644
--- a/install/ui/src/freeipa/idviews.js
+++ b/install/ui/src/freeipa/idviews.js
@@ -252,8 +252,16 @@ return {
name: 'description'
},
'uid',
+'gecos',
'uidnumber',
-'homedirectory'
+'gidnumber',
+'loginshell',
+'homedirectory',
+{
+$type: 'sshkeys',
+name: 'ipasshpubkey',
+label: '@i18n:objects.sshkeystore.keys'
+}
]
}
]
@@ -283,7 +291,10 @@ return {
enabled: false
},
'uid',
+'gecos',
'uidnumber',
+'gidnumber',
+'loginshell',
'homedirectory',
{
$type: 'textarea',
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On Fri, 10 Oct 2014 17:52:15 +0200 Ludwig Krispenz lkris...@redhat.com wrote: Hello, this is the current status of my work on #4302, and there are a few pieces still missing, eg the management command needs more input checking and error handling, but - I wanted to give people interested a chance to have a look again and get feedback - there came up the following questions I would like to get an opinion. First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage when thinking how to move from an existing deployment with direct management of replication agreement to the new way, there should not be any intermediate disconnects, and if possible transition should be made easy. So I think we should have defined a few modes of operation for the plugin: - initial/bootstrap [optional] - the plugin detects existing agreements and transforms it to segments in the shared tree This should not be optional imo, its the only way to do sane upgrades. When the plugin starts it needs to check if there are replication agreements with other freeipa servers (it should ignore anything else). Then check if these agreements have been autogenerated (this should be determined by new naming conventions for agreements in cn=config) or if they are pre-existing, if they are pre-existing then new shared entries will be generated in the shared tree. Note: this upgrade thing could also be done in ipa-upgrade plugins, at server upgrade time. Whichever is easier (main concern is if 2 servers are upgraded at the same time replication conflicts may arise). - pending - the plugin handles and propagates segments in the shared tree, but does not enforce teh deletion or creation of replication agreements Not sure what you mean here, but I think that once the plugin is active it should stay active and actively prevent manual changes to automatically created replication agreements. - active - directe management of replicatio agreements is rejected, existing segments ond their modifications are applied This should always be. I did run my tests of the management command as directory manager since admin did not have permissions to read plugin configuration in cn=config, Why would you need to access cn=config ? All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... I can add permissions, probably will also need permissions for the part in the shared tree, so what is the expected operation mode, which user needs access to the shared config data and configuration ? We need to introduce a role for Replication Admins and make the admins group a member by default, then use normal permissions framework to regulate access. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10 October 2014 12:21, Simo Sorce s...@redhat.com wrote: First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage I agree here... I think the current interface of ipa-replica-manage is fine, however the need to copy the credentials around and the need for a password are the problem. In fact, I particularly like the current interface, and puppet-ipa has already wrapped this successfully. In other words, the design checks out. Good job IPA team. All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... I'd just like to +1 / re-iterate this point... In addition, thank you for hacking on this and for posting this for early review. Cheers, James ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name
aci: (targetfilter = (objectClass=ipaToken))(targetattrs = objectclass || d escription || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNo tBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSer ial || ipatokenOwner)(version 3.0; acl *Users/managers can read basic token* info; allow (read, search, compare) userattr = ipatokenOwner#USERDN or use rattr = managedBy#USERDN;) ... [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed attr:managedBy for entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating ALLOW aci(11) *Users/managers can read basic token info* [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in cache [09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating ALLOW aci(19) Admin can manage any entry [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in cache [09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= Admin can manage any entry, acidn=dc=example,dc=com [09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: access to entry not allowed (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com) But for some reason, it evaluations of the READ access was not accepted. the key is READ SKIP, looks like it is using cached evaluation of the acis, where the aci did not apply. aci caching is Exact. well, I think I've been a bit too fast, the READ SKIP is only logged from the second attribute on, so caching was ok, but the wrong result was cached. What really is strange is these lines: [09/Oct/2014:21:34:58 -0400] NSACLPlugin - 1. Evaluating ALLOW aci(11) Users/managers can read basic token info [09/Oct/2014:21:34:58 -0400] NSACLPlugin - Attr:ipatokenOwner [09/Oct/2014:21:34:58 -0400] NSACLPlugin - ACL info: userdnattr does not allow ADD permission at level 0. [09/Oct/2014:21:34:58 -0400] NSACLPlugin - Returning UNDEFINED for userdnattr evaluation. why ADD, why UNDEFINED ? Now If I create two entries x/y and their associated ipatoken tokenX/tokenY and play updating x update tokenX then y updates tokenY x update tokenX then x updates tokenY y update tokenY then x updates tokenX ... each time I got the postread. Something curious going on that make ACL_EvalTestRights return something different that ACL_RES_ALLOW. Did you already open a ticket for this problem ? thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10/10/2014 06:30 PM, James wrote: On 10 October 2014 12:21, Simo Sorce s...@redhat.com wrote: First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage I agree here... I think the current interface of ipa-replica-manage is fine, however the need to copy the credentials around and the need for a password are the problem. In fact, I particularly like the current interface, and puppet-ipa has already wrapped this successfully. In other words, the design checks out. Good job IPA team. All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... I'll comment later on Simmo's other comments, but I need access to cn=config for two reasons, - I need to know if the plugin is deployed and enabled - the plugin configuration contains the location in the the shared tree where the toplogy information is stored. I do not like to have hardcoded paths. I'd just like to +1 / re-iterate this point... In addition, thank you for hacking on this and for posting this for early review. Cheers, James ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On Fri, 10 Oct 2014 18:38:36 +0200 Ludwig Krispenz lkris...@redhat.com wrote: On 10/10/2014 06:30 PM, James wrote: On 10 October 2014 12:21, Simo Sorce s...@redhat.com wrote: First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage I agree here... I think the current interface of ipa-replica-manage is fine, however the need to copy the credentials around and the need for a password are the problem. In fact, I particularly like the current interface, and puppet-ipa has already wrapped this successfully. In other words, the design checks out. Good job IPA team. All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... I'll comment later on Simmo's other comments, but I need access to cn=config for two reasons, - I need to know if the plugin is deployed and enabled Let's expose something in rootDSE then, that's the standard way to do this (though it is unnecessary, if the shared tree is present you already know it is available). - the plugin configuration contains the location in the the shared tree where the toplogy information is stored. I do not like to have hardcoded paths. In IPA it will be absolutely hardcoded with no chance of changing it. So it is not a problem for IPA tools. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
