linux-kernel - Re: [PATCH RFC v2 bpf-next 4/9] libbpf: Allow to resolve binary path in current directory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZAiSHjVjdS76kSVN@krava>
Date:   Wed, 8 Mar 2023 14:48:14 +0100
From:   Jiri Olsa <olsajiri@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Hao Luo <haoluo@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Matthew Wilcox <willy@...radead.org>, bpf@...r.kernel.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Namhyung Kim <namhyung@...il.com>
Subject: Re: [PATCH RFC v2 bpf-next 4/9] libbpf: Allow to resolve binary path
 in current directory

On Tue, Mar 07, 2023 at 05:19:00PM -0800, Andrii Nakryiko wrote:
> On Tue, Feb 28, 2023 at 1:33 AM Jiri Olsa <jolsa@...nel.org> wrote:
> >
> > Try to resolve uprobe/usdt binary path also in current directory,
> > it's used in the test code in following changes.
> 
> nope, that's not what shell is doing, so let's not invent new rules
> here. If some tests need something like that, utilize LD_LIBRARY_PATH
> or even better just specify './library.so'

ok, that fixed that:

SEC("uprobe/./liburandom_read.so:urandlib_read_without_sema")

thanks,
jirka

> 
> >
> > Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> > ---
> >  tools/lib/bpf/libbpf.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 05c4db355f28..f72115e8b7f9 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -10727,17 +10727,19 @@ static const char *arch_specific_lib_paths(void)
> >  /* Get full path to program/shared library. */
> >  static int resolve_full_path(const char *file, char *result, size_t result_sz)
> >  {
> > -       const char *search_paths[3] = {};
> > +       const char *search_paths[4] = {};
> >         int i, perm;
> >
> >         if (str_has_sfx(file, ".so") || strstr(file, ".so.")) {
> >                 search_paths[0] = getenv("LD_LIBRARY_PATH");
> >                 search_paths[1] = "/usr/lib64:/usr/lib";
> >                 search_paths[2] = arch_specific_lib_paths();
> > +               search_paths[3] = ".";
> >                 perm = R_OK;
> >         } else {
> >                 search_paths[0] = getenv("PATH");
> >                 search_paths[1] = "/usr/bin:/usr/sbin";
> > +               search_paths[2] = ".";
> >                 perm = R_OK | X_OK;
> >         }
> >
> > --
> > 2.39.2
> >