Message ID | cover.1623312996.git.fweimer@redhat.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 71B6C3AA9C5B for <patchwork@sourceware.org>; Thu, 10 Jun 2021 08:23:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 71B6C3AA9C5B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1623313402; bh=6FXHdzgy7ybTXs47r+KTHFRNrl//AeiH83h5lILz7VQ=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=O0iwZgU9UJrMgnsXHtSUMPmsNGsRcPKGW5djlC+5YbPFAn4yWo8I7l68O/+c4C0wi ulpJHqQpwByyvb2CQ+6Q8wTRloUpL2kt4vlLfjzoCGDTaSeZcli2bHl4QinDYl22RK FCCKOxgNNQs1tIw8wiUfyyVwOsRwJ5xAAPwMw0IU= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 0DF2A3AA9C61 for <libc-alpha@sourceware.org>; Thu, 10 Jun 2021 08:22:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0DF2A3AA9C61 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-348-gkHOFlLNPVyTnh_jmAX-FA-1; Thu, 10 Jun 2021 04:22:56 -0400 X-MC-Unique: gkHOFlLNPVyTnh_jmAX-FA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9E8BD100CA88 for <libc-alpha@sourceware.org>; Thu, 10 Jun 2021 08:22:55 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-115-60.ams2.redhat.com [10.36.115.60]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0DFBB60917 for <libc-alpha@sourceware.org>; Thu, 10 Jun 2021 08:22:54 +0000 (UTC) To: libc-alpha@sourceware.org Subject: [PATCH 0/4] Do not install shared objects under versioned names X-From-Line: eae14c3d57b3fef43892ca304f2d8017555e8447 Mon Sep 17 00:00:00 2001 Message-Id: <cover.1623312996.git.fweimer@redhat.com> Date: Thu, 10 Jun 2021 10:22:53 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Florian Weimer <fweimer@redhat.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Do not install shared objects under versioned names
|
|
Message
Florian Weimer
June 10, 2021, 8:22 a.m. UTC
This is essentially a repost of the “Add --disable-major-minor-libraries configure option” series. Joseph suggested that the configure option is not needed, so this version implements the change unconditionally. Tested on i686-linux-gnu and x86_64-linux-gnu. I compared two build-many-glibcs.py trees with and without these patches, using this command to see if there are missing files besides the versioned DSOs or any dangling symbolic links. cd /home/bmg/install/glibcs && find -printf '%P\n' \ | while read x ; do test -r /home/bmg-install-glibcs/$x || echo $x done \ | grep -v '\-2\.33\.9000\.so$' | grep -v '/libthread_db-1\.0\.so$' /home/bmg/install/glibcs is the unpatched build, /home/bmg-install-glibcs is the build with the patches applied. As expected, there was no output. Thanks, Florian Florian Weimer (4): nptl_db: Install libthread_db under a regular implementation name Makerules: Remove lib-version, $(subdir-version) elf: Generalize name-based DSO recognition in ldconfig Install shared objects under their ABI names INSTALL | 10 +++++++ Makefile | 6 ---- Makerules | 67 +++++---------------------------------------- NEWS | 8 ++++++ elf/Makefile | 12 ++------ elf/dl-is_dso.h | 33 ++++++++++++++++++++++ elf/ldconfig.c | 5 ++-- elf/tst-dl-is_dso.c | 35 +++++++++++++++++++++++ nptl_db/Makefile | 2 -- 9 files changed, 98 insertions(+), 80 deletions(-) create mode 100644 elf/dl-is_dso.h create mode 100644 elf/tst-dl-is_dso.c
Comments
* Florian Weimer via Libc-alpha: > This is essentially a repost of the “Add --disable-major-minor-libraries > configure option” series. Joseph suggested that the configure option is > not needed, so this version implements the change unconditionally. > > Tested on i686-linux-gnu and x86_64-linux-gnu. I compared two > build-many-glibcs.py trees with and without these patches, using this > command to see if there are missing files besides the versioned DSOs or > any dangling symbolic links. > > cd /home/bmg/install/glibcs && find -printf '%P\n' \ > | while read x ; do > test -r /home/bmg-install-glibcs/$x || echo $x > done \ > | grep -v '\-2\.33\.9000\.so$' | grep -v '/libthread_db-1\.0\.so$' > > /home/bmg/install/glibcs is the unpatched build, > /home/bmg-install-glibcs is the build with the patches applied. As > expected, there was no output. What are general thoughts about this change? Should we do it? If there's an emerging consensus that we want it, I can backport it downstream because we really need it there, and drop the patches once they have been merged. But I really don't want to carry another bunch of downstream-only patches indefinitely. Thanks, Florian
On 6/10/21 1:52 PM, Florian Weimer via Libc-alpha wrote: > This is essentially a repost of the “Add --disable-major-minor-libraries > configure option” series. Joseph suggested that the configure option is > not needed, so this version implements the change unconditionally. > > Tested on i686-linux-gnu and x86_64-linux-gnu. I compared two > build-many-glibcs.py trees with and without these patches, using this > command to see if there are missing files besides the versioned DSOs or > any dangling symbolic links. > > cd /home/bmg/install/glibcs && find -printf '%P\n' \ > | while read x ; do > test -r /home/bmg-install-glibcs/$x || echo $x > done \ > | grep -v '\-2\.33\.9000\.so$' | grep -v '/libthread_db-1\.0\.so$' > > /home/bmg/install/glibcs is the unpatched build, > /home/bmg-install-glibcs is the build with the patches applied. As > expected, there was no output. I was hoping that we would go in the opposite direction with this, i.e. encode a unique identifier in the names of the DSOs so that they can be installed in parallel, maybe with configuration options to pass the version string, similar to the kernel. This could for example allow us to implement recovery from broken glibcs without having to reach out for a rescue disk. However I understand that it would be quite a pain to implement and it doesn't seem to be on anyone's TODO list, certainly not mine. So I won't get in the way of this since it solves present day issues with library updates. It would be interesting to hear from other distribution maintainers on what they think of the change. Siddhesh
On 6/14/21 10:49 AM, Siddhesh Poyarekar wrote: > On 6/10/21 1:52 PM, Florian Weimer via Libc-alpha wrote: >> This is essentially a repost of the “Add >> --disable-major-minor-libraries configure option” series. Joseph >> suggested that the configure option is not needed, so this version >> implements the change unconditionally. >> >> Tested on i686-linux-gnu and x86_64-linux-gnu. I compared two >> build-many-glibcs.py trees with and without these patches, using >> this command to see if there are missing files besides the >> versioned DSOs or any dangling symbolic links. >> >> cd /home/bmg/install/glibcs && find -printf '%P\n' \ | while read x >> ; do test -r /home/bmg-install-glibcs/$x || echo $x done \ | grep >> -v '\-2\.33\.9000\.so$' | grep -v '/libthread_db-1\.0\.so$' >> >> /home/bmg/install/glibcs is the unpatched build, >> /home/bmg-install-glibcs is the build with the patches applied. >> As expected, there was no output. > > I was hoping that we would go in the opposite direction with this, > i.e. encode a unique identifier in the names of the DSOs so that they > can be installed in parallel, maybe with configuration options to > pass the version string, similar to the kernel. This could for > example allow us to implement recovery from broken glibcs without > having to reach out for a rescue disk. I think this is never going to happen. I'll tell you why. At one point I thought it *would* happen, and I thought we needed it, but two things prevent it: - Downstream QE teams rightly argue that changing libc has significant impact that much of the higher level stack testing needs to be redone. Consider the recent spat of seccomp/glibc, firefox/glibc, chrome/glibc issues all around "internal" implementation details that touch against the sandboxing. - Containers. In the past we might have said "Yeah, we need 2 libcs for the sake of two distinct requirements." Today we just run processes in containers. The general concept of "multiple libraries" I think is going to disappear underneath the improving container tooling. Rather than 2 libcs installed, we'll have two assembled containers, each with a different libc. > However I understand that it would be quite a pain to implement and > it doesn't seem to be on anyone's TODO list, certainly not mine. So > I won't get in the way of this since it solves present day issues > with library updates. It would be interesting to hear from other > distribution maintainers on what they think of the change. I think Florian is moving this in the *right* direction e.g. simple, robust, one file. Without a more compelling use case for multiple libcs in one setup I think this is the right move.
On 6/10/21 4:22 AM, Florian Weimer via Libc-alpha wrote: > This is essentially a repost of the “Add --disable-major-minor-libraries > configure option” series. Joseph suggested that the configure option is > not needed, so this version implements the change unconditionally. This is absolutely the right direction. I like that we simplify the layout. I have commented on Siddhesh's thoughts in the other thread, and I think we are never likely to implement a solution that installs parallel libcs given the QE and container aspects. Therefore I'd like to see this move forward. > Tested on i686-linux-gnu and x86_64-linux-gnu. I compared two > build-many-glibcs.py trees with and without these patches, using this > command to see if there are missing files besides the versioned DSOs or > any dangling symbolic links. > > cd /home/bmg/install/glibcs && find -printf '%P\n' \ > | while read x ; do > test -r /home/bmg-install-glibcs/$x || echo $x > done \ > | grep -v '\-2\.33\.9000\.so$' | grep -v '/libthread_db-1\.0\.so$' > > /home/bmg/install/glibcs is the unpatched build, > /home/bmg-install-glibcs is the build with the patches applied. As > expected, there was no output. > > Thanks, > Florian > > Florian Weimer (4): > nptl_db: Install libthread_db under a regular implementation name > Makerules: Remove lib-version, $(subdir-version) > elf: Generalize name-based DSO recognition in ldconfig > Install shared objects under their ABI names > > INSTALL | 10 +++++++ > Makefile | 6 ---- > Makerules | 67 +++++---------------------------------------- > NEWS | 8 ++++++ > elf/Makefile | 12 ++------ > elf/dl-is_dso.h | 33 ++++++++++++++++++++++ > elf/ldconfig.c | 5 ++-- > elf/tst-dl-is_dso.c | 35 +++++++++++++++++++++++ > nptl_db/Makefile | 2 -- > 9 files changed, 98 insertions(+), 80 deletions(-) > create mode 100644 elf/dl-is_dso.h > create mode 100644 elf/tst-dl-is_dso.c >
On 6/28/21 2:13 AM, Carlos O'Donell wrote: > I think this is never going to happen. I'll tell you why. At one point I > thought it *would* happen, and I thought we needed it, but two things > prevent it: > > - Downstream QE teams rightly argue that changing libc has significant > impact that much of the higher level stack testing needs to be redone. > Consider the recent spat of seccomp/glibc, firefox/glibc, chrome/glibc > issues all around "internal" implementation details that touch against > the sandboxing. > > - Containers. In the past we might have said "Yeah, we need 2 libcs for > the sake of two distinct requirements." Today we just run processes in > containers. The general concept of "multiple libraries" I think is > going to disappear underneath the improving container tooling. Rather > than 2 libcs installed, we'll have two assembled containers, each with > a different libc. I'm much less concerned about multiple system glibc versions being use in tandem; that may even be harmful. My concern is recovery. I agree that in practice recovery is much less of a common problem; I've managed to brick Fedora glibc only once (ok maybe twice) in my lifetime. So maybe I'm overthinking it. > I think Florian is moving this in the *right* direction e.g. simple, > robust, one file. Without a more compelling use case for multiple > libcs in one setup I think this is the right move. I agree that if there's no way to usefully utilize the version numbers then it's a step forward to drop them. Siddhesh