[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:
Depends
Related
is related to DOCS-11255 Document that 3.6 implicit sessions m... Closed
is related to DOCS-12376 Document that commands which do not r... Closed
is related to SERVER-39232 Allow commands that do not require au... Closed
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 DOCS-11255 to use the refreshSessions command instead of isMaster after creating this ticket. I think I agree that this is working as designed, here's a excerpt from the Logical Sessions design doc:

Sessions and Pre-Auth Commands
Certain MongoDB commands, like “ping” and “ismaster”, are processed outside of auth, and are used by drivers before authentication can begin. If a logical session id is passed to any of these commands, it will be ignored. Pre-auth commands cannot be associated with sessions.

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 DOCS-12376 to document the current behavior of ignoring sessions on certain commands since as far as I can tell it's not documented anywhere except the design doc.

I'd consider that a larger change, and something I'd want to at least see a scope for

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

Generated at Thu Feb 08 04:48:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.