Запуск новых рабочих мест от имени непривилегированных пользователей

Какой канонический способ заставить выскочившее задание изменить свой ИД пользователя и запустить скрипт как непривилегированный пользователь?

Очевидно, что можно использовать suили sudo, но это кажется хакерским (и может генерировать ненужные строки журнала).

В upstart v1.4 setuid и setgid изначально поддерживаются в конфигурационном файле.

Спрашивая на канале #upstart на freenode, официальный ответ на этот вопрос таков:

Будущий выпуск Upstart будет иметь встроенную поддержку для этого, но сейчас вы можете использовать что-то вроде:

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

Как насчет использования start-stop-daemon?

exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd

Из кулинарной книги Upstart :

Рекомендуемый метод для систем Debian и Ubuntu - использовать вспомогательную утилиту start-stop-daemon. […] start-stop-daemonНе накладывает ограничения PAM («сменный модуль аутентификации») на процесс, который он запускает.

Примечание: start-stop-daemonне поддерживается в RHEL.

Есть несколько способов сделать это, все с немного другой семантикой, особенно относящейся к членству в группе:

• setuidgid поместит вас в указанную вами группу.

  • Исходные daemontools 'поместят setuidgidвас только в эту группу, поэтому вы не сможете получить доступ к файлам, принадлежащим другим группам, членом которых вы являетесь.
  • setuidgidОт DaemonTools-бис а setuidgidиз Nosh набора инструментов оба имеют -s(он же --supplementary) вариант , который поставит вас в этой группе, а также поставить вас во всех дополнительных групп для пользователя , который вы укажете.

• Использование, как newgrpтолько вы станете менее привилегированным пользователем, добавит одну группу к вашему набору групп, но также создаст новый подоболочек, что затруднит использование внутри скриптов.

• start-stop-daemon сохраняет членство в вашей группе и делает гораздо больше, чем просто setuid / setgid.

• chpst -u username:group1:group2:group3... commandnameпозволит вам точно указать, какие членства в группах следует принять, но (в Ubuntu ) он поставляется только с runitпакетом, который является альтернативой upstart.

• su -c commandname usernameсобирает все членство в группах с именем пользователя, как и раньше sudo -u username commandname, так что они, вероятно, путь к наименьшему изумлению.

Используйте setuidgidиз пакета daemontools.

Документация здесь: http://cr.yp.to/daemontools/setuidgid.html

На экземпляре Ubuntu 10.10 на Amazon EC2 мне повезло с этой start-stop-daemonкомандой.

Я также боролся с некоторыми другими выскочившими строфами . Я вызываю приложение Python с конкретными virtualenvи некоторыми параметрами для моей исполняемой программы.

Вот что сработало для меня.

script
  export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
  exec start-stop-daemon --start  --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script

PYTHONPATH, Чтобы получить некоторые пакеты , установленные из источника в PYTHON путь модуля при выполнении этого выскочки работы. Я должен был делать все по абсолютному пути, потому что chdirстрофа, похоже, не работала.

Я использовал CentOS 6, и я не смог заставить рекомендованный хак (для Upstart 0.6.5) работать на меня, ни трюк 'su', потому что количество задействованных вилок (4, я думаю) не отслеживалось ожидаемым форком или ожидайте демона.

В конце концов я просто сделал

chown user:group executable
chmod +s executable

(т.е. установите бит setuid и смените владельца).

Возможно, это не самый безопасный метод, но для внутреннего проекта НИОКР в нашем случае это не имело значения.

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

Вы также можете изменить тайм-аут кэша паролей sudo . Но я не рекомендую его, если ваша машина не физически защищена (то есть вы считаете, что маловероятно, что прохожий попытается получить доступ к sudo).

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

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

В CentOS 6, upstart 0.6.5, вот что сработало для меня.

script

    exec su user_name << EOF
        exec /path/to/command [parameters...]
EOF

end script

или же :

script

    exec su user_name << EOF
       ..... what you want to do ....
EOF

end script

При использовании

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

процесс работы не может быть остановлен initclt stop. Я думаю, что причина в том, что:

1. the job forked and the main process is not tracked.
2. the main process changed its process group,because of `su -c`