kdbus.policy kdbus.policy kdbus.policy 7 kdbus.policy kdbus policy Description A kdbus policy restricts the possibilities of connections to own, see and talk to well-known names. A policy can be associated with a bus (through a policy holder connection) or a custom endpoint. kdbus stores its policy information in a database that can be accessed through the following ioctl commands: KDBUS_CMD_HELLO When creating, or updating, a policy holder connection. See kdbus.connection 7 . KDBUS_CMD_ENDPOINT_MAKE KDBUS_CMD_ENDPOINT_UPDATE When creating, or updating, a bus custom endpoint. See kdbus.endpoint 7 . In all cases, the name and policy access information is stored in items of type KDBUS_ITEM_NAME and KDBUS_ITEM_POLICY_ACCESS. For this transport, the following rules apply. An item of type KDBUS_ITEM_NAME must be followed by at least one KDBUS_ITEM_POLICY_ACCESS item. An item of type KDBUS_ITEM_NAME can be followed by an arbitrary number of KDBUS_ITEM_POLICY_ACCESS items. An arbitrary number of groups of names and access levels can be given. Names passed in items of type KDBUS_ITEM_NAME must comply to the rules of valid kdbus.name. See kdbus.name 7 for more information. The payload of an item of type KDBUS_ITEM_POLICY_ACCESS is defined by the following struct. For more information on the layout of items, please refer to kdbus.item 7 . struct kdbus_policy_access { __u64 type; __u64 access; __u64 id; }; The fields in this struct are described below. type One of the following. KDBUS_POLICY_ACCESS_USER Grant access to a user with the UID stored in the id field. KDBUS_POLICY_ACCESS_GROUP Grant access to a user with the GID stored in the id field. KDBUS_POLICY_ACCESS_WORLD Grant access to everyone. The id field is ignored. access The access to grant. One of the following. KDBUS_POLICY_SEE Allow the name to be seen. KDBUS_POLICY_TALK Allow the name to be talked to. KDBUS_POLICY_OWN Allow the name to be owned. id For KDBUS_POLICY_ACCESS_USER, stores the UID. For KDBUS_POLICY_ACCESS_GROUP, stores the GID. All endpoints of buses have an empty policy database by default. Therefore, unless policy rules are added, all operations will also be denied by default. Also see kdbus.endpoint 7 . Wildcard names Policy holder connections may upload names that contain the wildcard suffix (".*"). Such a policy entry is effective for every well-known name that extends the provided name by exactly one more level. For example, the name foo.bar.* matches both "foo.bar.baz" and "foo.bar.bazbaz" are, but not "foo.bar.baz.baz". This allows connections to take control over multiple names that the policy holder doesn't need to know about when uploading the policy. Such wildcard entries are not allowed for custom endpoints. Privileged connections The policy database is overruled when action is taken by a privileged connection. Please refer to kdbus.connection 7 for more information on what makes a connection privileged. Examples For instance, a set of policy rules may look like this: KDBUS_ITEM_NAME: str='org.foo.bar' KDBUS_ITEM_POLICY_ACCESS: type=USER, access=OWN, ID=1000 KDBUS_ITEM_POLICY_ACCESS: type=USER, access=TALK, ID=1001 KDBUS_ITEM_POLICY_ACCESS: type=WORLD, access=SEE KDBUS_ITEM_NAME: str='org.blah.baz' KDBUS_ITEM_POLICY_ACCESS: type=USER, access=OWN, ID=0 KDBUS_ITEM_POLICY_ACCESS: type=WORLD, access=TALK That means that 'org.foo.bar' may only be owned by UID 1000, but every user on the bus is allowed to see the name. However, only UID 1001 may actually send a message to the connection and receive a reply from it. The second rule allows 'org.blah.baz' to be owned by UID 0 only, but every user may talk to it. TALK access and multiple well-known names per connection Note that TALK access is checked against all names of a connection. For example, if a connection owns both 'org.foo.bar' and 'org.blah.baz', and the policy database allows 'org.blah.baz' to be talked to by WORLD, then this permission is also granted to 'org.foo.bar'. That might sound illogical, but after all, we allow messages to be directed to either the ID or a well-known name, and policy is applied to the connection, not the name. In other words, the effective TALK policy for a connection is the most permissive of all names the connection owns. For broadcast messages, the receiver needs TALK permissions to the sender to receive the broadcast. Both the endpoint and the bus policy databases are consulted to allow name registry listing, owning a well-known name and message delivery. If either one fails, the operation is failed with errno set to EPERM. For best practices, connections that own names with a restricted TALK access should not install matches. This avoids cases where the sent message may pass the bloom filter due to false-positives and may also satisfy the policy rules. Also see kdbus.match 7 . Implicit policies Depending on the type of the endpoint, a set of implicit rules that override installed policies might be enforced. On default endpoints, the following set is enforced and checked before any user-supplied policy is checked. Privileged connections always override any installed policy. Those connections could easily install their own policies, so there is no reason to enforce installed policies. Connections can always talk to connections of the same user. This includes broadcast messages. Custom endpoints have stricter policies. The following rules apply: Policy rules are always enforced, even if the connection is a privileged connection. Policy rules are always enforced for TALK access, even if both ends are running under the same user. This includes broadcast messages. To restrict the set of names that can be seen, endpoint policies can install SEE policies. See Also kdbus 7 kdbus.bus 7 kdbus.endpoint 7 kdbus.fs 7 kdbus.item 7 kdbus.message 7 kdbus.name 7 kdbus.pool 7