Replace remaining getpwuid() calls with getpwuid_r()?
От | Steve Lau |
---|---|
Тема | Replace remaining getpwuid() calls with getpwuid_r()? |
Дата | |
Msg-id | 24EDD099-AAD5-4173-8AB0-CC00E44802B9@outlook.com обсуждение исходный текст |
Ответы |
Re: Replace remaining getpwuid() calls with getpwuid_r()?
Re: Replace remaining getpwuid() calls with getpwuid_r()? |
Список | pgsql-hackers |
Hi hackers, when reading the source code, I noticed that Postgres is still using getpwuid(), which is not thread-safe sinceit returns a pointer to the static memory that can be overwritten by concurrent calls. Then I searched "getpwuid" inthe mailing list[1], and there was a committed patch that refactored one such usage. So maybe we can clean up the remaininggetpwuid() calls? Then I realized that Postgres does not use threads but processes, so technically IMHO getpwuid() is safe to Postgres? Butthat patch mentioned that[2]: > This is AFAICT the only call in the getpw*() family that needs to be dealt with. (There is also a getgrnam() call, butthat is called very > early in the postmaster, before multiprocessing, so we can leave that as is.) Which indeed confuses me. So my questions are: 1. Will the thread-safety issue of getpwuid() affect Postgres? Why? 2. If the answer to the first question is yes, should we clean up the remaining getpwuid() calls or not? [1]: https://www.postgresql.org/search/?m=1&ln=pgsql-hackers&q=getpwuid [2]: https://www.postgresql.org/message-id/5f293da9-ceb4-4937-8e52-82c25db8e4d3@eisentraut.org Best regards, Steve.
В списке pgsql-hackers по дате отправления: