Intersting, this is what I’m getting when executing your suggestion (and makes total sense if the intention is to access any internal library system with a random user other than root):
node
Welcome to Node.js v16.13.2.
Type ".help" for more information.
> const os = require('os');
undefined
> os.userInfo().shell
Uncaught:
SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory)
at __node_internal_captureLargerStackTrace (node:internal/errors:464:5)
at new SystemError (node:internal/errors:233:5)
at new NodeError (node:internal/errors:336:7)
at Object.userInfo (node:os:347:11) {
code: 'ERR_SYSTEM_ERROR',
info: {
errno: -2,
code: 'ENOENT',
message: 'no such file or directory',
syscall: 'uv_os_get_passwd'
},
errno: [Getter/Setter: -2],
syscall: [Getter/Setter: 'uv_os_get_passwd']
}
>
How exactly are you running the Discourse image? Are there any extra flags for security?
We’ve been using a containerized solution based in OpenShift, in which Discourse is running with a random user id. No issues so far, approach very similar to the official install guide.
It’s certainly that we can bypass this issue by setting EMBER_CLI_PROD_ASSETS
to 0
, assets are precompiled as in the old days, but sooner than later, if your plans are to move into this direction, can pose a real problem for this kind of solutions if the current precompiling process is abandoned.
So a couple of questions here:
- Do you have an ETA about abandoning (if that’s the case) precompiling assets the old way?
- Is there any way to access the
os
machinery on a different way, or consider a different approach, so that containerized solutions with random user id’s can still work?
Many thanks for looking into this, much appreciated.
Cheers,
Ismael