dbus-daemon - 云端在线

程序：

您的姓名

dbus-daemon - 消息总线守护进程

概要

dbus 守护进程

dbus 守护进程 [--版本] [--会话] [--系统] [--配置文件=文件]
[--打印地址[=描述符]] [--打印-pid [=描述符]] [ - 叉子]

商品描述

dbus 守护进程 是 D-Bus 消息总线守护进程。 看 http://www.freedesktop.org/software/dbus/
有关全局的更多信息。 D-Bus 首先是一个提供
任意两个应用程序之间的一对一通信； dbus 守护进程 是一个应用程序
使用这个库来实现一个消息总线守护进程。 多个程序连接到
消息总线守护进程，可以相互交换消息。

有两个标准的消息总线实例：系统范围的消息总线（安装在
许多系统作为“消息总线”初始化服务）和每用户登录会话消息总线
（每次用户登录时启动）。 dbus 守护进程 用于这两种情况，但
使用不同的配置文件。

--session 选项等效于“--config-file=/usr/share/dbus-1/session.conf“而
--system 选项等效于“--config-file=/usr/share/dbus-1/system.conf“。 经过
创建额外的配置文件并使用 --config-file 选项，额外的
可以创建特殊用途的消息总线守护进程。

系统范围的守护进程通常由一个 init 脚本启动，通常简称为
“消息总线”。

系统范围的守护进程主要用于广播系统事件，例如对
打印机队列，或添加/删除设备。

per-session 守护进程用于桌面之间的各种进程间通信
应用程序（但是，它不以任何方式绑定到 X 或 GUI）。

SIGHUP 将导致 D-Bus 守护进程部分重新加载其配置文件并刷新
它的用户/组信息缓存。 一些配置更改将需要踢所有
公交车上的应用程序； 所以它们只有在您重新启动守护程序时才会生效。 政策变化
应与 SIGHUP 一起生效。

配置

支持以下选项：

--config-file=文件
使用给定的配置文件。

- 叉子
强制消息总线 fork 并成为守护进程，即使配置文件没有
没有指定它应该。 在大多数情况下，配置文件已经得到了这个
没错，不过。 Windows 不支持此选项。

--nofork
强制消息总线不fork而成为守护进程，即使配置文件
指定它应该。 在 Windows 上，dbus-daemon 从不分叉，所以这个选项是
允许但什么都不做。

--打印地址[=DESCRIPTOR]
将消息总线的地址打印到标准输出或给定文件
描述符。 这由启动消息总线的程序使用。

--print-pid[=描述符]
将消息总线的进程 ID 打印到标准输出或给定文件
描述符。 这由启动消息总线的程序使用。

- 会议
使用每个登录会话消息总线的标准配置文件。

- 系统
使用系统范围的消息总线的标准配置文件。

- 版
打印守护进程的版本。

--内省
打印所有 D-Bus 内部接口的自省信息。

--address[=地址]
设置要监听的地址。 此选项会覆盖在
配置文件。

--systemd-激活
启用 systemd 风格的服务激活。 仅与 systemd 结合使用
Linux 上的系统和会话管理器。

--nopid 文件
即使在配置文件中配置了PID文件，也不要写入PID文件。

配置 文件

消息总线守护进程有一个配置文件，专门用于特定的
应用。 例如，一个配置文件可能将消息总线设置为
系统范围的消息总线，而另一个可能将其设置为每个用户登录会话的总线。

配置文件还建立了资源限制、安全参数等
向前。

配置文件不属于任何互操作性规范及其向后
不保证兼容性； 本文档是文档，而不是规范。

标准的系统范围和每会话消息总线设置在文件中配置
"/usr/share/dbus-1/system.conf“和”/usr/share/dbus-1/session.conf”。这些文件通常
一个 system-local.conf 或 session-local.conf 在 /etc/dbus-1; 你可以把本地
覆盖这些文件以避免修改主要配置文件。

配置文件是一个 XML 文档。 它必须具有以下文档类型声明：

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus 总线配置 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

配置文件中可能存在以下元素。

·

根元素。

·

众所周知的消息总线类型。 目前已知的值为“system”和“session”；
如果设置了其他值，则应将它们添加到 D-Bus 规范中，或者
命名空间。 最后元素“获胜”（忽略以前的值）。 这个元素
仅控制在激活中设置哪些消息总线特定环境变量
客户。 大多数区分会话总线和系统总线的策略是
由配置文件中的其他元素控制。

如果消息总线的已知类型是“会话”，则 DBUS_STARTER_BUS_TYPE
环境变量将设置为“会话”和 DBUS_SESSION_BUS_ADDRESS 环境
变量将被设置为会话总线的地址。 同样，如果类型
消息总线为“系统”，则将设置 DBUS_STARTER_BUS_TYPE 环境变量
到“系统”，并且 DBUS_SESSION_BUS_ADDRESS 环境变量将被设置为
系统总线的地址（这通常是众所周知的）。

例子： 会议

·

包含一个文件文件名.conf 这一点。 如果文件名是
相对，它相对于执行包含的配置文件定位。

有一个可选属性“ignore_missing=(yes|no)”，如果
不提供。 此属性控制包含的文件是否为致命错误
缺席。

·

包括所有文件食物这一点。 目录中的文件
以未定义的顺序包含在内。 仅包含以“.conf”结尾的文件。

这旨在允许通过特定包扩展系统总线。 例如，
如果 CUPS 希望能够发出打印机队列更改的通知，它可以
将文件安装到 /usr/share/dbus-1/system.d 或 /etc/dbus-1/system.d 允许所有应用程序
接收此消息并允许打印机守护程序用户发送它。

·

守护程序应该作为用户名或 UID 运行的用户帐户。 如果守护进程
无法在启动时更改此 UID，它将退出。 如果此元素不存在，则
守护进程不会改变或关心它的 UID。

最后文件“wins”中的条目，其他条目将被忽略。

总线完成初始化后，用户发生变化。 所以套接字等将是
在更改用户之前创建，但在更改用户之前不会从客户端读取数据。
这意味着可以在需要 root 的位置创建套接字和 PID 文件
写作的特权。

·

如果存在，总线守护程序将成为真正的守护程序（分叉到后台等）。 这个
通常使用而不是 --fork 命令行选项。

·

如果存在，总线守护进程在分叉时保留其原始 umask。 这可能对
避免影响子进程的行为。

·

如果存在，总线守护进程将记录到系统日志。

·

如果存在，总线守护进程会将其 pid 写入指定的文件。 --nopid 文件
命令行选项优先于此设置。

·

如果存在，使用匿名机制进行身份验证的连接将是
授权连接。 这个选项没有实际效果，除非 ANONYMOUS 机制
也已启用使用 元素，如下所述。

·

添加总线应侦听的地址。 地址采用标准D-Bus格式
包含传输名称和可能的参数/选项。

例子： unix:path=/tmp/foo

例子： tcp:host=localhost,port=1234

如果有多个元素，然后总线侦听多个地址。 这
总线会将其地址传递给已启动的服务或其他感兴趣的方
地址在第一的。 也就是说，应用程序将尝试连接到最后一个
先地址。

tcp 套接字可以接受 IPv4 地址、IPv6 地址或主机名。 如果主机名解析
到多个地址，服务器将绑定到所有地址。 family=ipv4 或 family=ipv6
选项可用于强制它绑定到地址子集

例子： tcp:host=localhost,port=0,family=ipv4

一种特殊情况是使用零端口号（或省略端口），这意味着
选择操作系统选择的可用端口。 选择的端口号可以是
使用 --print-address 命令行参数获得，并将出现在其他
服务器上报自己地址的情况，比如 DBUS_SESSION_BUS_ADDRESS 是
设置。

例子： tcp:host=localhost,port=0

tcp/nonce-tcp 地址还允许使用 bind=hostname 选项，在可监听地址中使用
配置服务器将在其上侦听的接口：主机名是 IP
本地机器接口之一的地址（最常见的是 127.0.0.1），一个 DNS 名称
解析为这些 IP 地址之一的“0.0.0.0”以侦听所有 IPv4 接口
同时，或 '::' 同时侦听所有 IPv4 和 IPv6 接口（如果
操作系统支持）。 如果未指定，则默认值与“host”相同。

例子： tcp:host=localhost,bind=0.0.0.0,port=0

·

列出允许的授权机制。 如果此元素不存在，则所有已知
机制是允许的。 如果有多个元素，所有列出的机制
被允许。 列出机制的顺序没有意义。

例子： 外部的

例子： DBUS_COOKIE_SHA1

·

添加目录以扫描 .service 文件。 扫描目录以
首先出现在配置文件中（发现的第一个 .service 文件提供了一个
将使用特定服务）。

服务文件告诉总线如何自动启动程序。 它们主要用于
使用每个用户会话总线，而不是系统范围的总线。

·

相当于指定一系列
“XDG 基本目录规范”中每个数据目录的元素
子目录“dbus-1/services”，例如“/usr/share/dbus-1/服务“ 将是
在搜索的目录中。

可以在以下位置找到“XDG 基本目录规范”
http://freedesktop.org/wiki/Standards/basedir-spec 如果它没有移动，否则试试你的
最喜欢的搜索引擎。

这选项仅与每用户会话总线相关
在 /etc/dbus-1/session.conf 中定义的守护进程。 将它放在任何其他配置文件中
大概是胡说八道。

·

指定标准的系统范围的激活目录
应该搜索服务文件。 该选项默认为
/usr/share/dbus-1/system-services。

这选项仅与每系统总线守护进程相关
在 /usr/share/dbus-1/system.conf 中定义。 将它放在任何其他配置文件中
大概是胡说八道。

·

指定用于启动系统守护进程的 setuid 帮助程序
备用用户。 通常这应该是 dbus-daemon-launch-helper 中的可执行文件
位于 libexec 中。

这选项仅与定义的每系统总线守护进程相关
/usr/share/dbus-1/system.conf。 将它放在任何其他配置文件中可能会
胡说八道。

·

建立资源限制。 例如：

64
512

name 属性是必需的。 可用的限制名称是：

“max_incoming_bytes”：消息的总大小（以字节为单位）
从单个连接传入
“max_incoming_unix_fds”：消息的unix fds总数
从单个连接传入
“max_outgoing_bytes”：消息的总大小（以字节为单位）
排队等待一个连接
“max_outgoing_unix_fds”：消息的unix fds总数
排队等待一个连接
"max_message_size" : 单个消息的最大大小
字节
"max_message_unix_fds" : 单个消息的最大 unix fds
“service_start_timeout”：毫秒（千分之一）直到
启动的服务必须连接
“auth_timeout”：毫秒（千分之一）
连接被赋予
认证
“pending_fd_timeout”：毫秒（千分之一）
fd 被发送到
断开连接前的 dbus-daemon
地都
"max_completed_connections" : 最大认证连接数
“max_incomplete_connections”：未认证的最大数量
连接
“max_connections_per_user”：来自的最大已完成连接数
同一个用户
"max_pending_service_starts" : 最大服务启动数
同时进步
“max_names_per_connection”：单个名称的最大数量
连接可以拥有
“max_match_rules_per_connection”：单个匹配规则的最大数量
地都
“max_replys_per_connection”：最大挂起方法数
每个连接的回复
（进行中的呼叫数）
“reply_timeout”：毫秒（千分之一）
直到方法调用超时

如果剩余一个字节，则最大传入/传出队列大小允许将新消息排队
低于最大值所以你实际上可以通过 max_message_size 超过最大值。

max_completed_connections 除以 max_connections_per_user 是用户数
可以通过耗尽所有连接来共同拒绝所有其他用户的服务
全系统总线。

限制通常只对系统范围的总线感兴趣，而不是用户会话总线。

·

这元素定义了要应用于特定集合的安全策略
与总线的连接。 政策是由和元素。 政策是
通常与全系统总线一起使用； 它们类似于防火墙，因为它们允许
预期流量并防止意外流量。

目前，系统总线有一个默认拒绝策略，用于发送方法调用和拥有
巴士名称。 其他一切，特别是回复消息、接收检查和信号都有
默认允许策略。

一般来说，最好将系统服务保留为小的、有针对性的程序，它们运行在
他们自己的进程并提供一个单一的总线名称。 那么，所需要的只是一个
允许进程声明总线名称的“自己的”权限规则，以及
“send_destination”规则允许来自某些或所有 uid 的流量到您的服务。

这元素具有四个属性之一：

上下文=“（默认|强制）”
at_console="(真|假)"
用户="用户名或用户名"
group="组名或 gid"

策略应用于连接如下：

- 应用所有 context="default" 策略
- 应用所有组=“连接的用户组”策略
以未定义的顺序
- 应用所有用户 =“连接的身份验证用户”策略
以未定义的顺序
- 应用所有 at_console="true" 策略
- 应用所有 at_console="false" 策略
- 应用所有 context="mandatory" 策略

当策略重叠时，稍后应用的策略将覆盖先前应用的策略。
具有相同用户/组/上下文的多个策略按它们出现的顺序应用
配置文件。




一种元素出现在一个元素并禁止某些操作。 这
元素对上一个例外语句，就像但
具有相反的意义。

这些元素的可能属性是：

发送接口=“接口名称”
send_member="method_or_signal_name"
发送错误=“错误名称”
发送目的地=“名称”
send_type="method_call" | "method_return" | “信号” | “错误”
发送路径=“/路径/名称”

接收接口=“接口名称”
receive_member="method_or_signal_name"
接收错误=“错误名称”
接收发送者=“名称”
receive_type="method_call" | "method_return" | “信号” | “错误”
接收路径=“/路径/名称”

send_requested_reply="true" | “错误的”
receive_requested_reply="true" | “错误的”

窃听=“真”| “错误的”

自己=“名字”
own_prefix="名称"
用户 =“用户名”
组=“组名”

例子：







这元素的属性决定拒绝是否“匹配”特定操作。
如果匹配，则拒绝该操作（除非配置文件中的后续规则允许）。

send_destination 和 receive_sender 规则意味着消息可能不会被发送到或
从给定名称的*所有者*收到，而不是它们可能不会被发送到*该名称*。
也就是说，如果一个连接拥有服务 A、B、C，并且发送到 A 被拒绝，则发送到 B
或 C 也不会工作。

其他的 send_* 和 receive_* 属性是纯粹的文本/按值匹配
消息头中的给定字段。

“窃听”发生在应用程序收到显式消息时
寻址到应用程序不拥有的名称，或者是对此类消息的回复。
因此窃听仅适用于发送到服务的消息和回复到
此类消息（即它不适用于信号）。

为了, eavesdrop="true" 表示即使在窃听时也符合规则。
eavesdrop="false" 是默认值，意味着该规则只允许邮件转到
他们指定的收件人。 为了, eavesdrop="true" 表示规则匹配
只有在偷听的时候。 eavesdrop="false" 是默认值还有，但在这里
意味着该规则始终适用，即使没有窃听也是如此。 窃听属性
只能与发送和接收规则结合使用（使用 send_* 和 receive_* 属性）。

[send|receive]_requested_reply 属性的工作方式与窃听属性类​​似。
它控制是否或者匹配预期的回复（对应于
先前的方法调用消息）。 此属性仅对回复消息有意义
（错误和方法返回），并被其他消息类型忽略。

为了, [send|receive]_requested_reply="true" 是默认值，表示只有
规则允许请求的回复。 [send|receive]_requested_reply="false" 表示
规则允许任何回复，即使是意外的。

为了, [send|receive]_requested_reply="false" 是默认值，但表示
规则仅在未请求回复时才匹配。 [发送|接收]_requested_reply="true"
表示该规则始终适用，无论未决答复状态如何。

用户和组拒绝意味着给定的用户或组可能无法连接到消息
总线。

对于“name”、“username”、“groupname”等，可以用字符“*”代替，意思是
“任何。” 现在不允许使用像“foo.bar.*”这样的复杂全局变量，因为它们可以用于
无论如何，实施并可能鼓励草率的安全性。

允许您拥有名字“ab”或任何名字
点分隔元素是“ab”：特别是，您可以拥有“abc”或“abcd”，但不能拥有
“a.bc”或“ac”。 当 Telepathy 和 ReserveDevice 等服务定义一个
已知名称的子树的含义，例如
org.freedesktop.Telepathy.ConnectionManager.(anything) 和
org.freedesktop.ReserveDevice1.(任何东西)。

拒绝一个用户或组内的用户是没有意义的对于用户或组；
用户/组拒绝只能在 context="default" 或 context="mandatory" 策略内。

一个规则可以指定属性的组合，例如 send_destination 和
发送接口和发送类型。 在这种情况下，拒绝仅适用于两个属性
匹配被拒绝的消息。 例如
send_destination="foo.blah"/> 将拒绝具有给定接口和给定接口的消息
巴士名称。 要获得 OR 效果，请指定多个规则。

您不能在同一规则中同时包含 send_ 和 receive_ 属性，因为“无论
消息可以发送”和“是否可以接收”是分开评估的。

小心使用 send_interface/receive_interface，因为消息中的接口字段
是可选的。 特别是，不要指定！ 这会
导致所有服务的无接口消息被阻止，这几乎肯定不是
你的意图。 始终使用以下形式的规则：
send_destination="org.foo.Service"/>

·

这元素包含与安全增强 Linux 相关的设置。 更多细节
联络一位教师

·

一个元素出现在一个元素并创建映射。 马上
只有一种关联是可能的：



这意味着，如果连接要求拥有名称“org.freedesktop.Foobar”，则
源上下文将是连接的上下文，目标上下文将是
“foo_t” - 请参阅下面对 SELinux 的简短讨论。

请注意，这里的上下文是请求名称时的目标上下文，而不是
拥有该名称的连接。

目前没有办法为拥有任何名称设置默认值，如果我们添加这个语法它
看起来像：



如果您发现这有用的原因，请告知开发人员。 现在默认将
是总线本身的安全上下文。

如果两个元素指定相同的名称，元素出现在后面
将使用配置文件。

·

这元素用于在总线上配置 AppArmor 中介。 它可以包含
一个指定中介模式的属性：



默认模式为“启用”。 在“启用”模式下，如果出现以下情况，将执行 AppArmor 中介
AppArmor 支持在内核中可用。 如果它不可用，dbus-daemon 将
启动但不会发生 AppArmor 调解。 在“禁用”模式下，AppArmor 中介是
禁用。 在“必需”模式下，如果 AppArmor 支持是
可用，否则 dbus-daemon 将拒绝启动。

总线启动后无法更改总线的 AppArmor 中介模式。 修改
配置文件中的模式和向守护进程发送 SIGHUP 信号无效
关于调解模式。

SELinux

参见 http://www.nsa.gov/selinux/ 有关 SELinux 的完整详细信息。 一些有用的摘录：

系统中的每个主体（进程）和对象（例如文件、套接字、IPC 对象等）都是
分配了一组安全属性，称为安全上下文。 一个安全
上下文包含与特定主题相关联的所有安全属性或
与安全策略相关的对象。

为了更好地封装安全上下文并提供更高的效率，
SELinux 的策略执行代码通常处理安全标识符 (SID) 而不是
比安全上下文。 SID 是一个整数，由安全服务器映射到
运行时的安全上下文。

当需要安全决策时，策略执行代码会传递一对 SID
（通常是主体的 SID 和客体的 SID，但有时是一对主体
SID 或一对对象 SID），以及安全服务器的对象安全类。 这
对象安全类表示对象的种类，例如进程、常规文件、
目录、TCP 套接字等。

访问决策指定是否为给定的 SID 对授予权限
和班级。 每个对象类都有一组相关的权限定义来控制
对具有该类的对象进行操作。

D-Bus 在两个地方执行 SELinux 安全检查。

首先，每当消息从一个连接路由到另一个连接时，总线
守护进程将使用第一个连接的安全上下文作为源检查权限，
作为目标的第二个连接的安全上下文，对象类“dbus”并请求
权限“send_msg”。

如果安全上下文不可用于连接（使用 UNIX 域时不可能
sockets），那么使用的目标上下文就是总线守护进程本身的上下文。 有
目前无法更改此默认值，因为我们假设只有 UNIX 域
套接字将用于连接到系统范围的总线。 如果这种情况发生变化，我们可能会添加
一种设置默认连接上下文的方法。

其次，任何时候一个连接要求拥有一个名字，总线守护进程将检查权限
以连接的安全上下文作为源，指定的安全上下文
配置文件中的名称作为目标，对象类“dbus”和请求的权限
“获取_svc”。

总线名称的安全上下文由描述的元素
在本文档的前面部分。 如果名称没有关联的安全上下文
配置文件中，将使用总线守护程序本身的安全上下文。

服装

AppArmor 限制上下文在应用程序连接到总线时存储。 这
限制上下文由标签和限制模式组成。 当安全决定
是必需的，守护进程使用限制上下文来查询 AppArmor 策略以
确定是否应允许或拒绝该操作以及是否应审核该操作。

该守护进程在三个地方执行 AppArmor 安全检查。

首先，每当消息从一个连接路由到另一个连接时，总线
守护进程将检查权限与第一个连接的标签作为来源，标签
和/或作为目标的第二个连接的连接名称，以及总线名称，
路径名、接口名和成员名。 回复消息，例如method_return
和错误消息，如果它们是对具有的消息的响应，则隐式允许
已经被允许。

其次，任何时候一个连接要求拥有一个名字，总线守护进程将检查权限
以连接的标签作为源，请求的名称作为目标，以及
巴士名称。

第三，任何时候一个连接试图窃听，总线守护进程都会检查权限
以连接标签作为源，以及总线名称。

总线调解的 AppArmor 规则不存储在总线配置文件中。 他们是
存储在应用程序的 AppArmor 配置文件中。 请参见 apparm.d(5) ，了解更多详情。

调试

如果你想弄清楚你的消息去哪里或者为什么你没有收到
消息，您可以尝试多种方法。

请记住，系统总线被严重锁定，如果您还没有安装
允许您的消息通过的安全策略文件，它将不起作用。 对于会话总线，
这不是问题。

找出总线上发生的事情的最简单方法是运行 dbus 监视器
程序，它随 D-Bus 包一起提供。 您还可以发送测试消息
dbus-发送. 这些程序有自己的手册页。

如果你想知道守护进程本身在做什么，你可以考虑运行一个单独的
要测试的守护程序副本。 这将允许您将守护进程置于
调试器，或使用详细输出运行它，而不会弄乱您的真实会话和系统
守护进程。

例如，要运行守护程序的单独测试副本，您可以打开一个终端并键入：

DBUS_VERBOSE=1 dbus-daemon --session --print-address

守护进程启动时将打印测试守护进程地址。 你需要
复制并粘贴此地址并将其用作 DBUS_SESSION_BUS_ADDRESS 的值
启动要测试的应用程序时的环境变量。 这会导致
这些应用程序连接到您的测试总线而不是 DBUS_SESSION_BUS_ADDRESS
你真正的会话总线。

DBUS_VERBOSE=1 将没有效果，除非您的 D-Bus 副本是用详细编译的
模式启用。 由于性能影响，不建议在生产版本中使用此方法。 你
如果您的副本不是在考虑调试的情况下构建的，则可能需要重建 D-Bus。 (DBUS_VERBOSE
也会影响 D-Bus 库，从而影响使用 D-Bus 的应用程序； 看看可能有用
客户端和守护进程的详细输出。）

如果你想变得更有趣，你可以为你的测试总线创建一个自定义的总线配置（参见
session.conf 和 system.conf 文件定义了两个默认配置
例子）。 这将允许您为 .service 文件指定不同的目录，例如
例。

使用 onworks.net 服务在线使用 dbus-daemon