- A connects to B
- A sends client_ident
- fault before A gets server_ident, so A doesn't know B's features or name
- B reconnects to A
- connection established
A thinks B is unknown.0 and has not idea what the featurs are.
Fix this by including id and featurs in reconnect. We don't know the type, but that is
included in TAG_HELLO in another branch, which will be merged separately; add a
Signed-off-by: Sage Weil <sage@redhat.com>
Stopping the osd daemon won't reliably get you HEALTH_WARN or ERR; you have
to make sure it is also marked down.
Signed-off-by: Sage Weil <sage@redhat.com>
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.
Signed-off-by: Sage Weil <sage@redhat.com>
The messenger doesn't activate until you set the dispatcher. Set up the auth_client
and auth_server values before that.
Signed-off-by: Sage Weil <sage@redhat.com>
For authv2, we only increase max_global_id from tick, not via prep_auth(), so we
need to ask the leader for more IDs here as we do there.
Signed-off-by: Sage Weil <sage@redhat.com>
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.
Signed-off-by: Sage Weil <sage@redhat.com>
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.
Signed-off-by: Sage Weil <sage@redhat.com>
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.
Signed-off-by: Sage Weil <sage@redhat.com>
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.
Signed-off-by: Sage Weil <sage@redhat.com>
Reuse MonConnection to do the authentication.
Note this is a change in behavior: ceph ping mon* now requires
authentication.
Signed-off-by: Sage Weil <sage@redhat.com>
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.
Signed-off-by: Sage Weil <sage@redhat.com>
This removes the wonky accessor on Connection, and most importantly
allows the caller to control the lifecycle of the AuthConnectionMeta.
Signed-off-by: Sage Weil <sage@redhat.com>
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.
Signed-off-by: Sage Weil <sage@redhat.com>
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>
