Attempting to acquire a LockManager lock while holding a mutex is prone to deadlock. The AuthorizationManager::getAuthorizationVersion() function constructs a CacheGuard which acquires the AuthorizationManager::_cacheMutex. While holding the mutex, it calls AuthorizationManager::getStoredAuthorizationVersion(), which attempts to acquire the global lock as part of constructing AutoGetCollectionForReadCommand in AuthzManagerExternalStateMongod::findOne(). Edit: As noted in SERVER-24083, the AuthorizationManager::_cacheMutex is released as part of AuthorizationManager::beginFetchPhase() ; however, a thread must wait if another thread is already calling into AuthorizationManager::getStoredAuthorizationVersion().

A thread running the db.eval() with nolock=false (thus holding the global X lock) would therefore deadlock if it ran any command that constructed a CacheGuard and attempted to acquire the AuthorizationManager::_cacheMutex.

The doc comment for the AuthorizationManager::CacheGuard class describes this general issue; however, it appears we are missing code to enforce it doesn't happen in practice.

NOTE: It is not safe to enter fetch phase while holding a database lock. Fetch phase operations are allowed to acquire database locks themselves, so entering fetch while holding a database lock may lead to deadlock.

https://github.com/mongodb/mongo/blob/r3.7.2/src/mongo/db/auth/authorization_manager.cpp#L167-L169