38163 2020-02-27 18:55:01 +0300 bwrap игнорирует PATH при поиске запускаемых приложений 2024-10-30 11:41:00 +0300 1 1 4 Development Sisyphus bubblewrap unstable x86_64 Linux CLOSED FIXED https://bugzilla.altlinux.org/show_bug.cgi?id=51514 P5 normal --- 34937 1 rider aris aris cas iv lav ldv rider underwit zerg qa-sisyphus oldest_to_newest 188229 0 rider 2020-02-27 18:55:01 +0300 Нарвался при попытке использовании opam, но это точно воспроизводится для всех приложений, запускающих что-то через bwrap В моём случае это выглядит так: $echo $PATH /home/rider/.opam/ocaml-base-compiler/bin:/home/rider/bin:/usr/lib/kf5/bin:/usr/local/bin:/usr/bin:/bin:/usr/games $ 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 ocam Creating root mount point creating new namespace forking for child launch executable ocam bwrap: execvp ocam: No such file or directory $ which ocaml /home/rider/.opam/ocaml-base-compiler/bin/ocaml Легко воспроизводится, если попытаться запустить с помощью bwrap что-то из ~/bin/ На других дистрибутивах такого нет. Проблема скорее всего в нашей glibc - execvpe сбрасывает PATH для суидных бинарей. А т.к. bwrap не работает, то проблемы запуска некоторых приложений flatpack тоже , вероятно, растут из этого места. 188230 1 rider 2020-02-27 18:56:03 +0300 В 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. 188231 2 rider 2020-02-27 18:57:56 +0300 Да, в первом примере запуск 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 188232 3 rider 2020-02-27 19:04:26 +0300 Для чего используется bwrap в opam можно почитать тут: https://opam.ocaml.org/doc/FAQ.html#Why-does-opam-require-bwrap 2ldv: хотелось бы, что бы bwrap у нас заработал так же как, как и в других дистрибутивах. 188237 4 ldv 2020-02-27 23:57:48 +0300 Из вышепроцитированного у меня сложилось ощущение, что это уязвимость в bwrap, причём в точности того класса, который наш ld.so затыкает. 188238 5 rider 2020-02-28 00:02:22 +0300 тогда это хороший повод сходить в апстрим, если у тебя есть понимание, в чём заключается уязвимость и как её эксплуатировать. Код в нём конечно ужасен, но именно в данном месте уязвимости быть не должно - 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. */ 188285 6 rider 2020-03-03 10:55:30 +0300 Есть предложение реализовать в bwrap самостоятельную обработку PATH по аналогии с execvpe из glibc. Дима, как по твоему, что лучше - тащить реализацию поиска приложение из glibc в bubblewrap или откатить в нашем glibc игнорирование PATH в execvpe для суидных придожений ? 189167 7 rider 2020-04-09 15:33:11 +0300 ping 189819 8 zerg 2020-05-08 11:40:06 +0300 Как видно, Дима предлагает самим выбрать из одного варианта. 189824 9 rider 2020-05-08 14:08:37 +0300 (Ответ для Sergey V Turchin на комментарий #8) > Как видно, Дима предлагает самим выбрать из одного варианта. Тогда перенесите в него поиск файла по пути, пожалуйста, из glibc, что бы нам не лезть в старый код в самом glibc. 190127 10 underwit 2020-05-20 13:22:14 +0300 Сделал исправление. Пропустите сборку #251987 190133 11 zerg 2020-05-20 16:29:33 +0300 У меня заработало. Например, установленный из flatpak kdenlive стал запускатся, 190248 12 repository-robot 2020-05-22 17:00:41 +0300 bubblewrap-0.4.1-alt2 -> sisyphus: Wed May 20 2020 Ivan Razzhivin <underwit@altlinux> 0.4.1-alt2 - fix run path (Closes: 38163)