Isaac Morland <isaac.morland@gmail.com> writes:
> On Thu, 1 Sept 2022 at 19:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This code was mine originally (336969e49), but I sure don't
>> remember why I wrote it like that.
> Does this happen in a context where we need to worried about the directory
> structure changing under us, either accidentally or maliciously?
Well, one of the reasons it'd be a good idea to not change cwd is
that then you don't have to worry about that moving while you're
messing around. But everything else that we're considering here is
either a component of PATH or a directory/symlink associated with
the PG installation. If $badguy has control of any of that,
you've already lost, so I'm not excited about worrying about it.
> I'm wondering because I understand cd'ing through the structure can avoid
> some of the related problems and might be the reason for doing it that way
> originally.
Pretty sure I was not thinking about that. I might have been
thinking about AFS installations, which IIRC often have two nominal
paths associated with them. But I don't recall any details about how
that works, and anyway the comment says nothing about AFS.
> My impression is that the modern equivalent would be to use
> openat() with O_PATH to step through the hierarchy. But then I'm not clear
> on how to get back to the absolute path, given a file descriptor for the
> final directory.
Yeah. The point here is not to open a particular file, but to derive
a pathname string for where the file is.
What I'm thinking right at the moment is that we don't necessarily
have to have the exact path that getcwd() would report. We need
*some* path-in-absolute-form that works. This leads me to think
that both the AFS case and the mount-point case are red herrings.
But I can't shake the feeling that I'm missing something.
regards, tom lane