Устранение глобальной установки StriderCD приводит к сбою доступа к файлу $HOME/.config $HOME/.cache

Я пытаюсь разработать лучший способ установки StriderCD во всем мире. Я установил node и npm через глобальную вилку nvm, и все пути отлично работают для других сборок, но ни один из них не требует установки post, как это.

Я пробовал как sudo npm install -g strider, так и просто установил его как root без sudo, но я всегда сталкивался с ошибками EACCESS в папках .config и .cache для bower на этапе post install:

Установленный как root, у root нет прав для него собственный $HOME dir, что очень странно, если bower не создает dirs и файлы с неправильными разрешениями. Может кто-нибудь объяснить это:

Используя sudo как пользователь ubuntu и попробовав chmod -R 777 $HOME/.config, я получаю то же самое на $HOME/.cache! Вздох.

Почему gower настаивает на использовании $HOME/.config, когда я использую --global, а также устанавливаю с помощью sudo? Есть ли способ сопоставить это с другим путем и сделать соответствующие разрешения? И когда я su root -l для установки, почему у root нет разрешения на доступ к файлам или создание директорий внутри него $HOME и/или $HOME/.config? Очень запутанно.

Это новый обновленный экземпляр 14.04 LTS AWS. Какова основная причина этой ошибки, и является ли это моей настройкой, вызывающей проблему или плохую конфигурацию на стороне Bower или Strider?

Ответы

Ответ 1

Разрешения вашей файловой системы кажутся странными и должны быть исследованы и восстановлены.

Тем не менее, важной частью этой первой трассировки стека является configstore, единица техники, используемая для кеширования или сохранения данных для диск. Излишне говорить, что он попытается написать в эти места. Это место для начала.

Проблемы с разрешениями вызываются в FAQ нового модуля conf, хотя, похоже, это не относится к Linux.

В configstore конфигурация хранится в ~/.config(которая в основном является соглашением Linux) для всех систем, а конфиг конфига в системном каталоге конфигурации по умолчанию. Как оказалось, каталог ~/.config часто имеет неправильное разрешение на macOS и Windows, что вызвало много горя для пользователей.

Переключение на conf устраняет проблему? Может быть, может и нет. Невозможно повредить создать файл. Это довольно тривиальная замена. И вы можете, конечно, взломать внутри своего node_modules, чтобы проверить, исправляет ли он его для вас.

Оба configstore и conf соблюдать переменную XDG_CONFIG_HOME envrionment. Однако они читают его в несколько раз, первый - в модуле require(), последний - при его создании.

Мы также должны оспаривать допущение процессов, выполняемых как конкретный пользователь (root), так как Node программы могут process.setuid(), и это относительно распространено среди инструментов командной строки.

Я бы изменил различные файлы node_modules, которые запускались и посыпались в некоторых...

console.log('User:', process.getuid());
console.log('Group:', process.getgid());
console.log('Effective user:', process.geteuid());
console.log('Effective group:', process.getegid());

Это полезно, потому что либо bower, либо npm может быть понижающим разрешения в неудобное время. Или возможно что-то внутри npm run build script делает это.

Если вы видите, что пользователи или группы меняются на протяжении всего жизненного цикла программы, это высокая потенциальная область ошибок. Внимательно проверьте, что у пользователей или групп есть полный доступ к неудачным путям. В зависимости от точной активности, может потребоваться иметь разрешения на выполнение (x) в родительских каталогах, вплоть до корня файловой системы.