Интересно, вот что я получаю при выполнении вашего предложения (и это имеет полный смысл, если цель — получить доступ к любой внутренней библиотеке системы с произвольным пользователем, отличным от 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']
}
>
Как именно вы запускаете образ Discourse? Есть ли какие-либо дополнительные флаги для безопасности?
Мы используем контейнеризованное решение на базе OpenShift, в котором Discourse работает с произвольным идентификатором пользователя. На данный момент проблем не возникало, подход очень похож на официальное руководство по установке.
Конечно, мы можем обойти эту проблему, установив EMBER_CLI_PROD_ASSETS в значение 0; ассеты будут предварительно скомпилированы, как в старые времена, но рано или поздно, если ваши планы включают движение в этом направлении, это может стать реальной проблемой для подобных решений, если текущий процесс предварительной компиляции будет заброшен.
Поэтому у меня несколько вопросов:
- Есть ли у вас ориентировочная дата отказа (если это так) от предварительной компиляции ассетов старым способом?
- Есть ли способ получить доступ к механизму
osиным образом или рассмотреть другой подход, чтобы контейнеризованные решения с произвольными идентификаторами пользователей всё ещё могли работать?
Большое спасибо за внимание к этому вопросу, очень ценим.
С уважением,
Исмаэль