From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by sourceware.org (Postfix) with ESMTPS id 0BF6F3857C6E for ; Wed, 16 Feb 2022 12:28:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0BF6F3857C6E Received: by mail-yb1-xb2c.google.com with SMTP id v186so5566965ybg.1 for ; Wed, 16 Feb 2022 04:28:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rnlC6EZzAjRB9Fy2hxkeYiIZbUTTTOJ/mJ1Epek4New=; b=MSuOzrbwoP6DkVLefYm1VX0GR0Qqn5dgTtmhw1LxrYHtQg/IEOyXZakXafHgHushpD +CjILZnP7iyVZi/WUUlED7QaQcaW4TaC+Ld+YfcB/ye+Hmau6pygPpQ8tF0Edkq6MSu2 5i0HXDDka2++SjBuJ6746itqw5r4LJ/a1vGZnev/AT/z/w4LXu11Lxt5NYsSvnoQ9Qya nEIRXlC2FUMW90Do58phdUpReoCWztOvvGJAS/3SJSEgaCYbNijR+PUREbixG1aUzpxE eawrgHJRE041+sDj20X5w3Ud5tSqjTsvxasBtb4jGpK/bCNSjNlxNY0dVeHws7bFWexl vmYA== X-Gm-Message-State: AOAM530CSlEqQoA6y9yrtPvnF8GjlaYwPBDh/IkKcnTWrPVK4jnIYz2/ WsBiQ3RTHz/cIT8nTv4IEEAXyEG7lB4lsOh23/uLICNsuDg= X-Google-Smtp-Source: ABdhPJyINkvjsv2GIB7fUe70VguSs+uQ455bjnhNoaCb4Gfx6kkP5Wva7YU3DM74MWJSp52b+Z0fnu6SMDcHipWMLJg= X-Received: by 2002:a0d:d756:0:b0:2d6:250c:1def with SMTP id z83-20020a0dd756000000b002d6250c1defmr2095706ywd.12.1645014505309; Wed, 16 Feb 2022 04:28:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: varun mittal Date: Wed, 16 Feb 2022 17:58:09 +0530 Message-ID: Subject: Re: Understanding 'initgroups' behavior in nsswitch.conf To: libc-help@sourceware.org X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_KAM_HTML_FONT_INVALID, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 12:28:27 -0000 >> "If user is not part of any secondary group, the group lookup will always go to other databases, irrespective of the initgroups configuration in nsswitch.conf" Any comments on this ? Should we not return immediately if even 1 group(be it primary group) is found in /etc/group, with the default 'initgroups' setting ? User may override it with 'success=continue' On Thu, Feb 10, 2022 at 1:08 PM varun mittal wrote: > Hi > > Working on a CentOS machine, with GlibC 2.17 I am struggling to find a > configuration which disables group lookup for local users on remote > directories. > > Then then I thought maybe initgroups can help but it doesn't seem to work > > My nsswitch.conf > > passwd: compat ldap lsass > shadow: files > group: files nis ldap lsass > hosts: files dns nis > protocols: files > rpc: files > services: files > initgroups: files nis ldap lsass > > This is the code snippet of glibc internal_getgrouplist function > > 133 /* For compatibility reason we will continue to look for more > 134 entries using the next service even though data has already > 135 been found if the nsswitch.conf file contained only a 'groups' > 136 line and no 'initgroups' line. If the latter is available > 137 we always respect the status. This means that the default > 138 for successful lookups is to return. */ > 139 if ((use_initgroups_entry || status != NSS_STATUS_SUCCESS) > 140 && nss_next_action (nip, status) == NSS_ACTION_RETURN) > 141 break; > > It looks like it should honor the initgroups config, but it doesn't seem > to, reason being the _nss_files_initgroups_dyn function returns > NSS_STATUS_NOTFOUND when the local user has only 1 primary group and no > secondary groups The relevant code snippet from _nss_files_initgroups_dyn > is > > 95 if (res > 0 && grp.gr_gid != group) > > Which boils down to > > "If user is not part of any secondary group, the group lookup will always go to other databases, irrespective to initgroups in nsswitch.conf" > > Is my understanding correct ? If yes, any reason why this has been implemented this way ? > > How do I get the desired behavior that local user's group lookup should never go to remote databases. > > In my case, if the remote directory ports are blocked or the remote directory is slow to respond, the service doing the lookup goes for a total hang. > > Our product ships with default nsswitch.conf and is not configurable by the end user. I need to have a static nsswitch.conf file with all the possible db's listed. > > > Thanks n regards > Mittal >