Могу ли я сделать файл доступным только для сценария, а не для пользователя?


11

У меня есть пользователь с ограниченным доступом в системе (то есть он не sudoer); давайте назовем его Боб .

У меня есть скрипт или бинарный файл, которому я, системный администратор, доверяю, и у меня не возникло бы проблем с его запуском от имени пользователя root; давайте назовем сценарий get-todays-passphrase.sh. Задача этого сценария состоит в том, чтобы читать данные из «частного» (принадлежащего пользователю / группе, отличному от Боба или даже корневого) файла, расположенного в нем /srv/daily-passphrases, и выводить только определенную строку из файла: строку, соответствующую текущей дате ,

Таким пользователям, как Боб, не разрешается знать парольную фразу завтрашнего дня, даже если она указана в файле. По этой причине файл /srv/daily-passphrasesзащищен разрешениями Unix, поэтому пользователям без полномочий root, таким как Bob, не разрешен прямой доступ к файлу. Однако им разрешено запускать get-todays-passphrase.shскрипт в любое время, который возвращает «отфильтрованные» данные.


Подводя итог ( версия TL; DR ):

  1. Боб не может прочитать защищенный файл
  2. Скрипт может читать защищенный файл
  3. В любое время Боб может запустить скрипт, который может прочитать файл

Возможно ли сделать это в разрешениях файлов Unix? Или, если Боб запускает сценарий, будет ли он всегда обречен на запуск с теми же разрешениями, что и Боб?

Ответы:


13

Это на самом деле распространено и довольно просто. sudoпозволяет ограничить конкретные приложения, которые пользователь может вызывать. Другими словами, вам не нужно давать им все права или ничего; вы можете дать им sudoразрешения на запуск определенной команды . Это именно то, что вы хотите, и это очень распространенная практика для таких вещей, как предоставление пользователям возможности загружать Git-репозитории через SSH и тому подобное.

Для этого все, что вам нужно сделать, это добавить строку, /etc/sudoersкоторая выглядит примерно так

bob ALL=(root) NOPASSWD: /path/to/command/you/trust

(Эта NOPASSWD:часть не обязательна, но в этой ситуации она очень распространена.) В этот момент bobможно вызывать с /path/to/command/you/trustпомощью sudo, но не более того.

Тем не менее, предоставление кому-то прав - то, что мы делаем здесь - может быть не совсем то, что вы хотите. Примечательно, что если в вашем скрипте были какие-либо изъяны, вы рискуете позволить своему ящику укорениться. По этой причине вы можете вместо этого предпочесть создать пользователя, specialuserкоторому будет принадлежать специальный файл, скажем, затем chownфайл для них, и /etc/sudoersсделать так, bobчтобы этот специальный пользователь был пользователем. В этом случае строка, которую вы добавляете, sudoersбудет просто

bob ALL=(specialuser) NOPASSWD: /path/to/command/you/trust

7
Я бы посоветовал не идти «корневым» путем - создать для этого специального пользователя / группу.
Гюнтберт

Хорошая точка зрения; Я исправлю ответ.
Бенджамин Поллак

7

Предисловие:

Как было отмечено в комментариях и по причинам, изложенным в этом ответе, ядро Linux игнорирует бит setuid / setguid при обработке скрипта. Я не собираюсь дублировать ответ Бенджамина, но вместо этого заменю скрипт на executetabe, чтобы сделать мой ответ правильным.


Краткий ответ: используйте setgid

Подробные шаги:

  1. Создать новую группу (например, readpass)
  2. Сделайте эту группу владельцем файла парольной фразы sudo chown :readpass thatfile
  3. Сделать файл доступным для чтения только по его группе sudo chmod g=r,o= thatfile
  4. Сделайте ваш исполняемый sgid readpass:sudo chmod g+s thatfile

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


2
Setgid и setuid не так легко работают со скриптами, верно?
Муру

1
Вы не можете создать скрипт setgid в Linux: бит setgid будет игнорироваться. Вместо этого добавьте правило sudo, позволяющее bob работать thatfileс группой readpass.
Жиль "ТАК - перестать быть злым"
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.