The modes are:
- crc: crc32c checksums to protect against bit errors. No secrecy or
authenticity guarantees, so a MITM could alter traffic in flight.
- secure: cryptographic secrecy and authenticity proection (i.e, encrypted
and signed).
We do not include a 'signed' mode that provides authenticity without
secrecy because the cryptographic protocols appear to be faster than
SHA-2.
New settings:
- ms_cluster_mode : mode(s list) for intra-cluster connections
- ms_service_mode : mode(s list) for daemons to allow
- ms_client_mode : mode(s list) for clients to allow
Also,
- ms_mon_cluster_mode : mon <-> mon connections
- ms_mon_service_mode : mon <-> daemon or client connections
The msgr2 protocol is expanded slightly to negotiate a mode. Client
shares it's allowed/preferred modes, and server picks one as auth finishes.
Negotiation is independent of the authentication, except that the
authentiction mode may precluse certain choices. Specifically, AUTH_NONE
does not support 'secure', only 'crc'.
Signed-off-by: Sage Weil <sage@redhat.com>
- MonClient implements AuthClient to authenticate as a client
- MonClient implements AuthServer to allow daemons to verify authorizers
- Monitor implements AuthServer to allow clients to authenticate with
an exchange of msgr2 frames
- Monitor implements AuthClient to authenticate with other monitors
After this change ProtocolV1 and SimpleMessenger still use all of the
old Dispatcher-based callbacks, but ProtocolV2 doesn't need them at
all (except for ms_handle_authentication when we finish).
Signed-off-by: Sage Weil <sage@redhat.com>
With msgr2 the initial kickoff of an authentication handshake is client ->
server, while with msgr1 it was server -> client. So existing
implementations have an empty initial message (outside of the messenger's
envelope). Future auth implementations that are msgr2 only (e.g., krb)
may want to make use of this initial payload.
Signed-off-by: Sage Weil <sage@redhat.com>
These will be the primary interfaces consumed by the messenger and
implemented by either MonClient (regular client, or service daemon) or
Monitor for doing authentication.
Signed-off-by: Sage Weil <sage@redhat.com>
The AuthAuthorizer encoding always begins with byte 0x01. Codify that
as AUTH_MODE_AUTHORIZER so that we can distinguish an authorizer from
something else (e.g., an attempt to authenticate and get an initial auth
ticket with the mon).
Signed-off-by: Sage Weil <sage@redhat.com>
Previously, we would give the client the auth ticket, like a rbd TGT
(ticket granting ticket), and the client would then ask for all of the
other tickets it wants in a separate message.
Instead, have the client specify which tickets it wants up front and pass
them all at the same time.
Also, generate and share the connection_secret, which will be used for
encryption.
Signed-off-by: Sage Weil <sage@redhat.com>
This will hold all of the authentication-related state in an easy-to-find
section that can be accessed via a Connection* or by the protocol stack
(as needed).
Signed-off-by: Sage Weil <sage@redhat.com>
We were passing CephXServiceTicketInfo in, but the only part of it we
needed was the embedded AuthTicket. Pass that instead.
No functional change.
Signed-off-by: Sage Weil <sage@redhat.com>
- We can now construct a session before we know who it is
- We can later call _ident to identify it
- and also later register it in the session map
Signed-off-by: Sage Weil <sage@redhat.com>
Previously we would call ms_handle_authentication() possibly multiple
times, and without knowning whether it might succeed. Instead, only call
it when start_session() or handle_request() returns >0 to indicate that
we should.
Signed-off-by: Sage Weil <sage@redhat.com>
- return error code, not type (which never changes)
- take const ref for input args
- pointers for output args
Signed-off-by: Sage Weil <sage@redhat.com>
The client's myaddr will be an ANY address, but the internel connection table
will use a v1: or v2: address. Use the get_peer_addrs() to figure out how to
connect instead.
Signed-off-by: Sage Weil <sage@redhat.com>
Only set type ANY if we are a pure client; otherwise, preserve the
type. Also, only populate the addr if we have a blank ip (sometimes
we already know it from learn_addr_unknowns).
Signed-off-by: Sage Weil <sage@redhat.com>
Since we register client connections as any:, we may have either a ProtocolV1 or V2
connection. This happens when clients have an imprecise mon search list and connect
to the same mon via both v1 and v2, for example when you do something like
ceph -m 'v2:127.0.0.1:40648/0,v1:127.0.0.1:40649/0' -s
If we do encounter the other protocol type than what we expect, just mark it down and
proceed. This is only a temporarily case that happens during mon discovery, the client
is always prepared to retry, and it doesn't actually matter which one succeeds since
it will return a monmap and the client will adapt accordingly.
Signed-off-by: Sage Weil <sage@redhat.com>
Return either the actual legacy addr, or an any addr as a legacy addr. If
neither is available, lie and return a v2 (or other) addr as a legacy adr.
Signed-off-by: Sage Weil <sage@redhat.com>
This returns a legacy v1 address out of a v1 or any address. It's
intended to be used in contexts where we *always* want a v1 address,
like SimpleMessenger.
Signed-off-by: Sage Weil <sage@redhat.com>
The client can speak v1 or v2, so it is misleading to identify it with a v1 or v2
address (it is either). This avoid some kludgey workarounds.
We also are a bit more precise about what target_addr means. It is only used by
the client to indicate which of the peer_addrs we are connecting to, or by a
peer to identify which the peer_addrs we *would* reconnect to.
Signed-off-by: Sage Weil <sage@redhat.com>
