Почему cron — самый опасный инструмент в Linux

Вот важная новость с фронта ИИ: SrvTrantor 13 минут назад Почему cron — самый опасный инструмент в Linux Простой 11 мин 389 Блог компании RUVDS. com Linux * Информационная безопасность * Серверное администрирование * Системное администрирование * Мнение Демон cron знаком каждому, кто админит Linux. Он крутит бэкапы, чистит временные файлы и запускает скрипты, о которых все уже давно забыли.

Однако многие не знают, что одна строка в crontab способна снести данные, забить диск, устроить форк-бомбу или открыть лазейку для хакера. Под катом я разберу, когда и как именно cron становится опасным, и какие команды помогут держать его в узде. Откуда взялся cronCron появился ещё в классическом Unix.

Технические детали

В Version 7 Unix, выпущенной Bell Labs в 1979 году, он уже входил в систему и запускался при переходе в многопользовательский режим. Системный планировщик задач раз в минуту открывал /usr/lib/crontab, сверял строки со временем и выполнял соответствующие команды. В первые версии cron входил один системный crontab, немного регулярных задач и обслуживание самой системы.

Когда Unix начали использовать на машинах с десятками учётных записей, демон давал сбой. Чтобы такого не происходило, в Университете Пердью сделали cron с очередью событий и пользовательскими crontab, который получал доступ к расписанию. Позже эта линия попала в Unix System V, BSD и коммерческие Unix-системы.

В конце 1980 годов Пол Викси выпустил свою реализацию планировщика. С ним обычно и связывают формат, который многие до сих пор видят в Linux: crontab, пять полей времени, команда в конце строки, переменные окружения внутри расписания, @reboot, @daily и интервалы вида */5. Однако в Red Hat-подобных системах сегодня чаще всего стоит cronie, а в Debian и Ubuntu используется Vixie cron 3.

Отраслевые последствия

Но эта разница практически ни на что не влияет. Сейчас через cron запускают бэкапы, чистку /tmp, самодельную ротацию логов, обновление кеша, проверку сертификатов, выгрузки для отчётов и небольшие сервисные скрипты. Из-за того, что одни строки добавляет текущая команда, другие прилетают с пакетами, а третьи остаются после миграций, через пару лет в crontab набирается много непонятных команд.

Зачастую их даже не чистят. Но проблему создают не только они, поэтому дальше я разберу каждое «опасное» место этого инструмента. Ошибки в cron не видны Когда cron запускает процесс, у него нет терминала и интерактивной shell-сессии.

Если скрипт завершится с ошибкой, то вы её не увидите. Всё, что программа пишет в stdout или stderr, cron попытается отправить владельцу crontab или адресу, указанному в MAILTO. Когда-то это действительно работало, ведь на серверах был настроен локальный почтовый агент, системную почту читали, а сообщения об ошибках не терялись.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.