☰

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

tag-icon • tag-icon solaris opensolaris smf illumos smartos
为什么 SMF 清单在 SmartOS 上导出时会丢失配置数据？

我在 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？

答案1

因为 svccfg(1M) 坏了，而且是我把它弄坏了。

早在 2007 年，我就为 SMF 添加了一项功能，允许属性组包含敏感信息，只有具有适当权限的用户才能读取。这个想法是，您可以向属性组添加“read_authorization”属性，任何没有特权（基本上是 root）或不拥有该属性命名的授权的人都将无法读取组中任何属性的值。这项功能集成在这次提交，并且至少被 Sun ZFS 存储产品用来存储 LDAP 密码之类的内容。

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

不幸的是，这个限制没有被正确应用；在这种情况下，我们只是拒绝导出“常规”属性组中除少数几个具有值的属性之外的任何属性。其余的属性都导出了，没有任何值，这就是您所看到的。不幸的是，使用 -a 选项在这里没有帮助，因为当我们到达相关点时，我们不再具有知道您已经通过该选项所需的上下文。甚至可以质疑是否应该要求此标志来公开这些值：允许更改服务状态的授权的身份确实很敏感，并且对攻击者很有用。毫无疑问，当我写这篇文章时，我脑子里就有这个想法，除非明确需要，否则限制其他人的观点是合理的。但在 S10 的早期版本中，导出的 XML 和档案包含它，因此这绝对是一个不兼容的更改。您对此感到不安是可以原谅的。但这里真正的问题是，当所讨论的属性组是“常规”时，-a 不起作用。我不知道您是如何成为第一个遇到这个问题的人的。

您可以在此处的页面上关注此问题。与此同时，您可以考虑通过在生成的 XML 中手动添加属性值来解决这个问题。请注意，如果需要，您也可以通过 svcprop(1) 读取它们。我很抱歉。感谢 Deirdre Straughan 让我注意到这个问题。

相关内容