Re: [Freeipa-devel] Managed permission versioning
Simo Sorce wrote:
On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
I would like to discuss more on the managed read permissions upgrades [1].
Right now, we simply merge an old permission with the new one, making sure that
we only add new attributes instead of just replacing them, to prevent a managed
permission to be spoiled by a lower FreeIPA server version which runs an
updates.
I was thinking about it some more and seems to me we could run in problems when
we for example find out that some permission is too relaxed and we want to
remove some default attribute. Or when we want to update the permission filter.
Or when object has anonymous and authenticated permission and we want to move
attribute from anonymous to authenticated permission.
Changes like this can happen, especially in the first release and we do not
have means to address them. What about simply versioning the permissions as we
do with our configs? I.e.
1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:
managed_permissions = {
'System: Read Roles': {
'version': 1,
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'permission',
'ipapermright': {'read', 'search', 'compare'},
'ipapermdefaultattr': {
'businesscategory', 'cn', 'description', 'member',
'memberof',
'o', 'objectclass', 'ou', 'owner', 'seealso',
},
'default_privileges': {'RBAC Readers'},
},
}
3) Modify updater to only update the permission if it's version is higher than
the one in LDAP. In that case, it should simply replace the managed permission
attributes with the new one, no merging (except the attributes that we allow
users to change).
When we want to change the permission, we simply do the changes, bump the
version and we are done and we do not need to fear some older FreeIPA will
overwrite it. That of course assumes that the versioning would be available
from FreeIPA 4.0.
Makes sense?
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
Uhmm, yes, and no, let me explain.
What you say *does* make sense, but you are being too focused :-)
The upgrade issue is not limited to permissions, but affects everything.
I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
script. if this number is higher than what we know we immediately stop
and do not perform updates that affect anything but our own server data.
This will protect the whole tree from unintentional changes caused by an
older replica.
Makes sense ?
This could lead to new features not working. Those features would rely
on containers, ACIs, etc to exist but they wouldn't if the updates
aren't run.
Sorry I don't get this, if they are new features, then the version will
be older and the update *will* run and at the end raise the version.
We just prevent old updates from running and current updates from
running multiple times, for the shared tree.
Do we depend on having updates run multiple times for the data in the
shared tree ?
Note that I am not saying that all updates should stop, any update for
cn=config would still need to be run on each server (although setting a
version there too would probably be beneficial).
Ok, so the update runs, adds data, which gets replicated out to
potentially old servers, and we're at the place you said we wouldn't be.
I am not following you, the aim here is not to avoid replicating new
data to old server, the aim is that if you update the rpm of an older
replica and the rpm runs the ldap updater with the *old* code, we do not
end up with that updater *undoing* what a more recent update did.
Updates are all loaded and sorted so that all changes to a given DN
should be applied at once, so it isn't like applying a old update and a
new update are two separate operations. In fact, it would likely be a
no-op in the case that they have already been applied.
Do you have any examples to clarify your concerns? I'm not following you.
Sure at some point version freeipa version 4.2 is released and it has an
update that changes a default object so that now attribute 'foo' is
added, this is done through the updater.
Later on we release freeipa version 5.0 and we realize we will have
again to remove attribute 'foo' because we never really needed it, plus
if it is still there it causes issues to new feature XYZ.
The admin installs 5.0 and all are happy, then a week later he runs a
simply yum update on th eolder replicas still running 4.2 and 4.2.1 is
available, and gets installed and ... bah the 4.2.1 updater re-adds
attribute 'foo' back ... and 5.0 servers are now broken.
If we have an
Re: [Freeipa-devel] Managed permission versioning
On Mon, 2014-04-21 at 08:39 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
I would like to discuss more on the managed read permissions upgrades
[1].
Right now, we simply merge an old permission with the new one, making
sure that
we only add new attributes instead of just replacing them, to prevent
a managed
permission to be spoiled by a lower FreeIPA server version which runs
an updates.
I was thinking about it some more and seems to me we could run in
problems when
we for example find out that some permission is too relaxed and we
want to
remove some default attribute. Or when we want to update the
permission filter.
Or when object has anonymous and authenticated permission and we want
to move
attribute from anonymous to authenticated permission.
Changes like this can happen, especially in the first release and we
do not
have means to address them. What about simply versioning the
permissions as we
do with our configs? I.e.
1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:
managed_permissions = {
'System: Read Roles': {
'version': 1,
'replaces_global_anonymous_aci': True,
'ipapermbindruletype': 'permission',
'ipapermright': {'read', 'search', 'compare'},
'ipapermdefaultattr': {
'businesscategory', 'cn', 'description', 'member',
'memberof',
'o', 'objectclass', 'ou', 'owner', 'seealso',
},
'default_privileges': {'RBAC Readers'},
},
}
3) Modify updater to only update the permission if it's version is
higher than
the one in LDAP. In that case, it should simply replace the managed
permission
attributes with the new one, no merging (except the attributes that we
allow
users to change).
When we want to change the permission, we simply do the changes, bump
the
version and we are done and we do not need to fear some older FreeIPA
will
overwrite it. That of course assumes that the versioning would be
available
from FreeIPA 4.0.
Makes sense?
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
Uhmm, yes, and no, let me explain.
What you say *does* make sense, but you are being too focused :-)
The upgrade issue is not limited to permissions, but affects everything.
I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
script. if this number is higher than what we know we immediately stop
and do not perform updates that affect anything but our own server data.
This will protect the whole tree from unintentional changes caused by an
older replica.
Makes sense ?
This could lead to new features not working. Those features would rely
on containers, ACIs, etc to exist but they wouldn't if the updates
aren't run.
Sorry I don't get this, if they are new features, then the version will
be older and the update *will* run and at the end raise the version.
We just prevent old updates from running and current updates from
running multiple times, for the shared tree.
Do we depend on having updates run multiple times for the data in the
shared tree ?
Note that I am not saying that all updates should stop, any update for
cn=config would still need to be run on each server (although setting a
version there too would probably be beneficial).
Ok, so the update runs, adds data, which gets replicated out to
potentially old servers, and we're at the place you said we wouldn't be.
I am not following you, the aim here is not to avoid replicating new
data to old server, the aim is that if you update the rpm of an older
replica and the rpm runs the ldap updater with the *old* code, we do not
end up with that updater *undoing* what a more recent update did.
Updates are all loaded and sorted so that all changes to a given DN
should be applied at once, so it isn't like applying a old update and a
new update are two separate operations. In fact, it would likely be a
no-op in the case that they have already been applied.
Do you have any examples to clarify your concerns? I'm not following you.
Sure at some point version freeipa version 4.2 is released and it has an
update that changes a default object so that now attribute 'foo' is
added, this is done through the updater.
Later on we release freeipa version 5.0 and we realize we will have
again to remove attribute 'foo' because we never really needed it, plus
if it is still there it causes issues to new feature XYZ.
Re: [Freeipa-devel] Client compatibility article
Martin Kosek wrote: On 04/18/2014 01:40 PM, Petr Viktorin wrote: On 04/18/2014 01:29 PM, Martin Kosek wrote: On 04/18/2014 10:52 AM, Petr Viktorin wrote: On 04/18/2014 10:33 AM, Martin Kosek wrote: FYI - I saw numerous questions about ipa tool backward compatibility (the most recent is https://bugzilla.redhat.com/show_bug.cgi?id=1089015), so I created a section about it: http://www.freeipa.org/page/Client#Compatibility and added it to FAQ. Looking for the version in an internal module doesn't strike me as the best method. Especially if you have to add a warning to not change the file. (And changing it is just discouraged? Really?) I specifically added the warning about changing it because this is what the user in the Bugzilla did and I really want to discourage people doing that. If you have better wording in mind, please feel free to improve :-) I'd rather not mention it at all; saying here is a stupid thing you really shouldn't do will just make people do it. Umm, ok, makes sense :) I removed the warning. As another data pint, ipa ping will show the server version: # rpm -q freeipa-client freeipa-client-3.3.90GIT6044229-0.fc20.x86_64 # ipa ping -- IPA server version 3.0.0. API version 2.49 -- # ipa user-show admin ipa: ERROR: 2.81 client incompatible with 2.49 server at ... rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
Ade Lee wrote: Attached is a patch that adds the script ipa-drm-install. This script will be used to install a drm in any ipa server that contains a Dogtag CA. Right now, it works for a master. I will add logic in a subsequent patch to allow the installation on a replica using the same script. This patch is to applied on top of the previous one. So, patch 2 and then patch 3. I will create a patch to address the issues mentioned below, as well as some other formatting issues reported by pycharm. I think the ipa-dns-install change should be committed separately. It is surprising that pylint didn't catch that. Please a comment to find_subject_base() that it can only be executed AFTER the ipa server is configured, the api is initialized elsewhere and requires that a ticket already have been acquired. I understand why this call is here, we just need to be clear it is used post-install and requires some pre-setup by the caller. Need a man page for ipa-drm-install. Running the uninstaller completes, then proceeds to install the DRM. I don't think the certmonger warnings apply because some of the certs are duplicates of the CA certs, so if you untracked them you would eventually end up not renewing the subsystem certs and your clone CA would fail. nit, some trailing white space after add_record_to_hosts() The tool failed to add a DRM in my test. The debug log doesn't seem to contain anything interesting at all. The drm install log contained: 2014-04-21T19:00:44Z DEBUG Starting external process 2014-04-21T19:00:44Z DEBUG args=/usr/sbin/pkispawn -s KRA -f /tmp/tmpWcj8rJ 2014-04-21T19:01:09Z DEBUG Process finished, return code=1 2014-04-21T19:01:09Z DEBUG stdout=Loading deployment configuration from /tmp/tmpWcj8rJ. Installing KRA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/kra/deployment.cfg. Installation failed. 2014-04-21T19:01:09Z DEBUG stderr= 2014-04-21T19:01:09Z CRITICAL failed to configure KRA instance Command '/usr/sbin/pkispawn -s KRA -f /tmp/tmpWcj8rJ' returned non-zero exit status 1 Thanks, Ade On Tue, 2014-04-15 at 11:41 -0400, Rob Crittenden wrote: Ade Lee wrote: Attached a new patch to address some of the concerns below, specifically I created a new base class DogtagInstance, in which much of the common CA/KRA code is placed. I'm sure we could go further in reducing duplication, and I'm open to further suggestions and refinements. I did not tackle the packaging and spec file dependencies, because I'd like some clearer direction on how we want to proceed here. In any case, I think the splitting of the ipa packages into ca and possibly kra packages should be a separate patch. As before, with this patch you can: - install a ca and drm using ipa-server-install - install a ca and drm replica using ipa-replica-prepare hostname ipa-replica-install --setup-ca --setup-drm replia file You need to use a PKI build from the 10.2 (master) branch). One such build is given below: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo The terms KRA and DRM tend to be used interchangeably. Should we pick one? Need to bump the version number in install/conf/ipa-pki-proxy.conf so that upgrades get the new LocationMatch. ipa-replica-install still uses the if/then to set the value of enable_drm when it can be reduced like you did in ipa-server-install. In ipa-server-install you have an extra comment, probably left for yourself: # code to create drm here In dogtaginstance.py there are a few direct references to DRM in comments and output. cainstance.py doesn't need to override is_installed.py I also don't think you need the explicit definitions for enable, start_instance, etc. Those should be inherited from the DogtagInstance class, in both cainstance.py and drminstance.py. I think spawn_instance should take an option to add things to nolog in case there are server-independent things we don't want to log. I don't want to pile too much on, but it seems to me that if we are going to copy in default.conf then we can do away with realm_info completely and just use default.conf. Both would need to be supported for a while though. Martin, what do you think? I still have quite a bit of functional testing to go. I've only installed a fresh standalone master. Still need to do upgrade and replication testing. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH][DOC] Sometimes users set bad uid ranges
Hello, Patch for the following ticket to add note in documentation about bad uid ranges: https://fedorahosted.org/freeipa/ticket/2090 Thanks, Gabe From ad9af09ef2250c497d75a53846539328df865578 Mon Sep 17 00:00:00 2001 From: Gabe redhatri...@gmail.com Date: Mon, 21 Apr 2014 17:13:13 -0600 Subject: [PATCH] [DOC] Sometimes users set bad uid ranges https://fedorahosted.org/freeipa/ticket/2090 --- src/user_guide/en-US/Users.xml | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/user_guide/en-US/Users.xml b/src/user_guide/en-US/Users.xml index a260855b8742b5738c4660beaa400c7e73666c6e..833274342f1651000a92c34620377d95050f 100644 --- a/src/user_guide/en-US/Users.xml +++ b/src/user_guide/en-US/Users.xml @@ -1053,7 +1053,18 @@ Disabling Plugin/screen range is depleted so that less than 100 IDs are available, it can contact one of the available servers for a new range allotment. A special extended operation splits the range in two, so that the original server and the replica each have half of the available range. /para - + note +titleNOTE/title +para + It is possible for an administrator to define an ID number range — which means that it is possible for an administrator to define a emphasisbad/emphasis range. +/para +para condition=fedora + OS; reserves all UID/GID numbers below 1000 for system use. SSSD treats all UID/GID numbers below 1000 as local system accounts. If an administrator sets the ID range to start at 500 to interact with a legacy application (for example), then user accounts assigned an ID number below 1000 will be unable to log in, because their user account is not recognized by SSSD. +/para +para condition=redhat + RHEL; reserves all UID/GID numbers below 1000 for system use. SSSD treats all UID/GID numbers below 1000 as local system accounts. If an administrator sets the ID range to start at 500 to interact with a legacy application (for example), then user accounts assigned an ID number below 1000 will be unable to log in, because their user account is not recognized by SSSD. +/para + /note /section section id=Assigning_UIDs_and_GIDs-Adding_New_Ranges -- 1.9.0 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
