Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c)
От | Andrew Gierth |
---|---|
Тема | Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c) |
Дата | |
Msg-id | 87in9uhbco.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c)
Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution(exec.c) |
Список | pgsql-bugs |
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> ... I find that quite an unacceptable answer. We need to resolve Tom> the symlink correctly, or we risk malfunctioning later, for the Tom> reasons recited in the comment for find_my_exec(). On systems with openat(), would it not be possible to resolve symlinks without ever needing chdir? Tom> I think your example of "sudo /usr/bin/pg_ctl" is pretty Tom> artificial; who'd bother spelling that out? Not necessarily exactly like that, but we do occasionally get this issue coming up on the IRC channel. Tom> While I've not thought about it very hard, it might be possible to Tom> rewrite find_my_exec() and resolve_symlinks() "from the ground up" Tom> so that they don't do getcwd() except in cases where there's Tom> really no alternative, such as the executable having been invoked Tom> using a relative path. I think getcwd is avoidable even then, if openat() etc. are available. -- Andrew (irc:RhodiumToad)
В списке pgsql-bugs по дате отправления: