From patchwork Fri Dec 14 22:37:53 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever X-Patchwork-Id: 206578 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aserp1040.oracle.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by ozlabs.org (Postfix) with ESMTPS id B8D342C008F for ; Sat, 15 Dec 2012 09:38:05 +1100 (EST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBEMc200027349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Dec 2012 22:38:03 GMT Received: from oss.oracle.com (oss-external.oracle.com [137.254.96.51]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBEMc1Eo010845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 22:38:02 GMT Received: from localhost ([127.0.0.1] helo=oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1TjdtJ-0005tp-Q4; Fri, 14 Dec 2012 14:38:01 -0800 Received: from ucsinet22.oracle.com ([156.151.31.94]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1TjdtE-0005tW-Hh for fedfs-utils-devel@oss.oracle.com; Fri, 14 Dec 2012 14:37:56 -0800 Received: from aserp1030.oracle.com (aserp1030.oracle.com [141.146.126.68]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qBEMbteO022116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 14 Dec 2012 22:37:56 GMT Received: from mail-ia0-f171.google.com (mail-ia0-f171.google.com [209.85.210.171]) by aserp1030.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBEMbsjJ000308 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 14 Dec 2012 22:37:55 GMT Received: by mail-ia0-f171.google.com with SMTP id k27so3643065iad.2 for ; Fri, 14 Dec 2012 14:37:54 -0800 (PST) Received: by 10.42.51.142 with SMTP id e14mr5990635icg.2.1355524674557; Fri, 14 Dec 2012 14:37:54 -0800 (PST) Received: from seurat.1015granger.net ([99.26.161.222]) by mx.google.com with ESMTPS id ww6sm7772421igb.2.2012.12.14.14.37.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 14:37:54 -0800 (PST) From: Chuck Lever To: fedfs-utils-devel@oss.oracle.com Date: Fri, 14 Dec 2012 17:37:53 -0500 Message-ID: <20121214223753.22243.57900.stgit@seurat.1015granger.net> In-Reply-To: <20121214221556.22243.9462.stgit@seurat.1015granger.net> References: <20121214221556.22243.9462.stgit@seurat.1015granger.net> User-Agent: StGIT/0.14.3 MIME-Version: 1.0 X-Flow-Control-Info: class=Default reputation=ipRepBelow100 ip=209.85.210.171 ct-class=R5 ct-vol1=0 ct-vol2=8 ct-vol3=7 ct-risk=49 ct-spam1=75 ct-spam2=7 ct-bulk=5 rcpts=1 size=2218 X-MM-CT-Classification: not spam X-MM-CT-RefID: str=0001.0A090205.50CBAA43.0036,ss=1,re=0.000,fgs=0 Subject: [fedfs-utils] [PATCH 04/11] libnsdb: Proper rationalization for disabling LDAP_OPT_REFERRALS X-BeenThere: fedfs-utils-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fedfs-utils Developers List-Id: fedfs-utils Developers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fedfs-utils-devel-bounces@oss.oracle.com Errors-To: fedfs-utils-devel-bounces@oss.oracle.com X-Source-IP: acsinet21.oracle.com [141.146.126.237] It wasn't always the case, but these days, the FedFS drafts _do_ have something to say about how to handle LDAP referrals when performing an NSDB request. NSDB clients must authenticate every NSDB they encounter. Thus an LDAP referral means the client has to consult its NSDB connection parameter database again for the referred-to NSDB node in order to authenticate it. The LDAP_OPT_REFERRALS option enables the LDAP library to handle LDAP referrals transparently to the caller. It's set to LDAP_OPT_ON by default. This means libnsdb would never see an LDAP referral. Since we need to make sure proper authentication occurs in this case, libnsdb must see LDAP referrals and deal with them. Thus, the LDAP_OPT_OFF setting is correct, but the reason in the comment for that setting is invalid. Our implementation also has a per-NSDB setting that allows an administrator to disable following LDAP referrals entirely. That's implemented by checking that setting when a referral occurs. This logic also requires that the LDAP library expose referrals to libnsdb. Signed-off-by: Chuck Lever --- src/libnsdb/ldap.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/src/libnsdb/ldap.c b/src/libnsdb/ldap.c index d1170d2..8b4291e 100644 --- a/src/libnsdb/ldap.c +++ b/src/libnsdb/ldap.c @@ -491,14 +491,15 @@ nsdb_open(const char *hostname, const unsigned short port, LDAP **ld, } /* - * The FedFS protocol drafts do not specify how to handle LDAP - * referrals. We probably don't want them, since our x.509 certs - * will probably not be usable with a referred to LDAP server. + * To authenticate a referred-to NSDB node and handle our + * per-NSDB "follow referrals" setting, libnsdb wants + * to handle LDAP referrals explicitly. */ rc = ldap_set_option(tmp, LDAP_OPT_REFERRALS, LDAP_OPT_OFF); if (rc != LDAP_OPT_SUCCESS) { - xlog(D_GENERAL, "%s: Failed to disable referrals: %s", - __func__, ldap_err2string(rc)); + xlog(D_GENERAL, "%s: Failed to disable referrals " + "for NSDB '%s': %s", __func__, + hostname, ldap_err2string(rc)); goto out_ldap_err; }