2014-11-17 16 views
8

Sto usando Sails.js 0.10.5 sul nodo 0.10.33 su Ubuntu Trusty. Mi piacerebbe eseguire il processo del nodo come utente non root con i minimi privilegi possibili nell'ambiente di produzione. Sono a mio agio con le varie opzioni per il binding alle porte inferiori a 1024, ma sono più interessato ai permessi delle directory.Eseguire sails.js con i privilegi minimi nella produzione

Idealmente, preferirei che il processo del nodo avesse solo accesso in scrittura ai suoi file di registro e nient'altro. Dovrebbe avere solo accesso in lettura alla directory contenente app.js e sotto.

Al momento è necessario concedere l'accesso in scrittura alla directory ./.tmp e anche alla directory ./views a causa delle attività grunt eseguite all'avvio. Preferirei eseguire le attività grunt al momento della distribuzione come utente diverso anziché in fase di esecuzione. Il comando sails www è apparso promettente ma non ho potuto ottenere il risultato desiderato.

Qualcuno può indicarmi la direzione giusta per l'esecuzione di Sails.js con accesso in scrittura zero alle sue risorse, visualizzazioni, ecc.?

+0

Sembra semplicemente creare un utente (con autorizzazioni particolari per determinate directory) ed eseguire 'node' (o avviare l'app) come dovrebbe funzionare quell'utente. Hai provato? – Whymarrh

+0

'sudo -u foo grunt something' e' sudo -u bar node app.js' (o simile)? – Whymarrh

+0

@Whymarrh Per quanto ho capito, l'esecuzione di 'node app.js' per l'applicazione basata su Sails avvia quindi' grunt' come processo figlio come lo stesso account utente. Se qualcuno sa come separare l'auto-esecuzione del grugnito da Sails, questo aiuterebbe a rispondere alla mia domanda. –

risposta

2

La soluzione più semplice per me sembra essere quella di separare le attività di grunt che richiedono i privilegi elevati in un file separato che è possibile chiamare con un utente diverso in fase di distribuzione. Quindi le vele non avranno bisogno di eseguire nulla e possono essere solo letti.

1

MODIFICATO: utilizzo PM2 con apache come proxy (con mod WS).

È possibile utilizzare un proxy come apache per il routing dalla porta 80 ad altre porte del server interno in base all'host.

Con questo modo è possibile eseguire più app nello stesso server.

Ha un sacco di funzioni utili come vedere i registri come varie applicazioni nel terminale, riavviare e registrare app in crash, eseguire app come utente, stato app ... ecc.

Pm2 link: https://github.com/Unitech/pm2

PM2 configurazioni: https://github.com/Unitech/PM2/blob/development/ADVANCED_README.md#options

+0

Sto usando PM2 in alcuni posti e per sempre in altri. In entrambi i casi, è sufficiente garantire che l'applicazione del nodo continui a funzionare in caso di errore.Questi strumenti non hanno alcun impatto sulle autorizzazioni richieste dall'applicazione nodo. –

+0

sì, ma è possibile utilizzarlo con un proxy come apache o nginx –

+0

Come per il primo paragrafo della mia domanda, la porta di supporto 80 con autorizzazioni limitate è un problema risolto tramite un proxy come Apache o Nginx, o tramite mappatura porta iptables, oppure tramite cap_net_bind_service. Sto puntando a eseguire l'applicazione nodo con accesso in scrittura zero ai suoi file sorgente. –

4

Usa sails www per costruire beni statici

chmod -R 440 tutti i file e le directory, in modo che l'utente e il server web (gruppo) può accedere ai file.

Utilizzare nginx/apache per ospitare un server Web sulla porta 80/443 e le richieste proxy alle vele (in esecuzione sulla propria porta o su un socket unix).

Eseguire le vele utilizzando PM2 per tenerlo in esecuzione e farlo gestire/raccogliere i registri.

Le vele si solleveranno, ma non saranno in grado di scrivere la sua directory .tmp, che non dovrebbe nemmeno essere necessaria poiché tutti i file statici verranno indirizzati alla directory www tramite nginx/apache.

+0

Inoltre, è possibile spostare la directory www fuori dalle vele e farla appartenere al server web. – user3590543

+0

Sembra fattibile. Stai suggerendo che sails.js si solleverà e continuerà a funzionare anche se non riesce a scrivere nella sua directory .tmp? Ho anche scoperto che vele/grunt stavano cercando di scrivere nella directory ./views/. –

Problemi correlati