Предлагаемые замены на самом деле являются лишь частями новых версий команды init: для варианта systemd это модули таймера, а для варианта Upstart идея заключается в возможности создания повторяющихся событий для запуска заданий. В конечном итоге оба варианта команды init могут запускать задачи от имени любого пользователя; они обладают также некоторыми преимуществами, такими как специальный вход в систему.
Однако реальность такова, что ни версия systemd, ни версия Upstart не обладают в данный момент всеми возможностями утилиты cron. Более того, когда они будут способны к этому, потребуется обратная совместимость для поддержки всего, что основано на службе cron. По этим причинам формат cron вряд ли исчезнет в ближайшее время.
7.7. Планирование единовременных задач с помощью службы at
Чтобы запустить задание в будущем один раз без помощи службы cron, воспользуйтесь службой at. Например, чтобы запустить команду myjob в 22:30 вечера, введите такую команду:
$ at 22:30
at myjob
Завершите ввод, нажав сочетание клавиш Ctrl+D. Утилита at считывает команды из стандартного ввода.
Чтобы убедиться в том, что задание запланировано, используйте команду atq. Чтобы его удалить, запустите команду atrm. Можно также указать день для выполнения задания, добавив дату в формате ДД.ММ.ГГ, например, так: 22:30 30.09.15.
О команде at больше нечего добавить. Хотя она используется нечасто, она может пригодиться тогда, когда вам необходимо сообщить системе, чтобы она выключилась в будущем.
7.8. Идентификаторы пользователей и переключение между пользователями
Мы рассказывали о том, каким образом setuid-команды вроде sudo и su позволяют вам сменить пользователя, а также упомянули о системных компонентах типа login, которые контролируют пользовательский доступ. Возможно, вам интересно, как работают эти составляющие и какую роль играет ядро в переключении между пользователями.
Существует два способа изменить идентификатор пользователя, и оба они используются ядром. Первый способ — с помощью исполняемого файла setuid, о котором рассказано в разделе 2.17. Второй способ — используя семейства системных вызовов setuid. Есть несколько различных версий таких вызовов, которые охватывают всевозможные идентификаторы пользователей, связанные с процессами, как вы узнаете далее.
Ядро обладает набором правил относительно того, что дозволено процессу, а что — нет. Приведу три основных правила.
• Процесс, запущенный как корневой (userid 0), может использовать команду setuid, чтобы стать любым другим пользователем.
• На процесс, запущенный не в качестве корневого, накладываются строгие ограничения по использованию команды setuid; в большинстве случаев он не может ее использовать.
• Любой процесс может выполнить setuid-команду, если у него есть соответствующие права доступа к файлам.
примечание
Переключение между пользователями никак не затрагивает пароли или имена пользователей. Эти понятия относятся исключительно к пространству пользователя, как вы уже видели на примере файла /etc/passwd в подразделе 7.3.1. Дополнительные подробности о том, как это работает, — в разделе 7.9.
Принадлежность процессов, эффективный, реальный и сохраненный идентификатор пользователя. Наш рассказ об идентификаторах пользователя до сего момента был упрощенным. В действительности каждый процесс снабжен несколькими идентификаторами пользователя. Мы описали
В современных системах различие между эффективным и реальным идентификаторами пользователя приводит к такой путанице, что большая часть документации, посвященной принадлежности процессов, является неверной.
Представляйте себе эффективный идентификатор пользователя как