Вопрос или проблема
Итак, у меня есть запись, которая выглядит следующим образом в моем файле sudoers:
user1 ALL=(user2) NOPASSWD: /scripts/dir/
Это позволяет user1 запускать все исполняемые файлы в /scripts/dir/ от имени user2 без ввода их пароля, используя команду типа sudo -u user2 /scripts/dir/script. Однако я столкнулся с проблемами, когда исполняемые файлы ожидают, что их будут запускать с окружением user2 ($PATH, $DISPLAY и т.д.). user1 может сделать это, запустив что-то вроде sudo -iu user2 /scripts/dir/script, что имитирует вход в оболочку, но с вышеуказанной записью sudoers это не работает, и им предлагают ввести свой пароль. Существует ли запись sudoers, которая позволит user1 выполнить эту команду или хотя бы иметь возможность загружать .bashrc, .cshrc и т.д. user2 при выполнении команд?
Я нашел опцию SETENV, но она позволяет user1 сохранить свое текущее окружение, а не взять окружение user2. Я мог бы сделать source /home/user2/.bashrc, а затем sudo -Eu user2 /scripts/dir/script; это даст user1 окружение user2, которое будет сохранено с помощью опции -E, но это предполагает, что у user1 есть доступ на чтение к файлу .bashrc и что скрипт не пытается выполнить какие-либо команды, которые user1 не имеет разрешения выполнять.
В руководстве по sudoers говорится следующее об опции -i для sudo:
В качестве особого случая, если указана опция -i (начальный вход) для sudo, sudoers инициализирует окружение независимо от значения env_reset. Переменные DISPLAY, PATH и TERM остаются неизменными; HOME, MAIL, SHELL, USER и LOGNAME устанавливаются на основе целевого пользователя. В AIX (и в системах Linux без PAM) также учитывается содержимое /etc/environment. В системах BSD, если установлен флаг use_loginclass, также применяются переменные path и setenv из /etc/login.conf. Все остальные переменные окружения удаляются.
Что, похоже, указывает на то, что возможно предоставить опцию -i с некоторой конфигурацией sudoers, возможно, предоставив user1 разрешение на выполнение ALL команд или специально разрешив опцию -i в sudoers, но я надеюсь, что существует более тонкий способ достичь этого. Кроме того, похоже, что PATH и DISPLAY будут взяты из окружения user1, что не является тем, что я хочу.
Конечно, я мог бы дать user1 больше прав, чем необходимо, чтобы достичь этого, но это создает риски для безопасности.
Итак, я не смог найти безопасный способ сделать это, поэтому в конечном итоге я использовал опцию SETENV: в записи sudoers, а затем перед тем, как выдавать команды от имени user1, я загружаю .bashrc user2 и предоставляю опцию -E при вызове sudo. Это не безопасный способ достичь того, что я хотел, потому что user1 может настроить свою переменную окружения PATH таким образом, чтобы позволить им выполнять произвольные исполняемые файлы от имени user2.
Ответ или решение
Чтобы разрешить пользователю запускать команды от имени другого пользователя с его окружением в файле sudoers, необходимо учесть несколько аспектов. Ваша проблема заключается в том, что текущая конфигурация sudoers позволяет пользователю (user1) запускать скрипты под именем другого пользователя (user2) без необходимости ввода пароля, но при этом не позволяет сохранить окружение user2. Давайте подробно разберем, как можно достичь желаемого результата, при этом избегая ненужных рисков для безопасности.
Шаги для реализации задачи
-
Изучение текущей записи в sudoers:
Ваша текущая запись:user1 ALL=(user2) NOPASSWD: /scripts/dir/Эта запись позволяет user1 запускать любые исполняемые файлы в директории
/scripts/dir/от имени user2 без запроса пароля. Однако, как вы уже заметили, использование командыsudo -iu user2 /scripts/dir/scriptприводит к запросу пароля, что нежелательно. -
Использование опции -i:
В документации sudo упоминается, что для использования опции-iнеобходимо явно указать её в sudoers. Однако в вашем случае вы хотите избежать широких прав. Решением может быть указание разрешений на использование конкретной команды с опцией-i.Например, можно добавить следующее:
user1 ALL=(user2) NOPASSWD: /bin/su - user2Эта запись разрешит user1 запускать команду
/bin/su - user2без необходимости ввода пароля. Тем не менее, это может также предоставить больше прав, чем необходимо, поэтому применять это решение следует с осторожностью. -
Сохранение окружения:
Ваша идея использоватьsource /home/user2/.bashrcи затем выполнить команду сsudo -Eu user2также имеет право на существование, но требует, чтобы user1 имел доступ к файлам конфигурации окружения user2. Это может быть небезопасно, так как user1 может неосознанно или умышленно изменить своё окружение, что приведет к потенциальным проблемам с безопасностью. -
Использование переменной окружения SETENV:
УказаниеSETENVв sudoers действительно позволяет вам сохранять переменные окружения, однако это может привести к возможным уязвимостям, поскольку user1 может изменять свои переменные среды. Вам нужно внимательно подойти к данной конфигурации, чтобы ограничить доступ к определённым критическим переменным окружения. -
Комбинированный подход:
Можно воспользоваться следующим способом, чтобы быть уверенным в том, что user1 будет запускать команды с окружением user2, но при этом без угрозы безопасности. Создайте небольшой обертку в виде скрипта, который будет включать всё необходимое окружение user2:#!/bin/bash source /home/user2/.bashrc exec "$@"Назовем этот скрипт, например,
run_as_user2.sh, и разместим его в директории, доступной user1. Затем вы можете настроить sudoers для разрешения выполнения этого скрипта.В sudoers:
user1 ALL=(user2) NOPASSWD: /path/to/run_as_user2.sh /scripts/dir/*
Заключение
Вам следует выбирать наиболее сбалансированный подход между функциональностью и безопасностью. Используйте ограниченные права доступа для команд, которые user1 должен запускать, а также старайтесь минимизировать возможности изменения критически важных переменных окружения. Такой подход поможет вам сохранить высокую степень контроля над разрешениями и ограничениям системы при использовании sudo.