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

=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> In both cases, the utility/daemon will fail (and exit) if the current
> directory is either not readable or not searchable, even though said
> utility/daemon has permission to access each component of its absolute
> path in argv0.

TBH, I don't have a whole lot of sympathy for the premise that we need to
support such cases. If we can do it without giving anything else up,
then OK, but ...

> In the patch below, path resolution is skipped if getcwd returns EACCES.

... I find that quite an unacceptable answer. We need to resolve the
symlink correctly, or we risk malfunctioning later, for the reasons
recited in the comment for find_my_exec().

The idea of pre-checking to see if the initial path is already absolute
seems safe enough, but I'm not sure how much of the use-case it'd cover.
I think your example of "sudo /usr/bin/pg_ctl" is pretty artificial;
who'd bother spelling that out?

While I've not thought about it very hard, it might be possible to rewrite
find_my_exec() and resolve_symlinks() "from the ground up" so that they
don't do getcwd() except in cases where there's really no alternative,
such as the executable having been invoked using a relative path.

Also, I realize that this patch is just a POC, but we don't much like
patches that make significant logic changes without appropriate
comment updates.

regards, tom lane