Checklist

• I have verified that the issue exists against the master branch of Celery.
• This has already been asked to the discussion group first.
• I have read the relevant section in the
  contribution guide
  on reporting bugs.
• I have checked the issues list
  for similar or identical bug reports.
• I have checked the pull requests list
  for existing proposed fixes.
• I have checked the commit log
  to find out if the bug was already fixed in the master branch.
• I have included all related issues and possible duplicate issues
  in this issue (If there are none, check this box anyway).

Mandatory Debugging Information

• I have included the output of celery -A proj report in the issue.
  (if you are not able to do this, then at least specify the Celery
  version affected).
• I have verified that the issue exists against the master branch of Celery.
• I have included the contents of pip freeze in the issue.
• I have included all the versions of all the external dependencies required
  to reproduce this bug.

Optional Debugging Information

• I have tried reproducing the issue on more than one Python version
  and/or implementation.
• I have tried reproducing the issue on more than one message broker and/or
  result backend.
• I have tried reproducing the issue on more than one version of the message
  broker and/or result backend.
• I have tried reproducing the issue on more than one operating system.
• I have tried reproducing the issue on more than one workers pool.
• I have tried reproducing the issue with autoscaling, retries,
  ETA/Countdown & rate limits disabled.
• I have tried reproducing the issue after downgrading
  and/or upgrading Celery and its dependencies.

Related Issues and Possible Duplicates

Related Issues

DefectDojo/django-DefectDojo#3582

Possible Duplicates

Environment & Settings

Steps to Reproduce

I have come across this when running using OpenShift restricted SCC

oc logs defect-dojo-defectdojo-celery-worker-78dbb86b48-2rxn2
uid=1000640000(1000640000) gid=0(root) groups=0(root),1000640000
Waiting for database to be reachable [06/Jan/2021 13:40:58] INFO [dojo.models:3474] enabling audit logging
[06/Jan/2021 13:41:00] INFO [dojo.models:3474] enabling audit logging
Running a worker with superuser privileges when the
worker accepts messages serialized with pickle is a very bad idea!
If you really want to continue then you have to set the C_FORCE_ROOT
environment variable (but please think about this before you do).
User information: uid=1000640000 euid=1000640000 gid=0 egid=0

Required Dependencies

• Minimal Python Version: N/A
• Minimal Celery Version: 4.1.1
• Minimal Kombu Version: 4.1
• Minimal Broker Version: N/A
• Minimal Result Backend Version: N/A
• Minimal OS and/or Kernel Version: N/A
• Minimal Broker Client Version: N/A
• Minimal Result Backend Client Version: N/A

Python Packages

Other Dependencies

Minimally Reproducible Test Case

Expected Behavior

I believe that GID=0 doesn't give superuser privileges, so am not sure why the celery checks are implemented in this manner.

Actual Behavior

The gid (and egid) being 0 does not give superuser prvilieges
as stated - https://unix.stackexchange.com/questions/44077/what-does-it-mean-to-be-in-group-0 and https://docs.celeryproject.org/en/stable/userguide/daemonizing.html#running-the-worker-with-superuser-privileges-root