From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id aK0sDj4h2WV6GwAAqHPOHw:P1 (envelope-from ) for ; Fri, 23 Feb 2024 23:50:38 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id aK0sDj4h2WV6GwAAqHPOHw (envelope-from ) for ; Fri, 23 Feb 2024 23:50:38 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=mdc-berlin.de header.s=mdc header.b="m uTUI7D"; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=mdc-berlin.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1708728637; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=/StkeXVALI0bfAYwfb+3CrGHcZARXjKkgachscYX0iM=; b=Wzahn5H4hL0/2PvUBkOcCx0Df5fm94ufDISf1BnAtoGtaBkuoc/YMG3TxYCozo48effIGB T3KsuGblHTZocQvcKXf8MQ6NbkD2xPE2eCDamQRgAkJ/i2pPGYwS/tGE7fGRYrS7ju4PxQ B5rMTYMeZBG9S7LLp7U7fCvVrOeYHToZrFjiKxYWQTvlRN7bG1ceKCDG0Sele6/eVWMRiX C5iee3rY6lRw/KIuSrf/oGdP77yGZxYvko1u2xctxbRfkVUKaxycQBifATSIMZJmMhGNlw tWIOBkH68H4fHI4G/dDz4UGWvl0xplhNvCCgHC8tK020JCh7iBkxjqtzadB/gQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=mdc-berlin.de header.s=mdc header.b="m uTUI7D"; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=mdc-berlin.de ARC-Seal: i=1; s=key1; d=yhetil.org; t=1708728637; a=rsa-sha256; cv=none; b=g/GaCA8fxM2seeSwMtH22YGubEzkC0xu6owrdIy5QXBwEnuES0I6lPA9H9uKlDijccH+fr AyPierHOu3KP/EBukCosd+gYsNwiYrqOtqwWuUgsyBYhHfubqyGirLS8vFKK5o4eO+GE9U h53Wq9tGXOchK4iQT51yizlsRJn684fj36tsqbtjY2EwtJrIbWwzD3m8R/6A5aaJERGDJp kNDnC26LIjQPzmOoJSTZk6nOvIOyN/uv64XVolnMEMSzEIzGhggP0AtHYxXD9py9j25vjL Uk2I6MJ/+YNxeClY6OGNyWbpYucAZg2oTfYfBlnmixVnZLT86OVPJqDeHP/1hg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CCE5E5E362 for ; Fri, 23 Feb 2024 23:50:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rdeM3-0002VW-JX; Fri, 23 Feb 2024 17:49:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rddpy-0007vu-I0 for guix-devel@gnu.org; Fri, 23 Feb 2024 17:16:10 -0500 Received: from a2062.mx.srv.dfn.de ([194.95.232.172]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rddpv-000484-9t for guix-devel@gnu.org; Fri, 23 Feb 2024 17:16:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mdc-berlin.de; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:in-reply-to:date:date:subject:subject:from:from :user-agent:references:received; s=mdc; t=1708726548; x= 1710540949; bh=/wWyf3cjZGsrRBjfMRDx268F/2/cI1l1kAwWdudoWRQ=; b=m uTUI7DYuoP5aUzdbmo/ggC2HGV+ZVNgvL5Am6nkJnBMUbe5ErGyqegu+A4nXBQSm GwxCQVzGJyRWt8qAOwTPwgI9qrn0QlXNlcsEh/J+NrdGuxwCOhDepkykoe50/oNS vlP43jnZ/7CcFfRvq8Uoa0k1//8SXVvq5WmalHBYpA= Received: from SW-IT-P-EX2.mdc-berlin.net (mgw2.mdc-berlin.de [141.80.113.60]) by a2062.mx.srv.dfn.de (Postfix) with ESMTPS id 304F4A0268; Fri, 23 Feb 2024 23:15:48 +0100 (CET) Received: from localhost (94.134.44.190) by SW-IT-P-EX2.mdc-berlin.net (141.80.113.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.4; Fri, 23 Feb 2024 23:15:47 +0100 References: <87sf1jh8gq.fsf@inria.fr> User-agent: mu4e 1.10.8; emacs 29.1 From: Ricardo Wurmus To: Ludovic =?utf-8?Q?Court=C3=A8s?= CC: Subject: Re: Supporting sssd, preparing for nscd sunset Date: Fri, 23 Feb 2024 22:48:16 +0100 In-Reply-To: <87sf1jh8gq.fsf@inria.fr> Message-ID: <875xyebze5.fsf@mdc-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [94.134.44.190] X-ClientProxiedBy: SW-IT-P-EX2.mdc-berlin.net (141.80.113.60) To SW-IT-P-EX2.mdc-berlin.net (141.80.113.60) X-TM-AS-Product-Ver: SMEX-14.0.0.3152-9.1.1006-28210.001 X-TM-AS-Result: No-10--9.569100-5.000000 X-TMASE-MatchedRID: vbSD0OnL8/JiHm449d3ilkNF5tKVli5KYb/nLV/lbk+pN11bG1ZGkjlC Rr8Hb3qiHOsy09mcAQZPnPkQmqDQsVWUwIAU9VkeBe3KRVyu+k0iSMnphO25RaXgzKrH43t48dz N1u13/KoNUccATRyd1H9lNIZ2pEmPjBuNayz6EYCVOwZbcOalS6X1XMd/Sqvuwxiuo77pMB5j+t FV4mTkF1hfDvae4xrmvnWmRBXDP7u/IFSslWntgRfqkKQlk1I59TTzpdGk91RXPwnnY5XL5Jpj+ XNqU6N7Ix/OqCk5J12/eXR4hAC4pLG2wMSpX9ItDlgxb8s+r0C1k3bRIdXVNEJsNXD374+pHDtA s7DqN4dOYwfQUBz1BAMTrxPQzhSPcRZVcflu3NCJXSm2bBmGrU3yuY9BGW8rFiG1vO5aVyWeAiC mPx4NwHJnzNw42kCxxEHRux+uk8hfNjF5BHUO+/FgScnMwi+T84JNdMIjY5sBbpSbcW4pN468L/ euAX+o18fdw4V1QMA= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--9.569100-5.000000 X-TMASE-Version: SMEX-14.0.0.3152-9.1.1006-28210.001 X-TM-SNTS-SMTP: 9830B413ED49EEF69D53273670648805EC48EF2F1A29B5253B7764FA6F421C272000:F Received-SPF: pass client-ip=194.95.232.172; envelope-from=Ricardo.Wurmus@mdc-berlin.de; helo=a2062.mx.srv.dfn.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -7.87 X-Spam-Score: -7.87 X-Migadu-Queue-Id: CCE5E5E362 X-Migadu-Scanner: mx11.migadu.com X-TUID: k6Cv6pLjiEJK Hi Ludo, thanks for getting the discussion started. This problem has been weighing on me for the past months and I don't see a good way forward. Ludovic Court=C3=A8s writes: > For the record, glibc maintainer Carlos O=E2=80=99Donell brought up our u= se case > a while back on the glibc mailing list but it wasn=E2=80=99t particularly= well > received: > > https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html DJ Delorie's response makes it sound like they would prefer that all of the host system's NSS *configuration* (alongside the NSS modules) be duplicated in the Guix "container", because that's not guaranteed to be compatible. That's not a way forward for us, because that would make running Guix-built software much harder and require significant configuration on the side of the user. > [...] If sssd becomes dominant, we > might just as well arrange to have NSS always load libnss_sss.so. What are the other contenders here? I assumed that sssd was what everyone=E2=84=A2 used nowadays. At the MDC we've been using sssd on RHEL for a long time and we've seen some problems with the na=C3=AFve approach of just having the Guix System's NSS load libnss_sss.so: - In a Guix System VM we also had to explicitly set LD_PRELOAD or LD_LIBRARY_PATH in the current environment (not just nscd's environment) to make things like "id" work. Having just NSS load the library was not enough to work with user accounts that are defined in LDAP, for example. - A different Guix System VM was configured to use nss-pam-ldapd. Upon reconfigure it attempted (and predictably failed) to delete all user accounts on LDAP, because none of them were defined locally. I guess Guix System needs to be a little less eager to manage remote accounts that NSS plugins (including sssd) say exist. - PAM in a container. While this is not strictly related to the disappearance of nscd, it is another obstacle relating to sssd. On foreign distros I use Guix containers that bind-mount the host system's /var/lib/sss/pipes directory. The hope was to use a native Guix build of libsss to talk to the socket at /var/lib/sss/pipes/pam (and potentially others) for authorizing users via the host system's sssd infrastructure. In "guix shell -C" this won't work, because sssd refuses to talk over that socket if the ownership is not root:root. In the Guix shell container there is only ever *one* user account, so root-owned files are assigned to the overflow user account, and thus communication with the host system's pam socket is impossible. I failed to fix this with subuids, because the "guix shell -C" process does not have sufficient privileges to map more than one user id. I'll note that /var/lib/sss/pipes also contains an "nss" socket; I don't know if it checks ownership on that socket, but it's possible that it also cannot be used in "guix shell -C". --=20 Ricardo