Как я говорю, что работаю в chroot?
Самый близкий эквивалент должен был бы, вероятно, установить ниже пакетов:
su -
yum install make automake gcc gcc-c++ kernel-devel
Однако, если Вы не заботитесь о точной эквивалентности и соглашаетесь с получением по запросу в большом количестве пакетов, можно установить все средства разработки и библиотеки с ниже команды.
su -
yum groupinstall "Development Tools" "Development Libraries"
Что я сделал, здесь должен протестировать ли корень init процесс (PID 1) совпадает с корнем текущего процесса. Хотя /proc/1/root всегда ссылка на / (если init самостоятельно chrooted, но это не случай, о котором я забочусь о), после него приводит к “основному” корневому каталогу. Эта техника используется в нескольких сценариях обслуживания в Debian, например, для пропуска запуска udev после установки в chroot.
if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then
echo "We are chrooted!"
else
echo "Business as usual"
fi
(Между прочим, это - еще один пример почему chroot бесполезно для безопасности, если процесс chrooted имеет корневой доступ. Некорневые процессы не могут читать /proc/1/root, но они могут следовать /proc/1234/root если существует рабочий процесс с PID 1234, работая как тот же пользователь.)
Если у Вас нет корневых полномочий, можно посмотреть на /proc/1/mountinfo и /proc/$$/mountinfo (кратко зарегистрированный в filesystems/proc.txt в документации ядра Linux). Этот файл читаем миром и содержит большую информацию о каждой точке монтирования в представлении процесса файловой системы. Пути в том файле ограничиваются chroot влияние на процесс читателя, если таковые имеются. Если чтение процесса /proc/1/mountinfo chrooted в файловую систему, это отличается от глобального корня (принятие pid 1, корень является глобальным корнем), затем никакая запись для / появляется в /proc/1/mountinfo. Если чтение процесса /proc/1/mountinfo chrooted к каталогу в глобальной корневой файловой системе, затем запись для / появляется в /proc/1/mountinfo, но с другим идентификатором монтирования. Кстати, корневое поле ($4) указывает, где chroot находится в своей основной файловой системе.
[ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]
Это - чистое решение Linux. Это может быть generalizable к другим вариантам Unix с достаточно подобным /proc (Солярис имеет подобное /proc/1/root, Я думаю, но нет mountinfo).
Как упомянуто Портативным способом найти inode число и Обнаружение chroot тюрьмы из, можно проверить ли inode количество / 2:
$ ls -di /
2 /
inode число это отличается от 2, указывает, что очевидный корень не является фактическим корнем файловой системы. Это не обнаружит chroots, которые, оказывается, базированы на точке монтирования, или в операционных системах со случайным корнем inode числа.
-
1Над какими файловыми системами работает эта эвристика? – Gilles 'SO- stop being evil' 09.11.2011, 13:36
-
2
-
3Таким образом, я дурачился, и я думаю, что нашел более надежный метод, который не требует корневых полномочий (только Linux). Я все еще открыт для контрпримеров или большего количества портативных методов. – Gilles 'SO- stop being evil' 09.11.2011, 21:15
-
4Это верно для расширения [234], но не всех файловых систем. Это также только тестирует тот Ваш корень, корень файловой системы, которая не может быть смонтирована как реальный корень. Другими словами, если Вы монтируете другой раздел в / тюрьме и
chroot /jail, затем это будет похоже на реальный корень к этому тесту. – psusi 09.11.2011, 21:26 -
5@AdamKatz, По-видимому, нет. Протестированный в 6.0-стабильном openbsd, inode число все еще 2 для фактического корневого пути, в то время как это - случайное число для chroot. – Dmitri DB 16.09.2016, 06:11
Это просто случайное наблюдение. Но если у вас есть доступ к чему-либо с помощью FUSE, вы можете что-то смонтировать, а затем использовать mount, чтобы показать путь монтирования, который будет показан с префиксом пути chroot.
Например, в программе запуска Github Actions для Mac вы можете сделать что-то вроде:
pip install --user ratarmount
folder=$(mktemp -d)
mountedFolder=$(mktemp -d)
# simple bind mount a folder
ratarmount "$folder" "$mountedFolder"
Теперь mountбудет печатать что-то вроде:
TarMount on /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmp.P5g4TomF (macfuse, nodev, nosuid, synchronous, mounted by runner)
хотя полный путь в переменной mountedFolderравен:/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmp.P5g4TomF. Поэтому кажется, что мы chrooted в /private.
Из-за этого хакерская mountpointкоманда замена с помощью mountи grepу меня не сработала.
init(8)должен был бы абсолютно иметь слот № 1, если нет некоторая трудно кодированная природа, которая требует его (в котором я все еще был бы не уверен относительно почему). Конечно, BSDs намного больше усовершенствовали тюрьмы, чем просто chroot, таким образом, я даже не уверен, насколько проблематичный это. – Adam Katz 16.01.2015, 12:02/proc. Мой ответ не был предназначен для обращения к чему-либо кроме Linux так или иначе. – Gilles 'SO- stop being evil' 16.01.2015, 13:40