Background: mongod checks file-based permissions of the 'keyFile' on startup. It will not start if it thinks the keyFile has an insecure owner+mode.
Problem: when the keyFile is owned as root and is only readable to mongod via the 'group' bit (0440 for example), mongod fails to start complaining that the key is insecure.
This is incorrect because a "root" owned file with "group-level" read and no "other" permissions is equally as secure as a "mongod" owned 0440-mode keyFile, which is allowed.
Why does this matter?
Kubernetes Secret files are always owned as root. We can give mongod the group-read bit to the keyFile, but it fails to start due to the problem above.
Secondly, it's just incorrect to consider a file with this owner+mode insecure.
Reproduction of the error:
Notice mongod will not start although only 'root' (who can read any file anyways) and the user running mongod can read the keyFile - which IS secure.
Desired fix: consider a keyFile that is owned as 'root' (UID:0) and has a group-read bit to the mongod user as secure. Don't fail startup with an error because the keyFile IS secure.
We should support modes (when owner is 'root'):
- 0440 (owner+group read)
- 0040 (group-only read)
- 0640 (owner read/write + group read)