Add kdbus implementation

From: Daniel Mack <[email protected]>
…

+5.4 Creating buses and endpoints
+--------------------------------

Documentation/kdbus.txt new file +3 -0

+
+KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
+struct kdbus_cmd_make argument.

Documentation/kdbus.txt new file +8 -0

+
+  __u64 kernel_flags;
+    Valid flags for this command, returned by the kernel upon each call.
+
+  struct kdbus_item items[0];
+    A list of items, only used for creating custom endpoints. Has specific
+    meanings for KDBUS_CMD_BUS_MAKE and KDBUS_CMD_ENDPOINT_MAKE (see above).
+};
…

From: Daniel Mack <[email protected]>

kdbus is a system for low-latency, low-overhead, easy to use interprocess communication (IPC).

The interface to all functions in this driver is implemented through ioctls on files exposed through the mount point of a kdbusfs. This patch adds detailed documentation about the kernel level API design.

Signed-off-by Daniel Mack <[email protected]>

Signed-off-by David Herrmann <[email protected]>

Signed-off-by Djalal Harouni <tixxdz-Umm1ozX2/[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---

Documentation/kdbus.txt new file +15 -0

+
+
+4. Items
+===============================================================================
+
+To flexibly augment transport structures used by kdbus, data blobs of type
+struct kdbus_item are used. An item has a fixed-sized header that only stores
+the type of the item and the overall size. The total size is variable and is
+in some cases defined by the item type, in other cases, they can be of
+arbitrary length (for instance, a string).
+
+In the external kernel API, items are used for many ioctls to transport
+optional information from userspace to kernelspace. They are also used for
+information stored in a connection's pool, such as messages, name lists or
+requested connection information.

Documentation/kdbus.txt new file +5 -0

+KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
+struct kdbus_cmd_make argument.
+
+struct kdbus_cmd_make {
+  __u64 size;

Documentation/kdbus.txt new file +87 -0

+
+
+6.2 Creating connections
+------------------------
+
+A connection to a bus is created by opening an endpoint file of a bus and
+becoming an active client with the KDBUS_CMD_HELLO ioctl. Every connected client
+connection has a unique identifier on the bus and can address messages to every
+other connection on the same bus by using the peer's connection id as the
+destination.
+
+The KDBUS_CMD_HELLO ioctl takes the following struct as argument.
+
+struct kdbus_cmd_hello {
+  __u64 size;
+    The overall size of the struct, including all attached items.
+
+  __u64 conn_flags;
+    Flags to apply to this connection:
+
+    KDBUS_HELLO_ACCEPT_FD
+      When this flag is set, the connection can be sent file descriptors
+      as message payload. If it's not set, any attempt of doing so will
+      result in -ECOMM on the sender's side.
+
+    KDBUS_HELLO_ACTIVATOR
+      Make this connection an activator (see below). With this bit set,
+      an item of type KDBUS_ITEM_NAME has to be attached which describes
+      the well-known name this connection should be an activator for.
+
+    KDBUS_HELLO_POLICY_HOLDER
+      Make this connection a policy holder (see below). With this bit set,
+      an item of type KDBUS_ITEM_NAME has to be attached which describes
+      the well-known name this connection should hold a policy for.
+
+    KDBUS_HELLO_MONITOR
+      Make this connection an eaves-dropping connection that receives all
+      unicast messages sent on the bus. To also receive broadcast messages,
+      the connection has to upload appropriate matches as well.
+      This flag is only valid for privileged bus connections.
+
+  __u64 attach_flags_send;
+      Set the bits for metadata this connection permits to be sent to the
+      receiving peer. Only metadata items that are both allowed to be sent by
+      the sender and that are requested by the receiver will effectively be
+      attached to the message eventually. Note, however, that the bus may
+      optionally enforce some of those bits to be set. If the match fails,
+      -ECONNREFUSED will be returned. In either case, this field will be set
+      to the mask of metadata items that are enforced by the bus. The
+      KDBUS_FLAGS_KERNEL bit will as well be set.
+
+  __u64 attach_flags_recv;
+      Request the attachment of metadata for each message received by this
+      connection. The metadata actually attached may actually augment the list
+      of requested items. See section 13 for more details.
+
+  __u64 bus_flags;
+      Upon successful completion of the ioctl, this member will contain the
+      flags of the bus it connected to.
+
+  __u64 id;
+      Upon successful completion of the ioctl, this member will contain the
+      id of the new connection.
+
+  __u64 pool_size;
+      The size of the communication pool, in bytes. The pool can be accessed
+      by calling mmap() on the file descriptor that was used to issue the
+      KDBUS_CMD_HELLO ioctl.
+
+  struct kdbus_bloom_parameter bloom;
+      Bloom filter parameter (see below).
+
+  __u8 id128[16];
+      Upon successful completion of the ioctl, this member will contain the
+      128 bit wide UUID of the connected bus.
+
+  struct kdbus_item items[0];
+      Variable list of items to add optional additional information. The
+      following items are currently expected/valid:
+
+      KDBUS_ITEM_CONN_DESCRIPTION
+        Contains a string to describes this connection's name, so it can be
+        identified later.
+
+      KDBUS_ITEM_NAME
+      KDBUS_ITEM_POLICY_ACCESS
+        For activators and policy holders only, combinations of these two

Documentation/kdbus.txt new file +62 -0

+
+6.4 Retrieving information on a connection
+------------------------------------------
+
+The KDBUS_CMD_CONN_INFO ioctl can be used to retrieve credentials and
+properties of the initial creator of a connection. This ioctl uses the
+following struct:
+
+struct kdbus_cmd_info {
+  __u64 size;
+    The overall size of the struct, including the name with its 0-byte string
+    terminator.
+
+  __u64 flags;
+    Specify which metadata items should be attached to the answer.
+    See section 13 for more details.
+
+    After the ioctl returns, this field will contain the current metadata
+    attach flags of the connection.
+
+  __u64 kernel_flags;
+    Valid flags for this command, returned by the kernel upon each call.
+
+  __u64 id;
+    The connection's numerical ID to retrieve information for. If set to
+    non-zero value, the 'name' field is ignored.
+
+  __u64 offset;
+    When the ioctl returns, this value will yield the offset of the connection
+    information inside the caller's pool.
+
+  struct kdbus_item items[0];
+    The optional item list, containing the well-known name to look up as
+    a KDBUS_ITEM_OWNED_NAME. Only required if the 'id' field is set to 0.
+    All other items are currently ignored.
+};
+
+After the ioctl returns, the following struct will be stored in the caller's
+pool at 'offset'.
+
+struct kdbus_info {
+  __u64 size;
+    The overall size of the struct, including all its items.
+
+  __u64 id;
+    The connection's unique ID.
+
+  __u64 flags;
+    The connection's flags as specified when it was created.
+
+  __u64 kernel_flags;
+    Valid flags for this command, returned by the kernel upon each call.
+
+  struct kdbus_item items[0];
+    Depending on the 'flags' field in struct kdbus_cmd_info, items of
+    types KDBUS_ITEM_OWNED_NAME and KDBUS_ITEM_CONN_DESCRIPTION are followed
+    here.
+};
+
+Once the caller is finished with parsing the return buffer, it needs to call
+KDBUS_CMD_FREE for the offset.
+

Documentation/kdbus.txt new file +11 -0

+
+7.3 Passing of Payload Data
+---------------------------
+
+When connecting to the bus, receivers request a memory pool of a given size,
+large enough to carry all backlog of data enqueued for the connection. The
+pool is internally backed by a shared memory file which can be mmap()ed by
+the receiver.
+
+KDBUS_MSG_PAYLOAD_VEC:
+  Messages are directly copied by the sending process into the receiver's pool,

Documentation/kdbus.txt new file +38 -0

+
+Apart from the sender filling-in the content into memfd files, the data will
+be passed as zero-copy from one process to another, read-only, shared between
+the peers.
+
+
+7.4 Receiving messages
+----------------------
+
+Messages are received by the client with the KDBUS_CMD_MSG_RECV ioctl. The
+endpoint file of the bus supports poll() to wake up the receiving process when
+new messages are queued up to be received.
+
+With the KDBUS_CMD_MSG_RECV ioctl, a struct kdbus_cmd_recv is used.
+
+struct kdbus_cmd_recv {
+  __u64 flags;
+    Flags to control the receive command.
+
+    KDBUS_RECV_PEEK
+      Just return the location of the next message. Do not install file
+      descriptors or anything else. This is usually used to determine the
+      sender of the next queued message.
+
+    KDBUS_RECV_DROP
+      Drop the next message without doing anything else with it, and free the
+      pool slice. This a short-cut for KDBUS_RECV_PEEK and KDBUS_CMD_FREE.
+
+    KDBUS_RECV_USE_PRIORITY
+      Use the priority field (see below).
+
+  __u64 kernel_flags;
+    Valid flags for this command, returned by the kernel upon each call.
+
+  __s64 priority;
+      With KDBUS_RECV_USE_PRIORITY set in flags, receive the next message in
+      the queue with at least the given priority. If no such message is waiting
+      in the queue, -ENOMSG is returned.

Documentation/kdbus.txt new file +22 -0

+A set of policy rules is described by a name and multiple access rules, defined
+by the following struct.
+
+struct kdbus_policy_access {
+  __u64 type;  /* USER, GROUP, WORLD */
+    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.
+
+  __u64 access;        /* OWN, TALK, SEE */
+    The access to grant.
+
+    KDBUS_POLICY_SEE
+      Allow the name to be seen.
+

+12. Pool
+===============================================================================

Documentation/kdbus.txt new file +3 -0

+
+A pool for data received from the kernel is installed for every connection of
+the bus, and is sized according to kdbus_cmd_hello.pool_size. It is accessed

Documentation/kdbus.txt new file +41 -0

+
+13. Metadata
+===============================================================================
+
+When a message is delivered to a receiver connection, it is augmented by
+metadata items in accordance to the destination's current attach flags. The
+information stored in those metadata items refer to the sender task at the
+time of sending the message, so even if any detail of the sender task has
+already changed upon message reception (or if the sender task does not exist
+anymore), the information is still preserved and won't be modfied until the
+message is freed.
+
+Note that there are two exceptions to the above rules:
+
+  a) Kernel generated messages don't have a source connection, so they won't be
+     augmented.
+
+  b) If a connection was created with faked credentials (see section 6.2),
+     the only attached metadata items are the ones provided by the connection
+     itself. Other bits in the destination's attach_flags_recv won't have any
+     effect in such cases.
+
+Also, there are two things to be considered by userspace programs regarding
+those metadata items:
+
+  a) Userspace must cope with the fact that it might get more metadata than
+     they requested. That happens, for example, when a broadcast message is
+     sent and receivers have different attach flags. Items that haven't been
+     requested should hence be silently ignored.
+
+  b) Userspace might not always get all requested metadata items that it
+     requested. That is because some of those items are only added if a
+     corresponding kernel feature has been enabled. Also, the two exceptions
+     described above will as well lead to less items be attached than
+     requested.
+
+
+13.1 Known item types
+---------------------
+
+The following attach flags are currently supported.

Documentation/kdbus.txt new file +6 -0

+  KDBUS_ATTACH_TID_COMM
+    Attaches an items of type KDBUS_ITEM_TID_COMM, transporting the sending
+    task's 'comm', for the tid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_PID_COMM
+    Attaches an items of type KDBUS_ITEM_PID_COMM, transporting the sending

Quoted 15 lines · Greg Kroah-Hartman

From: Daniel Mack <[email protected]>

kdbus is a system for low-latency, low-overhead, easy to use interprocess communication (IPC).

The interface to all functions in this driver is implemented through ioctls on files exposed through the mount point of a kdbusfs. This patch adds detailed documentation about the kernel level API design.

Signed-off-by Daniel Mack <[email protected]>

Signed-off-by David Herrmann <[email protected]>

Signed-off-by Djalal Harouni <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---

Documentation/kdbus.txt line 63

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+  Pool:
+    Each connection allocates a piece of shmem-backed memory that is used
+    to receive messages and answers to ioctl command from the kernel. It is
+    never used to send anything to the kernel. In order to access that memory,
+    userspace must mmap() it into its task.
+    See section 12 for more details.

At the risk of opening a can of worms, wouldn't this be much more useful if you could share a pool between multiple connections?

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
+struct kdbus_cmd_make argument.
+
+struct kdbus_cmd_make {
+  __u64 size;
+    The overall size of the struct, including its items.
+
+  __u64 flags;
+    The flags for creation.
+

Documentation/kdbus.txt line 283

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+    KDBUS_MAKE_ACCESS_GROUP
+      Make the device file group-accessible
+
+    KDBUS_MAKE_ACCESS_WORLD
+      Make the device file world-accessible

This thing is a file. What's wrong with using a normal POSIX mode? (And what to the read, write, and exec modes do?)

Documentation/kdbus.txt line 469

Quoted 8 lines

Documentation/kdbus.txt new file +8 -0

+      KDBUS_ITEM_CREDS
+      KDBUS_ITEM_SECLABEL
+        Privileged bus users may submit these types in order to create
+        connections with faked credentials. The only real use case for this
+        is a proxy service which acts on behalf of some other tasks. For a
+        connection that runs in that mode, the message's metadata items will
+        be limited to what's specified here. See section 13 for more
+        information.

This is still confusing. There are multiple places in which metadata is attached. Which does this apply to? And why are only creds and seclabel listed?

Quoted 5 lines

+6.5 Getting information about a connection's bus creator
+--------------------------------------------------------

Documentation/kdbus.txt new file +3 -0

+
+The KDBUS_CMD_BUS_CREATOR_INFO ioctl takes the same struct as
+KDBUS_CMD_CONN_INFO but is used to retrieve information about the creator of

Documentation/kdbus.txt line 563

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+the bus the connection is attached to. The metadata returned by this call is
+collected during the creation of the bus and is never altered afterwards, so
+it provides pristine information on the task that created the bus, at the
+moment when it did so.

What's this for? I understand the need for the creator of busses to be authenticated, but doing it like this mean that anyone who will *fail* authentication can DoS the authentic creator.

Quoted 15 lines

Documentation/kdbus.txt new file +15 -0

+
+7.3 Passing of Payload Data
+---------------------------
+
+When connecting to the bus, receivers request a memory pool of a given size,
+large enough to carry all backlog of data enqueued for the connection. The
+pool is internally backed by a shared memory file which can be mmap()ed by
+the receiver.
+
+KDBUS_MSG_PAYLOAD_VEC:
+  Messages are directly copied by the sending process into the receiver's pool,
+  that way two peers can exchange data by effectively doing a single-copy from
+  one process to another, the kernel will not buffer the data anywhere else.
+
+KDBUS_MSG_PAYLOAD_MEMFD:

Documentation/kdbus.txt line 833

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+  Messages can reference memfd files which contain the data.
+  memfd files are tmpfs-backed files that allow sealing of the content of the
+  file, which prevents all writable access to the file content.
+  Only sealed memfd files are accepted as payload data, which enforces
+  reliable passing of data; the receiver can assume that neither the sender nor
+  anyone else can alter the content after the message is sent.

This should specify *which* seals are checked.

Quoted 43 lines

Documentation/kdbus.txt new file +43 -0

+
+Apart from the sender filling-in the content into memfd files, the data will
+be passed as zero-copy from one process to another, read-only, shared between
+the peers.
+
+
+7.4 Receiving messages
+----------------------
+
+Messages are received by the client with the KDBUS_CMD_MSG_RECV ioctl. The
+endpoint file of the bus supports poll() to wake up the receiving process when
+new messages are queued up to be received.
+
+With the KDBUS_CMD_MSG_RECV ioctl, a struct kdbus_cmd_recv is used.
+
+struct kdbus_cmd_recv {
+  __u64 flags;
+    Flags to control the receive command.
+
+    KDBUS_RECV_PEEK
+      Just return the location of the next message. Do not install file
+      descriptors or anything else. This is usually used to determine the
+      sender of the next queued message.
+
+    KDBUS_RECV_DROP
+      Drop the next message without doing anything else with it, and free the
+      pool slice. This a short-cut for KDBUS_RECV_PEEK and KDBUS_CMD_FREE.
+
+    KDBUS_RECV_USE_PRIORITY
+      Use the priority field (see below).
+
+  __u64 kernel_flags;
+    Valid flags for this command, returned by the kernel upon each call.
+
+  __s64 priority;
+      With KDBUS_RECV_USE_PRIORITY set in flags, receive the next message in
+      the queue with at least the given priority. If no such message is waiting
+      in the queue, -ENOMSG is returned.
+
+  __u64 offset;
+      Upon return of the ioctl, this field contains the offset in the
+      receiver's memory pool.
+};

Documentation/kdbus.txt line 881

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+Unless KDBUS_RECV_DROP was passed, and given that the ioctl succeeded, the
+offset field contains the location of the new message inside the receiver's
+pool. The message is stored as struct kdbus_msg at this offset, and can be
+interpreted with the semantics described above.

I'm confused here. Is sent data written to the pool when send is called or when recv is called?

If the former, what prevents DoS, especially DoS due to sending too many fds?

If the latter, where is the data buffered in the mean time?

Documentation/kdbus.txt line 886

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+Also, if the connection allowed for file descriptor to be passed
+(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
+installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
+returns. The receiving task is obliged to close all of them appropriately.

This makes it sound like fds are installed at receive time. What prevents resource exhaustion due to having excessive numbers of fds in transit (that are presumably not accounted to anyone)?

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+7.5 Canceling messages synchronously waiting for replies
+--------------------------------------------------------
+
+When a connection sends a message with KDBUS_MSG_FLAGS_SYNC_REPLY and

Documentation/kdbus.txt line 900

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+blocks while waiting for the reply, the KDBUS_CMD_MSG_CANCEL ioctl can be
+used on the same file descriptor to cancel the message, based on its cookie.
+If there are multiple messages with the same cookie that are all synchronously
+waiting for a reply, all of them will be canceled. Obviously, this is only
+possible in multi-threaded applications.

What does "cancel the message" mean? Does it just mean that the wait for the reply is cancelled?

Documentation/kdbus.txt line 1315

Quoted 6 lines

+11. Policy
+===============================================================================

Documentation/kdbus.txt new file +4 -0

+
+A policy databases restrict the possibilities of connections to own, see and
+talk to well-known names. It can be associated with a bus (through a policy
+holder connection) or a custom endpoint.

ISTM metadata items on bus names should be replaced with policy that applies to the domain as a whole and governs bus creation.

Quoted 27 lines

Documentation/kdbus.txt new file +27 -0

+A set of policy rules is described by a name and multiple access rules, defined
+by the following struct.
+
+struct kdbus_policy_access {
+  __u64 type;  /* USER, GROUP, WORLD */
+    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.
+
+  __u64 access;        /* OWN, TALK, SEE */
+    The access to grant.
+
+    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.

Documentation/kdbus.txt line 1358

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+  __u64 id;
+    For KDBUS_POLICY_ACCESS_USER, stores the uid.
+    For KDBUS_POLICY_ACCESS_GROUP, stores the gid.
+};

What happens if there are multiple matches?

Documentation/kdbus.txt line 1425

Quoted 13 lines

Documentation/kdbus.txt new file +12 -0

+
+11.4 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 name 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.

This does seem illogical. Does the recipient at least know which well-known name was addressed?

Documentation/kdbus.txt line 1443

Quoted 6 lines

+11.5 Implicit policies
+----------------------

Documentation/kdbus.txt new file +4 -0

+
+Depending on the type of the endpoint, a set of implicit rules might be
+enforced. On default endpoints, the following set is enforced:
+

How do these rules interact with installed policy?

Documentation/kdbus.txt line 1448

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+  * 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.

Why?

If anyone ever strengthens the concept of identity to include things other than users (hmm -- there are already groups), this could be very limiting.

Documentation/kdbus.txt line 1452

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+  * Connections that own names might send broadcast messages to other
+    connections that belong to a different user, but only if that
+    destination connection does not own any name.
+

This is weird. It is also differently illogical than the "illogical" thing above.

Quoted 10 lines

+12. Pool
+===============================================================================

Documentation/kdbus.txt new file +8 -0

+
+A pool for data received from the kernel is installed for every connection of
+the bus, and is sized according to kdbus_cmd_hello.pool_size. It is accessed
+when one of the following ioctls is issued:
+
+  * KDBUS_CMD_MSG_RECV, to receive a message
+  * KDBUS_CMD_NAME_LIST, to dump the name registry
+  * KDBUS_CMD_CONN_INFO, to retrieve information on a connection

Documentation/kdbus.txt line 1477

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+Internally, the pool is organized in slices, stored in an rb-tree. The offsets
+returned by either one of the aforementioned ioctls describe offsets inside the
+pool. In order to make the slice available for subsequent calls, KDBUS_CMD_FREE
+has to be called on the offset.

Why are you documenting that the slices are stored in an rb-tree? That's just an implementation details, right?

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+
+To access the memory, the caller is expected to mmap() it to its task, like
+this:
+
+  /*
+   * POOL_SIZE has to be a multiple of PAGE_SIZE, and it must match the

Documentation/kdbus.txt line 1489

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+   * value that was previously passed in the .pool_size field of struct
+   * kdbus_cmd_hello.
+   */
+
+  buf = mmap(NULL, POOL_SIZE, PROT_READ, MAP_PRIVATE, conn_fd, 0);
+

Will mapping with PROT_WRITE fail? What about MAP_SHARED?

And why are you suggesting MAP_PRIVATE? That's just strange.

Quoted 3 lines

+
+13. Metadata
+===============================================================================

Quoted 8 lines

+13.1 Known item types
+---------------------

Documentation/kdbus.txt new file +6 -0

+
+The following attach flags are currently supported.
+
+  KDBUS_ATTACH_TIMESTAMP
+    Attaches an item of type KDBUS_ITEM_TIMESTAMP which contains both the
+    monotonic and the realtime timestamp, taken when the message was

Documentation/kdbus.txt line 1540

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+    processed on the kernel side.
+
+  KDBUS_ATTACH_CREDS
+    Attaches an item of type KDBUS_ITEM_CREDS, containing credentials as
+    described in kdbus_creds: the uid, gid, pid, tid and starttime of the task.
+

As mentioned last time, please remove or justify starttime.

Documentation/kdbus.txt line 1549

Quoted 9 lines

Documentation/kdbus.txt new file +9 -0

+  KDBUS_ATTACH_AUXGROUPS
+    Attaches an item of type KDBUS_ITEM_AUXGROUPS, containing a dynamic
+    number of auxiliary groups the sending task was a member of.
+
+  KDBUS_ATTACH_NAMES
+    Attaches items of type KDBUS_ITEM_OWNED_NAME, one for each name the sending
+    connection currently owns. The name and flags are stored in kdbus_item.name
+    for each of them.
+

That's interesting. What's it for?

Quoted 13 lines

Documentation/kdbus.txt new file +13 -0

+  KDBUS_ATTACH_TID_COMM
+    Attaches an items of type KDBUS_ITEM_TID_COMM, transporting the sending
+    task's 'comm', for the tid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_PID_COMM
+    Attaches an items of type KDBUS_ITEM_PID_COMM, transporting the sending
+    task's 'comm', for the pid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_EXE
+    Attaches an item of type KDBUS_ITEM_EXE, containing the path to the
+    executable of the sending task, stored in kdbus_item.str.
+
+  KDBUS_ATTACH_CMDLINE

Documentation/kdbus.txt line 1565

Quoted 3 lines

Documentation/kdbus.txt new file +3 -0

+    Attaches an item of type KDBUS_ITEM_CMDLINE, containing the command line
+    arguments of the sending task, as an array of strings, stored in
+    kdbus_item.str.

Please remove these four items. They are genuinely useless. Anything that uses them for anything is either buggy or should have asked the sender to put the value in the payload (and immediately wondered why it was doing that).

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+  KDBUS_ATTACH_CGROUP
+    Attaches an item of type KDBUS_ITEM_CGROUP with the task's cgroup path.
+
+  KDBUS_ATTACH_CAPS

Documentation/kdbus.txt line 1576

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+    Attaches an item of type KDBUS_ITEM_CAPS, carrying sets of capabilities
+    that should be accessed via kdbus_item.caps.caps. Also, userspace should
+    be written in a way that it takes kdbus_item.caps.last_cap into account,
+    and derive the number of sets and rows from the item size and the reported
+    number of valid capability bits.
+

Please remove this, too, or justify its use.

Documentation/kdbus.txt line 1580

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+  KDBUS_ATTACH_SECLABEL
+    Attaches an item of type KDBUS_ITEM_SECLABEL, which contains the SELinux
+    security label of the sending task. Access via kdbus_item->str.
+

This one, too, and please justify why code that uses it will work in containers an on non-selinux systems.

Documentation/kdbus.txt line 1584

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+  KDBUS_ATTACH_AUDIT
+    Attaches an item of type KDBUS_ITEM_AUDIT, which contains the audio label
+    of the sending taskj. Access via kdbus_item->str.
+

I will NAK the hell out of this until, at the very least, someone documents what this means, how to parse it, what its stability rules are, who is allowed to see the value it contains, why that value will never evolve to become *more* security sensitive than it is now, etc.

Audit gets to do crazy sh*t because it's restricted to privileged receivers. This isn't restricted like that, so it doesn't deserve the same dispensation. (And, honestly, I'm not sure that audit really deserves its free pass on making sense.)

Documentation/kdbus.txt line 1588

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+  KDBUS_ATTACH_CONN_DESCRIPTION
+    Attaches an item of type KDBUS_ITEM_CONN_DESCRIPTION that contains the
+    sender connection's current name in kdbus_item.str.
+

Which name? Can't there be several?

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+
+13.1 Metadata and namespaces
+----------------------------
+

Documentation/kdbus.txt line 1598

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+Metadata such as PIDs, UIDs or GIDs are automatically translated to the
+namespaces of the domain that is used to send a message over. The namespaces
+of a domain are pinned at creation time, which is when the filesystem has been
+mounted.
+
+Metadata items that cannot be translated are dropped.

What if the receiver said that the item was mandatory?

Hi Andy!

Quoted 24 lines · Andy Lutomirski

Quoted 15 lines · Greg Kroah-Hartman

From: Daniel Mack <[email protected]>

kdbus is a system for low-latency, low-overhead, easy to use interprocess communication (IPC).

The interface to all functions in this driver is implemented through ioctls on files exposed through the mount point of a kdbusfs. This patch adds detailed documentation about the kernel level API design.

Signed-off-by Daniel Mack <[email protected]>

Signed-off-by David Herrmann <[email protected]>

Signed-off-by Djalal Harouni <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---

Documentation/kdbus.txt line 63

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+  Pool:
+    Each connection allocates a piece of shmem-backed memory that is used
+    to receive messages and answers to ioctl command from the kernel. It is
+    never used to send anything to the kernel. In order to access that memory,
+    userspace must mmap() it into its task.
+    See section 12 for more details.

Quoted 2 lines

At the risk of opening a can of worms, wouldn't this be much more useful if you could share a pool between multiple connections?

Within a process it could theoretically be possible to share the same memory pool between multiple connections made by the process. However, note that normally a process only has a single connection to the bus open (possibly two, if it opens a connection to both the system and the user bus). Now, sharing the receiver buffer could certainly be considered an optimization, but it would have no effect on "usefulness", though, as just allocating space from a single shared per-process receiver won't give you any new possibilities...

We have thought about this, but decided to delay it for now. Shared pools can easily be added as an extension later on.

[snip]

Quoted 10 lines

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
+struct kdbus_cmd_make argument.
+
+struct kdbus_cmd_make {
+  __u64 size;
+    The overall size of the struct, including its items.
+
+  __u64 flags;
+    The flags for creation.
+

Quoted 8 lines

Documentation/kdbus.txt line 283

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+    KDBUS_MAKE_ACCESS_GROUP
+      Make the device file group-accessible
+
+    KDBUS_MAKE_ACCESS_WORLD
+      Make the device file world-accessible

This thing is a file. What's wrong with using a normal POSIX mode? (And what to the read, write, and exec modes do?)

Domains and buses are directories, endpoints are files. Domains also create control-files implicitly.

For kdbus clients there is just access or no access, but not distinction between read, write and execute access. Due to that we just break this down to per-group and world access bits, since doing more is pointless, and we shouldn't allow shoehorning more stuff into the access mode.

[snip]

Quoted 9 lines

Documentation/kdbus.txt line 469

Quoted 8 lines

Documentation/kdbus.txt new file +8 -0

+      KDBUS_ITEM_CREDS
+      KDBUS_ITEM_SECLABEL
+        Privileged bus users may submit these types in order to create
+        connections with faked credentials. The only real use case for this
+        is a proxy service which acts on behalf of some other tasks. For a
+        connection that runs in that mode, the message's metadata items will
+        be limited to what's specified here. See section 13 for more
+        information.

Quoted 3 lines

This is still confusing. There are multiple places in which metadata is attached. Which does this apply to? And why are only creds and seclabel listed?

Yes, and there are multiple places where metadata is *gathered*. This ioctl creates connections, so only the items that are actually *gathered* by that ioctl are documented here. These items are not part of any messages, but are used as identification of the connection owner (and in this particular case, to allow privileged proxies to overwrite the items so they can properly proxy a legacy-dbus peer connection).

[snip]

Quoted 5 lines

Quoted 5 lines

+6.5 Getting information about a connection's bus creator
+--------------------------------------------------------

Documentation/kdbus.txt new file +3 -0

+
+The KDBUS_CMD_BUS_CREATOR_INFO ioctl takes the same struct as
+KDBUS_CMD_CONN_INFO but is used to retrieve information about the creator of

Quoted 8 lines

Documentation/kdbus.txt line 563

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+the bus the connection is attached to. The metadata returned by this call is
+collected during the creation of the bus and is never altered afterwards, so
+it provides pristine information on the task that created the bus, at the
+moment when it did so.

What's this for? I understand the need for the creator of busses to be authenticated, but doing it like this mean that anyone who will *fail* authentication can DoS the authentic creator.

This returns information on a bus owner, to determine whether a connection is connected to a system, user or session bus. Note that the bus-creator itself is not a valid peer on the bus, so you cannot send messages to them. Which kind of DoS do you have in mind?

Quoted 16 lines

Quoted 16 lines

Documentation/kdbus.txt new file +15 -0

+
+7.3 Passing of Payload Data
+---------------------------
+
+When connecting to the bus, receivers request a memory pool of a given size,
+large enough to carry all backlog of data enqueued for the connection. The
+pool is internally backed by a shared memory file which can be mmap()ed by
+the receiver.
+
+KDBUS_MSG_PAYLOAD_VEC:
+  Messages are directly copied by the sending process into the receiver's pool,
+  that way two peers can exchange data by effectively doing a single-copy from
+  one process to another, the kernel will not buffer the data anywhere else.
+
+KDBUS_MSG_PAYLOAD_MEMFD:

Quoted 8 lines

Documentation/kdbus.txt line 833

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+  Messages can reference memfd files which contain the data.
+  memfd files are tmpfs-backed files that allow sealing of the content of the
+  file, which prevents all writable access to the file content.
+  Only sealed memfd files are accepted as payload data, which enforces
+  reliable passing of data; the receiver can assume that neither the sender nor
+  anyone else can alter the content after the message is sent.

This should specify *which* seals are checked.

True. Will be added to the documentation. For the record, it's the full set of seals right now, so F_SEAL_SHRINK|F_SEAL_GROW|F_SEAL_WRITE|F_SEAL_SEAL.

Quoted 44 lines

Quoted 44 lines

Documentation/kdbus.txt new file +43 -0

+
+Apart from the sender filling-in the content into memfd files, the data will
+be passed as zero-copy from one process to another, read-only, shared between
+the peers.
+
+
+7.4 Receiving messages
+----------------------
+
+Messages are received by the client with the KDBUS_CMD_MSG_RECV ioctl. The
+endpoint file of the bus supports poll() to wake up the receiving process when
+new messages are queued up to be received.
+
+With the KDBUS_CMD_MSG_RECV ioctl, a struct kdbus_cmd_recv is used.
+
+struct kdbus_cmd_recv {
+  __u64 flags;
+    Flags to control the receive command.
+
+    KDBUS_RECV_PEEK
+      Just return the location of the next message. Do not install file
+      descriptors or anything else. This is usually used to determine the
+      sender of the next queued message.
+
+    KDBUS_RECV_DROP
+      Drop the next message without doing anything else with it, and free the
+      pool slice. This a short-cut for KDBUS_RECV_PEEK and KDBUS_CMD_FREE.
+
+    KDBUS_RECV_USE_PRIORITY
+      Use the priority field (see below).
+
+  __u64 kernel_flags;
+    Valid flags for this command, returned by the kernel upon each call.
+
+  __s64 priority;
+      With KDBUS_RECV_USE_PRIORITY set in flags, receive the next message in
+      the queue with at least the given priority. If no such message is waiting
+      in the queue, -ENOMSG is returned.
+
+  __u64 offset;
+      Upon return of the ioctl, this field contains the offset in the
+      receiver's memory pool.
+};

Quoted 8 lines

Documentation/kdbus.txt line 881

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+Unless KDBUS_RECV_DROP was passed, and given that the ioctl succeeded, the
+offset field contains the location of the new message inside the receiver's
+pool. The message is stored as struct kdbus_msg at this offset, and can be
+interpreted with the semantics described above.

I'm confused here. Is sent data written to the pool when send is called or when recv is called?

When send is called.

Quoted 1 line

If the former, what prevents DoS, especially DoS due to sending too many fds?

FDs are installed into the task only when the receiver issues CMD_RECV, so a task won't explode unless it issues that ioctl. Plus, receiving FDs is already a per-connection opt-in. Furthermore, you can CMD_PEEK messages which allows you to look at the full message _without_ installing FDs. If you don't want the FDs, you can CMD_DROP the message.

Quoted 11 lines

If the latter, where is the data buffered in the mean time?

Documentation/kdbus.txt line 886

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+Also, if the connection allowed for file descriptor to be passed
+(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
+installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
+returns. The receiving task is obliged to close all of them appropriately.

This makes it sound like fds are installed at receive time. What prevents resource exhaustion due to having excessive numbers of fds in transit (that are presumably not accounted to anyone)?

We have a per-user message accounting for undelivered messages, as well as a maximum number of pending messages per connection on the receiving end. These limits are accounted on a "user<->user" basis, so the limit of a user A will not affect two other users (B and C) talking.

Quoted 9 lines

Documentation/kdbus.txt line 1315

Quoted 6 lines

+11. Policy
+===============================================================================

Documentation/kdbus.txt new file +4 -0

+
+A policy databases restrict the possibilities of connections to own, see and
+talk to well-known names. It can be associated with a bus (through a policy
+holder connection) or a custom endpoint.

ISTM metadata items on bus names should be replaced with policy that applies to the domain as a whole and governs bus creation.

No, well-known names are bound to buses, so a bus is really the right place to hold policy about which process is allowed to claim them. Every user is allowed to create a bus of its own, there's no policy for that, and there shouldn't be.

It has nothing to do with metadata items.

Quoted 28 lines

Quoted 28 lines

Documentation/kdbus.txt new file +27 -0

+A set of policy rules is described by a name and multiple access rules, defined
+by the following struct.
+
+struct kdbus_policy_access {
+  __u64 type;  /* USER, GROUP, WORLD */
+    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.
+
+  __u64 access;        /* OWN, TALK, SEE */
+    The access to grant.
+
+    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.

Quoted 8 lines

Documentation/kdbus.txt line 1358

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+  __u64 id;
+    For KDBUS_POLICY_ACCESS_USER, stores the uid.
+    For KDBUS_POLICY_ACCESS_GROUP, stores the gid.
+};

What happens if there are multiple matches?

We only have _granting_ policy entries. We search through the policy-db until we find an entry that grants access. We do _not_ stop on the first item that matches.

Quoted 17 lines

Quoted 4 lines

Documentation/kdbus.txt new file +2 -0

+
+11.4 TALK access and multiple well-known names per connection

Documentation/kdbus.txt line 1425

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+-------------------------------------------------------------
+
+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 name 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.

This does seem illogical. Does the recipient at least know which well-known name was addressed?

If the sender addressed it to a well-known name, yes. If the sender addressed the message to a unique-ID, there will be no such name, of course. Still, the policy applies to such transactions either way (standard D-Bus behavior).

Note however that dbus1 will not pass along the destination well-known name, hence most userspace libraries will ignore this information too, even if they run on kdbus which might pass this information around. The right way for services that carry multiple service names to discern which actual service is being talked to is having separate object paths for the different functionality to hide between the services.

Quoted 9 lines

Documentation/kdbus.txt line 1443

Quoted 7 lines

+11.5 Implicit policies
+----------------------

Documentation/kdbus.txt new file +4 -0

+
+Depending on the type of the endpoint, a set of implicit rules might be
+enforced. On default endpoints, the following set is enforced:
+

How do these rules interact with installed policy?

As said before, all policy entries _grant_ access. We look through all entries until we find one that grants access.

Quoted 6 lines

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+  * 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.

Quoted 1 line

Why?

All limits on buses are enforced on a user<->user basis. We don't want to provide policies that are more fine-grained than our accounting.

Quoted 4 lines

If anyone ever strengthens the concept of identity to include things other than users (hmm -- there are already groups), this could be very limiting.

If user-based accounting is not suitable, you can create custom endpoints. Future extensions to that are always welcome. So far, the default user-based accounting was enough. And I think it's suitable as default.

Quoted 4 lines

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+  * Connections that own names might send broadcast messages to other
+    connections that belong to a different user, but only if that
+    destination connection does not own any name.
+

Quoted 3 lines

This is weird. It is also differently illogical than the "illogical" thing above.

Actually it follows the same model described above. If two connections are running under the same user then broadcasts are allowed, but if they are running under different users *and* if the destination owns a well-known name, then broadcasts are subject to TALK policy checks since that destination may own a restricted well-known name that is not interested in broadcasts. So this implicit policy is just fast-path for the common case where the target is subscribed to a broadcast and does not own any name.

Quoted 6 lines

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+
+To access the memory, the caller is expected to mmap() it to its task, like
+this:
+
+  /*
+   * POOL_SIZE has to be a multiple of PAGE_SIZE, and it must match the

Quoted 8 lines

Documentation/kdbus.txt line 1489

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+   * value that was previously passed in the .pool_size field of struct
+   * kdbus_cmd_hello.
+   */
+
+  buf = mmap(NULL, POOL_SIZE, PROT_READ, MAP_PRIVATE, conn_fd, 0);
+

Will mapping with PROT_WRITE fail? What about MAP_SHARED?

PROT_WRITE will fail and VM_MAYWRITE is cleared.

Quoted 1 line

And why are you suggesting MAP_PRIVATE? That's just strange.

This was a leftover from pre-3.17. memfds require you to use MAP_PRIVATE if SEAL_WRITE is set (which is a linux-specific behavior, where MAP_SHARED is always accounted as writable mapping as mprotect(VM_WRITE) can be called any time). I fixed this up.

Quoted 4 lines

Quoted 4 lines

+
+13. Metadata
+===============================================================================

[snip]

Quoted 8 lines

Quoted 8 lines

+13.1 Known item types
+---------------------

Documentation/kdbus.txt new file +6 -0

+
+The following attach flags are currently supported.
+
+  KDBUS_ATTACH_TIMESTAMP
+    Attaches an item of type KDBUS_ITEM_TIMESTAMP which contains both the
+    monotonic and the realtime timestamp, taken when the message was

Quoted 8 lines

Documentation/kdbus.txt line 1540

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+    processed on the kernel side.
+
+  KDBUS_ATTACH_CREDS
+    Attaches an item of type KDBUS_ITEM_CREDS, containing credentials as
+    described in kdbus_creds: the uid, gid, pid, tid and starttime of the task.
+

As mentioned last time, please remove or justify starttime.

starttime allows detecting PID overflows. Exposing the process starttime is useful to detect when a PID is getting reused. Unfortunately, we don't have 64bit pids, so we need the pid+time combination to avoid ambiguity.

Quoted 12 lines

Documentation/kdbus.txt line 1549

Quoted 10 lines

Documentation/kdbus.txt new file +9 -0

+  KDBUS_ATTACH_AUXGROUPS
+    Attaches an item of type KDBUS_ITEM_AUXGROUPS, containing a dynamic
+    number of auxiliary groups the sending task was a member of.
+
+  KDBUS_ATTACH_NAMES
+    Attaches items of type KDBUS_ITEM_OWNED_NAME, one for each name the sending
+    connection currently owns. The name and flags are stored in kdbus_item.name
+    for each of them.
+

That's interesting. What's it for?

It a valuable piece of information for receivers to know which bus names a sender has claimed. For instance, we need this information for the D-Bus proxy service, because we have to apply D-Bus1 policy in that case, and we need to get a list of owned names in a race-free manner to check the policy against.

Quoted 14 lines

Quoted 14 lines

Documentation/kdbus.txt new file +13 -0

+  KDBUS_ATTACH_TID_COMM
+    Attaches an items of type KDBUS_ITEM_TID_COMM, transporting the sending
+    task's 'comm', for the tid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_PID_COMM
+    Attaches an items of type KDBUS_ITEM_PID_COMM, transporting the sending
+    task's 'comm', for the pid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_EXE
+    Attaches an item of type KDBUS_ITEM_EXE, containing the path to the
+    executable of the sending task, stored in kdbus_item.str.
+
+  KDBUS_ATTACH_CMDLINE

Quoted 8 lines

Documentation/kdbus.txt line 1565

Quoted 3 lines

Documentation/kdbus.txt new file +3 -0

+    Attaches an item of type KDBUS_ITEM_CMDLINE, containing the command line
+    arguments of the sending task, as an array of strings, stored in
+    kdbus_item.str.

Please remove these four items. They are genuinely useless. Anything that uses them for anything is either buggy or should have asked the sender to put the value in the payload (and immediately wondered why it was doing that).

We use them for logging, debugging and monitoring. With our wireshark extension it's pretty useful to know the comm-name of a process when monitoring a bus. As we explained last time, this is not about security. We're aware that a process can modify them. We use them only as additional meta-data for logging and debugging.

If we put those items into the payload, we have to transmit this data even if the destination process is not interested in this. Furthermore, each caller has to run multiple syscalls on each message to retrieve those values.

We use these items heavily for filtering and debugging, regardless of the payload protocol that is transmitted on the bus.

To give another specific use-case here: dbus supports bus activation, where a message sent to a non-running service causes it to be spawned implicitly without losing the message. Now, with such a scheme it is incredibly useful to be able to log which client caused a service to be triggered, hence we want to know the cmdline/exe/comm of the client. Not knowing this is a major pita when trying to trace the boot process and figuring out why a specific service got activated.

Also note that since v2 of the patch there's actually a per-sender mask for meta-data like this, hence a peer which doesn't want to pass its exec/cmdline/comm along can do that. Of course, this will seriously hamper debuggability and transparency...

Quoted 14 lines

Documentation/kdbus.txt line 1576

Quoted 12 lines

Documentation/kdbus.txt new file +11 -0

+
+  KDBUS_ATTACH_CGROUP
+    Attaches an item of type KDBUS_ITEM_CGROUP with the task's cgroup path.
+
+  KDBUS_ATTACH_CAPS
+    Attaches an item of type KDBUS_ITEM_CAPS, carrying sets of capabilities
+    that should be accessed via kdbus_item.caps.caps. Also, userspace should
+    be written in a way that it takes kdbus_item.caps.last_cap into account,
+    and derive the number of sets and rows from the item size and the reported
+    number of valid capability bits.
+

Please remove this, too, or justify its use.

cgroup information tells us which service is doing a bus request. This is useful for a variety of things. For example, the bus activation logging item above benefits from it. In general, if some message shall be logged about any client it is useful to know its service name.

Capabilities are useful to authenticate specific method calls. For example, when a client asks systemd to reboot, without this concept we can only check for UID==0 to decide whether to allow this. Breaking this down to capabilities in a race-free way has the benefit of allowing systemd to bind this to CAP_SYS_BOOT instead. There is no reason to deny a process with CAP_SYS_BOOT to reboot via bus-APIs, as they could just enforce it via syscalls, anyway.

We think it's a useful and reliable authentication method. Why should we remove it?

Anyway, these items are just optional. The sender can refuse the reveal them, and the item is only transmitted if the receiver opted in for it, too. So there's no need to drop any item type from the protocol.

Quoted 8 lines

Documentation/kdbus.txt line 1580

Quoted 5 lines

Documentation/kdbus.txt new file +4 -0

+  KDBUS_ATTACH_SECLABEL
+    Attaches an item of type KDBUS_ITEM_SECLABEL, which contains the SELinux
+    security label of the sending task. Access via kdbus_item->str.
+

This one, too, and please justify why code that uses it will work in containers an on non-selinux systems.

This maps to SCM_PEERSEC on AF_UNIX sockets. This is actually heavily used already on dbus1. For example, systemd actually uses this information about a bus peer to check whether certain operations are allowed, on top of the normal policy. To give an explicit example:
when starting a service systemd gets the client's peer label from AF_UNIX via SCM_PEERSEC, reads the security label of the service file in question, and then checks the selinux database (via one of libselinux APIs) whether to allow this change.

Note that this is really nothing we came up with, it's code from the SELinux folks, it's simple enough, and has been exposed and used that way since ages in dbus1. libselinux offers all the right APIs to make use of this, and kdbus really needs to provide the same functionality as dbus1 in this regard here.

Let met stress that checking the selinux database here is alway *on top* of the normal UID/caps based security checks services do. This is exactly how selinux enforces checks on files on top of UID/caps checks, or on process or anything else that is selinux-managed.

Quoted 11 lines

Documentation/kdbus.txt line 1584

Quoted 5 lines

Documentation/kdbus.txt new file +4 -0

+  KDBUS_ATTACH_AUDIT
+    Attaches an item of type KDBUS_ITEM_AUDIT, which contains the audio label
+    of the sending taskj. Access via kdbus_item->str.
+

I will NAK the hell out of this until, at the very least, someone documents what this means, how to parse it, what its stability rules are, who is allowed to see the value it contains, why that value will never evolve to become *more* security sensitive than it is now, etc.

Quoted 4 lines

Audit gets to do crazy sh*t because it's restricted to privileged receivers. This isn't restricted like that, so it doesn't deserve the same dispensation. (And, honestly, I'm not sure that audit really deserves its free pass on making sense.)

This was based on a misunderstanding, so I will ignore it here. Lets discuss this on the metadata-patch, in case it's still unclear.

Quoted 6 lines

Quoted 5 lines

Documentation/kdbus.txt new file +4 -0

+  KDBUS_ATTACH_CONN_DESCRIPTION
+    Attaches an item of type KDBUS_ITEM_CONN_DESCRIPTION that contains the
+    sender connection's current name in kdbus_item.str.
+

Quoted 1 line

Which name? Can't there be several?

No. There is only one connection description string, copied verbatim from what the connection supplied during HELLO.

Note that this is really just about debugging, since in some cases processes might end up with multiple kdbus fds, and it is useful in tools like "busctl" to know which one is which.

Quoted 13 lines

Documentation/kdbus.txt line 1598

Quoted 11 lines

Documentation/kdbus.txt new file +10 -0

+
+13.1 Metadata and namespaces
+----------------------------
+
+Metadata such as PIDs, UIDs or GIDs are automatically translated to the
+namespaces of the domain that is used to send a message over. The namespaces
+of a domain are pinned at creation time, which is when the filesystem has been
+mounted.
+
+Metadata items that cannot be translated are dropped.

What if the receiver said that the item was mandatory?

It is still dropped. It's the responsibility of the receiver to reject messages that lack required metadata.

Quoted 15 lines · David Herrmann

[snip]

Quoted 5 lines

Quoted 5 lines

+6.5 Getting information about a connection's bus creator
+--------------------------------------------------------

Documentation/kdbus.txt new file +3 -0

+
+The KDBUS_CMD_BUS_CREATOR_INFO ioctl takes the same struct as
+KDBUS_CMD_CONN_INFO but is used to retrieve information about the creator of

Quoted 8 lines

Documentation/kdbus.txt line 563

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+the bus the connection is attached to. The metadata returned by this call is
+collected during the creation of the bus and is never altered afterwards, so
+it provides pristine information on the task that created the bus, at the
+moment when it did so.

What's this for? I understand the need for the creator of busses to be authenticated, but doing it like this mean that anyone who will *fail* authentication can DoS the authentic creator.

Quoted 4 lines

This returns information on a bus owner, to determine whether a connection is connected to a system, user or session bus. Note that the bus-creator itself is not a valid peer on the bus, so you cannot send messages to them. Which kind of DoS do you have in mind?

I assume that the logic is something like:

connect to bus
request bus metadata
if (bus metadata matches expectations) {
great, trust the bus!
} else {
oh crap!
}

If I'm understanding it right, then user code only really has two
outcomes: the good case and the "oh crap!" case. The problem is that "oh crap!" isn't a clean failure -- if it happens, then the application has just been DoSed, because in that case, one of two things happened:

1. Some policy mismatch means that the legitimate bus owner did create the bus, but the user application is confused. This will result in difficult-to-diagnose failures.

2. A malicious or confused program created the bus. This is a DoS -- even the legitimate bus creator can't actually create the bus now.

So I think that the policy should be applied at the time that the bus name is claimed, not at the time that someone else tries to use the bus. IOW, the way that you verify you're talking to the system bus should be by checking that the bus is called "system", not by checking that UID 0 created the bus.

Quoted 10 lines

Quoted 9 lines

Documentation/kdbus.txt line 886

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+
+Also, if the connection allowed for file descriptor to be passed
+(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
+installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
+returns. The receiving task is obliged to close all of them appropriately.

This makes it sound like fds are installed at receive time. What prevents resource exhaustion due to having excessive numbers of fds in transit (that are presumably not accounted to anyone)?

Quoted 5 lines

We have a per-user message accounting for undelivered messages, as well as a maximum number of pending messages per connection on the receiving end. These limits are accounted on a "user<->user" basis, so the limit of a user A will not affect two other users (B and C) talking.

But you can shove tons of fds in a message, and you can have lots of messages, and some of the fds can be fds of unix sockets that have fds queued up in them, and one of those fds could be the fd to the kdbus connection that sent the fd...

This is not advice as to what to do about it, but I think that it will be a problem at some point.

Quoted 10 lines

Quoted 9 lines

Documentation/kdbus.txt line 1315

Quoted 6 lines

+11. Policy
+===============================================================================

Documentation/kdbus.txt new file +4 -0

+
+A policy databases restrict the possibilities of connections to own, see and
+talk to well-known names. It can be associated with a bus (through a policy
+holder connection) or a custom endpoint.

ISTM metadata items on bus names should be replaced with policy that applies to the domain as a whole and governs bus creation.

Quoted 6 lines

No, well-known names are bound to buses, so a bus is really the right place to hold policy about which process is allowed to claim them. Every user is allowed to create a bus of its own, there's no policy for that, and there shouldn't be.

It has nothing to do with metadata items.

But it does -- the creator of the bus binds metadata to that bus at creation time.

I think that a better solution would be to have a global policy that says, for example, "to create the bus called 'system', the creator must have selinux label xyz" or "to create a user bus called uid-1000-privileged-ui-bus the creator must have some cgroup" or whatever.

Although maybe a better solution would leave this in the kernel but allow any cgroup to create a bus with a same that indicates the creating cgroup. Then I could have my desktop shell create a "/cgroup/path/to/desktop" for per-user privileged things.

Quoted 37 lines

Quoted 36 lines

Quoted 23 lines

Documentation/kdbus.txt new file +22 -0

+A set of policy rules is described by a name and multiple access rules, defined
+by the following struct.
+
+struct kdbus_policy_access {
+  __u64 type;  /* USER, GROUP, WORLD */
+    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.
+
+  __u64 access;        /* OWN, TALK, SEE */
+    The access to grant.
+
+    KDBUS_POLICY_SEE
+      Allow the name to be seen.
+

Documentation/kdbus.txt line 1358

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+    KDBUS_POLICY_TALK
+      Allow the name to be talked to.
+
+    KDBUS_POLICY_OWN
+      Allow the name to be owned.
+
+  __u64 id;
+    For KDBUS_POLICY_ACCESS_USER, stores the uid.
+    For KDBUS_POLICY_ACCESS_GROUP, stores the gid.
+};

What happens if there are multiple matches?

Quoted 3 lines

We only have _granting_ policy entries. We search through the policy-db until we find an entry that grants access. We do _not_ stop on the first item that matches.

Yay! Can you document that more clearly?

Quoted 23 lines

Quoted 17 lines

Quoted 4 lines

Documentation/kdbus.txt new file +2 -0

+
+11.4 TALK access and multiple well-known names per connection

Documentation/kdbus.txt line 1425

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+-------------------------------------------------------------
+
+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 name 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.

This does seem illogical. Does the recipient at least know which well-known name was addressed?

If the sender addressed it to a well-known name, yes. If the sender addressed the message to a unique-ID, there will be no such name, of course. Still, the policy applies to such transactions either way (standard D-Bus behavior).

Quoted 7 lines

Note however that dbus1 will not pass along the destination well-known name, hence most userspace libraries will ignore this information too, even if they run on kdbus which might pass this information around. The right way for services that carry multiple service names to discern which actual service is being talked to is having separate object paths for the different functionality to hide between the services.

It seems unfortunate to keep around this really weird behavior for the benefit of legacy applications. Could there perhaps be a flag that a connection can set to indicate that it understands per-destination access control and therefore wants stricter policy enforcement?

Quoted 21 lines

Quoted 9 lines

Documentation/kdbus.txt line 1443

Quoted 7 lines

+11.5 Implicit policies
+----------------------

Documentation/kdbus.txt new file +4 -0

+
+Depending on the type of the endpoint, a set of implicit rules might be
+enforced. On default endpoints, the following set is enforced:
+

How do these rules interact with installed policy?

As said before, all policy entries _grant_ access. We look through all entries until we find one that grants access.

Quoted 7 lines

Documentation/kdbus.txt line 1448

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+  * 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.

Why?

Quoted 2 lines

All limits on buses are enforced on a user<->user basis. We don't want to provide policies that are more fine-grained than our accounting.

This seems completely at odds with all the fine-grained metadata stuff. Also, anything that relies on this may get very confused when the LSM hooks go in, because I'm reasonably sure that the intent is for them to *not* follow this principle.

Quoted 14 lines

Quoted 4 lines

If anyone ever strengthens the concept of identity to include things other than users (hmm -- there are already groups), this could be very limiting.

If user-based accounting is not suitable, you can create custom endpoints. Future extensions to that are always welcome. So far, the default user-based accounting was enough. And I think it's suitable as default.

Quoted 4 lines

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+  * Connections that own names might send broadcast messages to other
+    connections that belong to a different user, but only if that
+    destination connection does not own any name.
+

(Also, what does "might" mean here?)

Quoted 4 lines

Quoted 3 lines

This is weird. It is also differently illogical than the "illogical" thing above.

Quoted 8 lines

Actually it follows the same model described above. If two connections are running under the same user then broadcasts are allowed, but if they are running under different users *and* if the destination owns a well-known name, then broadcasts are subject to TALK policy checks since that destination may own a restricted well-known name that is not interested in broadcasts. So this implicit policy is just fast-path for the common case where the target is subscribed to a broadcast and does not own any name.

Huh?

Say I have two users, "Sender" and "Receiver", each with a single connection. If Receiver owns no well-known names, then Sender can send to it. If Receiver owns one well-known name, then Sender needs to pass a TALK check on that name. If Reciever owns two well-known names, then Sender only needs to pass a TALK check on one of them.

Am I understanding this right? If I am, then I think this is in the category of baroque and inconsistent security rules which everyone will screw up and therefore introduce security vulnerabilities.

Can you really not enforce the much simpler rule that, to send to a name, you must have permission to send to *that* name? If legacy dbus1 receivers register two names and don't validate everything correctly, then only the legacy receivers have problems.

Quoted 22 lines

Quoted 4 lines

Quoted 4 lines

+
+13. Metadata
+===============================================================================

[snip]

Quoted 8 lines

Quoted 8 lines

+13.1 Known item types
+---------------------

Documentation/kdbus.txt new file +6 -0

+
+The following attach flags are currently supported.
+
+  KDBUS_ATTACH_TIMESTAMP
+    Attaches an item of type KDBUS_ITEM_TIMESTAMP which contains both the
+    monotonic and the realtime timestamp, taken when the message was

Quoted 8 lines

Documentation/kdbus.txt line 1540

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+    processed on the kernel side.
+
+  KDBUS_ATTACH_CREDS
+    Attaches an item of type KDBUS_ITEM_CREDS, containing credentials as
+    described in kdbus_creds: the uid, gid, pid, tid and starttime of the task.
+

As mentioned last time, please remove or justify starttime.

Quoted 4 lines

starttime allows detecting PID overflows. Exposing the process starttime is useful to detect when a PID is getting reused. Unfortunately, we don't have 64bit pids, so we need the pid+time combination to avoid ambiguity.

NAK, I think.

I agree that PID overflow is a real issue and should be addressed somehow. But please address it for real instead of adding Yet Another Hack (tm). In the mean time, leave that hack out, please.

I would *love* to see PIDs have extra high bits at the end, done in a way that supports CRIU and that guarantees no reuse unless something privileged intentionally mis-programs it. But starttime isn't that mechanism.

Quoted 13 lines

Quoted 12 lines

Documentation/kdbus.txt line 1549

Quoted 10 lines

Documentation/kdbus.txt new file +9 -0

+  KDBUS_ATTACH_AUXGROUPS
+    Attaches an item of type KDBUS_ITEM_AUXGROUPS, containing a dynamic
+    number of auxiliary groups the sending task was a member of.
+
+  KDBUS_ATTACH_NAMES
+    Attaches items of type KDBUS_ITEM_OWNED_NAME, one for each name the sending
+    connection currently owns. The name and flags are stored in kdbus_item.name
+    for each of them.
+

That's interesting. What's it for?

Quoted 5 lines

It a valuable piece of information for receivers to know which bus names a sender has claimed. For instance, we need this information for the D-Bus proxy service, because we have to apply D-Bus1 policy in that case, and we need to get a list of owned names in a race-free manner to check the policy against.

But if you change the rule to the sensible one where you need permission to TALK to the name that you're talking to, this goes away, right?

Quoted 23 lines

Quoted 22 lines

Quoted 7 lines

Documentation/kdbus.txt new file +6 -0

+  KDBUS_ATTACH_TID_COMM
+    Attaches an items of type KDBUS_ITEM_TID_COMM, transporting the sending
+    task's 'comm', for the tid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_PID_COMM
+    Attaches an items of type KDBUS_ITEM_PID_COMM, transporting the sending

Documentation/kdbus.txt line 1565

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+    task's 'comm', for the pid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_EXE
+    Attaches an item of type KDBUS_ITEM_EXE, containing the path to the
+    executable of the sending task, stored in kdbus_item.str.
+
+  KDBUS_ATTACH_CMDLINE
+    Attaches an item of type KDBUS_ITEM_CMDLINE, containing the command line
+    arguments of the sending task, as an array of strings, stored in
+    kdbus_item.str.

Please remove these four items. They are genuinely useless. Anything that uses them for anything is either buggy or should have asked the sender to put the value in the payload (and immediately wondered why it was doing that).

Quoted 5 lines

We use them for logging, debugging and monitoring. With our wireshark extension it's pretty useful to know the comm-name of a process when monitoring a bus. As we explained last time, this is not about security. We're aware that a process can modify them. We use them only as additional meta-data for logging and debugging.

Use the PID. Really. Your wireshark extention can look this crap up in /proc and, if it fails due to a race, big frickin' deal.

Quoted 9 lines

If we put those items into the payload, we have to transmit this data even if the destination process is not interested in this. Furthermore, each caller has to run multiple syscalls on each message to retrieve those values.

We use these items heavily for filtering and debugging, regardless of the payload protocol that is transmitted on the bus.

Quoted 7 lines

To give another specific use-case here: dbus supports bus activation, where a message sent to a non-running service causes it to be spawned implicitly without losing the message. Now, with such a scheme it is incredibly useful to be able to log which client caused a service to be triggered, hence we want to know the cmdline/exe/comm of the client. Not knowing this is a major pita when trying to trace the boot process and figuring out why a specific service got activated.

Again, use the PID for tracing, please.

At the very least, make it impossible to specify these fields in the "must be received" set and rename them to something like KDBUS_INSTALL_UNRELIABLE_CMDLINE, etc, because they're unreliable

Finally, this stuff should only be readable by privileged users. And using the PID accomplishes that.

Quoted 5 lines

Also note that since v2 of the patch there's actually a per-sender mask for meta-data like this, hence a peer which doesn't want to pass its exec/cmdline/comm along can do that. Of course, this will seriously hamper debuggability and transparency...

Transparency is a terrible thing here.

How many users put passwords into things on the command line? Yes, it's a bad idea (for reasons that are entirely stupid), but now those passwords get *logged*.

If this is in the kernel, and someone complains that sensitive data is showing up on ten different logs on their system, they'll *correctly* blame the kernel. If you at least use the PID and restrict it to the logging code, then at least the bug report will go to the logging daemon, which will be *correctly* accused of doing something daft, and it can be fixed.

Quoted 20 lines

Quoted 14 lines

Documentation/kdbus.txt line 1576

Quoted 12 lines

Documentation/kdbus.txt new file +11 -0

+
+  KDBUS_ATTACH_CGROUP
+    Attaches an item of type KDBUS_ITEM_CGROUP with the task's cgroup path.
+
+  KDBUS_ATTACH_CAPS
+    Attaches an item of type KDBUS_ITEM_CAPS, carrying sets of capabilities
+    that should be accessed via kdbus_item.caps.caps. Also, userspace should
+    be written in a way that it takes kdbus_item.caps.last_cap into account,
+    and derive the number of sets and rows from the item size and the reported
+    number of valid capability bits.
+

Please remove this, too, or justify its use.

cgroup information tells us which service is doing a bus request. This is useful for a variety of things. For example, the bus activation logging item above benefits from it. In general, if some message shall be logged about any client it is useful to know its service name.

Quoted 7 lines

Capabilities are useful to authenticate specific method calls. For example, when a client asks systemd to reboot, without this concept we can only check for UID==0 to decide whether to allow this. Breaking this down to capabilities in a race-free way has the benefit of allowing systemd to bind this to CAP_SYS_BOOT instead. There is no reason to deny a process with CAP_SYS_BOOT to reboot via bus-APIs, as they could just enforce it via syscalls, anyway.

With all due respect, BS.

I admit that there is probably no reason to deny systemd-based reboot to a CAP_SYS_BOOT-capable process, but there is absolutely no reason to give processes that are supposed to reboot using systemd the CAP_SYS_BOOT capability.

In any event, I suspect you'll have a hard time justifying this for anything other than CAP_SYS_BOOT. Just because CAP_SYS_ADMIN users can probably do whatever they want doesn't mean that systemd should make that a built-in policy.

Also, wtf is the bounding set and such for? At the very least this should only be the effective set.

Quoted 3 lines

We think it's a useful and reliable authentication method. Why should we remove it?

Because the implementation is buggy and therefore it's insecure? Remember that caps are namespaced in an interesting way.

Quoted 5 lines

Anyway, these items are just optional. The sender can refuse the reveal them, and the item is only transmitted if the receiver opted in for it, too. So there's no need to drop any item type from the protocol.

No.

Because if receivers opt in to most of these, *they're doing it wrong*, and the kernel shouldn't be in the business of helping them.

Hi

Quoted 23 lines · Andy Lutomirski

Quoted 15 lines · David Herrmann

[snip]

Quoted 5 lines

Quoted 5 lines

+6.5 Getting information about a connection's bus creator
+--------------------------------------------------------

Documentation/kdbus.txt new file +3 -0

+
+The KDBUS_CMD_BUS_CREATOR_INFO ioctl takes the same struct as
+KDBUS_CMD_CONN_INFO but is used to retrieve information about the creator of

Quoted 8 lines

Documentation/kdbus.txt line 563

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+the bus the connection is attached to. The metadata returned by this call is
+collected during the creation of the bus and is never altered afterwards, so
+it provides pristine information on the task that created the bus, at the
+moment when it did so.

What's this for? I understand the need for the creator of busses to be authenticated, but doing it like this mean that anyone who will *fail* authentication can DoS the authentic creator.

Quoted 4 lines

This returns information on a bus owner, to determine whether a connection is connected to a system, user or session bus. Note that the bus-creator itself is not a valid peer on the bus, so you cannot send messages to them. Which kind of DoS do you have in mind?

I assume that the logic is something like:

Quoted 7 lines

connect to bus
request bus metadata
if (bus metadata matches expectations) {
great, trust the bus!
} else {
oh crap!
}

Uh, no, this is really not the logic that should be assumed. It's more for code where you want to simply pass a bus fd, and the code knows nothing about it. Now, the code can derive some information from the bus fd, like for example who owns it. Then, depending on some of the creds returned it can determine whether to read configuration file set A or B and so on. This is particularly useful for all kinds of unprivileged bus services that end up running on any kind of bus and need to be able to figure out what they are actually operating on.

Quoted 17 lines

Quoted 16 lines

Quoted 10 lines

Documentation/kdbus.txt line 886

Quoted 6 lines

Documentation/kdbus.txt new file +5 -0

+
+Also, if the connection allowed for file descriptor to be passed
+(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
+installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
+returns. The receiving task is obliged to close all of them appropriately.

This makes it sound like fds are installed at receive time. What prevents resource exhaustion due to having excessive numbers of fds in transit (that are presumably not accounted to anyone)?

We have a per-user message accounting for undelivered messages, as well as a maximum number of pending messages per connection on the receiving end. These limits are accounted on a "user<->user" basis, so the limit of a user A will not affect two other users (B and C) talking.

Quoted 4 lines

But you can shove tons of fds in a message, and you can have lots of messages, and some of the fds can be fds of unix sockets that have fds queued up in them, and one of those fds could be the fd to the kdbus connection that sent the fd...

You cannot send kdbus-fds or unix-fds over kdbus, right now. We have people working on the AF_UNIX gc to make it more generic and include external types. Until then, we simply prevent recursive fd passing.

Quoted 31 lines

This is not advice as to what to do about it, but I think that it will be a problem at some point.

Quoted 10 lines

Quoted 9 lines

Documentation/kdbus.txt line 1315

Quoted 6 lines

+11. Policy
+===============================================================================

Documentation/kdbus.txt new file +4 -0

+
+A policy databases restrict the possibilities of connections to own, see and
+talk to well-known names. It can be associated with a bus (through a policy
+holder connection) or a custom endpoint.

ISTM metadata items on bus names should be replaced with policy that applies to the domain as a whole and governs bus creation.

Quoted 6 lines

No, well-known names are bound to buses, so a bus is really the right place to hold policy about which process is allowed to claim them. Every user is allowed to create a bus of its own, there's no policy for that, and there shouldn't be.

It has nothing to do with metadata items.

But it does -- the creator of the bus binds metadata to that bus at creation time.

I think that a better solution would be to have a global policy that says, for example, "to create the bus called 'system', the creator must have selinux label xyz" or "to create a user bus called uid-1000-privileged-ui-bus the creator must have some cgroup" or whatever.

Quoted 4 lines

Although maybe a better solution would leave this in the kernel but allow any cgroup to create a bus with a same that indicates the creating cgroup. Then I could have my desktop shell create a "/cgroup/path/to/desktop" for per-user privileged things.

We enforce the UID as first entity of the bus name. Again, this is our default policy because we rely on user-based access control. If we want more fine-grained access-control, we can introduce other policies at any time. For instance, we could enforce "cg-<cgroup>-<busname>" later on, where the kernel requires the caller to prefix the bus with "cg-<cgroup>-", where <cgroup> is the cgroup-path encoded in some way.

We provide one policy as default, and we have a use-case for it. Further policies are always welcome as extensions later on. I don't see why we should provide all those right from the beginning without any users right now.

Quoted 38 lines

Quoted 38 lines

Quoted 37 lines

Quoted 24 lines

Documentation/kdbus.txt new file +22 -0

+A set of policy rules is described by a name and multiple access rules, defined
+by the following struct.
+
+struct kdbus_policy_access {
+  __u64 type;  /* USER, GROUP, WORLD */
+    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.
+
+  __u64 access;        /* OWN, TALK, SEE */
+    The access to grant.
+
+    KDBUS_POLICY_SEE
+      Allow the name to be seen.
+

Documentation/kdbus.txt line 1358

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+    KDBUS_POLICY_TALK
+      Allow the name to be talked to.
+
+    KDBUS_POLICY_OWN
+      Allow the name to be owned.
+
+  __u64 id;
+    For KDBUS_POLICY_ACCESS_USER, stores the uid.
+    For KDBUS_POLICY_ACCESS_GROUP, stores the gid.
+};

What happens if there are multiple matches?

Quoted 5 lines

Quoted 3 lines

We only have _granting_ policy entries. We search through the policy-db until we find an entry that grants access. We do _not_ stop on the first item that matches.

Yay! Can you document that more clearly?

Sure!

Quoted 31 lines

Quoted 23 lines

Quoted 17 lines

Quoted 4 lines

Documentation/kdbus.txt new file +2 -0

+
+11.4 TALK access and multiple well-known names per connection

Documentation/kdbus.txt line 1425

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+-------------------------------------------------------------
+
+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 name 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.

This does seem illogical. Does the recipient at least know which well-known name was addressed?

If the sender addressed it to a well-known name, yes. If the sender addressed the message to a unique-ID, there will be no such name, of course. Still, the policy applies to such transactions either way (standard D-Bus behavior).

Quoted 7 lines

Note however that dbus1 will not pass along the destination well-known name, hence most userspace libraries will ignore this information too, even if they run on kdbus which might pass this information around. The right way for services that carry multiple service names to discern which actual service is being talked to is having separate object paths for the different functionality to hide between the services.

Quoted 4 lines

It seems unfortunate to keep around this really weird behavior for the benefit of legacy applications. Could there perhaps be a flag that a connection can set to indicate that it understands per-destination access control and therefore wants stricter policy enforcement?

We actually think that it's a good idea not to use the destination name for doing different things, to make things more transparent. For example, we have tools that can explore the bus, introspect things (like d-bus), and they should show the same objects regardless by which name you access a service. It's more transparent then, and really just reduces names to some labels that make addressing things easier, but that are actually completely unnecessary for actual method invocations.

This behaviour is also relied on by a number of current bindings. For example GLib's implementation usually caches the unique name of a peer, and uses that for talking to remote objects (rather than always using the well-known name), in order to get an error back when a name becomes unavailable (maybe because a service died) or is moved to a different peer. If daemons would always take the destination name into account this kind of logic could never work.

It does take some time to get used to the fact that names are exclusively used for message routing and policies, not as target-entity of actual method calls. But the current dbus1 behaviour makes a ton of sense, and is really something we want to keep. It improves how clients can do life-cycle tracking of remote objects.

Note that D-Bus modeled unique-names and well-known-names after IP addresses and DNS names. It's a very similar model, and, like DNS names, well-known names have no effect on the routing of messages.

Quoted 22 lines

Quoted 22 lines

Quoted 10 lines

Documentation/kdbus.txt line 1443

Quoted 8 lines

+11.5 Implicit policies
+----------------------

Documentation/kdbus.txt new file +4 -0

+
+Depending on the type of the endpoint, a set of implicit rules might be
+enforced. On default endpoints, the following set is enforced:
+

How do these rules interact with installed policy?

As said before, all policy entries _grant_ access. We look through all entries until we find one that grants access.

Quoted 7 lines

Documentation/kdbus.txt line 1448

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+  * 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.

Why?

Quoted 7 lines

Quoted 2 lines

All limits on buses are enforced on a user<->user basis. We don't want to provide policies that are more fine-grained than our accounting.

This seems completely at odds with all the fine-grained metadata stuff. Also, anything that relies on this may get very confused when the LSM hooks go in, because I'm reasonably sure that the intent is for them to *not* follow this principle.

User-based accounting has always been the default, right? We are open to extend the API to support any other accounting scheme (LSM, cgroup-based, ...). But like bus-name-policies, I think it's fine to keep this as future extension. If you think the current design precludes LSM-based accounting, lemme know and we can fix it. But we have talked to LSM people before (and there have been patches on LKML), and they seemed fine with it.

Quoted 43 lines

Quoted 15 lines

Quoted 5 lines

If anyone ever strengthens the concept of identity to include things other than users (hmm -- there are already groups), this could be very limiting.

If user-based accounting is not suitable, you can create custom endpoints. Future extensions to that are always welcome. So far, the default user-based accounting was enough. And I think it's suitable as default.

Quoted 4 lines

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+  * Connections that own names might send broadcast messages to other
+    connections that belong to a different user, but only if that
+    destination connection does not own any name.
+

(Also, what does "might" mean here?)

Quoted 4 lines

Quoted 3 lines

This is weird. It is also differently illogical than the "illogical" thing above.

Quoted 8 lines

Actually it follows the same model described above. If two connections are running under the same user then broadcasts are allowed, but if they are running under different users *and* if the destination owns a well-known name, then broadcasts are subject to TALK policy checks since that destination may own a restricted well-known name that is not interested in broadcasts. So this implicit policy is just fast-path for the common case where the target is subscribed to a broadcast and does not own any name.

Huh?

Say I have two users, "Sender" and "Receiver", each with a single connection. If Receiver owns no well-known names, then Sender can send to it. If Receiver owns one well-known name, then Sender needs to pass a TALK check on that name. If Reciever owns two well-known names, then Sender only needs to pass a TALK check on one of them.

Am I understanding this right? If I am, then I think this is in the category of baroque and inconsistent security rules which everyone will screw up and therefore introduce security vulnerabilities.

Quoted 4 lines

Can you really not enforce the much simpler rule that, to send to a name, you must have permission to send to *that* name? If legacy dbus1 receivers register two names and don't validate everything correctly, then only the legacy receivers have problems.

Sorry, I got confused here. That implicit policy is now dropped.

Quoted 29 lines

Quoted 22 lines

Quoted 4 lines

Quoted 4 lines

+
+13. Metadata
+===============================================================================

[snip]

Quoted 8 lines

Quoted 8 lines

+13.1 Known item types
+---------------------

Documentation/kdbus.txt new file +6 -0

+
+The following attach flags are currently supported.
+
+  KDBUS_ATTACH_TIMESTAMP
+    Attaches an item of type KDBUS_ITEM_TIMESTAMP which contains both the
+    monotonic and the realtime timestamp, taken when the message was

Quoted 8 lines

Documentation/kdbus.txt line 1540

Quoted 6 lines

Documentation/kdbus.txt new file +6 -0

+    processed on the kernel side.
+
+  KDBUS_ATTACH_CREDS
+    Attaches an item of type KDBUS_ITEM_CREDS, containing credentials as
+    described in kdbus_creds: the uid, gid, pid, tid and starttime of the task.
+

As mentioned last time, please remove or justify starttime.

Quoted 4 lines

starttime allows detecting PID overflows. Exposing the process starttime is useful to detect when a PID is getting reused. Unfortunately, we don't have 64bit pids, so we need the pid+time combination to avoid ambiguity.

NAK, I think.

Quoted 8 lines

I agree that PID overflow is a real issue and should be addressed somehow. But please address it for real instead of adding Yet Another Hack (tm). In the mean time, leave that hack out, please.

I would *love* to see PIDs have extra high bits at the end, done in a way that supports CRIU and that guarantees no reuse unless something privileged intentionally mis-programs it. But starttime isn't that mechanism.

The starttime logic sufficiently fixes the issue. If one great day in the future somebody invents some completely new concept for making this problem go away, we can look into that, but even then the field is still valuable for informational purposes. I mean, the kernel tracks this and exposes this in /proc for a reason...

In the meantime, we don't have any other way of solving this problem, so we'll leave this in.

Quoted 19 lines

Quoted 18 lines

Quoted 12 lines

Documentation/kdbus.txt line 1549

Quoted 10 lines

Documentation/kdbus.txt new file +9 -0

+  KDBUS_ATTACH_AUXGROUPS
+    Attaches an item of type KDBUS_ITEM_AUXGROUPS, containing a dynamic
+    number of auxiliary groups the sending task was a member of.
+
+  KDBUS_ATTACH_NAMES
+    Attaches items of type KDBUS_ITEM_OWNED_NAME, one for each name the sending
+    connection currently owns. The name and flags are stored in kdbus_item.name
+    for each of them.
+

That's interesting. What's it for?

It a valuable piece of information for receivers to know which bus names a sender has claimed. For instance, we need this information for the D-Bus proxy service, because we have to apply D-Bus1 policy in that case, and we need to get a list of owned names in a race-free manner to check the policy against.

Quoted 3 lines

But if you change the rule to the sensible one where you need permission to TALK to the name that you're talking to, this goes away, right?

This does not work if a message is directed at a unique-name, as explained above (or, think broadcasts).

Quoted 24 lines

Quoted 24 lines

Quoted 23 lines

Quoted 8 lines

Documentation/kdbus.txt new file +6 -0

+  KDBUS_ATTACH_TID_COMM
+    Attaches an items of type KDBUS_ITEM_TID_COMM, transporting the sending
+    task's 'comm', for the tid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_PID_COMM
+    Attaches an items of type KDBUS_ITEM_PID_COMM, transporting the sending

Documentation/kdbus.txt line 1565

Quoted 10 lines

Documentation/kdbus.txt new file +10 -0

+    task's 'comm', for the pid.  The string is stored in kdbus_item.str.
+
+  KDBUS_ATTACH_EXE
+    Attaches an item of type KDBUS_ITEM_EXE, containing the path to the
+    executable of the sending task, stored in kdbus_item.str.
+
+  KDBUS_ATTACH_CMDLINE
+    Attaches an item of type KDBUS_ITEM_CMDLINE, containing the command line
+    arguments of the sending task, as an array of strings, stored in
+    kdbus_item.str.

Please remove these four items. They are genuinely useless. Anything that uses them for anything is either buggy or should have asked the sender to put the value in the payload (and immediately wondered why it was doing that).

Quoted 8 lines

Quoted 5 lines

We use them for logging, debugging and monitoring. With our wireshark extension it's pretty useful to know the comm-name of a process when monitoring a bus. As we explained last time, this is not about security. We're aware that a process can modify them. We use them only as additional meta-data for logging and debugging.

Use the PID. Really. Your wireshark extention can look this crap up in /proc and, if it fails due to a race, big frickin' deal.

I see no reason for leaving it up to the client to do this extra work if it can as well be attached by the kernel, really.

We use the PID on dbus1 systems for cases like this. But it's actually too racy to be useful. For example, in systemd we ship a tiny binary that is used as cgroup agent, which just pushes a message about the fact it just got called for a cgroup onto the bus and then exits. Since it only runs for a very very short time, any peer which then tries to read the metadata off it is pretty likely to fail. And there are quite a number of processes like that, that just do one thing and die, especially in the early boot process. For none of them we currently can generate useful log metadata, because all we have is a PID that we have barely any useful information about.
This is a real race we get lots of bug-reports for. With kdbus we want to fix this, by optionally attaching this useful data to the message, so that the receiver can get the information when it wants to.

Quoted 6 lines

Transparency is a terrible thing here.

How many users put passwords into things on the command line? Yes, it's a bad idea (for reasons that are entirely stupid), but now those passwords get *logged*.

Quoted 6 lines

If this is in the kernel, and someone complains that sensitive data is showing up on ten different logs on their system, they'll *correctly* blame the kernel. If you at least use the PID and restrict it to the logging code, then at least the bug report will go to the logging daemon, which will be *correctly* accused of doing something daft, and it can be fixed.

Hmm? Not following here. This information is visible via /proc too. If you hide it from /proc via the hide_pid logic, then it is also gone from the kdbus meta-data. Also, note again that clients that don't want this information to be passed to services can declare that now with their sender creds mask, introduced with v2.

Quoted 28 lines

Quoted 20 lines

Quoted 14 lines

Documentation/kdbus.txt line 1576

Quoted 12 lines

Documentation/kdbus.txt new file +11 -0

+
+  KDBUS_ATTACH_CGROUP
+    Attaches an item of type KDBUS_ITEM_CGROUP with the task's cgroup path.
+
+  KDBUS_ATTACH_CAPS
+    Attaches an item of type KDBUS_ITEM_CAPS, carrying sets of capabilities
+    that should be accessed via kdbus_item.caps.caps. Also, userspace should
+    be written in a way that it takes kdbus_item.caps.last_cap into account,
+    and derive the number of sets and rows from the item size and the reported
+    number of valid capability bits.
+

Please remove this, too, or justify its use.

cgroup information tells us which service is doing a bus request. This is useful for a variety of things. For example, the bus activation logging item above benefits from it. In general, if some message shall be logged about any client it is useful to know its service name.

Quoted 7 lines

Capabilities are useful to authenticate specific method calls. For example, when a client asks systemd to reboot, without this concept we can only check for UID==0 to decide whether to allow this. Breaking this down to capabilities in a race-free way has the benefit of allowing systemd to bind this to CAP_SYS_BOOT instead. There is no reason to deny a process with CAP_SYS_BOOT to reboot via bus-APIs, as they could just enforce it via syscalls, anyway.

Quoted 6 lines

With all due respect, BS.

I admit that there is probably no reason to deny systemd-based reboot to a CAP_SYS_BOOT-capable process, but there is absolutely no reason to give processes that are supposed to reboot using systemd the CAP_SYS_BOOT capability.

No, and this is not how this works. Note that for unpriviliged clients systemd checks PolicyKit in order to identify whether to allow certain priviliged operations. However, PolicyKit requires bus chatte, is slow and quite complex, hence the code shortcuts things if it knows that the client is priviliged anyway, and doesn't even bother with PolicyKit at all. This is where the caps come into play, since this shortcutting really should *NOT* be done for every single client, but only for those with the rights to do the operation anyway.

Hence, this is really not about overloading capabilities with new meanings. Instead it is about shortcutting policykit for priviliged clients. And this shortcutting should be as restricted as possible.

Quoted 5 lines

In any event, I suspect you'll have a hard time justifying this for anything other than CAP_SYS_BOOT. Just because CAP_SYS_ADMIN users can probably do whatever they want doesn't mean that systemd should make that a built-in policy.

Well, the other option for these APIs is to use the euid, which is hardly any better.

systemd-timedated shortcuts policykit if the client has CAP_SYS_TIME and tries to change the system clock. Similar, if a process asks logind to kill a session, we bypass pk if the client has CAP_KILL.

Quoted 2 lines

Also, wtf is the bounding set and such for? At the very least this should only be the effective set.

Yes, the code that makes use of this for shortcutting pk uses the effective set only. The other ones we allow sending across for enhancing logging of security operations.

In general: all creds we collect at the very least are incredibly useful for generating log records in a race-free fashion. As pointed out above the "race-free" bit alone solves real-world issues that are highly annoying if we don't have it.

Quoted 7 lines

Quoted 4 lines

We think it's a useful and reliable authentication method. Why should we remove it?

Because the implementation is buggy and therefore it's insecure? Remember that caps are namespaced in an interesting way.

Yes, we are well aware of the fact that we currently have no good way to translate a full set of capabilities from one user-ns to another. Hence, the only sane thing to do in such situations is to drop the entire item, which is what we do. Once we have a reliable way of translating things, we can add that to our code. Note that a set capability flag will only gain you more access level, so if caps are missing from a message, a user might only have *less* privileges, not more.

Quoted 9 lines

Quoted 6 lines

Anyway, these items are just optional. The sender can refuse the reveal them, and the item is only transmitted if the receiver opted in for it, too. So there's no need to drop any item type from the protocol.

No.

Quoted 2 lines

Because if receivers opt in to most of these, *they're doing it wrong*, and the kernel shouldn't be in the business of helping them.

No, they are not doing it "wrong". The services would do things wrong if they'd make security decisions on bits that cannot be acquired in a race-free way. And services do things in a dirty way if they'd generated logging data in a race-ful way (like you suggest), by reading things from /proc.

Then find a clean way that's gated on having the right /proc access, which is not guaranteed to exist on all of your eventual users' systems, and, if that access doesn't exist because the admin or sandbox designer has sensibly revoked it, then kdbus shouldn't override them.

--Andy

At the risk of opening a can of worms, wouldn't this be much more useful if you could share a pool between multiple connections?

* Andy Lutomirski:

Quoted 2 lines

At the risk of opening a can of worms, wouldn't this be much more useful if you could share a pool between multiple connections?

They would also be useful to reduce context switches when receiving data from all kinds of descriptors. At present, when polling, you receive notification, and then you have to call into the kernel, again, to actually fetch the data and associated information.

kernel could also queue the data for one specific recipient, addressing the same issue that SO_REUSEPORT tries to solve (on poll notification, the kernel does not know which recipient will eventually retrieve the data, so it has to notify and wake up all of them).

poll(2) and friends cannot return data for changed descriptors. I think a single trap for each KDBUS_CMD_MSG_RECV is acceptable. If this turns out to be a bottleneck, we can provide bulk-operations in the future. Anyway, I don't see how a _shared_ pool would change any of this?

Quoted 4 lines

kernel could also queue the data for one specific recipient, addressing the same issue that SO_REUSEPORT tries to solve (on poll notification, the kernel does not know which recipient will eventually retrieve the data, so it has to notify and wake up all of them).

We already queue data only for the addressed recipients. We *do* know all recipients of a message at poll-notification time. We only wake up recipients that actually got a message queued.

Not sure how this is related to SO_REUSEPORT. Can you elaborate on your optimizations?

* Greg Kroah-Hartman:

Documentation/kdbus.txt line 7

Quoted 5 lines

Documentation/kdbus.txt new file +5 -0

+The focus of this document is an overview of the low-level, native kernel D-Bus
+transport called kdbus. Kdbus exposes its functionality via files in a
+filesystem called 'kdbusfs'. All communication between processes takes place
+via ioctls on files exposed through the mount point of a kdbusfs. The default
+mount point of kdbusfs is /sys/fs/kdbus.

Does this mean the bus does not enforce the correctness of the D-Bus introspection metadata? That's really unfortunate. Classic D-Bus does not do this, either, and combined with the variety of approaches used to implement D-Bus endpoints, it makes it really difficult to figure out what D-Bus services, exactly, a process provides.

* Greg Kroah-Hartman:

Quoted 1 line

+7.4 Receiving messages

Documentation/kdbus.txt line 886

Quoted 4 lines

Documentation/kdbus.txt new file +4 -0

+Also, if the connection allowed for file descriptor to be passed
+(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
+installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
+returns. The receiving task is obliged to close all of them appropriately.

What happens if this is not possible because the file descriptor limit of the processes would be exceeded? EMFILE, and the message will not be received?

Quoted 7 lines

* Greg Kroah-Hartman:

Quoted 1 line

+7.4 Receiving messages

What happens if this is not possible because the file descriptor limit of the processes would be exceeded? EMFILE, and the message will not be received?

The message is returned without installing the FDs. This is signaled by EMFILE, but a valid pool offset.

* David Herrmann:

Quoted 9 lines · Florian Weimer

Quoted 7 lines

* Greg Kroah-Hartman:

Quoted 1 line

+7.4 Receiving messages

What happens if this is not possible because the file descriptor limit of the processes would be exceeded? EMFILE, and the message will not be received?

Quoted 2 lines

The message is returned without installing the FDs. This is signaled by EMFILE, but a valid pool offset.

Oh. This is really surprising, so it needs documentation. But it's probably better than the alternative (return EMFILE and leave the message stuck, so that you receive it immediately again—this behavior makes non-blocking accept rather difficult to use correctly).

Quoted 14 lines · Florian Weimer

* David Herrmann:

Quoted 11 lines · Florian Weimer

Quoted 7 lines

* Greg Kroah-Hartman:

Quoted 1 line

+7.4 Receiving messages

What happens if this is not possible because the file descriptor limit of the processes would be exceeded? EMFILE, and the message will not be received?

The message is returned without installing the FDs. This is signaled by EMFILE, but a valid pool offset.

Quoted 4 lines

Oh. This is really surprising, so it needs documentation. But it's probably better than the alternative (return EMFILE and leave the message stuck, so that you receive it immediately again—this behavior makes non-blocking accept rather difficult to use correctly).

So, was this point in the end explicitly documented? I not obvious that it is documented in the revised kdbus.txt that Greg K-H sent out 4 days ago.

Hi Michael,

Quoted 15 lines · Michael Kerrisk (man-pages)

Quoted 14 lines · Florian Weimer

* David Herrmann:

Quoted 11 lines · Florian Weimer

Quoted 7 lines

* Greg Kroah-Hartman:

Quoted 1 line

+7.4 Receiving messages

What happens if this is not possible because the file descriptor limit of the processes would be exceeded? EMFILE, and the message will not be received?

The message is returned without installing the FDs. This is signaled by EMFILE, but a valid pool offset.

Quoted 8 lines

Quoted 4 lines

Oh. This is really surprising, so it needs documentation. But it's probably better than the alternative (return EMFILE and leave the message stuck, so that you receive it immediately again—this behavior makes non-blocking accept rather difficult to use correctly).

So, was this point in the end explicitly documented? I not obvious that it is documented in the revised kdbus.txt that Greg K-H sent out 4 days ago.

No, we've revisited this point and changed the kernel behavior again in v3. We're no longer returning -EMFILE in this case, but rather set KDBUS_RECV_RETURN_INCOMPLETE_FDS in a new field in the receive ioctl struct called 'return_flags'. We believe that's a nicer way of signaling specific errors. The message will carry -1 for all FDs that failed to get installed, so the user can actually see which one is missing.

That's also documented in kdbus.txt, but we missed putting it into the Changelog - sorry for that.

From: Daniel Mack <[email protected]>
…

include/uapi/linux/kdbus.h new file +1 -0

+

+/**
+ * Ioctl API
+ * KDBUS_CMD_BUS_MAKE: After opening the "control" device node, this
+ * command creates a new bus with the specified
+ * name. The bus is immediately shut down and
+ * cleaned up when the opened "control" device node
+ * is closed.

+ * KDBUS_CMD_ENDPOINT_MAKE: Creates a new named special endpoint to talk to
+ * the bus. Such endpoints usually carry a more
+ * restrictive policy and grant restricted access
+ * to specific applications.
+ * KDBUS_CMD_HELLO: By opening the bus device node a connection is
+ * created. After a HELLO the opened connection
+ * becomes an active peer on the bus.

Quoted 2 lines · Greg Kroah-Hartman

From: Daniel Mack <[email protected]>
…

include/uapi/linux/kdbus.h line 636

Quoted 11 lines

include/uapi/linux/kdbus.h new file +11 -0

+
+/**
+ * enum kdbus_make_flags - Flags for KDBUS_CMD_{BUS,EP,NS}_MAKE
+ * @KDBUS_MAKE_ACCESS_GROUP:	Make the device node group-accessible
+ * @KDBUS_MAKE_ACCESS_WORLD:	Make the device node world-accessible
+ */
+enum kdbus_make_flags {
+	KDBUS_MAKE_ACCESS_GROUP		= 1ULL <<  0,
+	KDBUS_MAKE_ACCESS_WORLD		= 1ULL <<  1,
+};
+

"device node"