Использование mkdir в моем скрипте bash и отказ в получении разрешения - PullRequest
Новая
       21

Использование mkdir в моем скрипте bash и отказ в получении разрешения

0 голосов
/ 19 мая 2019

У меня есть скрипт, которым владеет root в каталоге, принадлежащем root. Часть сценария заключается в создании каталога, который будет содержать входы / выходы этого сценария. У меня также есть ссылка на этот скрипт, чтобы любой пользователь мог запустить его из любого места. я не использую временный каталог, так что эта информация может быть использована в качестве журналов позже. Проблема: когда пользователь пытается запустить скрипт, он получает ошибку, что каталог не может быть создан из-за отказа в доступе. Вопросы: почему скрипт не сделает каталог таким, чтобы root владел им независимо от того, какой пользователь его запускает? как скрипт может сделать каталог таким, чтобы root владел им вместо пользователя, который его запускал? эта информация нужна только сценарию, а не пользователю.

Дополнительная информация: каталог: drws - s - x. сценарий: -rwxr-xr-x. (если вам нужно знать) строка в скрипте просто: mkdir $ tempdirname

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

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

1 Ответ

0 голосов
/ 19 мая 2019

Скрипты запускаются от имени пользователя, который их запускает;владелец файла и / или каталога, в котором он находится, не имеет значения (за исключением того, что пользователю необходимо разрешение на чтение и выполнение для файла и каталога).У двоичных исполняемых файлов может быть установлен бит setuid, чтобы они всегда выполнялись как владелец файла.Старые unixes допускали это и для сценариев, но это приводило к дыре в безопасности, поэтому setuid игнорируется в сценариях в современных unixes / Linuxes.

Если вам нужно разрешить обычным пользователям запускать сценарий от имени пользователя root, есть парадругих способов сделать это.Одним из них является добавление сценария в файл / etc / sudoers, чтобы пользователи могли использовать sudo для запуска его от имени пользователя root.ВНИМАНИЕ: если вы испортили свой файл / etc / sudoers, может быть сложно восстановить доступ, чтобы очистить его и вернуться в нормальное состояние.Сначала сделайте резервную копию, не редактируйте ее ни с чем, кроме visudo, и я рекомендую открыть корневую оболочку, поэтому, если что-то пойдет не так, у вас будет доступ с правами root, вам нужно исправить это без необходимости продвигать по sudo,Строка, которую вам нужно добавить, будет выглядеть примерно так: 

%everyone ALL=NOPASSWD: /path/to/script

Если вы хотите сделать это автоматически, чтобы пользователям не приходилось явно использовать sudo для запуска сценария, выможно запустить скрипт следующим образом: 

#!/bin/bash

if [[ $EUID -ne 0 ]];
then
    exec sudo "$BASH_SOURCE" "$@"
fi

РЕДАКТИРОВАТЬ: мне пришла в голову более простая версия;вместо того, чтобы заново запускать сценарий под sudo, просто замените символическую ссылку на скрипт-заглушку, как этот: 

#!/bin/bash
exec sudo /path/to/real/script "$@"

Обратите внимание, что с этой опцией запись / etc / sudoers должна ссылаться нареальный путь сценария, а не символическая ссылка.Также, если скрипт не принимает аргументы, вы можете оставить "$@" выключенным.Или используйте его, это не принесет никакого вреда.

Если возиться с / etc / sudoers звучит слишком страшно, есть еще один вариант: вы можете «скомпилировать» скрипт с помощью shc (который на самом деле просто создает двоичную исполняемую оболочку вокруг него) и делает этот setuid root (chmod 4755 /path/to/compiled-script; chown root /path/to/compiled-script).Поскольку он находится в двоичной оболочке, setuid будет работать.

...