From patchwork Thu Aug 3 19:28:35 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 21911 Received: (qmail 56701 invoked by alias); 3 Aug 2017 19:28:43 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 55864 invoked by uid 89); 3 Aug 2017 19:28:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.5 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=replies, H*r:192.168.8, H*RU:!192.168.8.100!, H*r:ip*192.168.8.100 X-HELO: mail-qk0-f170.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XhopQTsepksB/1POt2A44MZPGKJ89MEm6VU9RvspTPs=; b=WiFGui98+8vwOAoRNHwfwy4Yu8lj9/QSr6AiyD4/xtCL45Ua4ldnLXPRjxdP5UKTYP RDfTFV/9Px8LdWP0OZkj3VZzqVWLBymiHzhBp0Z1YwgFrf28UViZgfAYc/DShniiD3GS FdxKbwRUevmESm7Qyk3FfaiRFSEPRZoVmjjMfcS1HSCCRLkGKA1+VZKtL3B/XBzDtxIT HJz0PzP1rTt22TV8itXq7CHWr0zU+AQ7hnG4G0DHDY1SSSJ3B4QAa00Sdnz/qId8gMIr tyBEfYcGp0WRJ1YQVsACFwTjKkaxRRMeTxf2vr9iDD7F1C//7lZCXFjfxJydxCnMjY1B WJvw== X-Gm-Message-State: AHYfb5jGdolPQrUIQXx/7rlpiiTbdGS1hw5rsiYfMf/DO01fW3hD0kU7 7AtQ5SyZpLpJ6am6PKf78w== X-Received: by 10.55.99.22 with SMTP id x22mr4257702qkb.173.1501788517688; Thu, 03 Aug 2017 12:28:37 -0700 (PDT) Subject: Re: NSS error reporting (bug 20532) To: Florian Weimer , GNU C Library References: <87e3d20e-5a51-93ba-6276-0f5305836b2c@redhat.com> <02cabe4c-f2e8-03f7-8307-71cf2aedace5@redhat.com> From: Carlos O'Donell Message-ID: Date: Thu, 3 Aug 2017 15:28:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <02cabe4c-f2e8-03f7-8307-71cf2aedace5@redhat.com> On 08/03/2017 01:18 PM, Florian Weimer wrote: > On 08/03/2017 06:49 PM, Carlos O'Donell wrote: >> On 08/03/2017 12:28 PM, Florian Weimer wrote: >>> (L) Carlos added NSS_STATUS_NOTFOUND with *errnop equals 0 as a >>> documented special case to the manual, in commit >>> d4e301c5c65393837e438b6d81feabfbfde7b9c7. This contradicts (A). >>> NSS_STATUS_NOTFOUND is handled implicitly by __nss_next2, which does not >>> have access to the errno value, so I do not understand how this could work. > >> I must assume that (A) is not quite correct. I had two reproducers where >> errno was propagated to the caller, and did result in observable differences? > > Can you dig up the details? And what was fixed in response to this > clarification? https://bugzilla.redhat.com/show_bug.cgi?id=988068 SSSD, installed, client setup, but no server running was returning NSS_STATUS_UNAVAIL / ENOENT, and that results in the ENOENT being propagated to the caller. This was not the intent. The intent was for the SSSD NSS service module to be transparent to the user if sssd was not running. So I had to clarify a class of NSS service module was was intalled, answering replies, lacked a connected data source, but wanted to return a no-error result that would be retried later. The example reproducer was as simple as: #include #include #include int main(int argc, char* argv[]) { struct passwd pwd; char buf[4096]; int err; struct passwd *res; err = getpwnam_r(argv[1], &pwd, buf, 4096, &res); printf("<%s> err: <%d>\n", argv[1], err); return 0; } With SSSD using status==NSS_STATUS_TRYAGAIN errno==EAGAIN: getgrent() OK group(0) = root getgrent() OK group(1) = bin getgrent() OK group(2) = daemon ... getgrent: Resource temporarily unavailable getgrent error 11 With SSSD using status==NSS_STATUS_UNAVAIL errno==ENOENT: getgrent() OK group(0) = root getgrent() OK group(1) = bin getgrent() OK group(2) = daemon ... getgrent: No such file or directory getgrent error 2 With SSSD using status==NSS_STATUS_NOTFOUND errno==0 (as suggested): getgrent() OK group(0) = root getgrent() OK group(1) = bin getgrent() OK group(2) = daemon getgrent() OK group(3) = sys ... getgrent() OK group(185) = wildfly > Are you sure this wasn't due to a NSS framework bug? > > If errno is indeed propagated, then setting it 0 is probably wrong > because POSIX does not allow setting it to 0. You are absolutely right. It should have been clarified to say "errno is left untouched." This is the patch I worked up during testing: --- Should we have saved and restored errno? diff -urN sssd-1.11.6/src/sss_client/nss_group.c sssd-1.11.6.mod/src/sss_client/nss_group.c --- sssd-1.11.6/src/sss_client/nss_group.c 2014-06-03 10:31:33.000000000 -0400 +++ sssd-1.11.6.mod/src/sss_client/nss_group.c 2014-09-10 12:21:52.330685026 -0400 @@ -539,6 +539,11 @@ if (nret != NSS_STATUS_SUCCESS) { errno = errnop; } + /* Always pretend we have no data. */ + if (nret == NSS_STATUS_UNAVAIL) { + nret = NSS_STATUS_NOTFOUND; + errno = 0; + } sss_nss_unlock(); return nret; @@ -639,6 +644,11 @@ if (nret != NSS_STATUS_SUCCESS) { errno = errnop; } + /* Always pretend we have no data. */ + if (nret == NSS_STATUS_UNAVAIL) { + nret = NSS_STATUS_NOTFOUND; + errno = 0; + } sss_nss_unlock(); return nret;