Serial number details in specification

[Simon McVittie]

On Fri, 10 May 2019 at 13:28:01 +0200, David Rheinsberg wrote:
> [The] bus-policy allows matching on "expected
> replies". This means, depending on whether a reply is to a pending
> method call, or stray, you can match on it and apply a different
> policy.
> In practice, this technique is used to reject any stray replies.

Or, to put it another way, since the system bus has a default-deny policy:
it's used to accept exactly one legitimate reply to each method call that
does not have the NO_REPLY_EXPECTED flag, leaving unsolicited replies
(either replying more than once, "replying" to a message that was never
sent, replying to a NO_REPLY_EXPECTED method call, or replying to a
non-method-call message like a signal, successful reply or error) to be
rejected by the default-deny policy.

This is necessary because method replies (both successful and error)
do not carry information about the method call to which they are the
reply, except for the serial number of the method call. This means
there is not enough information for the message bus to make meaningful
authorization decisions, except by remembering that it allowed a method
call from A to B with serial number N, and therefore it should also allow
one reply from B to A with REPLY_SERIAL N.

Like all of the message bus policy stuff, this is theoretically
configurable by OS integrators and sysadmins, but in practice there are
only really two useful policies for what to do with replies: either allow
everything (like the standard session bus policy), or allow one reply for
each method call that expects one (like the standard system bus policy).

    smcv