Запуск початкових завдань як непривілейованих користувачів

Який канонічний спосіб змінити завдання для початківців змінити його userid та запустити сценарій як непривілейований користувач?

Очевидно, що можна використовувати suабо sudo, але це здається хитким (і може генерувати непотрібні лінії журналів).

З upstart v1.4, configid та setgid підтримуються в конфігураційному файлі.

Запитуючи про канал #upstart на freenode, офіційним питанням є:

У майбутньому випуску Upstart буде підтримка для цього, але зараз ви можете використовувати щось на зразок:

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

Як щодо використання старт-стоп-демон?

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

З кулінарної книги Upstart :

Рекомендованим методом для систем Debian та Ubuntu є використання утиліти helper start-stop-daemon. […] start-stop-daemonНе вводить обмеження PAM ("модуль автентифікації, що підключається") для процесу, який він починає.

Примітка: start-stop-daemonне підтримується в RHEL.

Існує кілька способів зробити це, все з дещо різною семантикою, особливо що стосується членства в групі:

• setuidgid переведе вас у вказану групу.

  • Оригінальні демомонтоли "помістять setuidgidвас лише до цієї групи, тому ви не зможете отримати доступ до файлів, що належать до інших груп, до яких ви входите.
  • Як setuidgidвід daemontools-encore, так і setuidgidз набору інструментів nosh, є опція -s(aka --supplementary), яка введе вас у цю групу, а також поставить вас у всі додаткові групи для користувача, якого ви вказали.

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

• start-stop-daemon зберігає вашу групову приналежність і робить набагато більше, ніж просто налаштований / нестандартний.

• 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 . Але я не рекомендую це, якщо ваша машина не є фізично захищеною (тобто, ви вважаєте, що навряд чи перехожий намагатиметься отримати доступ до судо).

Є вагома причина, що існує дуже мало способів виконувати привілейовані дії та виконувати непотрібні необхідні реєстрації. Ослаблені обмеження становлять загрозу безпеці для вашої системи, а відсутність ведення журналу означатиме, що немає можливості дізнатися, що сталося, коли ви були порушені.

Якщо розмір ваших журнальних файлів викликає занепокоєння, то, мабуть, щось не так. Судо генерує лише один рядок за використання за звичайних умов.

У CentOS 6, на початку 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`