Наскільки безпечно зберігати сценарії, що не належать корінню, у /etc/init.d?

У мене є програма, яка працює як демон і керується скриптом в /etc/init.d
Іноді нам потрібно змінити деякі параметри запуску / контролю цих сценаріїв, а потім перезапустити демон. Ці сценарії мають лише дозвіл на запис для кореневого користувача, тому під час редагування цих скриптів мені потрібні привілеї root.

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

Чи прийнятно зберігати деякі некорінні файли, що належать до каталогу /etc/init.d?
Або це абсурд, порушує природний порядок системи?

Що відразу спадає на думку, це непривілейований користувач, який може запускати речі під завантаженням як root , що бажано для сухарів, які:

• Хочете збільшити привілеї інших облікових записів
• Хочете використовувати ваш сервер для розміщення негідних послуг
• Хочете запустити боти IRC / спаму, якщо сервер перезавантажиться
• Хочете пінг материнського корабля, щоб сказати "Я знову" і, можливо, завантажити новий корисний вантаж
• Хочете прибрати їхні сліди
• ... інші негаразди.

Це можливо, якщо ваш непривілейований користувач якось порушений, можливо, через інший сервіс (http / тощо). Більшість зловмисників швидко запускають lsабо findвмикають усе, /etcлише щоб побачити, чи існують такі можливості, є снаряди, написані на різних мовах, якими вони користуються, що робить це просто.

Якщо ви керуєте сервером віддалено, в основному за допомогою SSH, є дуже хороший шанс, що ви навіть цього не побачите, якщо не перевірите сценарій init, оскільки ви не побачите вихід під час завантаження (хоча, ви повинні використовувати щось, що перевіряє хеши цих скриптів на відомі хеші, щоб побачити, чи щось змінилося, або програмне забезпечення для управління версіями тощо)

Ви точно не хочете, щоб це сталося, root дійсно повинен володіти цим сценарієм init. Ви можете додати користувача розробки до списку sudoers, щоб було досить зручно оновлювати скрипт, але я б радив не допускати доступу недописуваного запису до нічого в init.d

На додаток до дуже хороших моментів, зроблених Тімом Постом, я додам, що для налаштування, де декілька людей повинні мати можливість натиснути зміни на сервер, слід розглянути можливість використання якоїсь системи управління конфігурацією.

Якщо ви, наприклад, використовуєте маріонетку, шеф-кухаря або cfengine, ви можете змусити відповідних користувачів редагувати файли локально, а потім висунути зміни за допомогою керування конфігурацією. Як саме це налаштувати, звичайно, буде залежати залежно від того, яку систему ви використовуєте, але якщо правильно налаштувати, вона буде включати в себе програмне забезпечення для версій, що полегшує повернення до попередньої версії конфігураційного файлу, коли (зауважте: коли , ні, якщо !) хтось помилився. Це також полегшить вам копіювання конфігурації в окрему тестову систему тощо.