Re: Can we avoid chdir'ing in resolve_symlinks() ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Can we avoid chdir'ing in resolve_symlinks() ?
Date: 2022-10-04 18:07:13
Message-ID: 2017063.1664906833@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> I tried lots of crazy stuff[1] to try to get an error out of this
> thing, but came up empty handed. Unlike realpath(), _fullpath()
> doesn't resolve symlinks (or junctions), so I guess there's less to go
> wrong. It still needs the present working directory, which is a
> per-drive concept on this OS, but even bogus drives don't seem to
> produce an error (despite what the manual says).

Interesting.

> I'd still lean towards assuming errno is set, given that the manual
> references errno and not GetLastError().

Agreed. In the attached, I drop the _dosmaperr() step and instead
just do "errno = 0" before the call. That way, if we ever do manage
to hit a _fullpath() failure, we can at least tell whether the errno
that's reported is real or not.

In this version I've attempted to resolve Peter's complaint by only
applying realpath() when the executable path we've obtained is relative
or has a symlink as the last component. Things will definitely not
work right if either of those is true and we make no effort to get
a more trustworthy path. I concede that things will usually work okay
without resolving a symlink that's two or more levels up the path,
but I wonder how much we want to trust that. Suppose somebody changes
such a symlink while the server is running --- nothing very good is
likely to happen if it suddenly starts consulting some other libdir
or sharedir. Maybe we need to add a flag telling whether we want
this behavior? TBH I think that pg_config is the only place I'd
be comfortable with doing it like this. Peter, would your concerns
be satisfied if we just made pg_config do it?

regards, tom lane

Attachment Content-Type Size
use-realpath-in-find_my_exec-2.patch text/x-diff 10.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-10-04 18:09:31 Re: New strategies for freezing, advancing relfrozenxid early
Previous Message Nathan Bossart 2022-10-04 17:57:55 Re: Suppressing useless wakeups in walreceiver