1

A co-worker has encountered a strange issue where their containerized app, which is running under lowered privileges, sometimes crashes at startup with a mysterious EPERM: operation not permitted, open operation. Something is trying to write to a file under node_modules (node_modules/winston/lib/winston.js to be exact). That file exists but only with read permissions. Sadly this is intermittent, and I cannot reproduce locally. Given that winston is a popular logging library, I can't help but suspect malware is at play here.

Is there a way to find the source of failed FS write attempts? I would love to see a stack trace, for example. We've already tried NODE_DEBUG=fs, but that outputs no additional information.

Full and only output before the process exits:

Error: EPERM: operation not permitted, open '/src/node_modules/winston/lib/winston.js'
Code: EPERM
Jacob
  • 77,566
  • 24
  • 149
  • 228
  • Well, nobody should be trying to write to `node_modules/winston/lib/winston.js` inside of your app. That could happen if some code (outside of your actual app, but perhaps part of some startup procedure) was trying to update the Winston module to the latest version. Does it tell you which `fs` module function is being used? Are you absolutely sure that your nodejs program was running at the time and it wasn't some other process that was part of the startup procedure? – jfriend00 Apr 19 '22 at 01:53
  • Yes, it's definitely the nodejs program. At times in the container's shell I am able to re-run the application and reproduce the error. I'm not told which `fs` module function is used. The strange thing is after the issue occurs _once_ it doesn't happen again. – Jacob Apr 19 '22 at 01:59
  • Well, this isn't enough information to know how to proceed. Is this an unhandled exception? An unhandled promise rejection? Where does this information come from? What is the COMPLETE output you get? Does it cause the app to fail and exit? – jfriend00 Apr 19 '22 at 02:15
  • Posted the full output; there's nothing else _but_ that error, and the process exits. Now that you mention it, I'd think if this was an unhandled exception/rejection it'd say that in the output, right? Might need to dig into this `oclif` CLI nonsense it's using. – Jacob Apr 19 '22 at 02:24

1 Answers1

0

By using the DEBUG=* environment variable, we were able to get a stack trace for the error. It's just a regular old require(...) call causing this. We suspect this is probably a bug with the hosting infrastructure/containers/whatever, but in general DEBUG=* helps a lot if you're experiencing mysterious issues like this.

Jacob
  • 77,566
  • 24
  • 149
  • 228