41501 2021-12-04 03:02:02 +0300 share_network не читается из .hasher/config 2022-05-15 21:02:42 +0300 1 1 4 Development Sisyphus hasher unstable all Linux RESOLVED LATER P5 normal --- 1 lakostis ldv at glebfm ldv placeholder qa-sisyphus oldest_to_newest 205699 0 lakostis 2021-12-04 03:02:02 +0300 $ rpm -q hasher hasher-1.4.7-alt1.noarch $ cat ~/.hasher/config share_network=1 install_resolver_configuration_files=1 Однако [lakostis@lks build (master)]$ hsh-run --rooter /opt/builds/tmp -- sh -c "curl 192.168.1.1" curl: (7) Couldn't connect to server [lakostis@lks build (master)]$ share_network=1 hsh-run --rooter /opt/builds/tmp -- sh -c "curl 192.168.1.1" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1485 100 1485 0 0 361k 0 --:--:-- --:--:-- --:--:-- 483k <!DOCTYPE html><html><head><meta charset=utf-8><meta http-equiv=Cache-Control Более того, если сделать export share_network=1 так тоже работает: [lakostis@lks build (master)]$ export share_network=1; hsh-run --rooter /opt/builds/tmp -- sh -c "curl 192.168.1.1" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1485 100 1485 0 0 115k 0 --:--:-- --:--:-- --:--:-- 120k <!DOCTYPE html><html><head><meta charset=utf-8><meta http-equiv=Cache-Control content=no-store><meta http-equiv=cache-control content=no-cache><meta http-equiv=cache-control content="max-age=0"><meta name=viewport content="width=device-width,initial-scaC [lakostis@lks build (master)]$ hsh-run --rooter /opt/builds/tmp -- sh -c "curl 192.168.1.1" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1485 100 1485 0 0 340k 0 --:--:-- --:--:-- --:--:-- 362k <!DOCTYPE html><html><head><meta charset=utf-8><meta http-equiv=Cache-Control content=no-store><meta http-equiv=cache-control content=no-cache><meta http-equiv=cache-control content="max-age=0"><meta name=viewport content="width=device-width,initial-scaC [lakostis@lks build (master)]$ unset share_network [lakostis@lks build (master)]$ hsh-run --rooter /opt/builds/tmp -- sh -c "curl 192.168.1.1" curl: (7) Couldn't connect to server Предполагаю что это было сломано вот этим revert'ом: commit 3312e1ffb9d1ea098746168feaba82dfec208906 Author: Dmitry V. Levin <ldv@altlinux.org> Date: Sun Oct 30 18:05:44 2011 +0000 Revert "hsh-run: disable network isolation when X11 forwarding is requested" I supposed that most of use cases where X11 forwarding is involved expect network access. Apparently, they are not. This reverts commit e47a84f4b6efe889f970d827c7ea445a25e60d65. diff --git a/hasher/hsh-run b/hasher/hsh-run index 6be1b84..a9a3ee2 100755 --- a/hasher/hsh-run +++ b/hasher/hsh-run @@ -182,11 +182,6 @@ lock_workdir deduce_lock_hasher_priv prepare_x11_forwarding || x11_forwarding= -if [ -n "$x11_forwarding" -a -z "${share_network-}" ]; then - message 'X11 forwarding requested, disabling network isolation.' - share_network=1 - export share_network -fi т.е. export share_network убрали совсем и навсегда. 205700 1 ldv 2021-12-04 03:22:07 +0300 (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #0) > $ cat ~/.hasher/config > share_network=1 Я думаю, что если в этом месте написать export share_network=1 то заработает так, как вам хотелось. Просто hasher состоит из двух частей, ~/.hasher/config читает только клиентская, а учитывает $share_network только "серверная". 205702 2 lakostis 2021-12-04 03:44:46 +0300 (In reply to Dmitry V. Levin from comment #1) > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #0) > > $ cat ~/.hasher/config > > share_network=1 > > Я думаю, что если в этом месте написать > export share_network=1 > то заработает так, как вам хотелось. > > Просто hasher состоит из двух частей, > ~/.hasher/config читает только клиентская, > а учитывает $share_network только "серверная". А чем плох вот такой патч? diff --git a/hasher/hsh-run b/hasher/hsh-run index 5e13e4c..1824e6f 100755 --- a/hasher/hsh-run +++ b/hasher/hsh-run @@ -171,6 +171,8 @@ deduce_lock_hasher_priv prepare_x11_forwarding || x11_forwarding= +[ -z "${share_network-}" ] || export share_network + [ -z "$run_script" ] || 205703 3 ldv 2021-12-04 04:12:19 +0300 (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #2) > А чем плох вот такой патч? > > diff --git a/hasher/hsh-run b/hasher/hsh-run > index 5e13e4c..1824e6f 100755 > --- a/hasher/hsh-run > +++ b/hasher/hsh-run > @@ -171,6 +171,8 @@ deduce_lock_hasher_priv > > prepare_x11_forwarding || x11_forwarding= > > +[ -z "${share_network-}" ] || export share_network > + > [ -z "$run_script" ] || Он не плох, но есть два вопроса: - share_network - это не единственная переменная с таким свойством, hasher-priv ещё поддерживает share_ipc и share_uts; - hsh-run - это не единственный скрипт, который запускает процессы в чруте, может быть, им тоже надо форвардить эти переменные. Сейчас hsh-sh-functions явно поддерживает те переменные hasher-priv, которыми управляет, см. комментарий "variables used by hasher-priv" в коде. Кажется, что если форвардить share_* системно, то это тоже лучше делать в hsh-sh-functions. 210714 4 lakostis 2022-05-15 21:02:42 +0300 (In reply to Dmitry V. Levin from comment #3) > (In reply to Konstantin A Lepikhov (L.A. Kostis) from comment #2) > > А чем плох вот такой патч? > > > > diff --git a/hasher/hsh-run b/hasher/hsh-run > > index 5e13e4c..1824e6f 100755 > > --- a/hasher/hsh-run > > +++ b/hasher/hsh-run > > @@ -171,6 +171,8 @@ deduce_lock_hasher_priv > > > > prepare_x11_forwarding || x11_forwarding= > > > > +[ -z "${share_network-}" ] || export share_network > > + > > [ -z "$run_script" ] || > > Он не плох, но есть два вопроса: > - share_network - это не единственная переменная с таким свойством, > hasher-priv ещё поддерживает share_ipc и share_uts; > - hsh-run - это не единственный скрипт, который запускает процессы в чруте, > может быть, им тоже надо форвардить эти переменные. > > Сейчас hsh-sh-functions явно поддерживает те переменные hasher-priv, > которыми управляет, > см. комментарий "variables used by hasher-priv" в коде. > Кажется, что если форвардить share_* системно, то это тоже лучше делать в > hsh-sh-functions. Учитывая, что пользователей этого функционала ровно один, обойдемся просто документированием этого поведения в bugzilla )