From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id EEC0D3858D20 for ; Wed, 31 May 2023 19:28:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EEC0D3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685561298; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=WRevpXo7K/MN9hLs1KmQF2+7EcOBRiJYEK1Adhyd89s=; b=hXrR2CW2FiKVcoSXC7C8kU+0KoPEkSgeTDcs7JTt3l1g5JQk5Q0oAwR26bHMOPAbzsOUMc sEk41j9SQjHlSzcMUt0RyVTh7NNRweobQ7JVYN5vMnB77hY+seR+Ry/7ALaNRRDPRr7cHy 5gpBBWVRhVEUmIIIvgTk7yud+1dhL50= Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-93-q4ITEuM7NJai3_w67igsqw-1; Wed, 31 May 2023 15:28:17 -0400 X-MC-Unique: q4ITEuM7NJai3_w67igsqw-1 Received: by mail-oi1-f198.google.com with SMTP id 5614622812f47-3983bbf4e37so5623646b6e.1 for ; Wed, 31 May 2023 12:28:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685561296; x=1688153296; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WRevpXo7K/MN9hLs1KmQF2+7EcOBRiJYEK1Adhyd89s=; b=aE64SYxbv5BF8dotrkQDb8qS1SgCEB4wI1aHyJiIt3e268+gfA9ApE1n6MvOwHRCcA mwNzmVZNBaQf+atfCQ0sC8zdhVy23nYQKhiHF2y+EfdIp/gBY3TOD9LzqWldJ5yx6Ibv SS/8mE6yJZ3RUyLSd32q7s5mTvPH4aAjyoLVCCYJ6YRhWZ7I2MzUllwZQZVhJEXvdBfH oNWN4zlJ1Xl6U0u7t+v8+zrET1y+B4RgEtl6avwxUeR8WaVIvorP69F6rsHNNxvKSZk5 vm8SrG1L3VwNsg6/C0S+/hTQcZ6xxzkHxrWBAB3i1iAhCm7VnbQ6ekk30KArXrR6UugB JCDg== X-Gm-Message-State: AC+VfDzwudQjq+uUo2QlVuC1JYedTd9HYS6E5lPkwOvbej41N5solHl1 N3NjGecjkxDcSIrcGOGJ+hbFy3OfR6Z6IjFzdluM8DAhxkXMS2zS0Z2ib+ObbsnWs6I/1uAclS/ lX1mfBw7QasfRQ06tVBr1NpSNIzcUtCxedNr8pmaUDTtQYxA= X-Received: by 2002:a05:6808:1c97:b0:397:ebe4:eb83 with SMTP id co23-20020a0568081c9700b00397ebe4eb83mr4365952oib.17.1685561296406; Wed, 31 May 2023 12:28:16 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ50GlxjkR/T0pJtuyDDTuANKlpCdb089z3uAo0hVWPJJvrszMbvo6JRXnLfvrWy1uO05wtAqrNJieuFsy1pXJQ= X-Received: by 2002:a05:6808:1c97:b0:397:ebe4:eb83 with SMTP id co23-20020a0568081c9700b00397ebe4eb83mr4365943oib.17.1685561296041; Wed, 31 May 2023 12:28:16 -0700 (PDT) MIME-Version: 1.0 From: Arjun Shankar Date: Wed, 31 May 2023 21:28:05 +0200 Message-ID: Subject: [RFC] Avoiding dlopen in statically linked applications that use nss [#27959] To: libc-alpha@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi all, I have been working on a fix for bug 27959 ([1], "glibc 2.33 NSS refactoring lost static NSS support") that involves getting rid of "--enable-static-nss" entirely and instead moves the decision of allowing/disallowing dlopen to application build-time. The solution I was trying to arrive at was: Statically linked applications that are built "as usual" continue to behave like they do currently, which is: except for the built-in "files" and "dns" backends, any other backends configured via nsswitch.conf *do* lead to the statically linked application dlopen'ing the corresponding module. However, for applications that want to avoid having nss related dlopen calls, a new statically linked library is provided by glibc - say "libnss_nodlopen.a". The archive would contain just enough of an alternative dlopen-free nss implementation that compiling with something like: $CC -static libnss_nodlopen.a application.c ...leads to the linker picking the alternative implementation of nss functions that are involved in loading nss modules from the new archive instead of libc.a -- and these wouldn't dlopen. Presumably, any non-built-in modules configured in nsswitch.conf get treated as if the corresponding service was unavailable during the call. Florian referred to this sort of solution back when he moved the "files" backend into libc [2]. I have been in touch with him and asking him questions about this topic as I work through this problem. I started by compiling an additional copy of nss/nss_module.c - the code that is responsible for module loading. The second copy, through some macros, avoids calling dlopen. My initial understanding was that this would be sufficient content in the "new" libnss_nodlopen.a and if it were provided first on the command line, the linker would prefer the implementations from there when resolving nss related references (e.g. "__nss_module_get_function"). This should lead to the application having no dlopen calls in the statically linked executable. This isn't what actually happens. The linker presumably first notes that the application calls, say "getpwent", then doesn't manage to resolve that reference until it arrives at libc.a. At that point, internal functions referred to by "getpwent" going up the nss call stack *all* get picked from libc.a, i.e. the libc.a copy of "__nss_module_get_function" gets picked up, and not the one in the "new" archive I was producing. Therefore, if my understanding of the situation is correct, this new statically linked library will need to have more bits from nss including all public functions available for name resolution in order for it to work. I expect this would also mean moving code from various places in the glibc source tree into nss/ (e.g. pwd/, resolv/, grp/ etc.) so that they can then be included in the new library. How reasonable does that sound as a solution? What other alternatives are there? Another way of tackling this could be changing the default so that libc.a doesn't call dlopen for nss and making the dlopen version optional instead -- presumably via a similar statically linked library that *does* use dlopen. Cheers! [1] https://sourceware.org/bugzilla/show_bug.cgi?id=27959 [2] https://sourceware.org/pipermail/libc-alpha/2021-June/127273.html -- Arjun Shankar he/him/his