[MONGOCRYPT-159] Define expected behavior when listCollections returns no collection info document Created: 30/Jul/19  Updated: 28/Oct/23  Resolved: 25/Aug/19

Status: Closed
Project: Libmongocrypt
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Shane Harvey Assignee: Kevin Albertson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When the state is MONGOCRYPT_CTX_NEED_MONGO_COLLINFO a driver is supposed to run a listCollections command with the given filter and feed the resulting collection info document back to libmongocrypt.

What is a driver supposed to do when no document is returned? This would happen when the collection is dropped for example. Should the driver:

  • feed in an empty BSON document?
  • skip the call mongocrypt_ctx_mongo_feed altogether?
  • raise an error?
  • do something else?


 Comments   
Comment by Githook User [ 25/Aug/19 ]

Author:

{'username': 'kevinAlbs', 'email': 'kevin.albertson@10gen.com', 'name': 'Kevin Albertson'}

Message: CDRIVER-3261 clarify empty listCollections results
Branch: master
https://github.com/mongodb/libmongocrypt/commit/cac50bcbdcf201259f6a75fd6ee762ec7a84bb27

Comment by Shane Harvey [ 30/Jul/19 ]

Thanks that makes sense to me.

I think this is another case where using the client side schemaMap option is more secure than relying on listCollections. Consider that if the collection is dropped or the jsonSchema validator is removed then previously encrypted fields will no longer be encrypted and will be sent in plaintext to the server.

Comment by Kevin Albertson [ 30/Jul/19 ]

In this case, skip the call to mongocrypt_ctx_mongo_feed. It is not an error, since even collections without a schema are checked through mongocryptd (e.g. aggregate with $lookup is always prohibited because it may fetch results from a different collection that does have automatic encryption enabled).

Generated at Thu Feb 08 09:08:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.