[SERVER-8368] Possible deadlock between db mutex and ClientCursor::ccmutex during authorization in ClientCursor::eraseIfAuthorized? Created: 29/Jan/13  Updated: 11/Jul/16  Resolved: 07/Feb/13

Status: Closed
Project: Core Server
Component/s: Concurrency, Security
Affects Version/s: 2.3.2
Fix Version/s: 2.4.0-rc1

Type: Bug Priority: Major - P3
Reporter: Aaron Staple Assignee: Spencer Brody (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-8389 Possible deadlock with auth check for... Closed
Participants:

 Description   

In various types of operations, the ClientCursor::ccmutex is acquired after the db mutex. For example, during a get more, a read lock on the db mutex is acquired, then the ccmutex is acquired to look up a ClientCursor with a particular cursor id.

Historically, a kill cursors ran by calling ClientCursor::erase() which acquired ClientCursor::ccmutex without a db mutex. (Any "in use" ClientCursor would be pinned and this function would fail before deleting it.)

Currently, kill cursors calls ClientCursor::eraseIfAuthorized(), which acquires the ClientCursor::ccmutex and then checks getAuthorizationManager()->checkAuthorization(). It looks like some code paths from checkAuthorization() may acquire a db lock to read user documents from a database's system.users collection - in particular in _probeForPrivilege … AuthExternalState::getPrivilegeDocument. I'm not familiar enough with the auth code to know under what circumstances these code paths will be triggered. However, if ccmutex can be acquired before the db mutex a deadlock is possible (as stated above most other operations acquire the db mutex then the ccmutex).

Could you let me know if I'm on the right tack with this?



 Comments   
Comment by auto [ 07/Feb/13 ]

Author:

{u'date': u'2013-01-29T18:43:24Z', u'email': u'spencer@10gen.com', u'name': u'Spencer T Brody'}

Message: SERVER-8368 Don't check authorization for deleting cursors while holding a mutex that is usually acquired after the DB level lock
Branch: master
https://github.com/mongodb/mongo/commit/63e792f9db6ff9b0ea798910301c30aa590b1678

Comment by Spencer Brody (Inactive) [ 29/Jan/13 ]

Yes, after looking at the code, I agree with you that this could be a problem. Investigating possible fixes now.

Generated at Thu Feb 08 03:17:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.