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

KRB5_CCNAME variable is reused between JSTest jobs when it shouldn't be

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.4.0-rc1, 4.7.0
    • Component/s: None
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.4
    • Sprint:
      Security 2020-03-23
    • Linked BF Score:
      16

      Description

      Cross-posting from BF-16430

      After doing some digging with Spencer Jackson, we believe BF-16430 stems from a race involving kdestroy and kinit which are called from two different tests around the same time. The idea is that one test kinits to generate a ticket, and then before the credentials cache is read, the other test destroys the cache. We had put in place a method of preventing this from happening, but it is not working as intended.

      The idea was to use the job's data dir to hold the credentials cache, but it seems the jobs are all using the same data dir. For example, notice how in the following logs:

      Notice how both of these tests place their credentials cache in the job2 data dir, despite the fact that neither of them are job2. We believe we have isolated the reason for this. On this line in jstest.py, we are making a shallow copy of the shell options dictionary. We later on modify the internal dictionary that contains some of the values that will be passed to the shell to eval. Since this is only a shallow copy, the internal dictionary is not thread-local and refers to the same memory used by the other jobs. We believe this issue can be fixed by using a deepcopy instead of a shallow copy.

      As a proof of concept, I have uploaded this patch

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              adam.cooper Adam Cooper (Inactive)
              Reporter:
              adam.cooper Adam Cooper (Inactive)
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: