Ідіоматичне розташування для файлових сокетів на системах Debian


13

Я пишу демон-процес для системи Debian, Cяка використовує сокет домену Unix .

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


Чому ви просто не дозволите це налаштувати?
BatchyX

3
@BatchyX Ну, якесь значення за замовчуванням (а не змушувати кожного адміністратора приймати рішення повністю самостійно), безумовно, може бути приємним. :)
CVn

Відповіді:


17

Вони зазвичай зустрічаються в /tmpабо їх підкаталозі. Зауважте, що все в /tmpпідлягає стиранню при відключенні - не те, що воно обов'язково стирається, просто будьте уважні, що це може бути , тому якщо ви використовуєте це, перевірте, чи потрібно кожного разу створювати свій підкаталог. Ви хочете використовувати підкаталог, якщо ви хочете обмежити доступ через дозволи, оскільки /tmpце читається у всьому світі.

/runі /var/run(які можуть бути пов’язані між собою) використовуються аналогічно, але вони, як правило, монтуються як файлові системи tmpfs - це означає, що вони створюються під час завантаження і знаходяться в пам'яті , а не на диску (тому не використовуйте це як місце для скидання велика кількість даних). Для розетки, можливо, це вдалий вибір.

Зауважте, що /runі всі інші каталоги, згадані тут, крім них /tmp , підлягають запису лише під коренем. Для системного процесу це нормально, але якщо програму може запускати непривілейований користувач, ви або хочете /tmpдесь використати або створити постійний каталог і встановити дозволи на нього, або використовувати розташування в $ HOME користувача.

Можливо створити каталог у /usr/share(або /usr/local/share) під час встановлення. Довідники та вміст потенційно не пожинають у чоботях, як це було б у /tmpабо /run. Однак, як в коментарях зазначає jordanm , це /usrможе бути встановлено лише для читання, і вказівки щодо ієрархії файлової системи linux відображають це . Звичайно, він не може бути доступний лише для читання, коли встановлено вашу програму, тому якщо вам зручно створювати там сокет, ви можете залишити його та використовувати його пізніше (ви все одно зможете записати в сокет, навіть якщо файл доступний лише для читання).

Якщо ви хочете десь наполегливі через чоботи, які не зможуть встановити лише для читання, /etcце досить безпечна ставка, оскільки це часто використовується для загальносистемних конфігурацій та повторних конфігурацій. OTOH, можливо, існують системи, де пристрій, що лежить в основі всієї кореневої файлової системи, є лише для читання (наприклад, вбудовані системи), з / tmp та / запускається на іншому пристрої (можливо, tmpfs в пам'яті). Отже, здається, дві найбільш надійні стратегії:

  • Встановіть сокет на постійне місце, коли програма встановлена.

  • Створіть каталог у /runабо /var/runпід час виконання та покладіть сокет туди.

  • Зробіть те саме, що тільки в /tmp.

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

Нарешті, як BatchyX підняв, ви повинні принаймні запропонувати варіант конфігурації для цього, відмовившись від вибору за замовчуванням.


2
/runабо /var/runтакож часто використовується для кореневих процесів.
BatchyX

Правильно. Це навіть більше tmp ніж /tmp. Я відредагую це.
goldilocks

/usrможна монтувати лише для читання. Файли ніколи не повинні створюватися там під час виконання. Інші пропозиції хороші.
jordanm

1
Дякую всім за ваш внесок, обговорення було дуже інформативним. Я вирішив зробити місце за замовчуванням, /tmp/.APPNAME/.APPSOCKоскільки демон не потребує постійних даних.
recursion.ninja

1
Ще одна ключова відмінність між /tmpі /run, полягає в тому, що тільки root має дозволи на запис /run.
BatchyX
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.