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

[Kyle Laker <kyle@laker.email>]

On 10/30/23 23:46, Bart Schaefer wrote:
> On Sun, Oct 22, 2023 at 11:59 AM Bart Schaefer 
> <schaefer@brasslantern.com> wrote:
>> 
>> So this reaches the "return NULL" at the end of zgetdir(), after 
>> the comment "Something bad happened." ?

>> Or conversely this is a consequence of zgetdir() not checking the 
>> return value from zchdir(), which it doesn't in a couple of 
>> places?

This is caused by not checking the return value. zgetdir() is returning
`buf + pos` so the error handling logic for `!ret` in zgetcwd() isn't hit.

> Lacking a response to this and unable to test this directly, I offer
>  the following patch, which attempts to cover all those cases.

Sorry for the delay. This patch does ensure that zgetdir() returns NULL
when the current working directory is clobbered. So it does fix that
part of the issue.

> I forced HAVE_GETCWD to be false and ran make check with no issues.

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). But because at that point cwd has been lost by zgetdir()/zchdir(),
calling getcwd() just returns "/" so the value isn't useful. `pwd -P`
will print "/" but no error message.

With this patch so long as HAVE_GETCWD == USE_GETCWD it seems like
things work as expected; however, if USE is false and HAVE is true,
there are still issues with losing the working directory without
printing the error message.