Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
On 5.9.2013 19:48, Rob Crittenden wrote: Petr Viktorin wrote: # External users system accounts I'm not sure how to handle external users here, since they're not added to any group. Either we'll need a special ACI for them, or somehow make it possible to add non-group sets of users to Roles. The same goes for system accounts, except those aren't even implemented in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). I think they would have to be part of a group. Otherwise 389-ds has nothing to evaluate against (and even with groups I'm not 100% sure it'll work). Once external users are mapped to entries in the directory (https://fedorahosted.org/freeipa/ticket/3242), they can be handled more or less the same way as internal users. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA server package group
On 09/05/2013 07:50 PM, Rob Crittenden wrote: Martin Kosek wrote: On 08/29/2013 12:22 PM, Tomas Babej wrote: On 08/29/2013 11:55 AM, Petr Viktorin wrote: On 08/28/2013 12:20 PM, Tomas Babej wrote: On 08/28/2013 12:03 PM, Petr Viktorin wrote: On 08/28/2013 11:46 AM, Tomas Babej wrote: On 08/26/2013 10:14 AM, Tomas Babej wrote: On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: On 08/26/2013 09:54 AM, Tomas Babej wrote: Hi, I cooked up a patch for comps that adds a FreeIPA package group. Please chime in if you're OK with package selection / description. For illustration, see the attached image. FreeIPA will be added as an add-on in an installer under the Infrastructure server environment, that means, in the included images it will be at the same level as DNS or FTP server. It will also appear in the Software Selection tool (PackageKit). It should also be available under as yum groupinstall FreeIPA server, and in PackageKit, as I understand comps is also source for that too. https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups https://fedorahosted.org/freeipa/ticket/3630 IMO the Audit part in the description is false advertisement. Same issue is in package descriptions. I know, it's taken directly from there. I'd rather have it consistent, if we're going to change it here, we should do there too, so that we do not end up with multiple (seemingly incomplete) descriptions at various places. Anybody else does have any other concerns? We need to move with this effort since string freeze for F20 is coming. I'm particulary dubious about including the freeipa-tests package. I don't think that should be included, developer tests are unnecessary for a server. It was marked as optional in the initial proposal, but I agree it's unnecessary for it to be there at all. We discussed the A (as Audit) part in the description with Rob. The fact is that this is taken from the freeipa-server package description and nobody complained in 7 years. Updated tests attached. Oh, one more thing I remembered just now -- is it too late? We should include bind-dyndb-ldap (which pulls in bind). Preferably as default. I included it there. If anyone else wants to chime in, please do now, I'll create a ticket with rel-eng at the end of the day. Thanks for this effort. What is the status of the bug - did you create the request already? We will need to do one more change and remove freeipa-server-strict package as up on the decision on today's developer meeting we decided to drop this subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous Integration system instead. I missed that meeting so maybe I'm re-hashing things, but I don't see how CI solves the problem that the strict subpackage does. Sure, it won't be as much a surprise to us when other packages are updated, but this doesn't prevent a user from also updating to the package. The strict package prevents upgrade until we've confirmed that things are actually working. CI does not. CI should prevent problems at the begging, before they happen - right when the new Dogtag/Kerberos/389-ds-base is in updates-testing. That gives a change to give negative Karma and have that package fixed before it hits stable updates. IMO freeipa-server-strict subpackage is too heavy weight and does not provide the benefit we would want. So far, IMHO, it was rather a burden for maintainers and broke quite frequently. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). An IPA terminology refresher for reference: - ACI: The DS-level permission. - Permission: IPA object that encapsulates one ACI. Example: add user. Permissions aren't as flexible as raw ACIs. - Privilege: IPA object that groups several permissions, e.g. with a manage users privilege you can add user, modify user, ... - Role: IPA object that groups privileges, e.g. an User Administrator can manage users and groups. Roles are assigned to users/groups/hosts. # Permission structure I think it would be best to have two permissions for each object, one for the entries and one for the container. This keeps the ACIs manageable with existing permission API: aci: (target = ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Read Groups;allow (read,search,compare) groupdn = ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX;) aci: (target = ldap:///cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Read Group Container;allow (read,search,compare) groupdn = ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX;) These would be combined in a Group Readers privilege. All the privileges would be granted to a role called Users, which would contain ipausers and admins. I'm not sure I follow, what are you trying to achieve here? The more ACIs the slower the processing. One of the main reason for this feature is to get rid of the global allowing ACI: aci: (targetfilter = ((!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenRadiusConfiguration(target != ldap:///idnsname=*,cn=dns,$SUFFIX;)(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;) ... as this ACI does not scale and adds burden for developers or plugin author wishing to add an attribute that should not be visible by default. Number of ACIs should still be kept low, that's true. # External users system accounts I'm not sure how to handle external users here, since they're not added to any group. Either we'll need a special ACI for them, or somehow make it possible to add non-group sets of users to Roles. The same goes for system accounts, except those aren't even implemented in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). I think they would have to be part of a group. Otherwise 389-ds has nothing to evaluate against (and even with groups I'm not 100% sure it'll work). # Protected attributes How to handle passwords and other non-public attributes? I'm thinking about keeping a global list of such attributes, and applying it to each read permission ACI on normal operations and upgrades; either generating a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. Possibly that list would be configurable and stored in LDAP. For reference, we currently exclude these in the anonymous read rule: userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming It could get ugly real fast, and potentially cause a lot of extra processing. I think the object(s) for each attribute should be considered so these wouldn't have to be applied to every ACI but only those that are affected. We don't need to worry about userPassword in groups, for example. I think that a decision that a param should not be included in default read rule should be included in the param object itself, see below. # Compat tree Do we want to reuse the read privileges for the compat tree, or create extra ones? I don't think so. # Combining read rights I think (read, search, compare) should be exposed in permission objects as a single right. Or is there a reason to keep it split? Yes, they are separate for a reason. Using only search and compare isn't common, but it isn't unheard of either. For example, to be able to detect the presence of an attribute you can provide just the search permission. Wouldn't most users use the (read, search, compare) triple? It would lower our number of ACIs significantly if we do not have 3 permissions per each object. # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This
Re: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0
On Thu, 05 Sep 2013, Petr Viktorin wrote: On 09/05/2013 08:08 AM, Alexander Bokovoy wrote: On Wed, 04 Sep 2013, Petr Viktorin wrote: On 08/19/2013 12:29 PM, Petr Viktorin wrote: Hello, The first patch fixes a minor problem that Pylint 1.0 finds in our code. The second patch makes make-lint compatible with Pylint 1.0. It contains a workaround for a Pylint bug; before pushing this we should wait for a while to see if a fixed Pylint is released. A fixed version of Pylint was released, bug workarounds are no longer necessary. Updated patches attached. https://fedorahosted.org/freeipa/ticket/3865 I tried the patches and still see an error on up to date Fedora 19 (including updates-testing): ./make-lint Traceback (most recent call last): [...] TypeError: unbound method infer() must be called with Tuple instance as first argument (got InferenceContext instance instead) At this point I'm not sure whether it is astroid's issue or ours... Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in Fedora 19 where version updates after release are generally discouraged, especially in case of ABI change). Hello, Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet, you have the earlier buggy version. I do have pylint 1.0.0-2.fc19 and yet it fails with the same error message. Nothing works, I had to disable make-lint call in Makefile to continue development. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0
On 09/06/2013 10:35 AM, Alexander Bokovoy wrote:
On Thu, 05 Sep 2013, Petr Viktorin wrote:
On 09/05/2013 08:08 AM, Alexander Bokovoy wrote:
On Wed, 04 Sep 2013, Petr Viktorin wrote:
On 08/19/2013 12:29 PM, Petr Viktorin wrote:
Hello,
The first patch fixes a minor problem that Pylint 1.0 finds in our
code.
The second patch makes make-lint compatible with Pylint 1.0. It
contains
a workaround for a Pylint bug; before pushing this we should wait
for a
while to see if a fixed Pylint is released.
A fixed version of Pylint was released, bug workarounds are no longer
necessary.
Updated patches attached.
https://fedorahosted.org/freeipa/ticket/3865
I tried the patches and still see an error on up to date Fedora 19
(including updates-testing):
./make-lint Traceback (most recent call last):
[...]
TypeError: unbound method infer() must be called with Tuple instance as
first argument (got InferenceContext instance instead)
At this point I'm not sure whether it is astroid's issue or ours...
Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in
Fedora 19 where version updates after release are generally
discouraged, especially in case of ABI change).
Hello,
Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet,
you have the earlier buggy version.
I do have pylint 1.0.0-2.fc19 and yet it fails with the same error
message. Nothing works, I had to disable make-lint call in Makefile to
continue development.
That is strange; I've confirmed on several machines that the -2.fc19
release fixes this bug.
If you run pylint on the following code, do you also get the unbound
method infer() error? (It's the upstream bug reproducer)
import collections
Point = collections.namedtuple('Point', ['x', 'y'])
p = Point(x=1.0, y=2.0)
print Area: %.1f % (p.x * p.y,)
Can you check the FILE in `pydoc pylint` to make sure you're running
pylint from the RPM?
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
On 09/06/2013 09:26 AM, Martin Kosek wrote: On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). [...] # Permission structure I think it would be best to have two permissions for each object, one for the entries and one for the container. This keeps the ACIs manageable with existing permission API: aci: (target = ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Read Groups;allow (read,search,compare) groupdn = ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX;) aci: (target = ldap:///cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Read Group Container;allow (read,search,compare) groupdn = ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX;) These would be combined in a Group Readers privilege. All the privileges would be granted to a role called Users, which would contain ipausers and admins. I'm not sure I follow, what are you trying to achieve here? The more ACIs the slower the processing. Yes, but with a feature request for fine-grained read permissions, I don't see how we can get away without increasing the number of ACIs. If we want the ACIs to be manageable, we need two ACIs per object type - one for the object itself, one for the container. Alternatively we could combine the two with some clever filter tricks and build a smart UI on top to manage them. I don't want to go this route. We might be able to get away with one global system ACI to cover all containers, so each object type would only have one read ACI, but that's also quite ugly. A potential way to get performance back is to move ACIs from $SUFFIX to the actual container they apply to. What is the reason we put our ACIs on $SUFFIX? Is it so that we can easily find/list them later? One of the main reason for this feature is to get rid of the global allowing ACI: aci: (targetfilter = ((!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenRadiusConfiguration(target != ldap:///idnsname=*,cn=dns,$SUFFIX;)(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;) ... as this ACI does not scale and adds burden for developers or plugin author wishing to add an attribute that should not be visible by default. Number of ACIs should still be kept low, that's true. # External users system accounts I'm not sure how to handle external users here, since they're not added to any group. Either we'll need a special ACI for them, or somehow make it possible to add non-group sets of users to Roles. The same goes for system accounts, except those aren't even implemented in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). I think they would have to be part of a group. Otherwise 389-ds has nothing to evaluate against (and even with groups I'm not 100% sure it'll work). # Protected attributes How to handle passwords and other non-public attributes? I'm thinking about keeping a global list of such attributes, and applying it to each read permission ACI on normal operations and upgrades; either generating a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. Possibly that list would be configurable and stored in LDAP. For reference, we currently exclude these in the anonymous read rule: userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming It could get ugly real fast, and potentially cause a lot of extra processing. I think the object(s) for each attribute should be considered so these wouldn't have to be applied to every ACI but only those that are affected. We don't need to worry about userPassword in groups, for example. There are two considerations in play: - We want users to be able to add or remove attributes to the ACIs. - We need to be able to update the ACIs on upgrade (and on user-initiated config changes, e.g. ipauserobjectclasses), so that attributes from new added object classes are added The hard part: merging the user changes back in after an upgrade. The only solutions to this that I found require us tracking more data than we are tracking now: either attribute lists from past IPA versions, or records of the user's actions. I plan to go with the latter. I think that a decision that a param should not be included in default read rule should be included in the param object itself, see below. # Compat tree Do we want to reuse the read privileges for the compat tree, or create extra ones? I don't think so. Can you disambiguate? :) # Combining read rights I think (read, search,
Re: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0
On Fri, 06 Sep 2013, Petr Viktorin wrote:
On 09/06/2013 10:35 AM, Alexander Bokovoy wrote:
On Thu, 05 Sep 2013, Petr Viktorin wrote:
On 09/05/2013 08:08 AM, Alexander Bokovoy wrote:
On Wed, 04 Sep 2013, Petr Viktorin wrote:
On 08/19/2013 12:29 PM, Petr Viktorin wrote:
Hello,
The first patch fixes a minor problem that Pylint 1.0 finds in our
code.
The second patch makes make-lint compatible with Pylint 1.0. It
contains
a workaround for a Pylint bug; before pushing this we should wait
for a
while to see if a fixed Pylint is released.
A fixed version of Pylint was released, bug workarounds are no longer
necessary.
Updated patches attached.
https://fedorahosted.org/freeipa/ticket/3865
I tried the patches and still see an error on up to date Fedora 19
(including updates-testing):
./make-lint Traceback (most recent call last):
[...]
TypeError: unbound method infer() must be called with Tuple instance as
first argument (got InferenceContext instance instead)
At this point I'm not sure whether it is astroid's issue or ours...
Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in
Fedora 19 where version updates after release are generally
discouraged, especially in case of ABI change).
Hello,
Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet,
you have the earlier buggy version.
I do have pylint 1.0.0-2.fc19 and yet it fails with the same error
message. Nothing works, I had to disable make-lint call in Makefile to
continue development.
That is strange; I've confirmed on several machines that the -2.fc19
release fixes this bug.
If you run pylint on the following code, do you also get the unbound
method infer() error? (It's the upstream bug reproducer)
import collections
Point = collections.namedtuple('Point', ['x', 'y'])
p = Point(x=1.0, y=2.0)
print Area: %.1f % (p.x * p.y,)
Here is clean Fedora 19 VM, created few hours ago:
# rpm -q pylint python-astroid
pylint-1.0.0-2.fc19.noarch
python-astroid-1.0.0-2.fc19.noarch
# pylint test.py
No config file found, using default configuration
* Module test
C: 1, 0: Missing module docstring (missing-docstring)
C: 3, 0: Invalid constant name p (invalid-name)
Traceback (most recent call last):
File /usr/bin/pylint, line 9, in module
load_entry_point('pylint==1.0.0', 'console_scripts', 'pylint')()
File /usr/lib/python2.7/site-packages/pylint/__init__.py, line 21, in
run_pylint
Run(sys.argv[1:])
File /usr/lib/python2.7/site-packages/pylint/lint.py, line 1010, in __init__
linter.check(args)
File /usr/lib/python2.7/site-packages/pylint/lint.py, line 599, in check
self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers)
File /usr/lib/python2.7/site-packages/pylint/lint.py, line 685, in
check_astroid_module
walker.walk(astroid)
File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk
self.walk(child)
File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk
self.walk(child)
File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk
self.walk(child)
File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk
self.walk(child)
File /usr/lib/python2.7/site-packages/pylint/utils.py, line 662, in walk
self.walk(child)
File /usr/lib/python2.7/site-packages/pylint/utils.py, line 659, in walk
cb(astroid)
File /usr/lib/python2.7/site-packages/pylint/checkers/typecheck.py, line
174, in visit_getattr
if is_super(owner) or getattr(owner, 'type', None) == 'metaclass':
File /usr/lib/python2.7/site-packages/astroid/bases.py, line 51, in
__getattr__
return getattr(self._proxied, name)
File /usr/lib/python2.7/site-packages/astroid/scoped_nodes.py, line 680, in
_class_type
for base in klass.ancestors(recurs=False):
File /usr/lib/python2.7/site-packages/astroid/scoped_nodes.py, line 801, in
ancestors
for baseobj in stmt.infer(context):
TypeError: unbound method infer() must be called with Tuple instance as
first argument (got InferenceContext instance instead)
Then I've ran 'yum upgrade' again, and python-astroid-1.0.0-3.fc19.noarch was
installed which finally fixed the problem.
So the actual problem was split across both pylint and python-astroid.
That means ACK for your patches.
--
/ Alexander Bokovoy
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 450 Fix redirection on deletion of last dns record entry
https://fedorahosted.org/freeipa/ticket/3907
--
Petr Vobornik
From d1c6e5e2e42551a707c0b295d6b760879b068ad1 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 6 Sep 2013 14:24:36 +0200
Subject: [PATCH] Fix redirection on deletion of last dns record entry
https://fedorahosted.org/freeipa/ticket/3907
---
install/ui/src/freeipa/dns.js | 2 +-
ipatests/test_webui/test_dns.py | 21 -
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/install/ui/src/freeipa/dns.js b/install/ui/src/freeipa/dns.js
index c31313a13de99fafb516d8032b32c640c9b1c08d..62b20e31cdae482dc21dc594b289e5194d628340 100644
--- a/install/ui/src/freeipa/dns.js
+++ b/install/ui/src/freeipa/dns.js
@@ -1313,7 +1313,7 @@ IPA.dnsrecord_redirection_dialog = function(spec) {
};
that.on_ok = function() {
-navigation.show_entity_page('dnszone','default');
+navigation.show_entity('dnszone','default');
};
return that;
diff --git a/ipatests/test_webui/test_dns.py b/ipatests/test_webui/test_dns.py
index aeff77b8e02eb7bf3775f3baceb5c034d1a450e5..c832190d39c23fc5b90884439779341c448cd099 100644
--- a/ipatests/test_webui/test_dns.py
+++ b/ipatests/test_webui/test_dns.py
@@ -46,11 +46,12 @@ ZONE_DATA = {
RECORD_PKEY = 'itest'
+A_IP = '192.168.1.10'
RECORD_ADD_DATA = {
'pkey': RECORD_PKEY,
'add': [
('textbox', 'idnsname', RECORD_PKEY),
-('textbox', 'a_part_ip_address', '192.168.1.10'),
+('textbox', 'a_part_ip_address', A_IP),
]
}
@@ -98,6 +99,24 @@ class test_dns(UI_driver):
self.navigate_by_breadcrumb(DNS Zones)
self.delete_record(ZONE_PKEY)
+def test_last_entry_deletion(self):
+
+Test last entry deletion
+
+self.init_app()
+self.add_record(ZONE_ENTITY, ZONE_DATA)
+self.navigate_to_record(ZONE_PKEY)
+self.add_record(ZONE_ENTITY, RECORD_ADD_DATA,
+facet=ZONE_DEFAULT_FACET)
+self.navigate_to_record(RECORD_PKEY)
+self.delete_record(A_IP, parent=self.get_facet(), table_name='arecord')
+self.assert_dialog('message_dialog')
+self.dialog_button_click('ok')
+self.wait_for_request(n=2)
+self.assert_facet(ZONE_ENTITY, ZONE_DEFAULT_FACET)
+self.navigate_by_breadcrumb(DNS Zones)
+self.delete_record(ZONE_PKEY)
+
def test_config_crud(self):
Basic CRUD: dnsconfig
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0066 Do not crash if DS is down during server uninstall
Hello,
This patch fixes the regression introduced by the original fix for ticket #3867.
https://fedorahosted.org/freeipa/ticket/3867
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
From 0ad82d43314ef7e8d9538de76b118ce0922e512d Mon Sep 17 00:00:00 2001
From: Ana Krivokapic akriv...@redhat.com
Date: Fri, 6 Sep 2013 14:53:01 +0200
Subject: [PATCH] Do not crash if DS is down during server uninstall
DS is contacted during server uninstallation, in order to obtain information
about replication agreements. If DS is unavailable, warn and continue with
uninstallation.
https://fedorahosted.org/freeipa/ticket/3867
---
install/tools/ipa-server-install | 64 +---
1 file changed, 41 insertions(+), 23 deletions(-)
mode change 100755 = 100644 install/tools/ipa-server-install
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
old mode 100755
new mode 100644
index 1bf932da731965b342c0c49d39e6a175bf98705b..f46e4b0548998dd5b0c8a12321ba8916ccb40f25
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -624,31 +624,49 @@ def main():
print Aborting uninstall operation.
sys.exit(1)
-conn = ipaldap.IPAdmin(api.env.host, ldapi=True, realm=api.env.realm)
-conn.do_external_bind(pwd.getpwuid(os.geteuid()).pw_name)
-rm = replication.ReplicationManager(api.env.realm, api.env.host, None,
-conn=conn)
-agreements = rm.find_ipa_replication_agreements()
-
-if agreements:
-other_masters = [a.get('cn')[0][4:] for a in agreements]
-msg = (
-\nReplication agreements with the following IPA masters
-found: %s. Removing any replication agreements before
-uninstalling the server is strongly recommended. You can
-remove replication agreements by running the following
-command on any other IPA master:\n % , .join(other_masters)
+try:
+conn = ipaldap.IPAdmin(
+api.env.host,
+ldapi=True,
+realm=api.env.realm
)
-cmd = $ ipa-replica-manage del %s\n % api.env.host
+conn.do_external_bind(pwd.getpwuid(os.geteuid()).pw_name)
+except Exception:
+msg = (\nWARNING: Failed to connect to Directory Server to find
+ information about replication agreements. Uninstallation
+ will continue dispite the possible existing replication
+ agreements.\n\n)
print textwrap.fill(msg, width=80, replace_whitespace=False)
-print cmd
-if not (options.unattended or user_input(Are you sure you want
- to continue with the
- uninstall procedure?,
- False)):
-print
-print Aborting uninstall operation.
-sys.exit(1)
+else:
+rm = replication.ReplicationManager(
+realm=api.env.realm,
+hostname=api.env.host,
+dirman_passwd=None,
+conn=conn
+)
+agreements = rm.find_ipa_replication_agreements()
+
+if agreements:
+other_masters = [a.get('cn')[0][4:] for a in agreements]
+msg = (
+\nReplication agreements with the following IPA masters
+found: %s. Removing any replication agreements before
+uninstalling the server is strongly recommended. You can
+remove replication agreements by running the following
+command on any other IPA master:\n % , .join(
+other_masters)
+)
+cmd = $ ipa-replica-manage del %s\n % api.env.host
+print textwrap.fill(msg, width=80, replace_whitespace=False)
+print cmd
+if not (options.unattended or user_input(Are you sure you
+ want to continue
+ with the uninstall
+ procedure?,
+ False)):
+print
+print Aborting uninstall operation.
+sys.exit(1)
return uninstall()
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA server package group
Martin Kosek wrote: On 09/05/2013 07:50 PM, Rob Crittenden wrote: Martin Kosek wrote: On 08/29/2013 12:22 PM, Tomas Babej wrote: On 08/29/2013 11:55 AM, Petr Viktorin wrote: On 08/28/2013 12:20 PM, Tomas Babej wrote: On 08/28/2013 12:03 PM, Petr Viktorin wrote: On 08/28/2013 11:46 AM, Tomas Babej wrote: On 08/26/2013 10:14 AM, Tomas Babej wrote: On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: On 08/26/2013 09:54 AM, Tomas Babej wrote: Hi, I cooked up a patch for comps that adds a FreeIPA package group. Please chime in if you're OK with package selection / description. For illustration, see the attached image. FreeIPA will be added as an add-on in an installer under the Infrastructure server environment, that means, in the included images it will be at the same level as DNS or FTP server. It will also appear in the Software Selection tool (PackageKit). It should also be available under as yum groupinstall FreeIPA server, and in PackageKit, as I understand comps is also source for that too. https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups https://fedorahosted.org/freeipa/ticket/3630 IMO the Audit part in the description is false advertisement. Same issue is in package descriptions. I know, it's taken directly from there. I'd rather have it consistent, if we're going to change it here, we should do there too, so that we do not end up with multiple (seemingly incomplete) descriptions at various places. Anybody else does have any other concerns? We need to move with this effort since string freeze for F20 is coming. I'm particulary dubious about including the freeipa-tests package. I don't think that should be included, developer tests are unnecessary for a server. It was marked as optional in the initial proposal, but I agree it's unnecessary for it to be there at all. We discussed the A (as Audit) part in the description with Rob. The fact is that this is taken from the freeipa-server package description and nobody complained in 7 years. Updated tests attached. Oh, one more thing I remembered just now -- is it too late? We should include bind-dyndb-ldap (which pulls in bind). Preferably as default. I included it there. If anyone else wants to chime in, please do now, I'll create a ticket with rel-eng at the end of the day. Thanks for this effort. What is the status of the bug - did you create the request already? We will need to do one more change and remove freeipa-server-strict package as up on the decision on today's developer meeting we decided to drop this subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous Integration system instead. I missed that meeting so maybe I'm re-hashing things, but I don't see how CI solves the problem that the strict subpackage does. Sure, it won't be as much a surprise to us when other packages are updated, but this doesn't prevent a user from also updating to the package. The strict package prevents upgrade until we've confirmed that things are actually working. CI does not. CI should prevent problems at the begging, before they happen - right when the new Dogtag/Kerberos/389-ds-base is in updates-testing. That gives a change to give negative Karma and have that package fixed before it hits stable updates. IMO freeipa-server-strict subpackage is too heavy weight and does not provide the benefit we would want. So far, IMHO, it was rather a burden for maintainers and broke quite frequently. I'm not a huge fan of the strict package, I resisted it for a long time. But it does serve its intended purpose: stability for users. I agree it is a pain, particularly in rawhide. I guess I'm just not convinced that CI is going to catch everything. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
Martin Kosek wrote: On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). An IPA terminology refresher for reference: - ACI: The DS-level permission. - Permission: IPA object that encapsulates one ACI. Example: add user. Permissions aren't as flexible as raw ACIs. - Privilege: IPA object that groups several permissions, e.g. with a manage users privilege you can add user, modify user, ... - Role: IPA object that groups privileges, e.g. an User Administrator can manage users and groups. Roles are assigned to users/groups/hosts. # Permission structure I think it would be best to have two permissions for each object, one for the entries and one for the container. This keeps the ACIs manageable with existing permission API: aci: (target = ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Read Groups;allow (read,search,compare) groupdn = ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX;) aci: (target = ldap:///cn=groups,cn=accounts,$SUFFIX;)(version 3.0;acl permission:Read Group Container;allow (read,search,compare) groupdn = ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX;) These would be combined in a Group Readers privilege. All the privileges would be granted to a role called Users, which would contain ipausers and admins. I'm not sure I follow, what are you trying to achieve here? The more ACIs the slower the processing. One of the main reason for this feature is to get rid of the global allowing ACI: aci: (targetfilter = ((!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenRadiusConfiguration(target != ldap:///idnsname=*,cn=dns,$SUFFIX;)(targetattr != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;) ... as this ACI does not scale and adds burden for developers or plugin author wishing to add an attribute that should not be visible by default. Number of ACIs should still be kept low, that's true. Right, I just want to know why it was proposed to add 2 ACIs for every container. # External users system accounts I'm not sure how to handle external users here, since they're not added to any group. Either we'll need a special ACI for them, or somehow make it possible to add non-group sets of users to Roles. The same goes for system accounts, except those aren't even implemented in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). I think they would have to be part of a group. Otherwise 389-ds has nothing to evaluate against (and even with groups I'm not 100% sure it'll work). # Protected attributes How to handle passwords and other non-public attributes? I'm thinking about keeping a global list of such attributes, and applying it to each read permission ACI on normal operations and upgrades; either generating a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. Possibly that list would be configurable and stored in LDAP. For reference, we currently exclude these in the anonymous read rule: userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming It could get ugly real fast, and potentially cause a lot of extra processing. I think the object(s) for each attribute should be considered so these wouldn't have to be applied to every ACI but only those that are affected. We don't need to worry about userPassword in groups, for example. I think that a decision that a param should not be included in default read rule should be included in the param object itself, see below. # Compat tree Do we want to reuse the read privileges for the compat tree, or create extra ones? I don't think so. # Combining read rights I think (read, search, compare) should be exposed in permission objects as a single right. Or is there a reason to keep it split? Yes, they are separate for a reason. Using only search and compare isn't common, but it isn't unheard of either. For example, to be able to detect the presence of an attribute you can provide just the search permission. Wouldn't most users use the (read, search, compare) triple? It would lower our number of ACIs significantly if we do not have 3 permissions per each object. There is nothing to prevent an ACI from containing multiple permissions. I wasn't proposing that. But rolling these three logically into the same thing in IPA I think is short-sighted. # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather
Re: [Freeipa-devel] FreeIPA server package group
On 09/06/2013 03:05 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2013 07:50 PM, Rob Crittenden wrote: Martin Kosek wrote: On 08/29/2013 12:22 PM, Tomas Babej wrote: On 08/29/2013 11:55 AM, Petr Viktorin wrote: On 08/28/2013 12:20 PM, Tomas Babej wrote: On 08/28/2013 12:03 PM, Petr Viktorin wrote: On 08/28/2013 11:46 AM, Tomas Babej wrote: On 08/26/2013 10:14 AM, Tomas Babej wrote: On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: On 08/26/2013 09:54 AM, Tomas Babej wrote: Hi, I cooked up a patch for comps that adds a FreeIPA package group. Please chime in if you're OK with package selection / description. For illustration, see the attached image. FreeIPA will be added as an add-on in an installer under the Infrastructure server environment, that means, in the included images it will be at the same level as DNS or FTP server. It will also appear in the Software Selection tool (PackageKit). It should also be available under as yum groupinstall FreeIPA server, and in PackageKit, as I understand comps is also source for that too. https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups https://fedorahosted.org/freeipa/ticket/3630 IMO the Audit part in the description is false advertisement. Same issue is in package descriptions. I know, it's taken directly from there. I'd rather have it consistent, if we're going to change it here, we should do there too, so that we do not end up with multiple (seemingly incomplete) descriptions at various places. Anybody else does have any other concerns? We need to move with this effort since string freeze for F20 is coming. I'm particulary dubious about including the freeipa-tests package. I don't think that should be included, developer tests are unnecessary for a server. It was marked as optional in the initial proposal, but I agree it's unnecessary for it to be there at all. We discussed the A (as Audit) part in the description with Rob. The fact is that this is taken from the freeipa-server package description and nobody complained in 7 years. Updated tests attached. Oh, one more thing I remembered just now -- is it too late? We should include bind-dyndb-ldap (which pulls in bind). Preferably as default. I included it there. If anyone else wants to chime in, please do now, I'll create a ticket with rel-eng at the end of the day. Thanks for this effort. What is the status of the bug - did you create the request already? We will need to do one more change and remove freeipa-server-strict package as up on the decision on today's developer meeting we decided to drop this subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous Integration system instead. I missed that meeting so maybe I'm re-hashing things, but I don't see how CI solves the problem that the strict subpackage does. Sure, it won't be as much a surprise to us when other packages are updated, but this doesn't prevent a user from also updating to the package. The strict package prevents upgrade until we've confirmed that things are actually working. CI does not. CI should prevent problems at the begging, before they happen - right when the new Dogtag/Kerberos/389-ds-base is in updates-testing. That gives a change to give negative Karma and have that package fixed before it hits stable updates. IMO freeipa-server-strict subpackage is too heavy weight and does not provide the benefit we would want. So far, IMHO, it was rather a burden for maintainers and broke quite frequently. I'm not a huge fan of the strict package, I resisted it for a long time. But it does serve its intended purpose: stability for users. I agree it is a pain, particularly in rawhide. Yeah, this is exactly a point where I am not sure if it serves it's purpose. We do not have some policy or official testing of new DS/CS/KRB releases. So I just do not know when exactly should be update the strict package. After the new DS version is used for a month in a community? Or after a smoke/unit test performed ad-hoc by somebody in the team? I do not know. But until we do that, we will have broken dependency. I guess I'm just not convinced that CI is going to catch everything. I am not sure if the strict versioning makes a difference, given that version is also bumped by a human/package maintainer who cannot catch everything either. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
On 09/06/2013 02:46 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). [...] Right, I just want to know why it was proposed to add 2 ACIs for every container. One for the container itself, one for the objects beneath it. I don't see a straightforward way to allow access to both in a single permission. (Currently, permissions need to be at $SUFFIX, so their subtrees are specified by target.) [...] # Combining read rights I think (read, search, compare) should be exposed in permission objects as a single right. Or is there a reason to keep it split? Yes, they are separate for a reason. Using only search and compare isn't common, but it isn't unheard of either. For example, to be able to detect the presence of an attribute you can provide just the search permission. Wouldn't most users use the (read, search, compare) triple? It would lower our number of ACIs significantly if we do not have 3 permissions per each object. There is nothing to prevent an ACI from containing multiple permissions. I wasn't proposing that. But rolling these three logically into the same thing in IPA I think is short-sighted. See my other e-mail with my reasoning. I don't particularly care about this issue, though. # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This should be done when the time comes for a new version of the ldap-updater. [...] Well, my alarm bells are going off. This would require some significant review each and every time any object is updated. Consider how many times API.txt is overlooked, and it has no security implications. Consider how many times the ldif or update files were overlooked. API.txt is checked during every build, whereas ldif/update files not, and are tedious to check. We can of course add a similar file for ACIs, in fact I was planning to do so. Any changes can be then reviewed both in the source and (like now) in the resulting ldif. Also, the information would be in one place, rather than in ldif (which doesn't apply on upgrades) and in update files. I believe it would actually be better for security. I can't say I'm a fan of programmatic ACI generation. Well, I'm sure not going to write the ACIs for this feature by hand. It would help I could actually polish, commit and integrate the script that generates them. In my book, programmatic generation is much better than copy+paste. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0003] Add timestamps to named debug logs in /var/named/data/named.run
On 09/05/2013 04:29 PM, Tomas Babej wrote: On 09/05/2013 04:25 PM, Petr Spacek wrote: Hello, Add timestamps to named debug logs in /var/named/data/named.run. Tomas Babej and I spent more than hour with debugging bind-dyndb-ldap and timestamps were invaluable. ACK Thanks, pushed to master: 0924177ab03d39a09bb8e9885f5d2a2f586a1eda ipa-3-3: b9e44e22e1ce60fda524e772ade118b8674cf205 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0
On 09/06/2013 02:22 PM, Alexander Bokovoy wrote:
On Fri, 06 Sep 2013, Petr Viktorin wrote:
On 09/06/2013 10:35 AM, Alexander Bokovoy wrote:
On Thu, 05 Sep 2013, Petr Viktorin wrote:
On 09/05/2013 08:08 AM, Alexander Bokovoy wrote:
On Wed, 04 Sep 2013, Petr Viktorin wrote:
On 08/19/2013 12:29 PM, Petr Viktorin wrote:
Hello,
The first patch fixes a minor problem that Pylint 1.0 finds in our
code.
The second patch makes make-lint compatible with Pylint 1.0. It
contains
a workaround for a Pylint bug; before pushing this we should wait
for a
while to see if a fixed Pylint is released.
A fixed version of Pylint was released, bug workarounds are no longer
necessary.
Updated patches attached.
https://fedorahosted.org/freeipa/ticket/3865
I tried the patches and still see an error on up to date Fedora 19
(including updates-testing):
./make-lint Traceback (most recent call last):
[...]
TypeError: unbound method infer() must be called with Tuple
instance as
first argument (got InferenceContext instance instead)
At this point I'm not sure whether it is astroid's issue or ours...
Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in
Fedora 19 where version updates after release are generally
discouraged, especially in case of ABI change).
Hello,
Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet,
you have the earlier buggy version.
I do have pylint 1.0.0-2.fc19 and yet it fails with the same error
message. Nothing works, I had to disable make-lint call in Makefile to
continue development.
That is strange; I've confirmed on several machines that the -2.fc19
release fixes this bug.
If you run pylint on the following code, do you also get the unbound
method infer() error? (It's the upstream bug reproducer)
import collections
Point = collections.namedtuple('Point', ['x', 'y'])
p = Point(x=1.0, y=2.0)
print Area: %.1f % (p.x * p.y,)
Here is clean Fedora 19 VM, created few hours ago:
# rpm -q pylint python-astroid
pylint-1.0.0-2.fc19.noarch
python-astroid-1.0.0-2.fc19.noarch
# pylint test.py No config file found, using default configuration
* Module test
C: 1, 0: Missing module docstring (missing-docstring)
C: 3, 0: Invalid constant name p (invalid-name)
Traceback (most recent call last):
File /usr/bin/pylint, line 9, in module
load_entry_point('pylint==1.0.0', 'console_scripts', 'pylint')()
[...]
TypeError: unbound method infer() must be called with Tuple instance as
first argument (got InferenceContext instance instead)
Then I've ran 'yum upgrade' again, and
python-astroid-1.0.0-3.fc19.noarch was
installed which finally fixed the problem.
So the actual problem was split across both pylint and python-astroid.
That means ACK for your patches.
I'm glad that got cleared up. Thanks for the review, pushed to
master: a9225be0fa7bb834cd78609603300d81dcc4d3c9
ipa-3-3: 41c255a8e91942377f00d85ed93a0b7afb617266
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
Petr Viktorin wrote: On 09/06/2013 02:46 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). [...] Right, I just want to know why it was proposed to add 2 ACIs for every container. One for the container itself, one for the objects beneath it. I don't see a straightforward way to allow access to both in a single permission. (Currently, permissions need to be at $SUFFIX, so their subtrees are specified by target.) [...] Right. I'm not sure you need to grant read,search,compare to the container. Have you tested that? # Combining read rights I think (read, search, compare) should be exposed in permission objects as a single right. Or is there a reason to keep it split? Yes, they are separate for a reason. Using only search and compare isn't common, but it isn't unheard of either. For example, to be able to detect the presence of an attribute you can provide just the search permission. Wouldn't most users use the (read, search, compare) triple? It would lower our number of ACIs significantly if we do not have 3 permissions per each object. There is nothing to prevent an ACI from containing multiple permissions. I wasn't proposing that. But rolling these three logically into the same thing in IPA I think is short-sighted. See my other e-mail with my reasoning. I don't particularly care about this issue, though. # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This should be done when the time comes for a new version of the ldap-updater. [...] Well, my alarm bells are going off. This would require some significant review each and every time any object is updated. Consider how many times API.txt is overlooked, and it has no security implications. Consider how many times the ldif or update files were overlooked. API.txt is checked during every build, whereas ldif/update files not, and are tedious to check. We can of course add a similar file for ACIs, in fact I was planning to do so. Any changes can be then reviewed both in the source and (like now) in the resulting ldif. Also, the information would be in one place, rather than in ldif (which doesn't apply on upgrades) and in update files. I believe it would actually be better for security. The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened. I can't say I'm a fan of programmatic ACI generation. Well, I'm sure not going to write the ACIs for this feature by hand. It would help I could actually polish, commit and integrate the script that generates them. In my book, programmatic generation is much better than copy+paste. On the other hand, it becomes very easy to just rely on it and not closely examine the output. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
Petr Viktorin wrote: On 09/06/2013 03:59 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 09/06/2013 02:46 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). [...] Right, I just want to know why it was proposed to add 2 ACIs for every container. One for the container itself, one for the objects beneath it. I don't see a straightforward way to allow access to both in a single permission. (Currently, permissions need to be at $SUFFIX, so their subtrees are specified by target.) [...] Right. I'm not sure you need to grant read,search,compare to the container. Have you tested that? To be honest, I assumed some from the bug description. I'll test it. If it's not necessary there'll be one ACI per object type. [...] # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This should be done when the time comes for a new version of the ldap-updater. [...] Well, my alarm bells are going off. This would require some significant review each and every time any object is updated. Consider how many times API.txt is overlooked, and it has no security implications. Consider how many times the ldif or update files were overlooked. API.txt is checked during every build, whereas ldif/update files not, and are tedious to check. We can of course add a similar file for ACIs, in fact I was planning to do so. Any changes can be then reviewed both in the source and (like now) in the resulting ldif. Also, the information would be in one place, rather than in ldif (which doesn't apply on upgrades) and in update files. I believe it would actually be better for security. The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened. Good to know. Is it still the plan? Do I only need to change the update files? It would be my preference. It goes beyond only changing one set of files. The existing ldif that duplicate things need to be deprecated. We can't get to a zero-ldif install, but it can be reduced significantly. I can't say I'm a fan of programmatic ACI generation. Well, I'm sure not going to write the ACIs for this feature by hand. It would help I could actually polish, commit and integrate the script that generates them. In my book, programmatic generation is much better than copy+paste. On the other hand, it becomes very easy to just rely on it and not closely examine the output. That is a question of checking the changes. Frankly I don't see that much difference between not checking after updates and not checking after copy+pasting. If nothing, the existence of an ACI.txt should remind us that security is at stake. Also, if the objectclasses change this will alert us that ACIs need changing as well. Well, there was little copy+pasting before. The majority of the current ACIs were generated by permission-add. The difference is that ACI changes may be automatically spawned by an update to the plugin. Right now the risk is that attributes won't be added to a write list, so there is limited potential damage. It is just annoying. If instead it will potentially grant both read and write access the scope of harm grows. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 450 Fix redirection on deletion of last dns record entry
On 09/06/2013 02:30 PM, Petr Vobornik wrote: https://fedorahosted.org/freeipa/ticket/3907 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
On 09/06/2013 03:59 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 09/06/2013 02:46 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). [...] Right, I just want to know why it was proposed to add 2 ACIs for every container. One for the container itself, one for the objects beneath it. I don't see a straightforward way to allow access to both in a single permission. (Currently, permissions need to be at $SUFFIX, so their subtrees are specified by target.) [...] Right. I'm not sure you need to grant read,search,compare to the container. Have you tested that? To be honest, I assumed some from the bug description. I'll test it. If it's not necessary there'll be one ACI per object type. [...] # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This should be done when the time comes for a new version of the ldap-updater. [...] Well, my alarm bells are going off. This would require some significant review each and every time any object is updated. Consider how many times API.txt is overlooked, and it has no security implications. Consider how many times the ldif or update files were overlooked. API.txt is checked during every build, whereas ldif/update files not, and are tedious to check. We can of course add a similar file for ACIs, in fact I was planning to do so. Any changes can be then reviewed both in the source and (like now) in the resulting ldif. Also, the information would be in one place, rather than in ldif (which doesn't apply on upgrades) and in update files. I believe it would actually be better for security. The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened. Good to know. Is it still the plan? Do I only need to change the update files? I can't say I'm a fan of programmatic ACI generation. Well, I'm sure not going to write the ACIs for this feature by hand. It would help I could actually polish, commit and integrate the script that generates them. In my book, programmatic generation is much better than copy+paste. On the other hand, it becomes very easy to just rely on it and not closely examine the output. That is a question of checking the changes. Frankly I don't see that much difference between not checking after updates and not checking after copy+pasting. If nothing, the existence of an ACI.txt should remind us that security is at stake. Also, if the objectclasses change this will alert us that ACIs need changing as well. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
On 09/06/2013 10:11 AM, Petr Viktorin wrote: On 09/06/2013 03:59 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 09/06/2013 02:46 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). [...] Right, I just want to know why it was proposed to add 2 ACIs for every container. One for the container itself, one for the objects beneath it. I don't see a straightforward way to allow access to both in a single permission. (Currently, permissions need to be at $SUFFIX, so their subtrees are specified by target.) [...] Right. I'm not sure you need to grant read,search,compare to the container. Have you tested that? To be honest, I assumed some from the bug description. I'll test it. If it's not necessary there'll be one ACI per object type. [...] # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This should be done when the time comes for a new version of the ldap-updater. [...] Well, my alarm bells are going off. This would require some significant review each and every time any object is updated. Consider how many times API.txt is overlooked, and it has no security implications. Consider how many times the ldif or update files were overlooked. API.txt is checked during every build, whereas ldif/update files not, and are tedious to check. We can of course add a similar file for ACIs, in fact I was planning to do so. Any changes can be then reviewed both in the source and (like now) in the resulting ldif. Also, the information would be in one place, rather than in ldif (which doesn't apply on upgrades) and in update files. I believe it would actually be better for security. The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened. Good to know. Is it still the plan? Do I only need to change the update files? I can't say I'm a fan of programmatic ACI generation. Well, I'm sure not going to write the ACIs for this feature by hand. It would help I could actually polish, commit and integrate the script that generates them. In my book, programmatic generation is much better than copy+paste. On the other hand, it becomes very easy to just rely on it and not closely examine the output. That is a question of checking the changes. Frankly I don't see that much difference between not checking after updates and not checking after copy+pasting. If nothing, the existence of an ACI.txt should remind us that security is at stake. Also, if the objectclasses change this will alert us that ACIs need changing as well. We probably can add some sort of a check to a patch apply command that if a file that does ACI part is added or modified in a patch and the corresponding ACI.txt file is not updated the patch apply operation would abort. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Notes and questions for fine-grained read permissions
On 09/06/2013 04:41 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 09/06/2013 03:59 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 09/06/2013 02:46 PM, Rob Crittenden wrote: Martin Kosek wrote: On 09/05/2013 07:48 PM, Rob Crittenden wrote: Petr Viktorin wrote: [...] # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This should be done when the time comes for a new version of the ldap-updater. [...] Well, my alarm bells are going off. This would require some significant review each and every time any object is updated. Consider how many times API.txt is overlooked, and it has no security implications. Consider how many times the ldif or update files were overlooked. API.txt is checked during every build, whereas ldif/update files not, and are tedious to check. We can of course add a similar file for ACIs, in fact I was planning to do so. Any changes can be then reviewed both in the source and (like now) in the resulting ldif. Also, the information would be in one place, rather than in ldif (which doesn't apply on upgrades) and in update files. I believe it would actually be better for security. The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened. Good to know. Is it still the plan? Do I only need to change the update files? It would be my preference. It goes beyond only changing one set of files. The existing ldif that duplicate things need to be deprecated. We can't get to a zero-ldif install, but it can be reduced significantly. Thanks, I'll keep it in mind. I can't say I'm a fan of programmatic ACI generation. Well, I'm sure not going to write the ACIs for this feature by hand. It would help I could actually polish, commit and integrate the script that generates them. In my book, programmatic generation is much better than copy+paste. On the other hand, it becomes very easy to just rely on it and not closely examine the output. That is a question of checking the changes. Frankly I don't see that much difference between not checking after updates and not checking after copy+pasting. If nothing, the existence of an ACI.txt should remind us that security is at stake. Also, if the objectclasses change this will alert us that ACIs need changing as well. Well, there was little copy+pasting before. The majority of the current ACIs were generated by permission-add. The difference is that ACI changes may be automatically spawned by an update to the plugin. Right now the risk is that attributes won't be added to a write list, so there is limited potential damage. It is just annoying. If instead it will potentially grant both read and write access the scope of harm grows. We have two cases here: 1. A core IPA plugin is changed. In this case the change is reflected in our ACI.txt file and vetted by developers. 2. A third-party plugin is changed. Currently third-party plugins needed to either change core IPA update files (which I doubt plugin authors will want to do), or have their own mechanism for granting permissions (yes, plugins can be bent to do anything, including installing their own updates). It would actually be more secure if we provided a tested mechanism to them. Also, read ACIs that would get deployed on install and then *only* changed by the user would mean that we can either: - Never add new hidden/password attributes, for (targetattr != ...), or - Never add new normal attributes, for (targetattr == ...), - Or (as we IMO do now) assume admins will manually update anything they have changed. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] IPA-CLIENT: NSS test needs to check against the domain name
On 09/05/2013 07:34 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In situations where the FreeIPA server is configured with different domain and realm values, we will fail to test for the admin account in the ipa-client-install script. With this patch, we will correctly run 'getent passwd admin@DOMAIN' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIowI8ACgkQeiVVYja6o6ORiwCgnX1uVtWTktYpKdrVxuVTyQjZ WCsAn0ULhTR0TsfcCsEpknVwgkAN0d7F =KpH4 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel You should also replace 'cli_realm' with 'cli_domain' in the 'if not found:' block that follows. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
