Дейв Тейлор - Сценарии командной оболочки. Linux, OS X и Unix. 2-е издание

····echo "Usage: $0 [-s] list of files or directories" >&2

····exit 1

··fi

··if ["$1" = "-s"]; then

····# Запрошена операция без журналирования…

····shift

··else

····echo "$(date): ${USER}: $@" >> $removelog

··fi

··/bin/rm "$@"

··exit 0

Первая условная инструкция в проверяет ввод пользователя и показывает сообщение, описывающее порядок использования сценария, если он вызван без аргументов. Затем, в строке , сценарий проверяет, не содержит ли аргумент $1 флаг −s; если содержит, сценарий пропустит операцию журналирования. В заключение сценарий записывает текущее время, имя пользователя и текст команды в файл $removelog , и передает свои параметры фактической программе /bin/rm .

Обычно при установке программ-оберток, таких как сценарий logrm, обертываемые команды переименовываются, а оберткам присваиваются имена оригинальных команд. Если вы решите пойти этим путем, убедитесь, что обертка вызывает переименованную программу, а не саму себя! Например, если вы переименовали /bin/rm в /bin/rm.old , а сценарий сохранили с именем /bin/rm , тогда в предпоследней строке сценария замените вызов /bin/rm на /bin/rm.old.

Как вариант, можно определить псевдоним, чтобы заменить стандартный вызов rm вызовом команды logrm:

alias rm=logrm

В любом случае вам потребуются права доступа к каталогу /var/log на выполнение и запись, что может не соответствовать настройкам системы по умолчанию.

Давайте создадим несколько файлов, удалим их и затем заглянем в журнал remove.log , как показано в листинге 2.11.

Листинг 2.11.Тестирование сценария logrm

$ touch unused.file ciao.c /tmp/junkit

$ logrm unused.file /tmp/junkit

$ logrm ciao.c

$ cat /var/log/remove.log

Thu Apr··6 11:32:05 MDT 2017: susan: /tmp/central.log

Fri Apr··7 14:25:11 MDT 2017: taylor: unused.file /tmp/junkit

Fri Apr··7 14:25:14 MDT 2017: taylor: ciao.c

Отлично! Обратите внимание, что пользователь susan удалил файл /tmp/central.log во вторник.

В сценарии может возникнуть проблема с правами доступа к файлу журнала. Файл remove.log либо будет доступен всем для записи, и тогда любой пользователь сможет удалить его содержимое, например, командой cat /dev/null > /var/log/remove.log, или он вообще не будет доступен для записи, и тогда сценарий просто не станет журналировать события. Можно, конечно, попробовать установить привилегию setuid, чтобы сценарий запускался с правами суперпользователя root, открывающими доступ к файлу журнала. Но тут есть две проблемы. Во-первых, это очень плохая идея! Никогда не давайте сценариям привилегию setuid! Она позволяет выполнить команду с правами определенного пользователя, независимо от того, кто ее вызывает, что ухудшает безопасность системы. Во-вторых, можно оказаться в ситуации, когда пользователи имеют право удалять свои файлы, но сценарий не дает сделать этого, потому что действующий идентификатор пользователя, установленный привилегией setuid, будет унаследован командой rm, что нарушит ее работу. Может возникнуть большой конфуз, если обнаружится, что пользователи не имеют права удалять даже свои собственные файлы!

Для файловых систем ext2, ext3 и ext4 (используются по умолчанию в большинстве дистрибутивов Linux), существует другое решение — с помощью команды chattr установить на файл журнала специальное разрешение «только для добавления», что сделает его доступным для записи всем пользователям без всякой опасности. Еще одно решение: записывать сообщения в системный журнал с помощью замечательной команды logger. Журналирование операций с командой rm в этом случае будет выглядеть так:

logger −t logrm "${USER:-LOGNAME}: $*"

Эта команда добавит в поток данных системного журнала, недоступный рядовым пользователям для изменения, запись с меткой logrm, именем пользователя и выполненной командой.

Если вы решите использовать команду logger, прочитайте страницу справочного руководства syslogd(8), где написано, как убедиться, что ваша конфигурация не отбрасывает события с приоритетом user.notice. Обычно эта настройка находится в файле /etc/syslogd.conf .