Вопросы Теги

Как проверить, может ли пользователь использовать crontab?

В более ранних версиях MacOSX простым исправлением было изменение владельца /usr/local, чтобы можно было создавать в нем каталоги без использования sudo. Однако, начиная с High Sierra, это больше невозможно -, операционная система полностью запрещает это.

Таким образом, обходной путь заключается в том, чтобы создать эти необходимые папки как root, а затем изменить их владельца на себя или на группу, членом которой вы являетесь, и убедиться, что они доступны для записи для вас, например:

sudo mkdir /usr/local/Frameworks

Сменить владельца на себя:

sudo chown YOURUSERNAME /usr/local/Frameworks

Чтобы изменить владельца группы администраторов и предоставить права на запись:

sudo chgrp admin /usr/local/Frameworks
sudo chmod g+w /usr/local/Frameworks

К сожалению, вам придется продолжать делать это для всех каталогов, которые нужно будет создать в /usr/local.

0
04.04.2021, 22:02
1 ответ
VISUAL=true EDITOR=true crontab -e 2>/dev/null

Эта команда не работает, но ее статус выхода указывает, может ли ваш скрипт (и, следовательно, пользователь, выполняющий его ), использовать crontab.

Чтобы протестировать другого пользователя, добавьте -u username(, если ваш crontabподдерживает -u), но это будет работать только в том случае, если ваш скрипт достаточно привилегирован для запуска crontabот имени другого пользователя. Непривилегированный скрипт -получит статус выхода 1, как если бы другой пользователь не мог использовать crontab. В качестве альтернативы используйте sudo -u username …(, но sudoможет или не может позволять вам устанавливать среду, в зависимости от ее конфигурации ).

Недостатки:

  • Ваш crontabможет поддерживать или не поддерживать-e(POSIX говорит, что это необязательно ).
  • Метод точно не проверяет, «что пользователь может использовать crontab», а скорее «что сценарий может использовать crontabот имени пользователя». Это может быть или не быть тем, что вы хотите. Если под «конкретным пользователем» вы подразумеваете «пользователя, запускающего скрипт», то вам не нужен -u, и метод должен работать нормально.

Преимущество:

  • Вам не нужно анализировать /etc/cron.allowи /etc/cron.deny(, они находятся в каталоге, определенном реализацией -, если вообще используются ); вам не нужно строить какую-либо логику, чтобы составить окончательный ответ. crontabсам все сделает за вас.

Примечания:

  • В моем Kubuntu 18.04.5 LTS crontabпроверяет VISUALперед EDITOR, но спецификация POSIX упоминает только EDITOR. Вот почему этот ответ устанавливает обе переменные.
  • Может показаться, что crontab -lлучше, но если crontab не существует, то команда вернет ошибку (по крайней мере, так она себя ведет в моей Kubuntu ).
  • В моем Kubuntu 18.04.5 LTS, если crontab не существует, VISUAL=true crontab -eбудет не устанавливать пустой. Я не уверен в других реализациях. В случае несуществующего crontab установка пустого может быть побочным эффектом.
2
28.04.2021, 22:54

Теги

Похожие вопросы