Почему 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?

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

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

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

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

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