Follow-up to #2631:
-
load_oidc_provider_config will raise an exception (i.e., prevent the settings module from being imported) if OIDC_RSA_KEY_FILE points to a file that doesn't exist or we do not have permission to read.
-
The generate_oidc_rsa_key command will create a key file that only the calling user ID has permission to read.
Separately these sound logical, but together they are a problem.
The secret keys should preferably only be readable by the uwsgi server UID. But other UIDs (such as the pn user, who runs migrations) also must be able to import the settings module.
Currently, for example, the Google and AWS account credentials are only readable by the uwsgi server. The pn user and other admin users can import the application but any attempt to perform Google/AWS operations will fail.
It would be wise to handle the OIDC keys in a similar way. Perhaps, raise an exception in settings/base.py if the file doesn't exist, but if the file exists and isn't readable then disable the functionality.
At least for the time being, we've changed the permissions of the key file so tahat all admin users are able to read it. However, this is fragile: in the future when somebody needs to rotate the keys they're likely to break things.
Follow-up to #2631:
load_oidc_provider_configwill raise an exception (i.e., prevent the settings module from being imported) if OIDC_RSA_KEY_FILE points to a file that doesn't exist or we do not have permission to read.The
generate_oidc_rsa_keycommand will create a key file that only the calling user ID has permission to read.Separately these sound logical, but together they are a problem.
The secret keys should preferably only be readable by the uwsgi server UID. But other UIDs (such as the
pnuser, who runs migrations) also must be able to import the settings module.Currently, for example, the Google and AWS account credentials are only readable by the uwsgi server. The
pnuser and other admin users can import the application but any attempt to perform Google/AWS operations will fail.It would be wise to handle the OIDC keys in a similar way. Perhaps, raise an exception in settings/base.py if the file doesn't exist, but if the file exists and isn't readable then disable the functionality.
At least for the time being, we've changed the permissions of the key file so tahat all admin users are able to read it. However, this is fragile: in the future when somebody needs to rotate the keys they're likely to break things.