Jump to content
Калькуляторы

Проблема с правами доступа systemd

Подскажите, у меня уже фантазия заканчивается.

 

Есть сервер на Ununtu Server 20, как водится, с systemd.

Мне нужно на этом сервере запустить NSD.

 

Первоначально я создал каталог /custom/nsd, и NSD полностью крутился внутри него (в этом каталоге были конфиги, файлы зон, а также подкаталоги var и tmp).

Конфигурация была такая:

server:
        username: nsd
        identity: "unknown server"
        hide-version: yes
        chroot: "/custom/nsd"
        zonesdir: "/custom/nsd"
        pidfile: "var/nsd.pid"
        database: ""
        zonelistfile: "var/zone.list"
        xfrdfile: "var/xfrd.state"
        xfrdir: "tmp/"
        round-robin: yes
        server-count: 2
        interface: 127.0.0.201
        ip-transparent: no
        do-ip4: yes
        do-ip6: no
        logfile: "var/nsd.log"
        verbosity: 1
#       log-time-ascii: yes

remote-control:
        control-enable: yes
        control-interface: 127.0.0.1
        control-port: 8952
        server-key-file: "nsd_server.key"
        server-cert-file: "nsd_server.pem"
        control-key-file: "nsd_control.key"
        control-cert-file: "nsd_control.pem"

И все бы хорошо, но была одна проблема.

Если сервис стартовать или перезапускать через systemctl, то консоль зависала.

Точнее, сервис успешно стартовал, но systemd (или кто там за его запуск отвечал) никак не мог в этом удостоверится и висел в ожидании, пока не отваливался по таймауту.

Особой проблемы в этом не было (так как DNS функционировал), но как-то это неаккуратно.

При этом если убрать (закомментировать) chroot, то все работало хорошо, systemctl моментально подтверждал выполнение.

 

Решил сделать аккуратнее.

Решил, что проблема с chroot из-за нестандартных путей.

Сделал все стандартно: в /etc/nsd лежат конфиги и сертификаты, в /var/lib/nsd режат зоны и изменяемые данные, в /var/log/nsd.log логи, в /run/nsd.pid файлы процесса, в /tmp временные данные.

server:
        username: nsd
        identity: "unknown server"
        hide-version: yes
        chroot: "/var/lib/nsd"
        zonesdir: "/var/lib/nsd"
        pidfile: "/run/nsd.pid"
        database: "/var/lib/nsd/nsd.db"
        zonelistfile: "/var/lib/nsd/zone.list"
        xfrdfile: "/var/lib/nsd/xfrd.state"
        xfrdir: "/tmp"
        round-robin: yes
        server-count: 2
        interface: 127.0.0.201
        ip-transparent: no
        do-ip4: yes
        do-ip6: no
        logfile: "/var/log/nsd.log"
        verbosity: 1
#       log-time-ascii: yes

remote-control:
        control-enable: yes
        control-interface: 127.0.0.1
        control-port: 8952
        server-key-file: "/etc/nsd/nsd_server.key"
        server-cert-file: "/etc/nsd/nsd_server.pem"
        control-key-file: "/etc/nsd/nsd_control.key"
        control-cert-file: "/etc/nsd/nsd_control.pem"

 

Но получилось все куда хуже и вообще непонятно.

Вот текущее содержимое unit-файла:

[Unit]
Description=Name Server Daemon
Documentation=man:nsd(8)
After=network.target

[Service]
Type=notify
Restart=always
ExecStart=/usr/sbin/nsd -d
ExecReload=+/bin/kill -HUP $MAINPID
CapabilityBoundingSet=CAP_CHOWN CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_CHROOT
MemoryDenyWriteExecute=true
NoNewPrivileges=true
PrivateDevices=true
PrivateTmp=false
ProtectHome=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectSystem=true
ReadWritePaths=/var/lib/nsd /var/log /run /tmp
RuntimeDirectory=nsd
RestrictRealtime=true
SystemCallArchitectures=native
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module mount @obsolete @resources

[Install]
WantedBy=multi-user.target

Если не добавлять ReadWritePath, то вообще ничего не работает, сервис жалуется на read only file system.

Если его добавить, он вроде бы стартует, но:

/var/log/nsd.log пустой, потому что под ограниченными правами nsd не может в него писать (причем даже если выдать права пользователю nsd, видимо systemd дополнительно ограничивает процесс).

/run/nsd.pid при первом запуске создается, владельцем оказывается root. И после этого nsd не может перезапуститься или остановится, потому что нет прав доступа к файлу.

Если закомментировать (или выключить) CapabilityBoundingSet и ProtectSystem, и не использовать chroot, тогда все начинает работать нормально.

Но хочется сделать по нормальному.

 

И аналогичная проблема с использованием Unbound, если я хочу использовать DNSSEC.

В этом случае возникает ошибка с правами доступа к файлу root.key — стартер systemd при запуска обновляет этот файл, и даже вроде бы выставляет пользователя unbound, но у unbound все равно нет доступа к этому файлу, скорее всего из-за дополнительных ограничений процесса.

 

Я уже подумываю снести нафиг systemd и поставить что-нибудь другое.

Сдерживает то, что в дальнейшем это еще больше проблем принесет.

Share this post


Link to post
Share on other sites

On 2/18/2022 at 2:47 PM, alibek said:

Мне нужно на этом сервере запустить NSD.

 

Первоначально я создал каталог /custom/nsd, и NSD полностью крутился внутри него

А нахрена? Можно просто установить пакет nsd, и он разложит себя по стандартным путям. И юнит-файл вручную создавать-править не придётся.

 

On 2/18/2022 at 2:47 PM, alibek said:

снести нафиг systemd

Это всегда хорошая идея, только сносить лучше вместе с дистром, заменить на Devuan или хотя бы простой Debian.

Сомневаюсь, что Ubuntu со снесённым systemd будет нормально работать.

Share this post


Link to post
Share on other sites

В 18.02.2022 в 12:54, rm_ сказал:

А нахрена?

Чтобы было удобно смотреть, изменять или бэкапить.

Мне это удобнее в одном подкаталоге делать, чем в разных местах смотреть.

 

В 18.02.2022 в 12:54, rm_ сказал:

хотя бы простой Debian

Уже тоже так думаю.

Под рукой был именно Ubuntu Server, лень было качать Debian, решил что раз Ubuntu на Debian основано, то и отличий будет немного.

 

В 18.02.2022 в 12:54, rm_ сказал:

Devuan

А вот это нет.

Потом эти не самые популярные дистрибутивы вымирают или закрываются.

Поэтому я стараюсь использовать только мейнстрим.

Share this post


Link to post
Share on other sites

On 2/18/2022 at 3:08 PM, alibek said:

Чтобы было удобно смотреть, изменять или бэкапить.

Мне это удобнее в одном подкаталоге делать, чем в разных местах смотреть.

Ну тогда вы не понимаете философию юникс-систем, и нужно работать над этим.

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

конкретно, забэкапить достаточно конфиги из /etc.

Share this post


Link to post
Share on other sites

У меня кроме конфигов есть зоны и скрипты, их генерирующие. Ну и всякая другая вспомогательная мелочь.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.