From patchwork Wed Sep 10 16:57:04 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 387901 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 18553140131 for ; Thu, 11 Sep 2014 02:57:14 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=MHmZ1b4zkMwn8OvM 4LaoJ4z3EmAgZ0Xc0po8aFcYtw8HgQ9o+tW6BA5xyVtacK7WjYVlJaj02iX5c1Gz nYXhSvDntdOGSi3YCl1ZM6tjEnavaRC9iTsgStryW/tkvhV3mhnt8RPKyOJR0yL1 yOD4HektdxjvlEC4Mise55TkJoY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=default; bh=ua5fmvrv16xfeUi9dojaNp TvfCw=; b=jzeKeBXwI6vzgti1pBCLoq5FgZatXUHbt2pkMxt8dwYX8qQKMXNYIZ +bydEq+IJVfVhK27XFilt7eQ6cTPVBPLBVSOdlCZZQb+i4veLByHSuOSbHogAflZ GGBbQ/BB6xGLOemABHKE4jQS4z8LD6nBG2uiIpyCJ3QDlbNKjrA4c= Received: (qmail 28733 invoked by alias); 10 Sep 2014 16:57:09 -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 28723 invoked by uid 89); 10 Sep 2014 16:57:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <541082E0.8050707@redhat.com> Date: Wed, 10 Sep 2014 12:57:04 -0400 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Siddhesh Poyarekar CC: Michael Kerrisk , "linux-man@vger.kernel.org" , Simo Sorce , Jakub Hrozek , GNU C Library Subject: Re: [PATCH] getgrent.3: Add ENOENT to error list. References: <54105ED1.5020206@redhat.com> <20140910145307.GC14885@spoyarek.pnq.redhat.com> In-Reply-To: <20140910145307.GC14885@spoyarek.pnq.redhat.com> On 09/10/2014 10:53 AM, Siddhesh Poyarekar wrote: > On Wed, Sep 10, 2014 at 10:23:13AM -0400, Carlos O'Donell wrote: >> It's possible to get ENOENT returned from getgrent >> if the backend, for example say SSSD, isn't configured >> or the daemon isn't running. The same can be said of any >> of the NSS backend. > > The daemon not running is internally a NSS_STATUS_TRYAGAIN + > EAGAIN[1], i.e. that is what the sssd nss plugin should return to > glibc. glibc then should return that as a NOTFOUND, which for > getgrent is a NULL return without errno set. I don't see why ENOENT > is necessary. This is orthogonal to the discussion at hand. At present glibc will return a NULL `struct group*' and errno set to ENOENT if the NSS plugin returns NSS_STATUS_UNAVAIL and errno ENOENT indicating it is incorrectly configured. This is a documented entry in the glibc manual, and is presently how SSSD behaves (until it gets fixed). Wether we like it or not there is a present day distinction between "permanently unavailable until an admin fixes it" (NSS_STATUS_UNAVAIL,ENOENT), "temporarily unavailable" (NSS_STATUS_TRYAGAIN,EAGAIN), and the former may be seen by the user, and may be useful to act upon by a program that is interested in that behaviour. I do not think glibc should hide NSS_STATUS_TRYAGAIN from the user. To be clear ENOENT is neccessary if you want to actually detect that something is wrong with your system and take evasive action. Simply getting back no results is not sufficient to take corrective action. In the case of sss however the intent of the inactive plugin is to operate as if it had no data. At least this is what I've been told by those working on SSSD at Red Hat. SSSD should *not* use status==NSS_STATUS_TRYAGAIN and errno==EAGAIN because that will simply result in EAGAIN being returned to userspace from getgrent which is again a deviation from the entire philosophy behind SSSD wanting `sss` in nsswitch.conf. The point is to appear as a transparent plugin that is enabled at a later time by starting up the daemon. For example if you fix SSSD to use status==NSS_STATUS_TRYAGIN errno==EAGAIN instead you get this still wrong behaviour from this test case: #include #include #include #include int main(int argc, char *argv[]) { struct group *p_group; setgrent(); while (1) { errno = 0; /* initialize for getgrent() */ p_group = getgrent(); if (p_group == NULL) { if (errno == 0) { break; /* end of groups */ } else { perror("getgrent"); /* error occurs. */ printf("getgrent error %d \n", errno); endgrent(); exit(-2); } } printf("getgrent() OK group(%d) = %s \n",p_group->gr_gid, p_group->gr_name); } exit(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: 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 Which completes successfully and is the only way it should work for an installed SSSD nss module. e.g. --- Please correct me if you think something I've said is wrong or doesn't make sense. Cheers, Carlos. 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;