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

Move away from using Bson_serialization_type “any”

    • Type: Icon: Task Task
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Security
    • Labels:
      None
    • Server Security
    • Security 2021-03-22, Security 2021-04-05, Security 2021-04-19

      Using Bson_serialization_type “any” means that idl compatibility checker script can’t do any type checking, since that logic is in cpp, so we want to disallow this type from parameters/reply fields as a result.

      However, lots of commands actually use it for valid reasons.
      For now we added some exceptions to allow using Bson_serialization_type “any” in our idl_checker script, these are the lisf of fields that still using Bson_serialization_type “any” that require your attention:

      src/mongo/db/auth/sasl_commands.idl

      1. The 'saslStart'' command has parameter 'payload' that has type
      2. 'SaslPayload' 'saslStart' has a reply field 'payload' of type 'SaslPayload' 
      3. The 'saslContinue'' command has parameter 'payload' that has type 'SaslPayload' 
      4. 'saslContinue' has a reply field 'payload' of type 'SaslPayload'

       

      Take a look at these fields and try to identify which ones can be converted away from using Bson_serialization_type “any”, and which ones must keep using it.
      Here are the two outcomes:
      1- if the field can be converted:

      • This change should be done before 5.0 (if the field is "stable") as this will be the realese for API stable Version 1
      • The exception for that field should be removed from idl_checker script (TODO will be added with this ticket number).

      2- if the field can't be converted, or the change can't be done before 5.0.

      • The type of that field type should stay of Bson_serialization_type “any” and can't be changed later for any reason unless it is defined as "unstable".
      • We need to put comments on the serialization/deserialization to prevent the behavioral changes (preferably to add tests to ensure that.)

            Assignee:
            backlog-server-security [DO NOT USE] Backlog - Security Team
            Reporter:
            m.maher@mongodb.com Moustafa Maher
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: