This is what the old code does so I kept it but I don't think it makes any sense.
Same with the defaults; let's just set the config option to something valid.
Sage Weil [Sun, 3 Feb 2019 13:41:26 +0000 (07:41 -0600)]
qa/suites/rados/workloads/rados_api_tests.yaml: debug mgrc = 20 on mon
Seeing some hangs when the mon is forwarding mgr commands (pg deep-scrub)
to the mgr. This is a buggy test (it should send it to the mgr directly)
but it is helpful to verify the mon forwarding behavior works.
Sage Weil [Fri, 1 Feb 2019 17:09:42 +0000 (11:09 -0600)]
mon/MonClient: request monmap on open instead of ping
The ping is useless. The MMonGetMap ensures we get a monmap (and finish
authenticate()) before we get any other maps/messages, like mgr_map.
Getting other maps sooner rather than later can be confuse to MonClient
users because they will get dispatched MMgrMap before the authenticate()
call has returned.
Sage Weil [Thu, 31 Jan 2019 20:05:37 +0000 (14:05 -0600)]
mon/MonClient: finsih authenticate() only after we get monmap; fix 'tell mgr'
We used to get a valid monmap before we finished the MAuth exchange and
returned from authenticate(). Now, we finish authenticating before we even
send or receive a message, so authenticate() returns quickly. This
confuses many callers, and is probably a bad idea. So, rejigger the
_finish_auth and _finish_hunting callers so that we finish hunting as soon
as we have picked a mon but don't finish_auth if we have not gotten our
first monmap.
Sage Weil [Thu, 31 Jan 2019 19:10:31 +0000 (13:10 -0600)]
mon: add auth_lock to protect auth_meta manipulation
In particular, we could be handling a get_auth_request() on a reconnect
while also running handle_auth_request() on a racing connection between
monitors.
Sage Weil [Tue, 29 Jan 2019 17:57:55 +0000 (11:57 -0600)]
msg/async/ProtocolV2: use shared_ptr to manage auth_meta
When we reconnect a session, we need to move the new connection's auth_meta
over to the existing connection. However, the existing connection may
have a thread that is unlocked and calling into an AuthClient or AuthServer
method making good use of the old auth_meta.
Resolved this by making auth_meta a shared_ptr and taking a local ref
before dropping the connection lock. This way we are free to move the
auth_meta over to the new connection as long as we are holding the lock,
and at the same time the existing connection can fiddle with the old
auth_meta without being disturbed. (That old auth_meta is about to get
discarded, but we still need to prevent the two threads from stomping on
each other.)
This also cleans up the reset_recv_state() a bit since we can simply
replace the old auth_meta with a totally fresh one without worrying about
what kind of state might be lurking in there.
Sage Weil [Wed, 23 Jan 2019 16:14:16 +0000 (10:14 -0600)]
auth: make connection_secret a std::string
Move connection mode decision to initial auth_request point so that it
can inform auth implementation how big the connection secret should be.
Pass that value through where appropriate.
The connection_secret is now a std::string filled with random bytes.
For now the v2 protocol just uses the session_key CryptoKey to encrypt,
but this is about to change.
- 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
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'.
Sage Weil [Mon, 21 Jan 2019 16:22:26 +0000 (10:22 -0600)]
switch monc, daemons to use new msgr2 auth frame exchange
- 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).
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.
Sage Weil [Sun, 20 Jan 2019 23:03:18 +0000 (17:03 -0600)]
auth: introduce AuthClient and AuthServer handlers
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.
Sage Weil [Sun, 20 Jan 2019 22:51:12 +0000 (16:51 -0600)]
auth: codify AUTH_MODE_AUTHORIZER
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).
Sage Weil [Wed, 16 Jan 2019 16:46:34 +0000 (10:46 -0600)]
auth/cephx: share all tickets and connection_secret in initial reply
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.
Sage Weil [Wed, 16 Jan 2019 20:57:13 +0000 (14:57 -0600)]
msg/async,auth: add AuthConnectionMeta to Protocol
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).
Sage Weil [Mon, 14 Jan 2019 23:18:13 +0000 (17:18 -0600)]
mon: only all ms_handle_authentication() if auth method says we're done
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.
Sage Weil [Wed, 6 Feb 2019 22:01:01 +0000 (16:01 -0600)]
ceph_test_msgr: fix server->client addr discovery
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.
Sage Weil [Wed, 6 Feb 2019 12:23:16 +0000 (06:23 -0600)]
msg/{async,simple}: make learned_addr a bit smarter
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).
Sage Weil [Tue, 5 Feb 2019 11:08:00 +0000 (05:08 -0600)]
msg/async: very protocol type when looking up existing connections
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
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.
Sage Weil [Sun, 3 Feb 2019 18:08:18 +0000 (12:08 -0600)]
msg/Messenger: add get_myaddr_legacy()
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.
Sage Weil [Mon, 28 Jan 2019 08:15:23 +0000 (02:15 -0600)]
msg/async: identify client using any: addr
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.