Скрытый потенциал UNIX

Евгений Зобнин ака j1m

Хакер, номер #094, стр. 094-110-2

UNIX глазами программиста

Инструментарий программиста занимает прочные позиции в окружении UNIX. Мощный скриптовый язык, встроенный в командный интерпретатор, концепция каналов (pipes) и принцип «программа должна выполнять только одну функцию, но делать это очень хорошо» создали благодатную почву для любительского программирования. Операционная система словно призывает тебя использовать богатый программистский функционал во всех областях деятельности. Многие администраторы и обычные пользователи применяют самопальные скрипты для выполнения сложных задач. Нет пользователя UNIX, который бы хоть раз в жизни не использовал каналы для обработки потоков информации (чего только стоит команда «dmesg | less»). Возможность комбинирования отдельных элементов операционной системы для создания чего-то нового является одной из основных причин жизнеспособности ОС.

Но не одним только шеллом жив юниксоид. Существует множество других примеров использования инструментов из арсенала программиста в обыденной жизни. Одним из них является утилита /usr/bin/make, созданная для облегчения сборки программы из исходных текстов. Область ее применения уже давно вышла за означенные выше рамки. Особенно ярко это выражено в системе портов BSD-систем. Весь фреймворк, необходимый для выкачивания программы из сети, соблюдения зависимостей, поиска и выполнения множества других операций, написан именно на языке сценариев make. И это вполне оправдано, если учитывать специфику синтаксиса make-файлов. Greg Lehe, автор книги The Complete FreeBSD, предложил использовать make для создания образов компакт-дисков:

$ vi ~/mkiso/Makefile

PPLID = "Dummy application"

BOOT = "-b floppies/boot.flp"

ISO = /var/tmp/isoimage

PREPARER = "me"

VOLID = "Volume 0000"

DIR = .

iso:

mkisofs -A ${APPLID} ${BOOT} -J -o ${ISO} -f \

-p ${PREPARER} -r -T -V ${VOLID} ${DIR}

UNIX глазами хакера

Некоторые юниксоиды даже не подозревают о том, что многие компоненты ОС, которые они привыкли использовать, изначально были созданы в целях облегчения отладки и исследования. В это легко поверить, если учитывать, на сколько глубоко эти компоненты укоренились в UNIX. Возьмем, к примеру, виртуальную файловую систему procfs. Главная ее задача - предоставить информацию об исполняющихся процессах, их окружении, адресах памяти. Предполагается, что пользователю все это знать не положено, но, тем не менее, опытные юниксоиды прибегают к помощи этой файловой системы. Procfs удобно использовать для выяснения причин аномального поведения программы или получения «снимка» ее окружения в момент исполнения, что может понадобиться при создании «песочниц» (читай мою статью «Под защитой песочного демона»). Более того, procfs стала настолько привычной для UNIX, что некоторые программы просто отказываются работать, обнаружив ее отсутствие.

Такие утилиты, как /usr/bin/ldd, /usr/bin/strace, /usr/bin/lsof и /usr/bin/fstat (*BSD), также находятся в одной целевой нише с файловой системой procfs. Их основное назначение - позволить программисту получить контроль над программой и ее исполнением. В то же время они стали просто панацеей для тех пользователей, кто задается вопросом «Почему эта программа не работает?». Сколько раз ты применял команду «ldd `which program`» после получения стандартной ошибки о ненайденных библиотеках? А ведь в конце man-страницы к Linux-версии ldd сказано: «Linux Programmer's Manual». Очень часто можно видеть, как трассировщик системных вызовов strace применяют для выяснения причин возникновения сбоя программы, и не программисты, а пользователи. Программы lsof и fstat не менее популярные инструменты, особенно при возникновении стандартной ошибки «device is busy» во время демонтирования файловой системы на съемном носителе.