3.4.0 portability regression because of openat(AT_FDCWD

[solardiz]

The 3.4.0 release blindly assumes that openat and AT_FDCWD are available when certain other things are, but this is not the case e.g. on ancient glibc. This fixes build on glibc 2.3.6:

+++ rsync-3.4.0/syscall.c	2025-01-15 03:21:50 +0000
@@ -734,7 +734,7 @@ int secure_relative_open(const char *bas
 		return -1;
 	}
 
-#if !defined(O_NOFOLLOW) || !defined(O_DIRECTORY)
+#if !defined(O_NOFOLLOW) || !defined(O_DIRECTORY) || !defined(AT_FDCWD)
 	// really old system, all we can do is live with the risks
 	if (!basedir) {
 		return open(relpath, flags, mode);

Just like the O_* checks here, this added check relies on AT_FDCWD being a macro (rather than e.g. part of an enum) on systems where it's present - I don't know whether that is guaranteed or perhaps not.

It's unfortunate that this fallback code keeps some of the security issues exposed - perhaps this is worth warning about somewhere beyond the source code comment? For example, maybe configure should fail on such systems by default, and require an "accept risks" option to override that.

[freakout42]

#ifdef HAVE_LINKAT has to be used here:

#else
  int dirfd = AT_FDCWD;
  if (basedir != NULL) {
    dirfd = openat(AT_FDCWD, basedir, O_RDONLY | O_DIRECTORY);
    if (dirfd == -1) {
      return -1;
    }
  }
  int retfd = -1;

[ncopa]

#ifdef HAVE_LINKAT has to be used here:

#else
  int dirfd = AT_FDCWD;
  if (basedir != NULL) {
    dirfd = openat(AT_FDCWD, basedir, O_RDONLY | O_DIRECTORY);
    if (dirfd == -1) {
      return -1;
    }
  }
  int retfd = -1;

Technically there should be a HAVE_OPENAT. Using AT_FD_CWD works and is better than use HAVE_LINKAT IMHO.