2.14 The Identity Channel
2.14.1 Socket #
An authority MUST listen on a SOCK_STREAM Unix domain socket at:
/run/ident.sock
The path is normative, for the same reason /run/logon.sock is: a name
resolver linked into every process on the system cannot be asked to find
it by configuration.
An authority MUST listen on both sockets. Offering one without the other is not conformance — a system whose principals cannot be named is as broken as one whose principals cannot sign in.
2.14.2 Access control #
The socket MUST carry a security descriptor granting connect access to every principal that runs ordinary programs.
This is the opposite posture to /run/logon.sock, and deliberately so.
A descriptor that withheld connect access would not protect anything: it
would make ls -l print numbers for the principals it excluded, while a
principal who can connect learns the same names either way.
Restriction, where an authority wants it, belongs on individual fields
(§2.16) — not on reaching the socket at all.
2.14.3 Framing #
Messages use the header, magic, version, size limit and body extensibility rules of §2.6 without modification. The message types served here are disjoint from those of the logon socket (§2.A).
A message of one socket's range arriving on the other MUST be refused.
An authority MUST NOT serve a Lookup received on /run/logon.sock,
and MUST NOT serve a LogonStart received on /run/ident.sock.
2.14.4 Multiplexing #
A connection carries any number of requests. A client MAY have more than one outstanding at a time, and an authority MAY answer them in any order.
Every request carries a tag, a u32 chosen by the client, and its
reply carries the same value. The tag is in the message body, not
the header, so that the header of §2.6 is unchanged.
A client MUST NOT reuse a tag while a request bearing it is outstanding. An authority MUST echo the tag it received and MUST NOT interpret it otherwise.
A client MUST NOT assume replies arrive in request order. An authority that answers strictly in order is conformant; a client that depends on it is not.
2.14.5 Concurrency and bounds #
An authority MUST serve connections concurrently, and MUST NOT let a slow answer on one connection delay answers on another.
An authority MUST bound the number of connections it will accept and the number of requests it will hold outstanding per connection, and SHOULD refuse further requests on a connection that exceeds the second rather than closing it.
An authority MUST NOT wait indefinitely for a source. A request that
cannot be answered within the authority's own bound MUST be answered
Unavailable (§2.18). The bound is on the request, not on each source
consulted: an authority that walks several sources in turn MUST NOT let
the total exceed what it would have allowed one.
2.14.6 No descriptor passing #
Nothing is transferred over this channel by descriptor. An authority MUST ignore ancillary data received here.
2.14.7 Peer identity #
An authority that restricts any field (§2.16) MUST establish peer identity from the connected socket's peer token, as §2.4 requires, and MUST NOT take it from a message body.
An authority that restricts no field MAY skip establishing peer identity, since it would make no decision with it.