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

Я запускаю процесс сервера под SMF (Средство управления сервером) на образе JOSENT 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?

Источник

1 ответ

Решение

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

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

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

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

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

Источник
Другие вопросы по тегам