Назад | Перейти на главную страницу

Возможно ли переключиться на «ролевую» учетную запись с использованием переадресации агентов sudo и ssh в дальнейшем?

Я хочу создать «ролевые» учетные записи для нескольких административных задач, которые обычно не требуют прав root. Например, рассмотрим www-admin пользователь, поддерживающий файлы в /var/www.

Мне кажется, что это самый простой способ решить проблемы с правами доступа к файлам: он гарантирует, что каждый, принимающий эту роль, создает файлы с разрешением / владением, чтобы все остальные с этой ролью могли редактировать / читать, без использования группового доступа с возможностью записи Режим.

Пользователи могли переключиться на эту роль, используя sudo su www-admin --preserve-environment --shell /bin/bash или аналогичная команда.

У меня есть две проблемы:

  1. Иногда www-admin роль должна выполнять sudo задачи. Но после перехода в роль sudo запросит пароль для ролевой учетной записи. Я не хочу устанавливать это и делиться этим со всеми. Могу я вместо этого заставить sudo запрашивать оригинал пароль пользователя?

  2. После переключения на роль пользователям может потребоваться использовать SSH, например, для проверки репозиториев git. Но разрешения SSH-сокета аутентификации (конечно) настроены таким образом, что «роль» пользователя не может считывать из него.

Я уверен, что это довольно распространенная проблема в административных командах, состоящих из нескольких человек. Как решить эту проблему?

Также я заметил, что sudo На странице руководства написано: «Реальный (не эффективный) ID пользователя вызывающего пользователя ...». Итак, если есть разница между реальным и эффективным идентификатором пользователя, поможет ли это здесь ...?

Может, лучше вообще не менять «роли»?

Вместо этого вы можете использовать ACL, чтобы гарантировать, что некоторый набор общих файлов можно редактировать без какого-либо переключения.

Также с помощью списков ACL вы можете принудительно ограничить «демонов» доступом R / O в случае необходимости.

- sudo возможно, это был в основном способ преодолеть стандартную модель доступа UNIX User / Group / Others (и еще одну, которую можно описать как «root» или «никто»), и, тем временем, она все еще широко используется, современные системы UNIX получили более мелкозернистый доступ модели другие, что вышеупомянутый.