Configuration des permissions pour nodejs

J'ai plusieurs applications fonctionnant sur mon server; ils sont construits dans meteor.js afin qu'ils soient process de nodejs et je les exécute en utilisant le module pour toujours npm;

Je lance actuellement pour toujours pour chacun d'eux en utilisant le même user dont le groupe possède tous les directorys de sites Web; Maintenant que cela va devenir un server de production, j'aimerais mieux comprendre les problèmes de security que cela peut causer; Existe-t-il des règles générales de security à suivre pour lancer le process nodejs? Est-ce que mon approche actuelle est peut-être dangereuse?

One Solution collect form web for “Configuration des permissions pour nodejs”

En supposant que votre application n'a pas besoin d'access en écriture aux données de l'application (ce qu'elle ne devrait vraiment pas), nous procédons comme suit:

Nous node-<app>-runtime les users en deux classs: node-<app>-runtime et node-<app>-data . <app> étant le nom de l'application. Ils font tous deux partie d'un groupe node-<app> . Ce ne sont pas les noms réels que nous utilisons pour les curieux là-bas.

Nous procédons comme suit:

1) Pour build l'application, nous construisons toujours sur une machine distincte, puis disposons d'un script npm dist qui ne place que les files nécessaires pour exécuter l'application dans un directory /dist et expédie une copy goudragée de ce directory à notre server de deployment. L'avantage de cela est double: nous soaps exactement ce qui se passe dans le deployment et nous pouvons nous assurer que tout dev-deps dans node_modules , .git directorys et autres données ne soit pas ajouté aux machines de production. Cela signifie également que lorsque GitHub / Npm / etc. diminue, il ne brise pas automatiquement la synchronisation automatique – notre server de deployment fournit le tarball pré-construit.

2) Nous utilisons notre système de gestion de configuration pour créer un directory log dans un location normalisé qui peut être écrit par node-<app>-runtime avec permissions 640. Le path d'access est fourni à l'application par une variable d'environnement standard. Notre démon de traitement de log les choisit automatiquement et les transmet à un server distant.

3) Notre système de deployment place les files d'application dans un endroit spécifique et les définit comme appartenant à node-<app>-data avec les permissions 640. Le path d'access est fourni à l'application par une variable d'environnement standard.

Le seul autre conseil que j'ai consiste à toujours vous assurer que vous définissez NODE_ENV=production . Beaucoup de modules de noeuds utilisent cette convention pour désactiver les symboles de debugging, ou pour améliorer les performances ( express vient à l'esprit).

  • Gestionnaire d'permissions de Windows Server 2008?
  • Pourquoi 777 cause un problème, mais 644 était bien
  • Accès aux files réseau à partir d'asp.net. De quelles permissions ai-je besoin?
  • Autorisations pour EC2 créées par Elastic Beanstalk se connectant à un RDS externe
  • Linux: force un set différent d'permissions de directory / file
  • Problème avec l'autorisation de dossier dans la migration du server de files - Partage des partages VS Autorisations NTFS
  • Le less d'permissions pour l'administration quotidienne de l'échange
  • Comment les permissions de partage et les permissions de security coopèrent-elles entre elles pour les partage de réseau?
  • Dossier partagé Windows 2003 Server
  • permission refusée lorsque le script tente de s'exécuter
  • Autorisations de fichier DSO Apache 777
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.