Re: [PATCH] Re: `pwd -P` with systemd-homed causes inconsistent cwd state

[Bart Schaefer <schaefer@brasslantern.com>]

On Wed, Nov 1, 2023 at 7:54 PM Kyle Laker <kyle@laker.email> wrote:
>
> It seems like this does in fact fix the case where _both_ HAVE_GETCWD
> and USE_GETCWD are false; however, in 5.9, even if HAVE_GETCWD is true,
> USE_GETCWD is false (and this same setup can be induced on master where
> the same behavior happens). In that case, the new error handling is
> never hit because after zgetdir() now returns NULL, getcwd() is called
> as a fallback (which sets ret so the subsequent logic to use pwd isnt
> hit).

The only possible case I can think of where we'd want to fall back on
getcwd() after zgetdir() returns NULL, is here:

363    if (stat(".", &sbuf) < 0) {
364        return NULL;
365    }

Somehow getcwd() might bypass whatever restriction caused this to
fail?  In all other cases we've chdir'd away from the current
directory and can't get back.  I'm tempted to say we should just
delete that entire fallback, but then we never use getcwd() at all.
Maybe we should be checking errno (for what?) as well as ret before
falling back to getcwd()?  Or maybe when USE_GETCWD, we should use it
preferentially, and zgetdir() should be the fallback?

Or maybe zgetdir() itself should USE_GETCWD there at line 364?

The whole situation seems a bit strange.  In utils.c:lchdir() we have
calls to zgetdir() in both an #ifndef HAVE_FCHDIR and later an #ifdef
HAVE_CHDIR branch.