Понимание chroot

Я запускаю пользовательские приложения в док-контейнерах, и все было в порядке, пока я не решил использовать supervisorctl, чтобы я мог удаленно запускать / останавливать приложения через rpc. Теперь мне нужен способ запретить пользовательскому приложению анализировать контейнер, обнаружив supervisord.conf & журналы и / или выполнение бункеров supervisord / supervisorctl.

Способ сделать это — использовать chroot, но мне неясно, как это сделать.

Чтение документации uwsgi, все, что нужно сделать, это запустить

mkdir -p /ns/001
debootstrap maverick /ns/001
chroot /ns/001
# in the chroot jail now
adduser uwsgi
apt-get install mercurial python-flask
su - uwsgi
# as uwsgi now
git clone https://github.com/unbit/uwsgicc.git .
exit # out of su - uwsgi
exit # out of the jail
Now on your real system run

uwsgi --socket 127.0.0.1:3031 --chdir /home/uwsgi/uwsgi --uid uwsgi --gid uwsgi --module uwsgicc --master --processes 4 --namespace /ns/001:mybeautifulhostname

Чтобы uwsgi работал в контейнере chroot.

PHP-FPM также, похоже, имеет аналогичный параметр конфигурации, где вы должны установить

prefix = /var/www/example.com
chroot = $prefix
chdir = /
listen = tmp/php5-fpm.sock
slowlog = log/$pool.log.slow

Я не уверен относительно необходимости запуска debootstrap внутри контейнера. Также я не понимаю, как в примере uwsgi; они запускают мусорную корзину uwsgi вне chroot, разве вам не нужно устанавливать uwsgi внутри chroot, а затем иметь что-то вроде / ns / 001 / usr / bin / uwsgi в вашем supervisord.conf вне chroot?

Я не могу найти ни одного стандартного способа запуска chroot и atm, поэтому я рассматриваю возможность запуска установки, аналогичной

RUN set -e;
apk add --no-cache supervisor;
mkdir -p /ns/001;
debootstrap alpine /ns/001;
chroot /ns/001;
# in the chroot jail now
# install all my packages here, all the stuff that was in the container apk add --no-cache everything
before gets moved here
# exit the chroot
in my superisord.conf then just specify /ns/001/path/to/bins/in/chroot

Будет ли вышесказанное жизнеспособным подходом?

Я думаю, что я также видел примеры, которые используют только chdir опция для php-fpm и uwsgi, это какой-то способ избежать настройки среды chroot? И очень простое предотвращение процесса, например. питон от просмотра за пределами chroot dir?

Будет ли chroot ограничивать переменные env, видимые этим процессом?