When a directory is replaced with a symlink at a critical moment, `chmod` will perform the unintended action of changing the mode of the linked-to file or directory. I tested in coreutils 8.26 on debian stretch, but believe that the current version 8.30 and the development version are vulnerable.
Basically, when chmodat is used here http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/chmod.c?id=694d10b71e418ef4ea68847185b73544fe03eae2#n273 it will dereference the symlink. Changing to lchmodat should resolve the problem, except that on GNU/Linux, it appears this works by passing AT_SYMLINK_NOFOLLOW to fchmodat, but that flag is noted as "not currently implemented" in the local man page ("release 4.10 of the Linux man-pages project"). Consequently, I'm not even sure there is a correct fix available on this common platform. Here are my steps to reproduce, which involve using gdb to pause the execution of chmod while the substitution is made, so that the window of opportunity is made as large as possible. I have followed the steps manually several times, so I hope they are correct and don't have any transcription errors. ### Note the ironic unsafe use of /tmp $ umask 077 $ mkdir -p /tmp/a/b/c; touch /tmp/a/b/c/d; touch /tmp/donttouchthis ### /tmp/donttouchthis is mode 0600 here $ ls -l /tmp/donttouchthis $ gdb --args chmod -R u=u /tmp/a (gdb) b fchmodat (gdb) run Breakpoint 1, fchmodat (fd=-100, file=0x5555557640f0 "/tmp/a", mode=493, (gdb) condition 1 !strcmp(file, "c") (gdb) continue Breakpoint 1, fchmodat (fd=5, file=0x55555576d6f8 "c", mode=493, flag=0) (gdb) shell cd /tmp/a/b && mv c noc && ln -s /tmp/donttouchthis c (gdb) continue /bin/chmod: cannot read directory '/tmp/a/b/c': Not a directory [Inferior 1 (process 13718) exited with code 01] (gdb) shell ls -l /tmp/donttouchthis ### donttouchthis is mode 0700 here, the old mode of /tmp/a/b/c! Note how the mode of /tmp/donttouchthis has been changed from 0600 to 0700, because it got the mode of the directory '/tmp/a/b/c'.