Назад | Перейти на главную страницу

Почему манифест SMF теряет данные конфигурации при экспорте в SmartOS?

Я запускаю серверный процесс в SMF (средство управления сервером) в образе Joyent Base64 1.8.1 SmartOS.

Для тех, кто не знаком со SmartOS, это облачный дистрибутив IllumOS с KVM. Но по сути он похож на Solaris и унаследован от OpenSolaris. Так что, даже если вы не использовали SmartOS, я надеюсь воспользоваться некоторыми знаниями Solaris о ServerFault.

Моя проблема в том, что я хочу, чтобы непривилегированному пользователю было разрешено перезапускать принадлежащую ему службу. Я разработал, как это сделать, используя RBAC и добавив авторизацию в /etc/security/auth_attr и связать эту авторизацию с моим пользователем.

Затем я добавил в свой манифест SMF для службы следующее:

<property_group name='general' type='framework'>
  <!-- Allow to be restarted-->
  <propval name='action_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
  <!-- Allow to be started and stopped -->
  <propval name='value_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
</property_group>

И это хорошо работает при импорте. Моему непривилегированному пользователю разрешено перезапускать, запускать и останавливать собственный серверный процесс (это для автоматического развертывания кода).

Однако, если я экспортирую манифест SMF, эти данные конфигурации исчезнут ... все, что я вижу в этом разделе, это следующее:

<property_group name='general' type='framework'>
  <property name='action_authorization' type='astring'/>
  <property name='value_authorization' type='astring'/>
</property_group>

Кто-нибудь знает, почему это происходит? У меня неправильный синтаксис, или я просто неправильно использую SMF?

Потому что svccfg (1M) сломан, а я его сломал.

Еще в 2007 году я добавил функцию в SMF, которая разрешила группы свойств, которые могут содержать конфиденциальную информацию, доступную для чтения только пользователям с соответствующими привилегиями. Идея заключалась в том, что вы могли добавить свойство "read_authorization" в группу свойств, и любой, кто не имел ни привилегий (в основном, root), ни одной из авторизаций, названных этим свойством, не смог бы прочитать значения любого свойства. в группе. Это было интегрировано в это коммит, и используется (по крайней мере) продуктами хранения Sun ZFS для хранения таких вещей, как пароли LDAP.

В рамках этой работы мы хотели убедиться, что даже привилегированные пользователи, которые могут читать эти значения, случайно не раскрыли их, экспортируя состояние службы или создавая архив репозитория SMF. Поэтому я добавил флаг '-a' к командам экспорта и архивирования в svccfg, которые будут явно экспортировать все значения свойств, и изменил значение по умолчанию, чтобы исключить все, что было защищено от чтения.

К сожалению, это ограничение применяется неправильно; в этом случае мы просто отказываемся экспортировать какие-либо свойства, кроме нескольких избранных, в «общей» группе свойств со значениями. Остальные экспортируются без каких-либо значений, что вы и видите. И, к сожалению, использование параметра -a здесь не поможет, потому что к тому времени, когда мы достигнем соответствующей точки, у нас больше не будет контекста, необходимого для того, чтобы знать, что вы его прошли. Справедливо даже спросить, должен ли этот флаг требоваться для раскрытия этих значений: идентификация авторизаций, которые позволяют изменять состояние службы, действительно чувствительна и может быть полезна для злоумышленника. Несомненно, это было у меня в голове, когда я писал это, и разумно ограничить это с точки зрения других, если это явно не требуется. Но в предыдущих версиях S10 экспортированный XML и архивы содержали его, так что это определенно несовместимое изменение. Вы были бы прощены за то, что расстроились из-за этого. Но настоящая проблема здесь в том, что -a не работает, когда рассматриваемая группа свойств является «общей». Я понятия не имею, как ты первый попал в это.

Вы можете следить за этим выпуском на его странице, здесь. А пока вы можете обойти это, вручную добавив значения свойств в сгенерированный XML. Обратите внимание, что вы также можете прочитать их через svcprop (1), если это необходимо. Приношу свои извинения. Спасибо Дейдре Страуган за то, что обратила мое внимание на этот вопрос.