Re: [PATCH] linux: make getcwd(3) fail if it cannot obtain an absolute path [BZ #22679]

[Florian Weimer <fweimer at redhat dot com>]

On 01/07/2018 04:05 AM, Dmitry V. Levin wrote:
> As the underlying getcwd syscall, starting with linux commit
> v2.6.36-rc1~96^2~2, may succeed without returning an absolute path,
> check for the path returned by syscall and fail with EACCES if the path
> is not absolute.

This appears to cause a failure in a gluster component:

https://lists.gluster.org/pipermail/gluster-users/2018-January/033293.html

I have a longer strace, but it is quite difficult to read because of the 
way chdir is used in a multi-threaded process.

What seems to happen is that we execve rsync with a current directory 
that has been lazily unmounted.  The current directory after the execve 
is unreachable from theroot, and we run into this rsync failure path

/* Like chdir(), but it keeps track of the current directory (in the
 * global "curr_dir"), and ensures that the path size doesn't overflow.
 * Also cleans the path using the clean_fname() function. */
int change_dir(const char *dir, int set_path_only)
{
	static int initialised, skipped_chdir;
	unsigned int len;

	if (!initialised) {
		initialised = 1;
		if (getcwd(curr_dir, sizeof curr_dir - 1) == NULL) {
			rsyserr(FERROR, errno, "getcwd()");
			exit_cleanup(RERR_FILESELECT);
		}
		curr_dir_len = strlen(curr_dir);
	}

during initialization of the rsync process.  This happens even if the 
current directory is never used because all rsync paths are absolute, 
and also with --ignore-missing-args:

There has been another issue in this area:

http://lists.gluster.org/pipermail/gluster-users/2017-April/030534.html

This was worked around with --ignore-missing-args, but rsync never gets 
to this point after the getcwd change.

I don't see how we can avoid fixing rsync (probably by caching the 
getcwd failure during initialization and reporting it only if the 
directory is used afterwards).

Any comments?

Thanks,
Florian