Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c) - Mailing list pgsql-bugs

From Andrew Gierth
Subject Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c)
Date
Msg-id 87in9uhbco.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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)  (Christoph Berg <myon@debian.org>)
List 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 by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: BUG #15116: pg_recvlogical always fails
Next
From: Tom Lane
Date:
Subject: Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c)