nautilus: qa/tasks/mgr/test_progress: fix wait_until_equal

Reviewed-by: Deepika Upadhyay <dupadhya@redhat.com>

nautilus: mgr: add mon metada using type of "mon"

Reviewed-by: Deepika Upadhyay <dupadhya@redhat.com>

Rotate tickets frequently to exercise those code paths during testing.

Signed-off-by: Sage Weil <sage@newdream.net>
(cherry picked from commit 94df762)

Conflicts:
	qa/tasks/cephadm.conf [ no cephadm in nautilus ]

Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 71a0d8a)

Conflicts:
	src/mon/Monitor.cc [ commit adf1486 ("common/admin_socket:
	  pass Formatter from generic infrastructure") not in nautilus ]

Eliminate confusion by moving auth from active_con into MonClient
instead of swapping them.

The existing MonClient::auth can be destroyed right away -- I don't
see why active_con would need it or a reason to delay its destruction
(which is what stashing in active_con effectively does).

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit eec24e4)

Commit a2eb6ae ("mon/monclient: hunt for multiple monitor in
parallel") introduced a regression where auth state (global_id and
AuthClientHandler) was no longer preserved on reconnects.  The ensuing
breakage was quickly noticed and prompted a follow-on fix 8bb6193
("mon/MonClient: persist global_id across re-connecting").

However, as evident from the subject, the follow-on fix only took
care of the global_id part.  AuthClientHandler is still destroyed
and all cephx tickets are discarded.  A new from-scratch instance
is created for each MonConnection and CEPHX_GET_AUTH_SESSION_KEY
requests end up with CephXAuthenticate::old_ticket not populated.
The bug is in MonClient, so both msgr1 and msgr2 are affected.

This should have resulted in a similar sort of breakage but didn't
because of a much larger bug.  The monitor should have denied the
attempt to reclaim global_id with no valid ticket proving previous
possession of that global_id presented.  Alas, it appears that this
aspect of the cephx protocol has never been enforced.  This is dealt
with in the next patch.

To fix the issue at hand, clone AuthClientHandler into each
MonConnection so that each respective CEPHX_GET_AUTH_SESSION_KEY
request gets a copy of the current auth ticket.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 236b536)

Conflicts:
	src/mon/MonClient.cc [ commit 1e9b180 ("mon: set
	  MonClient::_add_conn return type to void") not in nautilus ]

Destroying AuthClientHandler and not resetting global_id is another
way to get MonClient to send CEPHX_GET_AUTH_SESSION_KEY requests with
CephXAuthenticate::old_ticket not populated.  This is particularly
pertinent to get_monmap_and_config() which shuts down the bootstrap
MonClient between retry attempts.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit c9b022e)

Passing anything but MonClient instance's global_id doesn't make
sense.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit a71f6e9)

Conflicts:
	src/mon/MonClient.cc [ commit 1e9b180 ("mon: set
	  MonClient::_add_conn return type to void") not in nautilus ]
	src/mon/MonClient.h [ ditto ]

session_key, connection_secret and connection_secret_required_length
aren't material for start_session() across all three implementations.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit c151c96)

Conflicts:
	src/auth/AuthServiceHandler.h [ bufferlist vs
	  ceph::buffer::list ]
	src/auth/cephx/CephxServiceHandler.h [ ditto ]
	src/auth/none/AuthNoneServiceHandler.h [ ditto ]

Make the one in CephxServiceHandler private and drop the stub in
AuthNoneServiceHandler.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 49cba02)

Conflicts:
	src/auth/cephx/CephxServiceHandler.h [ bufferlist vs
	  ceph::buffer::list ]
	src/auth/none/AuthNoneServiceHandler.h [ ditto ]

AuthServiceHandler already has global_id field, but it is unused.
Revive it and let the handler know whether global_id is newly assigned
by the monitor or provided by the client.

Lift the setting of entity_name into AuthServiceHandler.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit b50b6ab)

Conflicts:
	src/auth/AuthServiceHandler.h [ bufferlist vs
	  ceph::buffer::list ]
	src/auth/cephx/CephxServiceHandler.cc [ ditto ]
	src/auth/cephx/CephxServiceHandler.h [ ditto ]
	src/auth/none/AuthNoneServiceHandler.h [ ditto ]

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 6b86068)

global_id is a cluster-wide unique id that must remain stable for the
lifetime of the client instance.  The cephx protocol has a facility to
allow clients to preserve their global_id across reconnects:

(1) the client should provide its global_id in the initial handshake
    message/frame and later include its auth ticket proving previous
    possession of that global_id in CEPHX_GET_AUTH_SESSION_KEY request

(2) the monitor should verify that the included auth ticket is valid
    and has the same global_id and, if so, allow the reclaim

(3) if the reclaim is allowed, the new auth ticket should be
    encrypted with the session key of the included auth ticket to
    ensure authenticity of the client performing reclaim.  (The
    included auth ticket could have been snooped when the monitor
    originally shared it with the client or any time the client
    provided it back to the monitor as part of requesting service
    tickets, but only the genuine client would have its session key
    and be able to decrypt.)

Unfortunately, all (1), (2) and (3) have been broken for a while:

- (1) was broken in 2016 by commit a2eb6ae ("mon/monclient:
  hunt for multiple monitor in parallel") and is addressed in patch
  "mon/MonClient: preserve auth state on reconnects"

- it turns out that (2) has never been enforced.  When cephx was
  being designed and implemented in 2009, two changes to the protocol
  raced with each other pulling it in different directions: commits
  0669ca2 ("auth: reuse global_id when requesting tickets")
  and fec3196 ("auth: when renewing session, encrypt ticket")
  added the reclaim mechanism based strictly on auth tickets, while
  commit 5eeb711 ("auth: change server side negotiation a bit")
  allowed the client to provide global_id in the initial handshake.
  These changes didn't get reconciled and as a result a malicious
  client can assign itself any global_id of its choosing by simply
  passing something other than 0 in MAuth message or AUTH_REQUEST
  frame and not even bother supplying any ticket.  This includes
  getting a global_id that is being used by another client.

- (3) was broken in 2019 with addition of support for msgr2, where
  the new auth ticket ends up being shared unencrypted.  However the
  root cause is deeper and a malicious client can coerce msgr1 into
  the same.  This also goes back to 2009 and is addressed in patch
  "auth/cephx: ignore CEPH_ENTITY_TYPE_AUTH in requested keys".

Because (2) has never been enforced, no one noticed when (1) got
broken and we began to rely on this flaw for normal operation in
the face of reconnects due to network hiccups or otherwise.  As of
today, only pre-luminous userspace clients and kernel clients are
not exercising it on a daily basis.

Bump CephXAuthenticate version and use a dummy v3 to distinguish
between legacy clients that don't (may not) include their auth ticket
and new clients.  For new clients, unconditionally disallow claiming
global_id without a corresponding auth ticket.  For legacy clients,
introduce a choice between permissive (current behavior, default for
the foreseeable future) and enforcing mode.

If the reclaim is disallowed, return EACCES.  While MonClient does
have some provision for global_id changes and we could conceivably
implement enforcement by handing out a fresh global_id instead of
the provided one, those code paths have never been tested and there
are too many ways a sudden global_id change could go wrong.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit abebd64)

Conflicts:
	src/auth/AuthServiceHandler.h [ bufferlist vs
	  ceph::buffer::list ]
	src/auth/cephx/CephxProtocol.h [ ditto ]
	src/auth/cephx/CephxServiceHandler.h [ ditto ]
	src/auth/none/AuthNoneServiceHandler.h [ ditto ]

When unauthorized global_id (re)use is disallowed, we don't want to
let unpatched clients in because they wouldn't be able to reestablish
their monitor session later, resulting in subtle hangs and disrupted
user workloads.

Denying the initial connect for all legacy (CephXAuthenticate < v3)
clients is not feasible because a large subset of them never stopped
presenting their ticket on reconnects and are therefore compatible with
enforcing mode: most notably all kernel clients but also pre-luminous
userspace clients.  They don't need to be patched and excluding them
would significantly hamper the adoption of enforcing mode.

Instead, force clients that we are not sure about to reconnect shortly
after they go through authentication and obtain global_id.  This is
done in Monitor::dispatch_op() to capture both msgr1 and msgr2, most
likely instead of dispatching mon_subscribe.

We need to let mon_getmap through for "ceph ping" and "ceph tell" to
work.  This does mean that we share the monmap, which lets the client
return from MonClient::authenticate() considering authentication to be
finished and causing the potential reconnect error to not propagate to
the user -- the client would hang waiting for remaining cluster maps.
For msgr1, this is unavoidable because the monmap is sent immediately
after the final MAuthReply.  But for msgr2 this is rare: most of the
time we get to their mon_subscribe and cut the connection before they
process the monmap!

Regardless, the user doesn't get a chance to start a workload since
there is no proper higher-level session at that point.

To help with identifying clients that need patching, add global_id and
global_id_status to "sessions" output.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 08766a1)

Conflicts:
	src/mon/Monitor.cc [ commit e1163b4 ("mon: print
	  entity_name along with caps to debug log") not in nautilus ]

If unauthorized global_id (re)use is disallowed, a client that has
been disconnected from the network long enough for keys to rotate
and its auth ticket to expire (i.e. become invalid/unverifiable)
would not be able to reconnect.

The default TTL is 12 hours, resulting in a 12-24 hour reconnect
window (the previous key is kept around, so the actual window can be
up to double the TTL).  The setting has stayed the same since 2009,
but it also hasn't been enforced.  Bump it to get a 72 hour reconnect
window to cover for something breaking on Friday and not getting fixed
until Monday.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 522a52e)

When handling CEPHX_GET_AUTH_SESSION_KEY requests from nautilus+
clients, ignore CEPH_ENTITY_TYPE_AUTH in CephXAuthenticate::other_keys.
Similarly, when handling CEPHX_GET_PRINCIPAL_SESSION_KEY requests,
ignore CEPH_ENTITY_TYPE_AUTH in CephXServiceTicketRequest::keys.
These fields are intended for requesting service tickets, the auth
ticket (which is really a ticket granting ticket) must not be shared
this way.

Otherwise we end up sharing an auth ticket that a) isn't encrypted
with the old session key even if needed (should_enc_ticket == true)
and b) has the wrong validity, namely auth_service_ticket_ttl instead
of auth_mon_ticket_ttl.  In the CEPHX_GET_AUTH_SESSION_KEY case, this
undue ticket immediately supersedes the actual auth ticket already
encoded in the same reply (the reply frame ends up containing two auth
tickets).

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 05772ab)

Two new alerts:

- AUTH_INSECURE_GLOBAL_ID_RENEWAL_ALLOWED if we are allowing clients to reclaim
global_ids in an insecure manner (for backwards compatibility until
clients are upgraded)

- AUTH_INSECURE_GLBOAL_ID_RENEWAL if there are currently clients connected that
do not know how to securely renew their global_id, as exposed by
auth_expose_insecure_global_id_reclaim=true.  The client auth names and IPs
are listed the alert details (up to a limit, at least).

The docs recommend operators mute these alerts instead of silencing, but
we still include option that allow the alerts to be disabled entirely.

Signed-off-by: Sage Weil <sage@newdream.net>
(cherry picked from commit 18b343b)

Conflicts:
	doc/rados/operations/health-checks.rst [ MON_DISK_* alerts
	  present but not documented in nautilus; "ceph health mute"
	  not in nautilus -- silencing temporarily is not possible ]
	src/mon/HealthMonitor.cc [ commits e4bf716 ("mon: store
	  a reference as member variable") and d0eb22f
	  ("mon/health_checks: associate a count with health_alert_t")
	  not in nautilus ]

…m health alerts

Turn these off everywhere for our tests so they don't interfere with our health checks.

Signed-off-by: Sage Weil <sage@newdream.net>
(cherry picked from commit 9f6fd4f)

Conflicts:
	qa/tasks/cephadm.conf [ no cephadm in nautilus ]

Signed-off-by: Sage Weil <sage@newdream.net>
(cherry picked from commit 72c4fc7)

When an incomplete multipart upload has in excess of 1000 parts,
looping over those parts was not handled property causing an infinite
loop. The paging/marker is now handled correctly.

Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
(cherry picked from commit 098edda)

Conflicts:
        src/rgw/rgw_orphan.cc: back out Zipper 10 updates

Make sure there are more than 1000 incomplete multiparts and also make
sure one of the incomplete multiparts has at least 1000 parts. This
test is done indirectly through rgw-orphan-list, which invokes
`radosgw-admin radoslist`.

Also, clean up shell flags, so script output is less verbose.

Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
(cherry picked from commit d76e65b)

Fixes: https://tracker.ceph.com/issues/49882
Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit bb1fd87)

Fixes: https://tracker.ceph.com/issues/49882
Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit b2375ad)

Conflicts:
  src/pybind/cephfs/mock_cephfs.pxi : Not present in octopus
  src/pybind/cephfs/c_cephfs.pxd : Not present in octopus
  src/pybind/cephfs/cephfs.pyx : Few of the fops is not part of octopus
      which got pulled as part of this backport
  src/test/pybind/test_cephfs.py :  Few of the fops is not part of
      octopus, which got pulled as part of this backport. Added missing
      stat import.

Fixes: https://tracker.ceph.com/issues/49882
Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit 92dc982)

Conflicts:
  qa/tasks/cephfs/test_volumes.py: Few of the testcases are not preset
      in octopus, hence the conflicts.

Increase verbosity in nodeenv command for debugging purposes.

Fixes: https://tracker.ceph.com/issues/50044
Signed-off-by: Ernesto Puerta <epuertat@redhat.com>
(cherry picked from commit 2c2a397)

 Conflicts:
	make-dist
	src/pybind/mgr/dashboard/CMakeLists.txt
      - Adopted the master branch changes.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 3078af7)

If auth_mon_ticket_ttl is increased by several times as done in
commit 522a52e ("auth/cephx: rotate auth tickets less often"),
active clients eventually get stuck because the monitor sends out an
auth ticket with a bogus validity.  The ticket is secured with the
"current" secret that is scheduled to expire according to the old TTL,
but the validity of the ticket is set to the new TTL.  As a result,
the client simply doesn't attempt to renew, letting the secrets rotate
potentially more than once.  When that happens, the client first hits
auth authorizer errors as it tries to renew service tickets and when
it finally gets to renewing the auth ticket, it hits the insecure
global_id reclaim wall.

Cap TTL by expiration of "next" key -- the "current" key may be
milliseconds away from expiration and still be used, legitimately.
Do it in KeyServerData alongside key rotation code and propagate the
capped TTL to the upper layer.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 370c9b1)

Conflicts:
	src/auth/cephx/CephxKeyServer.cc [ commit ef3c42c ("auth:
	  EACCES, not EPERM") not in nautilus ]

The second KeyServer::build_session_auth_info() overload is used only
by the monitor, for mon <-> mon authentication.  The monitor passes in
service_secret (mon secret) and secret_id (-1).  The TTL is irrelevant
because there is no rotation.

However the signature doesn't make it obvious.  Clarify that
service_secret and secret_id are input parameters and info is the only
output parameter.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 6f12cd3)

There is no need to do a check_pool_perm() on anything that isn't
a regular file, as the MDS is what handles talking to the OSD in
those cases. Just return 0 if it's not a regular file.

Signed-off-by: Xiubo Li <xiubli@redhat.com>
(cherry picked from commit 59a3006)

nautilus: librbd: race when disabling object map with overlapping in-flight writes

Reviewed-by: Ilya Dryomov <idryomov@redhat.com>

nautilus: librbd: fix sporadic failures in TestMigration.StressLive

Reviewed-by: Ilya Dryomov <idryomov@redhat.com>

nautilus: ceph-monstore-tool: use a large enough paxos/{first,last}_committed

Reviewed-by: Deepika Upadhyay <dupadhya@redhat.com>

It fixes the bug when the handle_start_replay detected the cancel
when it called on_replay_interrupted and returned without
completing m_on_start_finish context.

This is a direct commit to nautilus. The bug was accidentally
fixed in newer versions during refactoring.

Signed-off-by: Mykola Golub <mgolub@suse.com>

nautilus: rbd-mirror: image replayer stop might race with instance replayer shut down

Reviewed-by: Ilya Dryomov <idryomov@redhat.com>