Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-33648

Attempting to perform user- and role-management commands in db.eval() with nolock=false can lead to deadlock

    • Type: Icon: Bug Bug
    • Resolution: Gone away
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: JavaScript, Security
    • Labels:
    • Server Security
    • ALL
    • Platforms 2018-05-07
    • 16

      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.


            backlog-server-security Backlog - Security Team
            max.hirschhorn@mongodb.com Max Hirschhorn
            0 Vote for this issue
            8 Start watching this issue