[SERVER-38432] A session can expire on the server even when the driver is using it Created: 05/Dec/18 Updated: 08/Jan/24 Resolved: 25/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Shane Harvey | Assignee: | Randolph Tan |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | security | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Sharding 2019-01-14, Sharding 2019-01-28 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
A session which is being continually used by a driver can expire on the server because the server does not update a session's "lastUse" time for commands that do not require auth, instead the session related arguments are ignored completely: https://github.com/mongodb/mongo/blob/r4.0.4/src/mongo/db/initialize_operation_session_info.cpp#L64-L71 In practice this means that it's not possible to keep a noCursorTimeout:true cursor alive by periodically running isMaster with the cursor's session. As a workaround users can run a command that requires auth (such as listCollections) to correctly keep the session, and therefore the cursor, alive. It seems to me that when a user is authenticated, any command they run that includes a session should create the session if necessary and update its lastUse time. |
| Comments |
| Comment by Shane Harvey [ 17/Jan/19 ] |
|
Thanks Jason, I did update
However, I would still like to see this change implemented because it makes sessions behave more consistently across all commands. I think most (if not all) of the drivers team would be surprised to learn about this behavior. Opened
SGTM |
| Comment by Mira Carey [ 16/Jan/19 ] |
|
renctan, Logical sessions only make sense in the context of an authenticated user. Using the noDigest uid is effectively creating sessions under the "" user, which are meaningless (the real user won't be able to act on them, won't be able to kill or read from cursors opened in them, etc.) shane.harvey, I think session refresh is working as designed. There was an explicit mechanism made to refresh logical sessions (refreshSessions), which does use auth and does... refresh sessions. I'm not sure why isMaster needs to do that job. I can see an argument for changing commands which don't require auth to still bind an lsid (on auth'd connections), but I'd consider that a larger change, and something I'd want to at least see a scope for |
| Comment by Randolph Tan [ 11/Jan/19 ] |
|
spencer.jackson Yes, that was the intention, to be able to extend the lifetime of whatever session they may have been using on ops that don't require auth. Our docs doesn't appear to say anything about requiring auth, so I was unsure whether we should assign a default uid for these cases or just completely ignore the session id from the user (I don't think we can just error since drivers would always have a default session). |
| Comment by Spencer Jackson [ 10/Jan/19 ] |
|
renctan, what do you want to use this hash for? To generate the ID whose lastUse you're about to update? Is this for the case where there actually is no currently authenticated user? If so, why are we attempting to parse apart the LSID, given that the client should not be allowed to bump the expiration of any session? |
| Comment by Randolph Tan [ 10/Jan/19 ] |
|
I was trying to fix this and I ran into an issue when auth is on because it asserts that a user should be authenticated when trying to compute for the uid hash for the logical session id. I am planning on using this digest for cases when auth ON + auth not required for cmd + no user logged in. Does that sound good to you? mira.carey@mongodb.com, spencer.jackson |