summaryrefslogtreecommitdiff
path: root/.mailmap
diff options
context:
space:
mode:
authorDaniel Mack <daniel@zonque.org>2014-09-11 18:58:45 +0200
committerSeung-Woo Kim <sw0312.kim@samsung.com>2016-12-14 13:48:30 +0900
commit90c5cbcab8014300a8f64bf554914a96ed9f33ed (patch)
tree1cf4601ccbd50448321776f1306b5d72fa8b0be3 /.mailmap
parent8679a25a16c23cc3c2d2e461bcde3e3767ca9181 (diff)
kdbus: add code to gather metadata
A connection chooses which metadata it wants to have attached to each message it receives with kdbus_cmd_hello.attach_flags. The metadata will be attached as items to the messages. All metadata refers to information about the sending task at sending time, unless otherwise stated. Also, the metadata is copied, not referenced, so even if the sending task doesn't exist anymore at the time the message is received, the information is still preserved. In traditional D-Bus, userspace tasks like polkit or journald make a live lookup in procfs and sysfs to gain information about a sending task. This is racy, of course, as in a a connection-less system like D-Bus, the originating peer can go away immediately after sending the message. As we're moving D-Bus prmitives into the kernel, we have to provide the same semantics here, and inform the receiving peer on the live credentials of the sending peer. Metadata is collected at the following times. * When a bus is created (KDBUS_CMD_MAKE), information about the calling task is collected. This data is returned by the kernel via the KDBUS_CMD_BUS_CREATOR_INFO call. * When a connection is created (KDBUS_CMD_HELLO), information about the calling task is collected. Alternatively, a privileged connection may provide 'faked' information about credentials, PIDs and security labels which will be stored instead. This data is returned by the kernel as information on a connection (KDBUS_CMD_CONN_INFO). Only metadata that a connection allowed to be sent (by setting its bit in attach_flags_send) will be exported in this way. * When a message is sent (KDBUS_CMD_SEND), information about the sending task and the sending connection are collected. This metadata will be attached to the message when it arrives in the receiver's pool. If the connection sending the message installed faked credentials (see kdbus.connection(7)), the message will not be augmented by any information about the currently sending task. Which metadata items are actually delivered depends on the following sets and masks: (a) the system-wide kmod creds mask (module parameter 'attach_flags_mask') (b) the per-connection send creds mask, set by the connecting client (c) the per-connection receive creds mask, set by the connecting client (d) the per-bus minimal creds mask, set by the bus creator (e) the per-bus owner creds mask, set by the bus creator (f) the mask specified when querying creds of a bus peer (g) the mask specified when querying creds of a bus owner With the following rules: [1] The creds attached to messages are determined as a & b & c. [2] When connecting to a bus (KDBUS_CMD_HELLO), and ~b & d != 0, the call will fail with, -1, and errno is set to ECONNREFUSED. [3] When querying creds of a bus peer, the creds returned are a & b & f. [4] When querying creds of a bus owner, the creds returned are a & e & g. See kdbus.metadata(7) and kdbus.item(7) for more details on which metadata can currently be attached to messages. Signed-off-by: Daniel Mack <daniel@zonque.org> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Djalal Harouni <tixxdz@opendz.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paul Osmialowski <p.osmialowsk@samsung.com>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions