☰

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

tag-icon • tag-icon solaris opensolaris smf illumos smartos
Почему манифест SMF теряет данные конфигурации при экспорте в SmartOS?

Я запускаю серверный процесс под управлением SMF (Server Management Facility) на образе 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?

решение1

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

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

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

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

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

Связанный контент