Разрешить только сценарий оболочки, но не команду

Простой ответ: Невозможно заставить ваших пользователей использовать ваш сценарий оболочки.

Причина этого довольно проста; сценарий оболочки - это интерпретируемая программа. Это означает, что bash (или какой-либо другой процесс оболочки) должен прочитать файл для выполнения команд, которые в нем вызываются.

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

Если вы просто пытаетесь помешать необразованным пользователям замедлить работу вашей системы, существует множество способов сделать это , например, то, что предлагает @mikeserv в комментарии к вашему вопросу. Я могу придумать как минимум пять дополнительных способов **, многие из которых можно было бы использовать в комбинации; Важно понимать, что они небезопасны . На самом деле они не запрещают пользователю использовать команду напрямую вместо сценария оболочки, а также не (и не могут) предотвратить создание пользователем собственной копии сценария оболочки ( который он должен иметь права на чтение, чтобы вообще иметь возможность запускать) и изменяет его по своему усмотрению.

Можно написать короткую программу на C для выполнения функции сценария-оболочки, который компилируется в двоичный исполняемый файл, а затем сделать эту программу на C SUID ***, так что это единственный способ пользователь может запустить команду, о которой вы говорите, но это выходит за рамки моей компетенции и моей компетенции.

Другие варианты включают в себя чрезвычайно странные обходные пути (хаки), такие как установка cronjob для изменения вашего файла sudoers, чтобы разрешить запуск команды только в определенное время дня ... но это становится действительно, очень странным и территорией плохих идей.

Я думаю, что стандартный способ сделать это (хотя до сих пор без принуждения технически подкованных пользователей использовать ваш сценарий оболочки) был бы:

(Я сделаю вид, что ограничивающая команда - ] date .)

1. Убедитесь, что внутри вашего скрипта его вызов date использует абсолютный путь: / bin / date (Вы можете узнать, что это за работает с датой .) Также убедитесь, что ваш сценарий имеет правильный шебанг, чтобы его можно было запустить без необходимости набирать bash ./myscript, но можно просто запустить как . / myscript , и убедитесь, что он доступен для чтения и выполнения всем. ( chmod 555 myscript )
2. Поместите сценарий оболочки в / usr / local / bin / и переименуйте его как date .
3. Убедитесь, что у пользователей есть / usr / local / bin в начале их переменной $ PATH . (Просто войдите в систему как пользователь и запустите echo "$ PATH" .) У них уже должно быть это по умолчанию.Он не обязательно должен быть в самом начале, если он находится на их пути до / bin (или независимо от того, где находится исходная команда date ).

Если его нет на пути, вы можете добавить его, запустив: echo 'PATH = "/ usr / local / bin: $ PATH"' | sudo tee /etc/profile.d/my_path_prefix.sh

Теперь каждый раз, когда пользователь пытается запустить команду напрямую, он фактически запускает ваш сценарий оболочки, потому что каталог, в котором находится сценарий оболочки, появляется первым в его $ PATH .

Гораздо более хитрым решением было бы фактически замаскировать исходный двоичный файл, не помещая другую версию ранее в путь для пользователей, а помещая сценарий оболочки вместо самой команды, на прежнем месте. Используйте на свой страх и риск:

1. Поместите саму команду где-нибудь за пределами обычных каталогов bin , чтобы ни у кого не было ее пути. Вы можете переместить его, например, в / var / local . (Возможно, есть место получше, но это уже взлом, так что это не имеет большого значения, не так ли?)
2. Убедитесь, что вызов date в вашем сценарии-оболочке указывает на новое местоположение для даты - его абсолютный путь: / var / local / date в моем примере.
3. Переместите сценарий оболочки в старое расположение date с исходным именем date .

Главное предостережение заключается в том, что каждый раз, когда кто-либо пытается запустить эту команду, включая системные сценарии инициализации, они вместо этого получат ваш сценарий оболочки.

Это просто взлом, и его нельзя квалифицировать как хорошее системное администрирование. Но это возможно, и вы также можете знать, что это можно сделать. Лучшее решение - это то, что я написал выше.

_{* Исключения из этого связаны с изменением среды и программ, которые ведут себя по-разному, когда они запускаются в интерактивном режиме по сравнению с тем, когда они запускаются из сценария. Однако эти исключения не имеют ничего общего с разрешениями , поэтому они не имеют отношения к этому обсуждению.}

_{** Если вам интересно, спросите о них в комментариях, и я расскажу о них подробнее.}

_{*** НЕ suid root. Если вы это сделаете, просто создайте пользователя, поместите его в группу, которая является единственной, у которой есть разрешение на запуск команды, о которой вы говорите ( chmod 010 или что-то в этом роде), а затем chown ваш недавно скомпилированный двоичный файл оболочки должен принадлежать этому пользователю и установить его бит suid с помощью chmod 4511 .}