Repository navigation
Running process as another user causes permission denied error when setting up database connection. #910
Description
- asyncpg version: 0.25.0
- PostgreSQL version: 13
- Do you use a PostgreSQL SaaS? If so, which? Can you reproduce
the issue with a local PostgreSQL install?: Both RDS and Docker. Not a PG related issue. - Python version: 3.8.11 (RedHat)
- Platform: CentOS 7
- Do you use pgbouncer?: No
- Did you install asyncpg with pip?: Yes
- If you built asyncpg locally, which version of Cython did you use?: n/a
- Can the issue be reproduced under both asyncio and
uvloop?: Untested, but shouldn't be relevant.
And I ran into this issue when upgrading from 0.23.0 to 0.25.0, but I believe it was introduced in 0.25.0 based on my reading of the git history.
I am using supervisord to run an app as a different user. When it gets to https://github.com/MagicStack/asyncpg/blob/master/asyncpg/connect_utils.py#L542 when setting up a connection. That resolves the path to /root/.postgresql/postgresql.key and results in an a Permission denied error when it calls .exists() on a file within /root/ as a non root user.
I believe this is because http://supervisord.org/subprocess.html#subprocess-environment doesn't change HOME in the path, and pathlib still sees HOME="/root". So I will be tinkering with unsetting that.
Even if changing the environment fixes my issue, it may be worth adding exception handling for when those paths resolve to a directory the user running asyncpg cannot access.
Activity
lqhuang commentedon Jun 16, 2022
Thanks, I have suffered totally same issue where I'm using
docker+supervisord+asyncpg.Through I found this is an expected situation documented in supervisord docs, it may not only specify to
supervisord. AsyncPg will also fail for every systems which environments have been messed up intentionally or unintentionally.tarsil commentedon Nov 16, 2022
Any news how to fix this? I'm having the same issue with docker, nginx, supervisor and asyncpg and the version is the 0.26.0
eseglem commentedon Nov 16, 2022
@tarsil I believe I set
environment=HOME=""within the supervisor config. If that doesn't work I'll go dig up what I did.tarsil commentedon Nov 16, 2022
@eseglem home as empty string? Because if not, I tried and it doesn't work
eseglem commentedon Nov 16, 2022
@tarsil yeah, effectively unset it so asyncpg doesn't try to look in it.
tarsil commentedon Nov 16, 2022
@eseglem did you add it to the program? If yes, I will give it a try tomorrow and let you know :)
tarsil commentedon Nov 16, 2022
@eseglem under program it still fails.
aemr3 commentedon Jan 30, 2023
Setting HOME to a different path inside Dockerfile fixed this problem for us. Our celery worker was running as nobody user but HOME was set to /root.
tarsil commentedon Apr 11, 2023
@eseglem after 300 tries, your solution worked :)
verhovensky commentedon Feb 15, 2024
I also faced the issue. For me it was a big surprise.
Solved by upgrading postgresql from 15 to 15.1 version and setting HOME env variable in docker-compose.yml file
Also take into consideration docker volumes if you use docker.
For me it was crucial to actually RENAME volume with postgresql data, because deleting them was not working.
himalczyk commentedon Aug 27, 2024
I faced this issue as well. In my case the container was missing the HOME path to be set to the directory in which the apps is contained.
Eg.
HOME: /home/app_nameThis changes where the application looks for ssl keys (such as postgresql.key).
Default Behavior: When the application inside the container runs and tries to access /root/.postgresql/postgresql.key, it encounters a "Permission denied" error because it likely does not have the necessary permissions to access files in /root/.
Custom HOME Directory: By setting the HOME environment variable to /home/app_name, you are telling the operating system and your application to treat /home/app_name as the home directory. As a result, the application will now look for the SSL key files in /home/app_name/.postgresql/ instead of /root/.postgresql/.