Чому 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 неправильно?

Тому що svccfg (1M) зламаний, і я його зламав.

Ще в 2007 році я додав функцію SMF, яка дозволяла групам властивостей, які могли містити конфіденційну інформацію, читатимуть лише користувачі з відповідними привілеями. Ідея полягала в тому, що ви можете додати властивість "read_authorization" до групи властивостей, і кожен, хто не мав ні привілейованого (в основному, root), ні власника одного з авторизацій, названих цією властивістю, не зміг би прочитати значення жодної властивості в групі. Це було інтегровано в рамках цього зобов’язання і використовується (принаймні) продуктами зберігання Sun ZFS для зберігання таких речей, як паролі LDAP.

В рамках цієї роботи ми хотіли переконатися, що навіть привілейовані користувачі, які могли прочитати ці значення, випадково не виявлять їх, експортуючи стан служби або створивши архів сховища SMF. Тому я додав прапор '-a' до команд експорту та архіву у svccfg, який явно експортував би всі значення властивостей, і змінив типовий параметр, щоб виключити будь-які, захищені від читання.

На жаль, це обмеження не застосовується правильно; у цьому випадку ми просто відмовляємось експортувати будь-які, крім декількох вибраних властивостей, у "загальну" групу властивостей зі значеннями. Решта експортується без будь-яких значень, саме те, що ви бачите. І, на жаль, використання параметра -a тут не допоможе, оскільки до моменту досягнення відповідної точки ми вже не маємо необхідного контексту, щоб знати, що ви пройшли це. Навіть справедливо сумніватися, чи повинен цей прапор вимагати викриття цих значень: ідентифікація авторизацій, які дозволяють змінити стан служби, справді є чутливою та корисною для зловмисника. Без сумніву, це було в моїх думках, коли я писав це, і розумно обмежувати це з точки зору інших, якщо це прямо не хочеться. Але в попередніх версіях S10, експортували XML та архіви, що містили його, тож, безумовно, це було несумісною зміною. Вам би пробачили за те, що засмутився з цього приводу. Але справжня проблема тут полягає в тому, що -a не працює, коли група властивостей є "загальною". Як ти перший, хто вдарив це, я поняття не маю.

Ви можете слідкувати за цим питанням на його сторінці, тут . Тим часом, ви можете розглянути можливість його вирішення, вручну додавши значення властивостей у створений XML. Зауважте, що при необхідності ви також можете їх прочитати через svcprop (1). Ви маєте вибачення. Дякую Дейдрі Штрауган за те, що донесла моє увагу до цього питання.