Fix Sensitive Data Exposure: Set umask to default value after use

[fazledyn-or]

What kind of change does this PR introduce?

• bug fix
• feature
• docs update
• tests/coverage improvement
• refactoring
• other

Other information:

Details

While triaging your project, our bug fixing tool generated the following message(s)-

In file: plugins.py, there is a method daemonize that grants permission to the others class which refers to all users except the owner and member of the file's group class. This may lead to undesired access to a confidential file. iCR replaced the loose permission with a stricter permission.

Notes

According to your codebase and comments, it seems that the os.umask(0) has to be called in order to daemonize a process. However, it's suggested that the umask value be set to default after the daemonizing task. Otherwise the umask value could propagate for the rest of the codebase and may introduce vulnerability.

Proof of Concept

• POC - Sensitive Data Exposure - umask - CherryPy.mp4
• Example Source Code:

  import os.path
  import cherrypy
  from cherrypy.process.plugins import Daemonizer
  
  class HelloWorld:
      """ Sample request handler class. """
      # ...
      @cherrypy.expose
      def index(self):
          # ...
          with open("test_daemonize_webserver", "w") as f:
              f.write("I'm writing this from the webserver")
          mask = os.umask(0o644)
          return 'Hello world!'
  
  with open("test_daemonize_before", "w") as f:
      f.write("I'm writing this before daemonizing")
  
  # Let's daemonize the process
  Daemonizer(cherrypy.engine).subscribe()
  tutconf = os.path.join(os.path.dirname(__file__), 'tutorial.conf')
  
  if __name__ == '__main__':
      # ...
      cherrypy.quickstart(HelloWorld(), config=tutconf)

Changes

Set the os.umask value to what it was before after daemonizing the process. For example -

Previously Found & Fixed

• Fixed Sensitive Data Exposure (File permission in attachments) django-helpdesk/django-helpdesk#1120

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

All contributed commits are already automatically signed off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).
- Git Commit SignOff documentation

Sponsorship and Support

This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.

The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory and then manually triaging the results.

---

Checklist:

• I think the code is well written
• I wrote good commit messages
• I have squashed related commits together after the changes have been approved
• Unit tests for the changes exist
• Integration tests for the changes exist (if applicable)
• I used the same coding conventions as the rest of the project
• The new code doesn't generate linter offenses
• Documentation reflects the changes
• The PR relates to only one subject with a clear title
  and description in grammatically correct, complete sentences