为什么在SmartOS上导出时SMF清单会丢失配置数据？

我正在Joyent的Base64 1.8.1 SmartOS映像上的SMF（服务器管理工​​具）下运行服务器进程。

对于不熟悉SmartOS的用户，它是带有KVM的IllumOS的基于云的发行版。但从本质上讲，它类似于Solaris，并且继承自OpenSolaris。因此，即使您没有使用SmartOS，我也希望利用ServerFault上的一些Solaris知识。

我的问题是我希望允许非特权用户重新启动他们拥有的服务。我已经弄清楚了如何使用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）也没有拥有该属性命名的授权之一的任何人将无法读取任何属性的值在组中。它已集成在此commit之下，并且（至少）由Sun ZFS存储产品用于存储LDAP密码之类的东西。

作为该工作的一部分，我们希望确保即使是能够读取这些值的特权用户也不会通过导出服务状态或创建SMF存储库的存档而意外地暴露它们。因此，我在svccfg中的export和archive命令中添加了“ -a”标志，该标志将显式导出所有属性值，并更改了默认值以排除任何受读保护的属性。

不幸的是，此限制没有正确应用。在这种情况下，我们只是拒绝导出“常规”属性组中带有值的少数几个属性。其余部分将导出而没有任何值，这就是您所看到的。不幸的是，使用-a选项在这里无济于事，因为到我们到达相关点时，我们就不再需要知道您已通过的上下文。甚至公平地质疑是否需要使用此标志来公开这些值：允许更改服务状态的授权的身份确实是敏感的，并且对攻击者有用。毫无疑问，当我写这篇文章时，这就是我的想法。除非明确提出要求，否则将其限制在他人看来是合理的。但是在S10的早期版本中，导出的XML以及包含它的档案，因此这绝对是不兼容的更改。您会为此感到沮丧。但是这里真正的问题是，当所讨论的属性组为“常规”时，-a不起作用。我不知道你如何成为第一个实现此目标的人。

您可以在此处的页面上关注此问题。同时，您可以考虑通过在生成的XML中手动添加属性的值来解决该问题。请注意，如果需要，您也可以通过svcprop（1）读取它们。你有我的道歉。感谢Deirdre Straughan将这个问题提请我注意。