rpms
/
ipa
7
0
Fork 0
Code Issues Pull Requests Releases Activity

Remove old patches 

- Resolves: rhbz#2015608 - [Rebase] Rebase ipa to latest 4.9.x release RHEL9
This commit is contained in:
Florence Blanc-Renaud 2021-12-03 09:34:04 +01:00
parent 848d623257
commit b28fca276d
10 changed files with 0 additions and 539 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
0051-selinux-policy-allow-custodia-to-access-proc-cpuinfo.patch
View File

@ -1,41 +0,0 @@
From 07e2bf732f54f936cccc4e0c7b468d77f97e911a Mon Sep 17 00:00:00 2001
From: Florence Blanc-Renaud <flo@redhat.com>
Date: Mon, 30 Aug 2021 18:40:24 +0200
Subject: [PATCH] selinux policy: allow custodia to access /proc/cpuinfo
On aarch64, custodia creates AVC when accessing /proc/cpuinfo.
According to gcrypt manual
(https://gnupg.org/documentation/manuals/gcrypt/Configuration.html),
/proc/cpuinfo is used on ARM architecture to read the hardware
capabilities of the CPU. This explains why the issue happens only
on aarch64.
audit2allow suggests to add the following:
allow ipa_custodia_t proc_t:file { getattr open read };
but this policy would be too broad. Instead, the patch is using
the interface kernel_read_system_state.
Fixes: https://pagure.io/freeipa/issue/8972
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
---
selinux/ipa.te | 1 +
1 file changed, 1 insertion(+)
diff --git a/selinux/ipa.te b/selinux/ipa.te
index 68e10941951ac391fda7854d1403558c069dad46..7492fca04d4f0d031ecd83871078247d73cc87e0 100644
--- a/selinux/ipa.te
+++ b/selinux/ipa.te
@@ -364,6 +364,7 @@ files_tmp_filetrans(ipa_custodia_t, ipa_custodia_tmp_t, { dir file })
kernel_dgram_send(ipa_custodia_t)
kernel_read_network_state(ipa_custodia_t)
+kernel_read_system_state(ipa_custodia_t)
auth_read_passwd(ipa_custodia_t)
--
2.31.1

46
0052-extdom-return-LDAP_NO_SUCH_OBJECT-if-domains-differ.patch
View File

@ -1,46 +0,0 @@
From 4fca95751ca32a1ed16a6d8a4e557c5799ec5c78 Mon Sep 17 00:00:00 2001
From: Sumit Bose <sbose@redhat.com>
Date: Wed, 25 Aug 2021 17:10:29 +0200
Subject: [PATCH] extdom: return LDAP_NO_SUCH_OBJECT if domains differ
If a client sends a request to lookup an object from a given trusted
domain by UID or GID and an object with matching ID is only found in a
different domain the extdom should return LDAP_NO_SUCH_OBJECT to
indicate to the client that the requested ID does not exists in the
given domain.
Resolves: https://pagure.io/freeipa/issue/8965
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
---
.../ipa-extdom-extop/ipa_extdom_common.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index 5d97ff6137d9d660f6121f468261c6878a9aa12a..6f646b9f49ef31e1872e87640c524db972e53b6d 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -542,7 +542,9 @@ int pack_ber_user(struct ipa_extdom_ctx *ctx,
if (strcasecmp(locat+1, domain_name) == 0 ) {
locat[0] = '\0';
} else {
- ret = LDAP_INVALID_SYNTAX;
+ /* The found object is from a different domain than requested,
+ * that means it does not exist in the requested domain */
+ ret = LDAP_NO_SUCH_OBJECT;
goto done;
}
}
@@ -655,7 +657,9 @@ int pack_ber_group(enum response_types response_type,
if (strcasecmp(locat+1, domain_name) == 0 ) {
locat[0] = '\0';
} else {
- ret = LDAP_INVALID_SYNTAX;
+ /* The found object is from a different domain than requested,
+ * that means it does not exist in the requested domain */
+ ret = LDAP_NO_SUCH_OBJECT;
goto done;
}
}
--
2.31.1

35
0053-subid-subid-match-display-the-owner-s-ID-not-DN.patch
View File

@ -1,35 +0,0 @@
From 4785a90946ec694ccc082f062b2181b23c7099e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fran=C3=A7ois=20Cami?= <fcami@redhat.com>
Date: Thu, 2 Sep 2021 16:17:01 +0200
Subject: [PATCH] subid: subid-match: display the owner's ID not DN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Previously, the subid-match command would output the full
DN of the owner of the matched range.
With this change, the UID of the owner is displayed, just like
for other subid- commands.
Fixes: https://github.com/freeipa/freeipa/pull/6001
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
---
ipaserver/plugins/subid.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/ipaserver/plugins/subid.py b/ipaserver/plugins/subid.py
index 440f24ee627f0736100f63026158c564b04520c2..132c85c7f198217ba70f2332306ee2550be86035 100644
--- a/ipaserver/plugins/subid.py
+++ b/ipaserver/plugins/subid.py
@@ -524,6 +524,7 @@ class subid_match(subid_find):
osubuid = options["ipasubuidnumber"]
new_entries = []
for entry in entries:
+ self.obj.convert_owner(entry, options)
esubuid = int(entry.single_value["ipasubuidnumber"])
esubcount = int(entry.single_value["ipasubuidcount"])
minsubuid = esubuid
--
2.31.1

37
0054-migrate-ds-workaround-to-detect-compat-tree.patch
View File

@ -1,37 +0,0 @@
From 3c4f9e7347965ff9a887147df34e720224ffa7cc Mon Sep 17 00:00:00 2001
From: Florence Blanc-Renaud <flo@redhat.com>
Date: Tue, 7 Sep 2021 17:06:53 +0200
Subject: [PATCH] migrate-ds: workaround to detect compat tree
Migrate-ds needs to check if compat tree is enabled before
migrating users and groups. The check is doing a base
search on cn=compat,$SUFFIX and considers the compat tree
enabled when the entry exists.
Due to a bug in slapi-nis, the base search may return NotFound
even though the compat tree is enabled. The workaround is to
perform a base search on cn=users,cn=compat,$SUFFIX instead.
Fixes: https://pagure.io/freeipa/issue/8984
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
---
ipaserver/plugins/migration.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ipaserver/plugins/migration.py b/ipaserver/plugins/migration.py
index db5241915497b14a12ed2c33003e1c4fc1a5369f..6ee205fc836a463ac250baa6131e43acb0c00efa 100644
--- a/ipaserver/plugins/migration.py
+++ b/ipaserver/plugins/migration.py
@@ -922,7 +922,8 @@ migration process might be incomplete\n''')
# check whether the compat plugin is enabled
if not options.get('compat'):
try:
- ldap.get_entry(DN(('cn', 'compat'), (api.env.basedn)))
+ ldap.get_entry(DN(('cn', 'users'), ('cn', 'compat'),
+ (api.env.basedn)))
return dict(result={}, failed={}, enabled=True, compat=False)
except errors.NotFound:
pass
--
2.31.1

60
0055-Don-t-store-entries-with-a-usercertificate-in-the-LD.patch
View File

@ -1,60 +0,0 @@
From be1e3bbfc13aff9a583108376f245b81cc3666fb Mon Sep 17 00:00:00 2001
From: Rob Crittenden <rcritten@redhat.com>
Date: Thu, 9 Sep 2021 15:26:55 -0400
Subject: [PATCH] Don't store entries with a usercertificate in the LDAP cache
usercertificate often has a subclass and both the plain and
subclassed (binary) values are queried. I'm concerned that
they are used more or less interchangably in places so not
caching these entries is the safest path forward for now until
we can dedicate the time to find all usages, determine their
safety and/or perhaps handle this gracefully within the cache
now.
What we see in this bug is that usercertificate;binary holds the
first certificate value but a user-mod is done with
setattr usercertificate=<new_cert>. Since there is no
usercertificate value (remember, it's usercertificate;binary)
a replace is done and 389-ds wipes the existing value as we've
asked it to.
I'm not comfortable with simply treating them the same because
in LDAP they are not.
https://pagure.io/freeipa/issue/8986
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
---
ipapython/ipaldap.py | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/ipapython/ipaldap.py b/ipapython/ipaldap.py
index f94b784d680f33d026e4d56ec8627d4d2ab87931..ced8f1bd66dc8f1f5c206677d2725d1e72b489f9 100644
--- a/ipapython/ipaldap.py
+++ b/ipapython/ipaldap.py
@@ -1821,9 +1821,17 @@ class LDAPCache(LDAPClient):
entry=None, exception=None):
# idnsname - caching prevents delete when mod value to None
# cospriority - in a Class of Service object, uncacheable
- # TODO - usercertificate was banned at one point and I don't remember
- # why...
- BANNED_ATTRS = {'idnsname', 'cospriority'}
+ # usercertificate* - caching subtypes is tricky, trade less
+ # complexity for performance
+ #
+ # TODO: teach the cache about subtypes
+
+ BANNED_ATTRS = {
+ 'idnsname',
+ 'cospriority',
+ 'usercertificate',
+ 'usercertificate;binary'
+ }
if not self._enable_cache:
return
--
2.31.1

68
0056-ipatests-Test-that-a-user-can-be-issued-multiple-cer.patch
View File

@ -1,68 +0,0 @@
From 86588640137562b2016fdb0f91142d00bc38e54a Mon Sep 17 00:00:00 2001
From: Rob Crittenden <rcritten@redhat.com>
Date: Fri, 10 Sep 2021 09:01:48 -0400
Subject: [PATCH] ipatests: Test that a user can be issued multiple
certificates
Prevent regressions in the LDAP cache layer that caused newly
issued certificates to overwrite existing ones.
https://pagure.io/freeipa/issue/8986
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
---
ipatests/test_integration/test_cert.py | 29 ++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/ipatests/test_integration/test_cert.py b/ipatests/test_integration/test_cert.py
index 7d51b76ee347237450b7484cf48c2e6a1bed7f7d..b4e85eadcf41212fdd16f0f3aa130a916b5019fa 100644
--- a/ipatests/test_integration/test_cert.py
+++ b/ipatests/test_integration/test_cert.py
@@ -16,6 +16,7 @@ import string
import time
from ipaplatform.paths import paths
+from ipapython.dn import DN
from cryptography import x509
from cryptography.x509.oid import ExtensionOID
from cryptography.hazmat.backends import default_backend
@@ -183,6 +184,34 @@ class TestInstallMasterClient(IntegrationTest):
)
assert "profile: caServerCert" in result.stdout_text
+ def test_multiple_user_certificates(self):
+ """Test that a user may be issued multiple certificates"""
+ ldap = self.master.ldap_connect()
+
+ user = 'user1'
+
+ tasks.kinit_admin(self.master)
+ tasks.user_add(self.master, user)
+
+ for id in (0,1):
+ csr_file = f'{id}.csr'
+ key_file = f'{id}.key'
+ cert_file = f'{id}.crt'
+ openssl_cmd = [
+ 'openssl', 'req', '-newkey', 'rsa:2048', '-keyout', key_file,
+ '-nodes', '-out', csr_file, '-subj', '/CN=' + user]
+ self.master.run_command(openssl_cmd)
+
+ cmd_args = ['ipa', 'cert-request', '--principal', user,
+ '--certificate-out', cert_file, csr_file]
+ self.master.run_command(cmd_args)
+
+ # easier to count by pulling the LDAP entry
+ entry = ldap.get_entry(DN(('uid', user), ('cn', 'users'),
+ ('cn', 'accounts'), self.master.domain.basedn))
+
+ assert len(entry.get('usercertificate')) == 2
+
@pytest.fixture
def test_subca_certs(self):
"""
--
2.31.1

56
0057-Parse-getStatus-as-JSON-not-XML.patch
View File

@ -1,56 +0,0 @@
From 7fb95cc638b1c9b7f2e9a67dba859ef8126f2c5f Mon Sep 17 00:00:00 2001
From: Chris Kelley <ckelley@redhat.com>
Date: Tue, 27 Jul 2021 21:57:26 +0100
Subject: [PATCH] Parse getStatus as JSON not XML
On dogtagpki/pki master XML is being replaced by JSON, getStatus will
return JSON in PKI 11.0+
The PR for dogtagpki/pki that makes this change necessary is:
https://github.com/dogtagpki/pki/pull/3674
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
---
install/tools/ipa-pki-wait-running.in | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/install/tools/ipa-pki-wait-running.in b/install/tools/ipa-pki-wait-running.in
index 4f0f2f34a7b0a43210676e7fd50e7029e798f301..9ca6e974e55a4d68afd06e1d9c7b67c5f926e48c 100644
--- a/install/tools/ipa-pki-wait-running.in
+++ b/install/tools/ipa-pki-wait-running.in
@@ -13,6 +13,7 @@ import logging
import sys
import time
from xml.etree import ElementTree
+import json
from ipalib import api
from ipaplatform.paths import paths
@@ -74,10 +75,19 @@ def get_status(conn, timeout):
"""
client = SystemStatusClient(conn)
response = client.get_status(timeout=timeout)
- root = ElementTree.fromstring(response)
- status = root.findtext("Status")
- error = root.findtext("Error")
- logging.debug("Got status '%s', error '%s'", status, error)
+ status = None
+ error = None
+ try:
+ json_response = json.loads(response)
+ status = json_response['Response']['Status']
+ except KeyError as e:
+ error = repr(e)
+ except json.JSONDecodeError:
+ logger.debug("Response is not valid JSON, try XML")
+ root = ElementTree.fromstring(response)
+ status = root.findtext("Status")
+ error = root.findtext("Error")
+ logger.debug("Got status '%s', error '%s'", status, error)
return status, error
--
2.31.1

79
0058-Parse-cert-chain-as-JSON-not-XML.patch
View File

@ -1,79 +0,0 @@
From 40f76a53f78267b4d2b890defa3e4f7d27fdfb7a Mon Sep 17 00:00:00 2001
From: Chris Kelley <ckelley@redhat.com>
Date: Thu, 5 Aug 2021 12:00:15 +0100
Subject: [PATCH] Parse cert chain as JSON not XML
On dogtagpki/pki master XML is being replaced by JSON in PKI 11.0+
The PR for dogtagpki/pki that makes this change necessary is:
https://github.com/dogtagpki/pki/pull/3677
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
---
ipapython/dogtag.py | 28 +++++++++++++++++++---------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py
index 0503938fb9783d397cc7366339bb9fab48033985..8f0f0473ae313edb17e10de8b2ca7f43f231e706 100644
--- a/ipapython/dogtag.py
+++ b/ipapython/dogtag.py
@@ -20,6 +20,7 @@
import collections
import gzip
import io
+import json
import logging
from urllib.parse import urlencode
import xml.dom.minidom
@@ -100,6 +101,10 @@ def get_ca_certchain(ca_host=None):
data = res.read()
conn.close()
try:
+ doc = json.loads(data)
+ chain = doc['Response']['ChainBase64']
+ except (json.JSONDecodeError, KeyError):
+ logger.debug("Response is not valid JSON, try XML")
doc = xml.dom.minidom.parseString(data)
try:
item_node = doc.getElementsByTagName("ChainBase64")
@@ -107,9 +112,9 @@ def get_ca_certchain(ca_host=None):
except IndexError:
raise error_from_xml(
doc, _("Retrieving CA cert chain failed: %s"))
- finally:
- if doc:
- doc.unlink()
+ finally:
+ if doc:
+ doc.unlink()
else:
raise errors.RemoteRetrieveError(
reason=_("request failed with HTTP status %d") % res.status)
@@ -118,13 +123,18 @@ def get_ca_certchain(ca_host=None):
def _parse_ca_status(body):
- doc = xml.dom.minidom.parseString(body)
try:
- item_node = doc.getElementsByTagName("XMLResponse")[0]
- item_node = item_node.getElementsByTagName("Status")[0]
- return item_node.childNodes[0].data
- except IndexError:
- raise error_from_xml(doc, _("Retrieving CA status failed: %s"))
+ doc = json.loads(body)
+ return doc['Response']['Status']
+ except (json.JSONDecodeError, KeyError):
+ logger.debug("Response is not valid JSON, try XML")
+ doc = xml.dom.minidom.parseString(body)
+ try:
+ item_node = doc.getElementsByTagName("XMLResponse")[0]
+ item_node = item_node.getElementsByTagName("Status")[0]
+ return item_node.childNodes[0].data
+ except IndexError:
+ raise error_from_xml(doc, _("Retrieving CA status failed: %s"))
def ca_status(ca_host=None):
--
2.31.1

84
0059-Specify-PKI-installation-log-paths.patch
View File

@ -1,84 +0,0 @@
From 5abf1bc79f8b32c6638ff98fbe2e4a8dec9a5010 Mon Sep 17 00:00:00 2001
From: "Endi S. Dewata" <edewata@redhat.com>
Date: Thu, 12 Aug 2021 13:26:42 -0500
Subject: [PATCH] Specify PKI installation log paths
The DogtagInstance.spawn_instance() and uninstall() have
been modified to specify the paths of PKI installation
logs using --log-file option on PKI 11.0.0 or later.
This allows IPA to have a full control over the log files
instead of relying on PKI's default log files.
Fixes: https://pagure.io/freeipa/issue/8966
Signed-off-by: Endi Sukma Dewata <edewata@redhat.com>
---
ipaserver/install/dogtaginstance.py | 35 ++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/ipaserver/install/dogtaginstance.py b/ipaserver/install/dogtaginstance.py
index 644acd4eacea22f41a7cd36b54553d6d7cd22690..0d9aebb542f242b81315edd016699697f2fc4091 100644
--- a/ipaserver/install/dogtaginstance.py
+++ b/ipaserver/install/dogtaginstance.py
@@ -36,8 +36,10 @@ from configparser import DEFAULTSECT, ConfigParser, RawConfigParser
import six
+import pki
from pki.client import PKIConnection
import pki.system
+import pki.util
from ipalib import api, errors, x509
from ipalib.install import certmonger
@@ -202,6 +204,18 @@ class DogtagInstance(service.Service):
"-f", cfg_file,
"--debug"]
+ # specify --log-file <path> on PKI 11.0.0 or later
+
+ pki_version = pki.util.Version(pki.specification_version())
+ if pki_version >= pki.util.Version("11.0.0"):
+ timestamp = time.strftime(
+ "%Y%m%d%H%M%S",
+ time.localtime(time.time()))
+ log_file = os.path.join(
+ paths.VAR_LOG_PKI_DIR,
+ "pki-%s-spawn.%s.log" % (self.subsystem.lower(), timestamp))
+ args.extend(["--log-file", log_file])
+
with open(cfg_file) as f:
logger.debug(
'Contents of pkispawn configuration file (%s):\n%s',
@@ -290,10 +304,25 @@ class DogtagInstance(service.Service):
if self.is_installed():
self.print_msg("Unconfiguring %s" % self.subsystem)
+ args = [paths.PKIDESTROY,
+ "-i", "pki-tomcat",
+ "-s", self.subsystem]
+
+ # specify --log-file <path> on PKI 11.0.0 or later
+
+ pki_version = pki.util.Version(pki.specification_version())
+ if pki_version >= pki.util.Version("11.0.0"):
+ timestamp = time.strftime(
+ "%Y%m%d%H%M%S",
+ time.localtime(time.time()))
+ log_file = os.path.join(
+ paths.VAR_LOG_PKI_DIR,
+ "pki-%s-destroy.%s.log" % (self.subsystem.lower(), timestamp))
+ args.extend(["--log-file", log_file])
+
try:
- ipautil.run([paths.PKIDESTROY,
- "-i", 'pki-tomcat',
- "-s", self.subsystem])
+ ipautil.run(args)
+
except ipautil.CalledProcessError as e:
logger.critical("failed to uninstall %s instance %s",
self.subsystem, e)
--
2.31.1

33
0060-Make-Dogtag-return-XML-for-ipa-cert-find.patch
View File

@ -1,33 +0,0 @@
From d43b513927d6dd0a12464dd24287ce40ccaf33e4 Mon Sep 17 00:00:00 2001
From: Chris Kelley <ckelley@redhat.com>
Date: Fri, 10 Sep 2021 16:47:22 +0100
Subject: [PATCH] Make Dogtag return XML for ipa cert-find
Using JSON by default within Dogtag appears to cause ipa cert-find to
return JSON, when the request was made with XML. We can request that XML
is returned as before by specifying so in the request header.
Fixes: https://pagure.io/freeipa/issue/8980
Signed-off-by: Chris Kelley <ckelley@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
---
ipaserver/plugins/dogtag.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py
index be2e4bb4e2a1b96c1bff6056da30c704c36789f3..b4feddfac19a4c5659d29bf7b6f5fd9b1247524c 100644
--- a/ipaserver/plugins/dogtag.py
+++ b/ipaserver/plugins/dogtag.py
@@ -1832,7 +1832,8 @@ class ra(rabase.rabase, RestClient):
method='POST',
headers={'Accept-Encoding': 'gzip, deflate',
'User-Agent': 'IPA',
- 'Content-Type': 'application/xml'},
+ 'Content-Type': 'application/xml',
+ 'Accept': 'application/xml'},
body=payload
)
--
2.31.1