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

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

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

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

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

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