From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) by sourceware.org (Postfix) with ESMTPS id 32BF73858033 for ; Tue, 23 Nov 2021 16:36:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 32BF73858033 Received: by mail-ua1-x935.google.com with SMTP id i6so44926429uae.6 for ; Tue, 23 Nov 2021 08:36:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=0HOFWAD+X6O9ev/v/LLd9GiFvNDd3j9cu9JyKCRs8H0=; b=49gnw00mef+HZ4X834SqWOfwEwsoWdTnJ3XiphbQpjakY5gz4oLRPHKfgcysO9KsEp 84G0n/aPWK6eA7A5V7+xDC1yE7pHAQq8saUxntA7OBoNoZkewYhHrcjecz5/HTqO2D9N 8KUebw+R7/3qZrRmqTo+H4+gHBWN23tsVjqz8l85wVksovri9Mv1lAWJL0LoV06c8ZxB jUPC0Q6BDUTYDzY/eRxhskeyGgvUIUTr7tnpCO6XOXajCBMcFo3GgVOcGdIKhTACs4+A iMAcR1nESs37w3D1ZW2Yo+LaMygMvbOUvsVRYYyIVB9E3xF4E7IJBPyDPW6bqGr/y6hj tGsA== X-Gm-Message-State: AOAM532qFwG9OtVojloI2r4Dc//Sd2cqtoXW3++tCineyVOLRIyBoW7a t2Hfy1KSMMCtD8l/l/9yZD0dwQAOLwjDag== X-Google-Smtp-Source: ABdhPJxLl7VI2448KiR9ARKh0qNE58q/s4he4Zzddvy7VogFeYyAHeI+kllNn1Qx+Ji2OlHwabwn1w== X-Received: by 2002:a67:fa0f:: with SMTP id i15mr10416569vsq.16.1637685376662; Tue, 23 Nov 2021 08:36:16 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:e054:570f:87aa:2a8d:f2bc? ([2804:431:c7cb:e054:570f:87aa:2a8d:f2bc]) by smtp.gmail.com with ESMTPSA id 14sm7420627vkg.35.2021.11.23.08.36.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 08:36:16 -0800 (PST) Message-ID: <5f1dc6a2-47c4-43a1-26e1-61bca100037f@linaro.org> Date: Tue, 23 Nov 2021 13:36:13 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Fwd: [PATCH v5 00/22] Some rtld-audit fixes Content-Language: en-US To: Florian Weimer Cc: Jonathon Anderson , John Mellor-Crummey , libc-alpha@sourceware.org, "Mark W. Krentel" , Xiaozhu Meng References: <0D3F0C5F-2586-42F9-916D-2F327432AF13@rice.edu> <87bl2i345m.fsf@oldenburg.str.redhat.com> <87ee7c9coo.fsf@oldenburg.str.redhat.com> <87wnl399b9.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87wnl399b9.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 16:36:18 -0000 On 19/11/2021 17:31, Florian Weimer wrote: > * Adhemerval Zanella: > >>> "" for the main executable is widely known. Usually code uses it to >>> implement a fallback on argv[0] or /proc/self/exe, though. >> >> There are still the issue where audit interface does not have direct >> access to argv[0] from the audited process and '/proc' might also not >> be accessible. I am still not convinced that provided argv[0] for >> l_name for main executable is worse than "", specially because the >> fallback might not work. > > I think it's better to give the auditor a chance to figure out whether > they want to use program_invocation_name (if that's not available in the > inner libc, that's for sure a bug we must fix), AT_EXECFN, or > /proc/self/exe. If we pick one of these for the auditor, we make it > more difficult to make the appropriate choice. > >>> Changing l_addr will break the libgcc unwinder. It uses l_addr to >>> relocate the program header (see the code I quoted previously). Not >>> everyone uses the platform unwinder, and the libgcc unwinder is >>> sometimes linked statically. This is different from the l_name change: >>> The l_addr would definitely cause widespread breakage. >>> >>>>  - Every use case I can think of for obtaining a link_map from the dl* >>>> functions (dlinfo and dladdr1) will either already have the special >>>> handling, or won't operate on the main executable, or likely won't opt >>>> to use l_addr (vs. dlsym or dli_fbase) or l_name (vs. dli_fname). >>> >>> Some special-case the main executable based on l_name, I expect, which >>> is why I'm so reluctant to change l_name. The GDB comment is actually >>> hinting strongly towards a "" convention (that Solaris broke). >> >> So I take that Solaris does provide the application name to l_name? And >> what kind of breakage it has done on gdb? > > Solaris seems to use the pathname argument to execve as l_name, > via AT_SUN_EXECNAME. I do not know if it is an absolute name. > The documentation for getexecname suggests it may not be: > > | Normally this is an absolute pathname, as the majority of commands are > | executed by the shells that append the command name to the user's PATH > | components. If this is not an absolute path, the output of getcwd(3C) > | can be prepended to it to create an absolute path, unless the process > | or one of its ancestors has changed its root directory or current > | working directory since the last successful call to one of the exec > | family of functions. > > > > If that's accurate, it would be just like our AT_EXECFN. I suspect this > won't work for fexecve, so they are just going to fall back to argv[0] > in that case. I seems to return a relative path used for process execution: azanella@gcc-solaris11:~$ uname -a SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise azanella@gcc-solaris11:~$ cat lname.c #include #include #include #include int main (int argc, char *argv[]) { void *h = dlopen (NULL, RTLD_NOW); assert (h != NULL); struct link_map *l; assert (dlinfo (h, RTLD_DI_LINKMAP, &l) == 0); printf ("%s\n", l->l_name); return 0; } azanella@gcc-solaris11:~$ gcc -Wall lname.c -o lname azanella@gcc-solaris11:~$ ./lname lname azanella@gcc-solaris11:~$ /export/home/azanella/lname /export/home/azanella/lname > > Still I think we have 20+ years of doing things our way (the BSD way), > and I do worry about the backwards compatibility impact of such a > change. >