XFS reports lchmod failure, but changes file system contents

[Florian Weimer <fw at deneb dot enyo dot de>]

In principle, Linux supports lchmod via O_PATH descriptors and chmod
on /proc/self/fd.  (lchmod is the non-symbolic-link-following variant
of chmod.)

This helper program can be used to do this:

#define _GNU_SOURCE
#include <err.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <unistd.h>

int
main (int argc, char **argv)
{
  if (argc != 3)
    {
      fprintf (stderr, "usage: %s MODE FILE\n", argv[0]);
      return 2;
    }

  unsigned int mode;
  if (sscanf (argv[1], "%o", &mode) != 1
      || mode != (mode_t) mode)
    errx (1, "invalid mode: %s", argv[1]);

  int fd = open (argv[2], O_PATH | O_NOFOLLOW);
  if (fd < 0)
    err (1, "open");

  char *fd_path;
  if (asprintf (&fd_path, "/proc/self/fd/%d", fd) < 0)
    err (1, "asprintf");

  if (chmod (fd_path, mode) != 0)
    err (1, "chmod");

  free (fd_path);
  if (close (fd) != 0)
    err (1, "close");

  return 0;
}

When changing the permissions of on XFS in this way, the chmod
operation fails:

$ ln -s does-not-exist /var/tmp/symlink
$ ls -l /var/tmp/symlink 
lrwxrwxrwx. 1 fweimer fweimer 14 Feb 12 12:41 /var/tmp/symlink -> does-not-exist
$ strace ./lchmod 0 /var/tmp/symlink
[…]
openat(AT_FDCWD, "/var/tmp/symlink", O_RDONLY|O_NOFOLLOW|O_PATH) = 3
[…]
chmod("/proc/self/fd/3", 000)           = -1 EOPNOTSUPP (Operation not supported)
write(2, "lchmod: ", 8lchmod: )                 = 8
write(2, "chmod", 5chmod)                    = 5
write(2, ": Operation not supported\n", 26: Operation not supported
) = 26
exit_group(1)                           = ?

But the file system contents has changed nevertheless:

$ ls -l /var/tmp/symlink 
l---------. 1 fweimer fweimer 14 Feb 12 12:41 /var/tmp/symlink -> does-not-exist
$ echo 3 | sudo tee /proc/sys/vm/drop_caches 
$ ls -l /var/tmp/symlink 
l---------. 1 fweimer fweimer 14 Feb 12 12:41 /var/tmp/symlink -> does-not-exist

This looks like an XFS bug to me.  With tmpfs, the chmod succeeds and
is reflected in the file system.

This bug also affects regular files, not just symbolic links.

It causes the io/tst-lchmod glibc test to fail (after it has been
fixed, the in-tree version has another bug).