fs.copyFile on Mac OS does not respect permissions

[akhoury]

• Version: v11.2.0
• Platform: Darwin iMac.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
• Subsystem:

When setting a file mode to 444 using chmodSync, then trying to copy another file over it, on Windows and on Linux, copyFile will throw an error, but on a Mac it does not, and it will override the file

fs.chmodSync(dest, '444');
// then try to 
fs.copyFile(source, dest, function (err) {
 // 	i do expect an err here, 
 // but there is no error on Mac
});

i even check the stat.mode using parseInt(fs.statSync(dest).mode.toString(8), 10) and it does in fact say 100444

This is a sample when everything is working well
https://repl.it/repls/CylindricalGlisteningCondition

However, when i run it on my mac, I get this

This platform is darwin
fs.stat.mode ./dest: 100444
/Users/akhoury/rcloned/code/NodeBB/rrr.js:26
 throw new Error(`This should've thrown an error!`);
 ^

Error: This should've thrown an error!

Thanks

[Trott]

I'm able to replicate this bug on Mojave. Seems like libuv is somehow running copyfile() with COPYFILE_UNLINK set or else there's a bug in macOS? @nodejs/fs @nodejs/libuv @nodejs/platform-macos

[Trott]

Confirmed with Node.js 8.x, 10.x, 11.x, and current master branch. (fs.copyFile() does not exist in Node.js 6.x.)

[Trott]

I tried adding this to libuv's fs.c file and recompiling but it didn't change anything...

 // Turn off unlinking of the destination file.
 // Refs: https://github.com/nodejs/node/issues/26936
 flags &= ~(1 << 21); /* COPYFILE_UNLINK */

(Of course, it's entirely likely I'm doing the bit math wrong or something simple like that.....)

[richardlau]

I'm able to replicate this bug on Mojave. Seems like libuv is somehow running copyfile() with COPYFILE_UNLINK set or else there's a bug in macOS? @nodejs/fs @nodejs/libuv @nodejs/platform-macos

I'm not a macOS person, but being able to bypass file permissions sounds like an OS bug.

[cjihrig]

This seems to be related to permissions and probably not a bug we can control. I'm also seeing no error by default, but if I run with sudo -u nobody then I get an EPERM error.

[Trott]

I'm not a macOS person, but being able to bypass file permissions sounds like an OS bug.

Yeah, definitely agree after playing around with different copyfile() flags inside libuv. Astonishingly, it seems that copyfile(3) on macOS does not respect file permissions. We can't be the first people to ever experience this, though... 🤔

[Trott]

libuv's fs.c has Apple-specific code for uv__fs_copyfile() added by @cjihrig in libuv/libuv#1465. Do you know if there was a reason other than "use analogous native functionality when you can" for using different code for macOS? Removing it all and using the code used by other UNIX-like operating systems fixes this problem. node continues to pass all tests too. So maybe that's the way to go?

[Trott]

libuv/libuv#2233