Domanda Come evitare di usare sudo quando si lavora in / var / www?


Voglio smettere di doverlo usare sudo ogni volta che lavoro /var/www. Come lo posso fare? Voglio semplicemente mettere tutti i miei siti in questa directory e lavorare con loro senza troppa pena.


162
2018-06-01 03:43


origine


Stai usando Apache? - Rinzwind
Dopo aver letto qui, questo può anche aiutare nella parte di autorizzazione: askubuntu.com/questions/20105/... - Luis Alvarado♦
Un altro modo per ottenere la sicurezza è continuare a usare sudo -u www-data ma limitati a te stesso sudoers file per essere in grado di sudo www-data (e non sudo root). Vedere serverfault.com/questions/295429/... - Simon Woodside


risposte:


La maggior parte delle risposte qui non sono state scritte pensando alla sicurezza. È bello avere la sensazione di correre sudo ogni volta non è molto saggio. Se fai un refuso (ad es.non eseguire) sudo rm -rf / var/www/dir), potresti cestinare il tuo sistema.

Nota: A partire da Apache 2.4.7 / Ubuntu 14.04, /var/www è stato spostato a /var/www/html Regolare i comandi in questa risposta di conseguenza.

Vedere:

Cattive idee:

  • chmod 777 (sagarchalise) - questo permette a chiunque abbia accesso al tuo sistema di scrivere nelle directory e nei file e quindi consentire all'intruso di eseguire qualsiasi codice sotto il www-data utente
  • chgrp -R www-data $HOME (pannocchia) - questo consente www-data leggere o scrivere qualsiasi file nella home directory. Questo non tiene conto della regola del Least Privilege
  • chown -R $USER:$USER /var/www (kv1dr) - a meno che il mondo non abbia le autorizzazioni di lettura /var/www, il server web in esecuzione www-data non sarà in grado di leggere (servire) i file. Se il file è un documento HTML semplice accessibile al pubblico, potrebbe non essere un problema se il mondo può leggere il file. Ma se il file è un file PHP contenente password, lo è.

NOTA: nelle soluzioni di seguito, ho concesso www-data scrivere i privilegi. Però, /usr/share/doc/base-passwd/users-and-groups.txt.gz stati:

www-data

Alcuni server Web funzionano come www-data. I contenuti Web non dovrebbero essere di proprietà di questo     utente, o un server Web compromesso sarebbe in grado di riscrivere un sito web. Dati     scritti dai server web saranno di proprietà di www-data.

Dove possibile, fallo non concedere permessi di scrittura al file www-data gruppo. www-data deve solo essere in grado di leggere i file in modo che il webserver possa servirlo. L'unico caso in cui www-data ha bisogno di permessi di scrittura è per le directory che memorizzano i caricamenti e altre posizioni che devono essere scritte.

Soluzione 1

Aggiungi te stesso al www-data raggruppa e imposta il bit setgid su /var/www directory tale che tutti i file appena creati ereditano anche questo gruppo.

sudo gpasswd -a "$USER" www-data

Correggi i file creati in precedenza (assumendo che tu sia l'unico utente di /var/www):

sudo chown -R "$USER":www-data /var/www
find /var/www -type f -exec chmod 0660 {} \;
sudo find /var/www -type d -exec chmod 2770 {} \;

(ancora più sicuro: usare 640 o 2750 e manualmente chmod g+w file-or-dir che deve essere scritto dal webserver)

Soluzione 2

Crea un link simbolico per ogni progetto nella tua home directory. Supponi che il tuo progetto si trovi a ~/projects/foo e vuoi averlo localizzato in /var/www/foo, correre:

sudo ln -sT ~/projects/foo /var/www/foo

Se la tua home directory non ha un bit di esecuzione (discendente) impostato per other (per motivi di sicurezza), cambiare il gruppo di esso in www-data, ma imposta solo il bit di esecuzione (nessuna lettura / scrittura). Fai lo stesso per il ~/projectscartella in quanto potrebbe contenere altri progetti oltre a www. (Non hai bisogno sudo se in precedenza hai aggiunto il tuo utente a www-data gruppo.)

sudo chgrp www-data ~ ~/projects
chmod 710 ~ ~/projects

Imposta il gruppo su www-data sopra ~/projects/foo e consentire al server web di leggere e scrivere su file e file + directory e scendere nelle directory:

sudo chgrp www-data ~/projects/foo
find ~/projects/foo -type f -exec chmod 660 {} \;
find ~/projects/foo -type d -exec chmod 2770 {} \;

Ancora più sicuro: usa 640 e 2750 per impostazione predefinita e modifica manualmente i file e le directory che devono essere modificabili dall'utente del webserver. Il bit setgid dovrebbe essere aggiunto solo se si desidera che ogni file appena creato in ~/projects/foo essere accessibile dal gruppo.

D'ora in poi, puoi accedere al tuo sito all'indirizzo http://localhost/foo e modifica i tuoi file di progetto in ~/projects/foo.

Guarda anche


229
2018-06-01 09:48



Cosa ne pensi di una sessione www in un terminale di sudo su www-data? Combinato con un prompt di colore diverso, per rendere più ovvio che è la shell di un utente diverso, e una politica per mettere sempre il corrispondente xterm su - per esempio - il desktop virtuale 4, in modo da abituarsi ad esso, a evitare la confusione? - user unknown
@user unknown: se fai tutto nel terminale, hai una chiara separazione tra account utente. Ma non funzionerà se si utilizza un programma con interfaccia grafica come gedit. Non ho mai studiato se eseguire un programma GUI con un altro utente nella sessione corrente sia sicuro o meno, sarebbe una domanda interessante. - Lekensteyn
@imaginaryRobots: se avessi intenzione di pubblicare soluzioni diverse per ogni domanda, Askubuntu sarebbe pieno di risposte di tre righe. Lo terrò così com'è, a meno che tu non riesca a convincermi a dividerlo. - Lekensteyn
@berbt setfacl -d u::rwX,g::rX /var/www ha l'effetto buffo che la modalità predefinita diventa 0750 (o 0640) anche se umask è zero. Potrebbe essere una buona idea se si vogliono evitare i file scrivibili in tutto il mondo, ma se /var/www è già inaccessibile dal mondo non è necessario. - Lekensteyn
C'è un problema con l'inversione del processo in soluzione 1? Con ciò intendo, /var/www/app01 ha la proprietà app01:app01e poi il www-data  utente è aggiunto al app01  gruppo? O si romperà qualcosa? - Jack_Hu


Anziché archiviare i miei siti Web in / var / www, inserisco i collegamenti ai siti che si trovano nella mia cartella home. Posso modificare liberamente o aggiungere pagine ai miei siti. Quando sono felice con i cambiamenti, ho poi FTP per una società di hosting in cui il mio nome di dominio si collega.


7
2018-06-01 07:06



Questa è un'idea sensata. - thomasrutter


Se rendi / var / www scrivibile dal suo gruppo e aggiungi te stesso al gruppo, non dovrai usare sudo pur essendo abbastanza sicuro. Prova questo:

sudo adduser <username> www-data
sudo chown -R www-data:www-data /var/www
sudo chmod -R g+rw /var/www

Dovresti quindi essere in grado di modificare /var/www/ file senza problemi.

La prima linea ti aggiunge al www-data gruppo, la seconda riga cancella tutti i file con proprietà incasinate, e la terza fa in modo che tutti gli utenti che sono membri della www-data gruppo può leggere e scrivere tutti i file in /var/www.


6
2017-07-01 00:41



Questa è una pessima idea per la sicurezza e questo consiglio non dovrebbe essere seguito, per ragioni spiegate in altre risposte. www-data dovrebbe essere un senza privilegi gruppo, senza accesso in scrittura. - thomasrutter


cosa non fare

  • Non impostare i permessi sui file su 777 (Mondo-scrivibile)

    Si tratta di un difetto di sicurezza significativo, soprattutto se si abilitano gli script sul lato server come PHP. I processi non privilegiati non dovrebbero essere in grado di scrivere su file che potrebbero influire sul sito Web o, nel caso di script sul lato server in uso, eseguire codice arbitrario.

  • Non aggiungerti come membro del www-data raggruppare e dargli permessi di scrittura

    Lo scopo di quel gruppo è che è un senza privilegi gruppo che il processi del server correre come. Dovrebbero solo avere accesso in lettura ai file del sito Web ove possibile, per gli stessi motivi di cui sopra.

  • Non modificare le autorizzazioni dei processi di Apache

    I processi figlio di Apache vengono eseguiti come www-data utente e gruppo per impostazione predefinita, e questo non dovrebbe essere modificato. Questo è solo un modo per non concedere loro permessi di scrittura sul filesystem.

    In determinate circostanze si desidera che gli script sul lato server siano in grado di scrivere sui file, nel qual caso solo questi file dovrebbero essere resi scrivibili da www-data e occorre prestare attenzione per garantire la sicurezza.

dos

  • Imposta i file di tua proprietà

    Se sei l'unico, o il solito, a modificare determinati file sul sito web, allora ha perfettamente senso assumere la proprietà di quei file. Imposta il loro proprietario a <your username>.

    Non è necessario modificare le autorizzazioni del server per questo, poiché il server continuerà ad ottenere l'accesso di sola lettura anche quando i file sono di proprietà dell'utente.

  • Scegli un posto sensato dove alloggiare i file (usando DocumentRoot)

    Se /var/www non ha senso, siete invitati a metterli altrove. Se sono specifici per il tuo sviluppo o test, puoi metterli nella tua home directory. O puoi impostare alcune directory in /srv.

  • Se vuoi dare gruppo accesso in scrittura, creare a nuovo gruppo per lo scopo

    Non riutilizzare un gruppo di sistemi, poiché questi sono in genere progettati per avere l'accesso che hanno attualmente e, non più, per ragioni di sicurezza.


5
2017-11-23 23:43





È così semplice Non è necessario abilitare apache 'UserDir' (sconsigliato) né fare confusione con i gruppi 'www-data' (gruppo apache nel caso in Fedora)

Basta creare la directory del progetto all'interno /var/www/html

cd /var/www/html
sudo mkdir my_project

Quindi chown la directory del progetto al tuo utente.

sudo chown your_username my_project

Ora puoi iniziare a lavorare sulla cartella del tuo progetto come utente normale con qualsiasi editor, IDE di tua scelta. Non piu sudos :)


5
2017-08-06 07:49



+1 Questo è quello che faccio: cambia la proprietà non di /var/www stesso, ma di sottodirectory. - fkraiem


chmod in / var su www per consentire l'accesso al proprietario e chown per assicurarsi di possederlo. Probabilmente un'idea stupida, ma funzionerebbe sicuramente.


1
2018-06-01 03:59



Non è un'idea stupida, è un'idea ragionevole per quanto riguarda la sicurezza. Nota: non è necessario (e non dovrebbe) modificare le autorizzazioni di /var, appena /var/www e / o il suo contenuto. - thomasrutter


Puoi avviare una sessione www in un terminale

sudo su www-data

Combinato con un prompt di colore diverso *, per rendere più ovvio che è la shell di un utente diverso, e una politica sempre per mettere il corrispondente xterm (e editor e così via) - per esempio - il desktop virtuale 4, in modo che ci si abitua, per evitare confusione.

*) Per un prompt di colore diverso con un carattere diverso, creare un file / etc / prompt come questo:

# PROMPTING
#       When  executing  interactively, bash displays the primary prompt PS1 when it is ready to read a command, and the sec-
#       ondary prompt PS2 when it needs more input to complete a command.  Bash allows these prompt strings to be  customized
#       by inserting a number of backslash-escaped special characters that are decoded as follows:
#              \a     an ASCII bell character (07)
#              \d     the date in "Weekday Month Date" format (e.g., "Tue May 26")
#              \D{format}
#                     the  format is passed to strftime(3) and the result is inserted into the prompt string; an empty format
#                     results in a locale-specific time representation.  The braces are required
#              \e     an ASCII escape character (033)
#              \h     the hostname up to the first `.'
#              \H     the hostname
#              \j     the number of jobs currently managed by the shell
#              \l     the basename of the shell's terminal device name
#              \n     newline
#              \r     carriage return
#              \s     the name of the shell, the basename of $0 (the portion following the final slash)
#              \t     the current time in 24-hour HH:MM:SS format
#              \T     the current time in 12-hour HH:MM:SS format
#              \@     the current time in 12-hour am/pm format
#              \A     the current time in 24-hour HH:MM format
#              \u     the username of the current user
#              \v     the version of bash (e.g., 2.00)
#              \V     the release of bash, version + patchelvel (e.g., 2.00.0)
#              \w     the current working directory
#              \W     the basename of the current working directory
#              \!     the history number of this command
#              \#     the command number of this command
#              \$     if the effective UID is 0, a #, otherwise a $
#              \nnn   the character corresponding to the octal number nnn
#              \\     a backslash
#              \[     begin a sequence of non-printing characters, which could be used to embed a terminal  control  sequence
#                     into the prompt
#              \]     end a sequence of non-printing characters
#
#       The  command  number and the history number are usually different: the history number of a command is its position in
#       the history list, which may include commands restored from the history file (see HISTORY below),  while  the  command
#       number  is  the  position in the sequence of commands executed during the current shell session.  After the string is
#
# colors:
# \[...\]   wird benötigt, damit die shell weiß, daß hier kein printable output ist, und die Umbrüche richtig plaziert.
#
# ANSI COLORS
CRE="\[
[K\]"
NORMAL="\[[0;39m\]"
# RED: Failure or error message
RED="\[[1;31m\]"
# GREEN: Success message
GREEN="\[[1;32m\]"
# YELLOW: Descriptions
YELLOW="\[[1;33m\]"
# BLUE: System messages
BLUE="\[[1;34m\]"
# MAGENTA: Found devices or drivers
MAGENTA="\[[1;35m\]"
# CYAN: Questions
CYAN="\[[1;36m\]"
# BOLD WHITE: Hint
WHITE="\[[1;37m\]"
#
# default:
# postgres, oracle, www-data
#
# PS1=$BLUE"machine]->"$NORMAL\\w"$BLUE ø $NORMAL"
PS1=$BLUE"machine]:"$NORMAL\\w"$BLUE > $NORMAL"
#
# root, stefan:
#
case "$UID" in
    '0')
        PS1=$RED"machine:"$NORMAL\\w"$RED # $NORMAL"
    ;;
    '1000')
    PS1=$GREEN"machine:"$BLUE\\w$YELLOW" > "$NORMAL
    ;;
#    default)
#    ;;
esac

e provenire da /etc/bash.bashrc per esempio.

Come strumento aggiuntivo per aiutare la distinzione, puoi sempre modificare i tuoi file con un alias "edit" o un link simbolico, che punta, a seconda della tua identità (taylor / www-data) a gedit o mousepad, vim o pico. Oppure potresti usare diversi profili di editor, almeno in gedit puoi ad esempio impostare le tue preferenze su testo nero su fondo bianco o testo bianco su fondo nero.

Ho solo una tale politica per lavorare come root, quindi non sono sicuro di quanto possa adattarsi a lavorare con www-data. Combinato con ssh-sessions a diversi host, che hanno i loro prompt, non mi ha impedito di essere a volte sbagliato, ma se succede, mi rendo conto velocemente, cosa è sbagliato, e succede raramente.

nota: lo script di richiesta è in parte una copia della manpage di bash.


1
2018-06-01 15:49



Ciò funzionerà e non sarà (se usato con attenzione) impatto negativo sulla sicurezza, ma potrebbe non essere la soluzione più semplice. È una soluzione valida per alcune persone però. - thomasrutter


Sopra questa pagina del mio sito Copro i comandi per cambiare il permesso in /var/www tra apache e l'utente pi ma è essenziale

sudo chown -R pi /var/www

poi un riavvio di apache

sudo service apache2 restart

-1
2017-11-23 23:27



Link funziona ora - Gadgetroid