andykimpe / rpms / 389-ds-base

Forked from rpms/389-ds-base 5 months ago
Clone
Blob Blame History Raw
From f6e1acdefc97aa0f808b622c6f6a3dc0a683d457 Mon Sep 17 00:00:00 2001
From: Mark Reynolds <mreynolds@redhat.com>
Date: Mon, 15 Apr 2019 11:23:46 -0400
Subject: [PATCH] Ticket 50053 - Subtree password policy overrides a
 user-defined password policy

Bug Description:

When an entry contains an attribute that is also defined by a cos definition
a specifier defines which values win: the real values that are in the entry or the
virtual values that are cos defined.
The specifier 'default' means that the real values are the winners (returned).
'operational-default' has the same behavior but just specify that the attribute
is operational.
The bug is that when real values exists, the 'operational-default' specifier
drops the real values in favor of the virtual ones.

Fix Description:

Change the test, so that real values are not kept for 'operation-default'
Note: the full routine cos_cache_query_attr looks quite messy and error prone
It would be nice to rewrite it when we have time

https://pagure.io/389-ds-base/issue/50053
---
 ldap/servers/plugins/cos/cos_cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ldap/servers/plugins/cos/cos_cache.c b/ldap/servers/plugins/cos/cos_cache.c
index 5e0cf1725..64c0441c4 100644
--- a/ldap/servers/plugins/cos/cos_cache.c
+++ b/ldap/servers/plugins/cos/cos_cache.c
@@ -2279,7 +2279,7 @@ cos_cache_query_attr(cos_cache *ptheCache, vattr_context *context, Slapi_Entry *
         /* now for the tests */
 
         /* would we be allowed to supply this attribute if we had one? */
-        if (entry_has_value && !pAttr->attr_override && !pAttr->attr_operational && !pAttr->attr_operational_default) {
+        if (entry_has_value && !pAttr->attr_override && !pAttr->attr_operational) {
             /* answer: no, move on to the next attribute */
             attr_index++;
             continue;
-- 
2.17.2