В glibc это поведение привносится:
commit 69a1f59f8b86ee9b031c74fcd3d218605ba5be93
Author: Dmitry V. Levin <ldv@altlinux.org>
Date:   Mon Oct 20 11:06:36 2008 +0000

    owl-alt-sanitize-env
    
    Sanitize the environment in a paranoid way.

Да, в первом примере запуск bwrap был с опечаткой, но по сути ничего не меняется:
$ bwrap --unshare-net --new-session --proc /proc --dev /dev --bind /tmp/.private/rider /tmp --setenv TMPDIR /tmp --setenv TMP /tmp --setenv TEMPDIR /tmp --setenv TEMP /tmp --tmpfs /run --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind /etc /etc --ro-bind /opt /opt --ro-bind /home /home --ro-bind /var /var --ro-bind /home/rider/.opam/ocaml-base-compiler /home/rider/.opam/ocaml-base-compiler --bind /home/rider /home/rider --bind /home/rider/.cache/dune /home/rider/.cache/dune ocaml
Creating root mount point
creating new namespace
forking for child
launch executable ocaml
bwrap: execvp ocaml: No such file or directory

Для чего используется bwrap в opam можно почитать тут:
https://opam.ocaml.org/doc/FAQ.html#Why-does-opam-require-bwrap

2ldv: хотелось бы, что бы bwrap у нас заработал так же как, как и в других дистрибутивах.

Из вышепроцитированного у меня сложилось ощущение, что это уязвимость в bwrap, причём в точности того класса, который наш ld.so затыкает.

тогда  это хороший повод сходить в апстрим, если у тебя есть понимание, в чём заключается уязвимость и как её эксплуатировать.

Код в нём конечно ужасен, но именно в данном месте уязвимости быть не должно - bwrap в этом месте работает уже не под рутом.

/* This acquires the privileges that the bwrap will need it to work.
 * If bwrap is not setuid, then this does nothing, and it relies on
 * unprivileged user namespaces to be used. This case is
 * "is_privileged = FALSE".
 *
 * If bwrap is setuid, then we do things in phases.
 * The first part is run as euid 0, but with fsuid as the real user.
 * The second part, inside the child, is run as the real user but with
 * capabilities.
 * And finally we drop all capabilities.
 * The reason for the above dance is to avoid having the setup phase
 * being able to read files the user can't, while at the same time
 * working around various kernel issues. See below for details.
 */

Есть предложение реализовать в bwrap самостоятельную обработку PATH по аналогии с execvpe из glibc.

Дима, как по твоему, что лучше - тащить реализацию поиска приложение из glibc в bubblewrap или откатить в нашем glibc игнорирование PATH в execvpe для суидных придожений ?

ping

Как видно, Дима предлагает самим выбрать из одного варианта.

(Ответ для Sergey V Turchin на комментарий #8)
> Как видно, Дима предлагает самим выбрать из одного варианта.

Тогда перенесите в него поиск файла по пути, пожалуйста, из glibc, что бы нам не лезть в старый код в самом glibc.

Сделал исправление. Пропустите сборку #251987

У меня заработало. Например, установленный из flatpak kdenlive стал запускатся,

bubblewrap-0.4.1-alt2 -> sisyphus:

 Wed May 20 2020 Ivan Razzhivin <underwit@altlinux> 0.4.1-alt2
 - fix run path (Closes: 38163)