diff options
author | Daniel Mack <daniel@zonque.org> | 2014-09-11 18:58:45 +0200 |
---|---|---|
committer | Seung-Woo Kim <sw0312.kim@samsung.com> | 2016-12-14 13:48:30 +0900 |
commit | 90c5cbcab8014300a8f64bf554914a96ed9f33ed (patch) | |
tree | 1cf4601ccbd50448321776f1306b5d72fa8b0be3 /.mailmap | |
parent | 8679a25a16c23cc3c2d2e461bcde3e3767ca9181 (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