Test 'ncp / error / dest-permission' / 'should return an error:' fails inside a container

[dcermak]

• Operating System: openSUSE Tumbleweed, Fedora 33, Ubuntu
• Node.js version: 15, 16
• fs-extra version: git head

I am currently trying to run the unit tests of node-fs-extra in a container, but sadly the ncp / error / dest-permission / should return an error: test fails consistently with:

  1) ncp / error / dest-permission
       should return an error:
     Uncaught AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  assert(err)

      at /node-fs-extra/lib/copy/__tests__/ncp/ncp-error-perm.test.js:45:7
      at /node-fs-extra/node_modules/graceful-fs/polyfills.js:247:20
      at FSReqCallback.oncomplete (node:fs:184:23)

How to reproduce:

$ podman run --rm -it node /bin/bash
# git clone https://github.com/jprichardson/node-fs-extra.git
Cloning into 'node-fs-extra'...
remote: Enumerating objects: 5760, done.
remote: Counting objects: 100% (135/135), done.
remote: Compressing objects: 100% (102/102), done.
remote: Total 5760 (delta 56), reused 83 (delta 31), pack-reused 5625
Receiving objects: 100% (5760/5760), 1.17 MiB | 10.03 MiB/s, done.
Resolving deltas: 100% (3511/3511), done.
root@950ba24c05d3:/# cd node-fs-extra/
root@950ba24c05d3:/node-fs-extra# npm install
npm WARN deprecated har-validator@5.1.5: this library is no longer supported
npm WARN deprecated mkdirp@0.5.1: Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142

added 426 packages, and audited 427 packages in 15s

51 packages are looking for funding
  run `npm fund` for details

3 low severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.
npm notice
npm notice New minor version of npm available! 7.10.0 -> 7.11.2
npm notice Changelog: https://github.com/npm/cli/releases/tag/v7.11.2
npm notice Run npm install -g npm@7.11.2 to update!
npm notice
root@950ba24c05d3:/node-fs-extra# npm run unit

> fs-extra@10.0.0 unit
> node test.js



  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․,․․․․․․․․․․․․․․․․․․․․․
  ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․,․․․․․․․․․․․․․․․․․․․․․․․․․․․․․!․․․․․․․․․․․

  695 passing (8s)
  2 pending
  1 failing

  1) ncp / error / dest-permission
       should return an error:
     Uncaught AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  assert(err)

      at /node-fs-extra/lib/copy/__tests__/ncp/ncp-error-perm.test.js:45:7
      at /node-fs-extra/node_modules/graceful-fs/polyfills.js:247:20
      at FSReqCallback.oncomplete (node:fs:184:23)



npm notice
npm notice New minor version of npm available! 7.10.0 -> 7.11.2
npm notice Changelog: https://github.com/npm/cli/releases/tag/v7.11.2
npm notice Run npm install -g npm@7.11.2 to update!
npm notice

I have tried this on Fedora and openSUSE Tumbleweed hosts, with docker and podman and with multiple container images. I am not really familiar with the code, but my guess is that a different failure occurs inside a container in contrast to a bare metal system.

[RyanZim]

I'm guessing the issue is that the container filesystem does not support the full range of Unix file permissions. That test relies on setting a directory permission to 444:

node-fs-extra/lib/copy/__tests__/ncp/ncp-error-perm.test.js

Line 40 in fb6c0ca

fs.chmodSync(dest, 0o444)

If I were to guess, I'd say that call is somehow silently failing. To confirm, try modifying that file:

     fs.chmodSync(dest, 0o444)
+    console.warn(fs.statSync(dest).mode.toString(8))
 
     const subdest = path.join(dest, 'another-dir')

That should print the full file mode to the console; if the chmod is working correctly, it should end in 444, my guess is it won't.

[dcermak]

Ryan Zimmerman ***@***.***> writes:

That should print the full file mode to the console; if the `chmod` is working correctly, it should end in `444`, my guess is it won't.

The file mode is: 40444

[RyanZim]

OK, what's the output with this change?

     ncp(src, subdest, err => {
+      console.warn(fs.readdirSync(subdest))
       assert(err)

[dcermak]

Ryan Zimmerman ***@***.***> writes:

OK, what's the output with this change? ```diff ncp(src, subdest, err => { + console.warn(fs.readdirSync(subdest)) assert(err) ```

This: ․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․,․․․․․․․․․․․․․․․․․․․․․․․․․․․․․40444 [ 'some-file' ] !․․․․․․․․․․․

[RyanZim]

Well, that explains why the test fails. The test is supposed to ensure fs-extra properly passes up EACCESS errors, so we copying a file to directory that we don't have write permissions for, and verify the error is properly passed up. Only problem, somehow your container filesystem is allowing us to write to a directory we don't have write permissions to; I have no idea why that might be. Is this running as root or something odd?

[dcermak]

Ryan Zimmerman ***@***.***> writes:

Well, that explains why the test fails. The test is supposed to ensure `fs-extra` properly passes up `EACCESS` errors, so we copying a file to directory that we don't have write permissions for, and verify the error is properly passed up. Only problem, somehow your container filesystem is allowing us to write to a directory we don't have write permissions to; I have no idea why that might be. Is this running as root or something odd?

Nope, this is the node container from dockerhub running as a rootless container in podman. But it happens with other containers too and when using docker as well.

[RyanZim]

Must be something with the container filesystem that doesn't actually respect file permissions then.

[dcermak]

Ah, no, it's actually far simpler: by default everything inside the container runs as root, so it can create the directory, even if the user doesn't have the permissions.