From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FROM_GOV_DKIM_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9667 invoked from network); 13 Jan 2022 20:36:37 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Jan 2022 20:36:37 -0000 Received: (qmail 3549 invoked by uid 550); 13 Jan 2022 20:36:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16362 invoked from network); 13 Jan 2022 20:04:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=llnl.gov; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=02022021-podllnl; bh=lpYrcmJ4XScI/UijoxV0q3EqpsvMI7EDSprtHL7kaE0=; b=tP5ljO4m1TcDLGG7Lidu5f/DKhL7BhVpQQXWy1mhy2npKAv+GmiW33stoIEBtQrEvika OL8+L3A7hhzrDXKuPIynnFTXHutT5rH6do/DXDywaax/7z3WNg1gtQNpidG+poVusuPk sGkYhrY2euT2qrCl6v3uuM9nn/1BxmjQ+0hqj/R2WSXEK+ymH/pH54gthDqCtWIVFHhF NIqKnCf62DJ2m2nY5nwo3Uu9TmSvu/VAYx62LVAoIulLz4P71KUmOe3kN+v9BEKp0TM3 afkhLP+zeBXXf9M4uHR5Mip7QdmYfkVBMW2/Kna0xYf9y+H+asPXZ8hxwL8ShK5yc1xq BA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RATlwGmVXk31fzjxSdHmn6oFle3icCr/gbLi1WQfjxUrWNVj42KK1x4u4voQX7se1eeBRKacDMYYZGhApwqDaW2V5lo5kpZ7/PXFSHzHveNpSZB6uEGtSts/upNXLoWyvX66I2DrxUx+zZ706GCVDvoQKSj71oj55PFnLIwh2+EPN1dHHWBGCGdKUFwUqfM8BbuZx+SLQJHoW6eIoz//EtSTCAcsq0a5OZuJzSU0MEXrGed0WxPc4RwV5aE6G70JMdwVulsn+e/lhwEpEPe7wjwWyQqIAuo1XElULtkVbsbQHRBoTYg769CjpBSFXYGCxkHfJrRT2afYYSh+u3I/DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lpYrcmJ4XScI/UijoxV0q3EqpsvMI7EDSprtHL7kaE0=; b=Jz251n7I103AyE6X8HXS6Yc9LrI9srF9OquZa4utd7jMbJQlfEvgWGW8QpvgdK7pPYbzpKN7QBF+MyVEbVOWGyGXbqRMwlpzAHzmCRU1oRq8TCdgohHpDm9mBYka2KIs48u7rVoQv1fNI35oJY3V2cB0TEmrgkWOXCS2kBBmoVuI2G/u+o+TcsaAfk6T2mql8c6vcpfv3gDloKAeTEHD/Xy/uAnArJ1Rf2Y7MpCEKWiELln1kkNvP8UR8AOoAxigA4nP1OP1G9XwczXEwkgskHzeF+9ZnVPUYQB2Ua/dWUafBNg0hmPRWvdQkr59BIPibmEye1/9VWzMgOyUmEFxdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=llnl.gov; dmarc=pass action=none header.from=llnl.gov; dkim=pass header.d=llnl.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doellnl.onmicrosoft.com; s=selector1-doellnl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lpYrcmJ4XScI/UijoxV0q3EqpsvMI7EDSprtHL7kaE0=; b=rW+/jfv9yjdq+OPB2BxbG+FP/E5M39vGpR2FGF4XfiZ8VQOZrI1KLS03PoOaul4KjVoH8mXuFkJxFFqqrm6uDdgUrKXP5deZG4NXZD1OSBCZZcAbevicqdH2zPpRGk3FYSG13W/idzxJJ9HL5TtZwJmcR8n+JCXzA2uEMpI9Wog= From: Tom Scogland To: Farid Zakaria Cc: Rich Felker , musl@lists.openwall.com, me@harmenstoppels.nl, Carlos Maltzahn Date: Thu, 13 Jan 2022 12:04:04 -0800 X-Mailer: MailMate (1.14r5853) Message-ID: <9070DA87-A1FC-4EE9-9F47-873427860920@llnl.gov> In-Reply-To: References: <20220113032953.GX7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: BY5PR20CA0014.namprd20.prod.outlook.com (2603:10b6:a03:1f4::27) To SJ0PR09MB7071.namprd09.prod.outlook.com (2603:10b6:a03:259::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5f919261-5341-401f-8c60-08d9d6cfda08 X-MS-TrafficTypeDiagnostic: SJ0PR09MB7309:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LtZLKeRAFUrodbjh+QbJCbds0Z5/d8n7eI+SQATBKHAXs7vZT7Cp/x2x323BKVSAoG45gOEcj9iZrv8fcbfrVTR3gG00CSqFr73pHmB9H7cq4c+b2TVqpWXrlKkJSl7ePcWzlIPFT+gO90E8+s3TLI3rm1vDnejzc8M7cWhaYumjPCN/b6JovLhqQlu1rEIr7etDnrboUOp3Xnl5IomI5z0qMrO3LdKS1POD3j1SPyE00vs1JpJPfAIeoiOgRQ43VZs/TMYJ9EKqc5t7sqL69OC/N4nRjFTVo5K+bK3ryGBeYbqgPda3+FvZjVgJfNg6YWBflLNNSh8oHBxme5cJeZmSLhxE5ERc2u/4VESkQoNmO2NLKEwj8RAR6UsB9UmPEINb3O8rrnmMFCWab8BUKsOrKqzI/jQVcn6IFsYtpsYGAHypELnuU63MCVOMMoXFv2/NckN8Y3bayxH433vpAEf1Ov8q/QLY8iO/4DY0FT2JhZtOC2oCLjQMTkD6B2aGBEvJtVJ9kmqWggl9vMZ50QosfVU3g4dEjK0h3b9DNZv1HJsybCn8uKarnHU5+EqFOKJ1137GClxYVPIfG97TBY2VvS/RztwU95pjM1MwyIpnDvy/3YI2PWG9xW2rTDedsfVG+Mt45b8NDd+u4QzSmDul85f1xOPMZ+0jGN7szl3lZLj3wOi8qnvQyVqbWChKTqyFavTqKxcblquzP3m6Fg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR09MB7071.namprd09.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(83380400001)(66556008)(2906002)(53546011)(186003)(6512007)(6506007)(33656002)(2616005)(8676002)(8936002)(36756003)(5660300002)(66946007)(66476007)(6486002)(26005)(508600001)(82960400001)(54906003)(316002)(86362001)(4326008)(38100700002)(6916009)(45980500001);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WkR4RklEcnB4a3lTWVN0eFlWenVBRnduclhVa0lJSGdITitoY25ySlJrN0dY?= =?utf-8?B?eVBBdXc2Ny9aNFVaVWduNWQwaHZ2a2xYYnNBMkdqYS9YOC9xT2t5eFVSaDlk?= =?utf-8?B?N3ZNaDVOZ2dxdXc2Rjh1S0ZieU85anJyM1FhdTV6TzdnWU1zTmQ1T0J1VjdU?= =?utf-8?B?WlVTYnNjZkRHb3BHV20vV0kyQ2FqQ0d5WVRsZzU3U29JdUIzeHhic1htMnFz?= =?utf-8?B?YzFqUldnQ3FpdHFIYWkrQUVsSjF3aENUZlNvdndoY05PbWdWOThpbHozVVpY?= =?utf-8?B?QUM3cHY1V281RFFlaENBaFNhMWcvclkxUTlhamR0RDV0bi8zTmlveUVBVG1C?= =?utf-8?B?MjRxV1FQaXoxUnh3c0JrT0pJK3VxemdLOXR1YmNjSDhnU0dCQStXazh3Z2hZ?= =?utf-8?B?bytjR2FsTm5PZ0czdGdZc2U5UVM4dzZrMG92VjU3NlBiNXl4NlpwSFc1WEtk?= =?utf-8?B?ODhIQ0RReXJEb0hKdnFxTlZKOS9KL0dHNUk2U2RxTkRjY2EzcWFaUXIvTXhN?= =?utf-8?B?bDFvMXhZK24yWHJWZXFtaEcvaDRJQXNqRXAxaU54eU9NaU9sSForMzlMT2c1?= =?utf-8?B?L2dMZURXQWF0MlZiZnZpTSs1cWJkMzRtTFJ6bDdxNmNieXRNTUlJTnV0TUZP?= =?utf-8?B?Nnd4bkNBd3FwaFREYlZLZktMenNnQnBJVG1uMlVHV1NNRDNTdm5vbnpKUUpQ?= =?utf-8?B?eTZQUTJIeDlPTld1bmhZbUVBazNKdDBaZ3d1a0FURjZGREtiUkhaN3VlZXpr?= =?utf-8?B?dzBXWkFhTEFHb0hRZm4zWVN3NDFNdXJhSXU5cXlIRzljd05aQVd4VTlhd00x?= =?utf-8?B?bUlhYUxOUFRGN0RuM3dtN1dGV1Z3Ukl0Titkdk00bVdiV0JFQWk3TStCZFZ3?= =?utf-8?B?WVRXTGVabGlpL3I0QUhhV0VZMWNXMmFVK3h1SHN5QWtmeXFFemFIOUQvbk1o?= =?utf-8?B?ZU1qU1dGRWNuWVR2RkJSanJDcng1NWFjQmViamYvNVdlQ3QwVWFLKzJub1U4?= =?utf-8?B?cGgzczlzaVBTOFVMbStmeTBUN1g4bG1uNHBGUXhsWE0vZkZyclp6Z1ZwTFEr?= =?utf-8?B?cFF0MHYrNklHT3ppWXlGakE5VTB6MmVoVmpNZmRrR2RQcTkxaCtDMXJRd21p?= =?utf-8?B?OWZIbFZMRVN1NzFXb3RTYUR1VzVVeWQxUWVMNXU0aHBuSFptTE50L3ZuQzdY?= =?utf-8?B?dWRaWWtEN3Vtc3VraTdteXZ3cEpHMUhoSWtmUzdQNm4veFAwSmZQM0ZWVEs2?= =?utf-8?B?aWwwTUc4czVFR3QwcFlzam53WFMxeXZyeDRHYzB3b3IxNEJhVkFIeDNBVmFQ?= =?utf-8?B?azAxSXZmdkcxaERCdi9xeDdYdW9jZThhUExNaUVGbUh0ZHZrN3pwV2dSOGQy?= =?utf-8?B?Ui9vek5ZN3d2bXlJM3cwL2FrY2JpZzZ0TmhIcXlaK0liSXA4dWMxb2w5YW00?= =?utf-8?B?cWtHTnlEWG1pVU9wS0pncVBpbWhGcEsrSkpLbTUwd0V4Wmo0eExnd1lOWEJy?= =?utf-8?B?Z0RlWlVxWXB5THFNTXpKZVl0ZFltM3BvQTdVbFVuSEY0M3A1WHVFdG5JLy9a?= =?utf-8?B?aFFXUnM5OUFWK3JjaG9WLzg3Mi8rQzFBS3Y2Q3hiaHoybWhEWndKL1A5Yk8w?= =?utf-8?B?U01JamNIazdIN3JQVklCSXJHZkpiVmFDdmt0K1NNVEFyTXp2enlIM1FoazVV?= =?utf-8?B?UE5hR1JWRFNVRnJhODdkYWUvZGI2eklxMk1xUnQxeTNJYldhOVUreTdWcFNp?= =?utf-8?Q?bDo1sP/GyfDEq2S0pNbfjpbGUGL9R///HYiyX+G?= X-OriginatorOrg: llnl.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 5f919261-5341-401f-8c60-08d9d6cfda08 X-MS-Exchange-CrossTenant-AuthSource: SJ0PR09MB7071.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2022 20:04:05.6234 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: a722dec9-ae4e-4ae3-9d75-fd66e2680a63 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR09MB7309 X-Proofpoint-ORIG-GUID: 4JzDOUix5QQw5zCV5bOj_AyDHD-0RM0i X-Proofpoint-GUID: 4JzDOUix5QQw5zCV5bOj_AyDHD-0RM0i X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.816 definitions=2022-01-13_07:2022-01-12,2022-01-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 spamscore=0 phishscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 suspectscore=0 malwarescore=0 impostorscore=0 clxscore=1011 mlxlogscore=473 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2201130125 Subject: Re: [musl] is RUNPATH being incorrectly inherited inherited? On 12 Jan 2022, at 19:46, Farid Zakaria wrote: > Hi Rich, > > Thank you for taking the time to read my email and responding. > I was worried it was a bit too pedantic in explanation and I had had > some trivial error in the setup. > (I am only beginning to gain deeper knowledge on linking) > > On Wed, Jan 12, 2022 at 7:29 PM Rich Felker wrote: >>> To me this means that the ld.so here is not respecting the description >>> of not propagating the search paths to the children. >> >> Yes, that's intentional. Is this something you want not to happen? > > This specific case, I only brought up after having read the manpage > for linux-ld/ld.so > on my quest to better understand dynamic linkers. It does seem that > other tools are making similar assumptions > however (libtree) when trying to replicate the search pattern employed > by a linker. > > The rationale you mention about the ability to set a single top-level > RUNPATH is desirable however > I do find the delta between what's documented for ld.so to have been conf= using. > > I am as part of some research evaluating other alternatives to how to > specify link-paths and part of that > research direction involves more explicitly specifying whether a path > should/should not be inherited; in addition to a > few other ideas. > > It's clear you are aware of this discrepancy and it was done so knowingly= . > At least I know I was not mis-understanding the results of my setup :) Adding a bit of extra context here, it=E2=80=99s not so much that we want i= t not to propagate (although I can work up examples where that=E2=80=99s wh= at we would want) as it is that the System-V specification says it doesn=E2= =80=99t propagate so this is pretty surprising behavior. In a way it=E2=80= =99s good, in that it means musl will work with QT-style plugin loading eve= n when using runpath, but it=E2=80=99s also unfortunate in that we have no = way to override LD_LIBRARY_PATH as a package builder when we know there are= dirty environment modules on a system that set LD_LIBRARY_PATH to non-sens= ical values (I really wish this were not a problem). What I think we actually want doesn=E2=80=99t currently exist anywhere, whi= ch is a way to specify search paths before and after LD_LIBRARY_PATH and wh= ether they do or do not propagate. There are cases where overriding LD_LIB= RARY_PATH is desirable, along with many where it isn=E2=80=99t, and cases w= here propagation is harmful, along with many where it isn=E2=80=99t. We=E2= =80=99re trying to figure out what one would do if we were designing someth= ing like DT_NEEDED and DT_RUNPATH today, and I=E2=80=99d be interested in w= hat you would want, or not want, out of that if you have further thoughts o= n the matter. >>> FWIW, as per the other correspondence, if I remove part of the >>> RUNPATH, then the binary fails to load even though _libx.so_ was >>> already present. >> >> This is expected given the current lack of SONAME processing because, >> while it's present, it's not tracked as being "what you should get by >> resolving the name libx.so". If we do adopt SONAME processing here it >> would be found, and would necessarily preclude any path search from >> happening since it would already be present. Presumably that's what >> you would want to happen, right? > > Yes! This is more of an interesting quirk I find different between > glibc whose functionality > I think would make a positive addition. Happy to continue discussing > this issue on the other > mailing list emails :) Yes, that would actually help a good deal in making what we=E2=80=99re tryi= ng to do more robust. It would also make things more consistent. So far i= t seems most implementations fall into two buckets: either doing soname pro= cessing, and using soname for deduplication; or pretending the basename is = the soname and using that, well or using soname if it exists and basename i= f not. I think musl is the only one I=E2=80=99ve run into that works based= on inode rather than some proxy for library name. -Tom