У меня есть служба systemd, которая запускает go-ethereum (geth), которая затем создает сокет Unix, используемый для предоставления консоли управления. Моя проблема в том, что мой пользователь не может подключиться к сокету Unix, потому что, хотя мой пользователь и пользователь службы находятся в одной группе, а созданный файл автоматически принадлежит как пользователю службы, так и группе, процесс geth не дает автоматически разрешение rw группе. Я могу исправить это сам, запустивsudo chmod 660 /path/to/socket из терминала перед использованием его консоли, но я хотел бы делать это автоматически, если это возможно.
Я попробовал добавить такое правило в [Service]раздел файла службы: ExecStartPost=/bin/chmod 660 /path/to/socket. Но это не работает, я полагаю, потому что есть задержка между запуском процесса службы и созданием сокета.ExecStartPost Затем команда не выполняется, что, в свою очередь, приводит к отключению службы.
Один из вариантов, который я вижу для исправления этого, — написать скрипт, который многократно проверяет существование файла, а затем изменяет разрешения файла, как только файл обнаружен. Затем я мог бы изменить правило на ExecStartPost=/path/to/script. Более простым и, возможно, менее надежным решением в том же ключе может быть создание правила ExecStartPost=/bin/bash -c "sleep 5 && /bin/chmod 660 /path/to/socket".
Является ли такое решение наилучшим вариантом или systemd предоставляет какой-то другой/более простой механизм, который можно использовать для моих целей?
решение1
Основной руководящий принцип здесь заключается в том, чтовсе, что связываетAF_LOCAL сокет, должно устанавливать его разрешения. Поступать иначе — это шаткая штуковина Хита Робинсона.
Если программа службы dæmon создает и связывает сокет, то ищите параметры конфигурации, которые позволяют вам указать разрешения сокета. К сожалению, вы можете обнаружить, что авторы программы могли не подумать, что людям нужно это делать.
Если программа службы демона не имеет такого механизма настройки, то попробуйте сделать программу службы демонаполучатьего управляющий сокет при запуске как уже открытый файловый дескриптор, передал информацию об этом файловом дескрипторе черезLISTEN_FDS (так как, предположительно, это прослушивающий сокет, который принимает запросы на подключение). Затем управление службами отвечает за создание и привязку сокета и установку его прав, которые systemdделаетесть ручки для.
Затем настройте Accept=Noмодуль сокета systemd, описывающий этот сокет, включая соответствующую ListenStreamнастройку (поскольку, предположительно, интерфейс управления является потоковым сокетом) и настройку SocketMode=0660.